Forwarding this to PGI support. This thread is archived at
http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/5059 .
* Paul Eggert wrote on Thu, Dec 29, 2005 at 10:35:24PM CET:
> Claudio Fontana <[EMAIL PROTECTED]> writes:
>
> >> pgcc -DHAVE_CONFIG_H -I. -I. -I.. -g -c regex.c
> >> PGC-F-0249-#error -- "Add case for new bitset_word
> >> size" (./regex_internal.h: 186)
> >> PGC/x86-64 Linux/x86-64 5.2-1: compilation aborted
> >
> > I do not know whether this is something that should be
> > acted upon, or if the compiler in question is not
> > doing the right thing.
>
> It sounds like the compiler is buggy, and this should be acted upon.
I think so, too.
> What is the value of ULONG_MAX on that host? Your user can find out
> by compiling the following little program with "pgcc -g -E":
>
> #include <limits.h>
> "ULONG_MAX = " ULONG_MAX
"ULONG_MAX = " ( 9223372036854775807L * 2UL + 1UL )
This is pgcc 6.0-8 64-bit target on x86-64 Linux, but as indicated
above, the issue is present in 5.2-1 as well.
> > Could this be related to 64bit quantities being used
> > in preprocessor constant expressions?
>
> Yes, possibly the pgcc preprocessor mishandles 64-bit numbers.
Yep. Here's a small self-contained example to expose the fact that the
preprocessor does not do correct 64bit unsigned arithmetic:
/* snip */
#include <limits.h>
#include <stdio.h>
#define BITSET_WORD_MAX ULONG_MAX
int main(void)
{
#if BITSET_WORD_MAX >> 31 >> 31 >> 1 == 1
#else
puts("preprocessor is buggy");
#endif
printf("ULONG_MAX = %llu\nsizeof(ulong) = %lu\n", ULONG_MAX, sizeof(unsigned
long));
printf("%llu\n", BITSET_WORD_MAX >> 31 >> 31 >> 1);
return 0;
}
/* snip */
It outputs
| preprocessor is buggy
| ULONG_MAX = 18446744073709551615
| sizeof(ulong) = 8
| 1
Cheers,
Ralf
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
