AC_COMPILE_CHECK_SIZEOF

AC_COMPILE_CHECK_SIZEOF

[Jones Desougi]

AC_COMPILE_CHECK_SIZEOF (in config/accross.m4) takes an optional argument
and uses it for two incompatible purposes. One is additional sizes to try
and the other is additional code sent to AC_TRY_COMPILE.
This affects mainline and the 3.4 branch. The gcc_AC_COMPILE_CHECK_SIZEOF
that was in 3.3.x used two optional arguments for this.
The optional argument does not appear to be used anywhere at this time.

This patch takes the approach of the old macro and applies to both
mainline and 3.4 branch:

2004-09-05  Jones Desougi  <jones@ingate.com>

	* accross.m4 (AC_COMPILE_CHECK_SIZEOF): Split self conflicting
	optional argument into two.


Index: config/accross.m4
===================================================================
RCS file: /cvsroot/gcc/gcc/config/accross.m4,v
retrieving revision 1.3
diff -u -r1.3 accross.m4
--- config/accross.m4	9 Mar 2004 01:16:10 -0000	1.3
+++ config/accross.m4	5 Sep 2004 14:42:49 -0000
@@ -7,7 +7,7 @@
 changequote([, ])dnl
 AC_MSG_CHECKING(size of $1)
 AC_CACHE_VAL(AC_CV_NAME,
-[for ac_size in 4 8 1 2 16 12 $2 ; do # List sizes in rough order of prevalence.
+[for ac_size in 4 8 1 2 16 12 $3 ; do # List sizes in rough order of prevalence.
   AC_TRY_COMPILE([#include "confdefs.h"
 #include <sys/types.h>
 $2

Re: AC_COMPILE_CHECK_SIZEOF

[Zack Weinberg]

Jones Desougi <jones@ingate.com> writes:

> AC_COMPILE_CHECK_SIZEOF (in config/accross.m4) takes an optional argument
> and uses it for two incompatible purposes. One is additional sizes to try
> and the other is additional code sent to AC_TRY_COMPILE.
> This affects mainline and the 3.4 branch. The gcc_AC_COMPILE_CHECK_SIZEOF
> that was in 3.3.x used two optional arguments for this.
> The optional argument does not appear to be used anywhere at this time.

For mainline, I think it would be better if you cut us over to
plain AC_CHECK_SIZEOF, which works correctly when cross-compiling in
autoconf 2.5x.

For 3.4, we'd need to know that there was an actual problem before
changing anything.  Did you encounter a problem?

zw

Re: AC_COMPILE_CHECK_SIZEOF

[Jones Desougi]

> For mainline, I think it would be better if you cut us over to
> plain AC_CHECK_SIZEOF, which works correctly when cross-compiling in
> autoconf 2.5x.

That isn't a simple one line fix though. :-)

A brief glance suggests that it may not be that much more, but that
there are subtle differences in behaviour.
Interestingly enough, libjava and fastjar appears to have moved in the
other direction in 2002, for the latter as part of cross-compiling support.

How about starting off with the simple patch to fix the broken macro?

> For 3.4, we'd need to know that there was an actual problem before
> changing anything.  Did you encounter a problem?

There should be no bad effects of this bug for current 3.4.

      /Jones

Re: AC_COMPILE_CHECK_SIZEOF

[Zack Weinberg]

Jones Desougi <jones@ingate.com> writes:

>> For mainline, I think it would be better if you cut us over to
>> plain AC_CHECK_SIZEOF, which works correctly when cross-compiling in
>> autoconf 2.5x.
>
> That isn't a simple one line fix though. :-)

Yes, well, mainline is the place for not-simple-one-line-fixes.
Although, we are on the threshold of stage 3 of development, so this
might be better held for 3.6.

Does this bug cause any problems in mainline?

> A brief glance suggests that it may not be that much more, but that
> there are subtle differences in behaviour.  Interestingly enough,
> libjava and fastjar appears to have moved in the other direction in
> 2002, for the latter as part of cross-compiling support.

In 2002 we were still using autoconf 2.13, which didn't support cross
compilation nearly as well.

zw

Re: AC_COMPILE_CHECK_SIZEOF

[Giovanni Bajo]

Zack Weinberg wrote:

>>> For mainline, I think it would be better if you cut us over to
>>> plain AC_CHECK_SIZEOF, which works correctly when cross-compiling in
>>> autoconf 2.5x.
>>
>> That isn't a simple one line fix though. :-)
>
> Yes, well, mainline is the place for not-simple-one-line-fixes.
> Although, we are on the threshold of stage 3 of development, so this
> might be better held for 3.6.

Why? I thought that Stage 3 was for fixing bugs, even if you need to
rearrange the code or do non trivial changes. It is the release branch where
we fix only regressions, and possibly with one liners.
Am I wrong?

Giovanni Bajo

Re: AC_COMPILE_CHECK_SIZEOF

[Zack Weinberg]

"Giovanni Bajo" <rasky@develer.com> writes:

> Zack Weinberg wrote:
>
>>>> For mainline, I think it would be better if you cut us over to
>>>> plain AC_CHECK_SIZEOF, which works correctly when cross-compiling in
>>>> autoconf 2.5x.
>>>
>>> That isn't a simple one line fix though. :-)
>>
>> Yes, well, mainline is the place for not-simple-one-line-fixes.
>> Although, we are on the threshold of stage 3 of development, so this
>> might be better held for 3.6.
>
> Why? I thought that Stage 3 was for fixing bugs, even if you need to
> rearrange the code or do non trivial changes. It is the release
> branch where we fix only regressions, and possibly with one liners.
> Am I wrong?

No, you're not wrong.  But keep in mind that my impression here is
that there is no actual bug, although I'm not sure why the original
poster wants to change the macro in that case.  As such, I'm being
rather more conservative about what's an okay change than I might.

If the 2.5x AC_CHECK_SIZEOF were a drop-in replacement for our
AC_COMPILE_CHECK_SIZEOF - and it certainly ought to be - then I'd be
fine with that change during stage 3 even if it fixed no user-visible
bugs (since the archaic kludges in the configure script are themselves
bugs).  And if there are semantic differences, I still might be fine
with changing it and fixing up whatever fallout results, but we have
to proceed with somewhat more caution.

zw

Re: AC_COMPILE_CHECK_SIZEOF

[Jones Desougi]

> Yes, well, mainline is the place for not-simple-one-line-fixes.
> Although, we are on the threshold of stage 3 of development, so this
> might be better held for 3.6.

Right, the place but not always.

> Does this bug cause any problems in mainline?

It's a latent bug. Perhaps you do not consider such worth fixing.
In that case we disagree.

In retrospect I would make a minor change to how the original patch resolves
the issue, but that's academic if another way altogether is prefered.

The obvious difference between AC_CHECK_SIZEOF and AC_COMPILE_CHECK_SIZEOF
is that if type is unknown the former sets the size to zero while the latter
issues an error. AC_CHECK_SIZEOF also has a simple sanity check on its first
argument, demanding a literal.
Would you approve a patch that cuts over to AC_CHECK_SIZEOF?

    /Jones

Re: AC_COMPILE_CHECK_SIZEOF

[Zack Weinberg]

Jones Desougi <jones@ingate.com> writes:

>> Yes, well, mainline is the place for not-simple-one-line-fixes.
>> Although, we are on the threshold of stage 3 of development, so this
>> might be better held for 3.6.
>
> Right, the place but not always.
>
>> Does this bug cause any problems in mainline?
>
> It's a latent bug. Perhaps you do not consider such worth fixing.

When there's no immediate problem, I would prefer to replace it with
the stock AC_CHECK_SIZEOF or else leave it alone.

> The obvious difference between AC_CHECK_SIZEOF and AC_COMPILE_CHECK_SIZEOF
> is that if type is unknown the former sets the size to zero while the latter
> issues an error. AC_CHECK_SIZEOF also has a simple sanity check on its first
> argument, demanding a literal.
> Would you approve a patch that cuts over to AC_CHECK_SIZEOF?

Yes, as long as it comes fairly soon.

zw

Re: AC_COMPILE_CHECK_SIZEOF

[Jones Desougi]

>> Would you approve a patch that cuts over to AC_CHECK_SIZEOF?
> 
> Yes, as long as it comes fairly soon.

Ok, this one does just that.

Regenerating the files in libffi (with automake 1.8.5) also seems to
get one automake version (1.8.3) out of the tree.


2004-09-12  Jones Desougi  <jones@ingate.com>

	* accross.m4 (AC_COMPILE_CHECK_SIZEOF): Removed.

	* configure.ac: Replace local AC_COMPILE_CHECK_SIZEOF with the
	standard AC_CHECK_SIZEOF macro.


Index: config/accross.m4
===================================================================
RCS file: /cvsroot/gcc/gcc/config/accross.m4,v
retrieving revision 1.3
diff -u -r1.3 accross.m4
--- config/accross.m4	9 Mar 2004 01:16:10 -0000	1.3
+++ config/accross.m4	13 Sep 2004 00:41:51 -0000
@@ -1,29 +1,3 @@
-AC_DEFUN([AC_COMPILE_CHECK_SIZEOF],
-[changequote(<<, >>)dnl
-dnl The name to #define.
-define(<<AC_TYPE_NAME>>, translit(sizeof_$1, [a-z *], [A-Z_P]))dnl
-dnl The cache variable name.
-define(<<AC_CV_NAME>>, translit(ac_cv_sizeof_$1, [ *], [_p]))dnl
-changequote([, ])dnl
-AC_MSG_CHECKING(size of $1)
-AC_CACHE_VAL(AC_CV_NAME,
-[for ac_size in 4 8 1 2 16 12 $2 ; do # List sizes in rough order of prevalence.
-  AC_TRY_COMPILE([#include "confdefs.h"
-#include <sys/types.h>
-$2
-], [switch (0) case 0: case (sizeof ($1) == $ac_size):;], AC_CV_NAME=$ac_size)
-  if test x$AC_CV_NAME != x ; then break; fi
-done
-])
-if test x$AC_CV_NAME = x ; then
-  AC_MSG_ERROR([cannot determine a size for $1])
-fi
-AC_MSG_RESULT($AC_CV_NAME)
-AC_DEFINE_UNQUOTED(AC_TYPE_NAME, $AC_CV_NAME, [The number of bytes in type $1])
-undefine([AC_TYPE_NAME])dnl
-undefine([AC_CV_NAME])dnl
-])
-
 AC_DEFUN([AC_C_BIGENDIAN_CROSS],
 [AC_CACHE_CHECK(whether byte ordering is bigendian, ac_cv_c_bigendian,
 [ac_cv_c_bigendian=unknown
Index: fastjar/configure.ac
===================================================================
RCS file: /cvsroot/gcc/gcc/fastjar/configure.ac,v
retrieving revision 1.5
diff -u -r1.5 configure.ac
--- fastjar/configure.ac	19 Jul 2004 20:08:20 -0000	1.5
+++ fastjar/configure.ac	13 Sep 2004 00:41:51 -0000
@@ -37,11 +37,11 @@
 gcc_AC_FUNC_MKDIR_TAKES_ONE_ARG
 
 dnl Check for type-widths
-AC_COMPILE_CHECK_SIZEOF(char)
-AC_COMPILE_CHECK_SIZEOF(short)
-AC_COMPILE_CHECK_SIZEOF(int)
-AC_COMPILE_CHECK_SIZEOF(long)
-AC_CHECK_TYPES([long long],[AC_COMPILE_CHECK_SIZEOF(long long)])
+AC_CHECK_SIZEOF(char)
+AC_CHECK_SIZEOF(short)
+AC_CHECK_SIZEOF(int)
+AC_CHECK_SIZEOF(long)
+AC_CHECK_TYPES([long long],[AC_CHECK_SIZEOF(long long)])
 
 dnl Check byte order
 AC_C_BIGENDIAN_CROSS
Index: gcc/configure.ac
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/configure.ac,v
retrieving revision 2.65
diff -u -r2.65 configure.ac
--- gcc/configure.ac	11 Sep 2004 04:26:36 -0000	2.65
+++ gcc/configure.ac	13 Sep 2004 00:41:58 -0000
@@ -289,15 +289,15 @@
 gcc_AC_C_LONG_LONG
 
 # sizeof(char) is 1 by definition.
-AC_COMPILE_CHECK_SIZEOF(void *)
-AC_COMPILE_CHECK_SIZEOF(short)
-AC_COMPILE_CHECK_SIZEOF(int)
-AC_COMPILE_CHECK_SIZEOF(long)
+AC_CHECK_SIZEOF(void *)
+AC_CHECK_SIZEOF(short)
+AC_CHECK_SIZEOF(int)
+AC_CHECK_SIZEOF(long)
 if test $ac_cv_c_long_long = yes; then
-  AC_COMPILE_CHECK_SIZEOF(long long)
+  AC_CHECK_SIZEOF(long long)
 fi
 if test $ac_cv_c___int64 = yes; then
-  AC_COMPILE_CHECK_SIZEOF(__int64)
+  AC_CHECK_SIZEOF(__int64)
 fi
 
 # ---------------------
Index: libffi/configure.ac
===================================================================
RCS file: /cvsroot/gcc/gcc/libffi/configure.ac,v
retrieving revision 1.7
diff -u -r1.7 configure.ac
--- libffi/configure.ac	30 Aug 2004 15:43:00 -0000	1.7
+++ libffi/configure.ac	13 Sep 2004 00:42:56 -0000
@@ -109,8 +109,8 @@
 AC_CHECK_FUNCS(memcpy)
 AC_FUNC_ALLOCA
 
-AC_COMPILE_CHECK_SIZEOF(double)
-AC_COMPILE_CHECK_SIZEOF(long double)
+AC_CHECK_SIZEOF(double)
+AC_CHECK_SIZEOF(long double)
 
 # Also AC_SUBST this variable for ffi.h.
 HAVE_LONG_DOUBLE=0
Index: libjava/configure.ac
===================================================================
RCS file: /cvsroot/gcc/gcc/libjava/configure.ac,v
retrieving revision 1.7
diff -u -r1.7 configure.ac
--- libjava/configure.ac	8 Sep 2004 19:57:13 -0000	1.7
+++ libjava/configure.ac	13 Sep 2004 00:42:59 -0000
@@ -1122,7 +1122,7 @@
 
 CPPFLAGS=$GCJ_SAVE_CPPFLAGS
 
-AC_COMPILE_CHECK_SIZEOF(void *)
+AC_CHECK_SIZEOF(void *)
 
 ZLIBS=
 SYS_ZLIBS=

Re: AC_COMPILE_CHECK_SIZEOF

[Zack Weinberg]

Jones Desougi <jones@ingate.com> writes:

>>> Would you approve a patch that cuts over to AC_CHECK_SIZEOF?
>> 
>> Yes, as long as it comes fairly soon.
>
> Ok, this one does just that.
>
> Regenerating the files in libffi (with automake 1.8.5) also seems to
> get one automake version (1.8.3) out of the tree.

I approve the changes to the gcc subdir.  The Java maintainers must be
consulted on the changes to fastjar,libffi,libjava, and the top level
configury maintainers on the changes to config/.  I see no reason why
this cannot go in piecemeal.

zw

Re: AC_COMPILE_CHECK_SIZEOF

[DJ Delorie]

> I approve the changes to the gcc subdir.  The Java maintainers must be
> consulted on the changes to fastjar,libffi,libjava, and the top level
> configury maintainers on the changes to config/.  I see no reason why
> this cannot go in piecemeal.

The config/* part is rejected.  BFD uses AC_COMPILE_CHECK_SIZEOF.

Now, if you can get BFD to stop using it also...