Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ?? - Solaris

This is a discussion on Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ?? - Solaris ; I'm having a hard time tying to build gcc 4.3.1 on Solaris using the GNU
compilers. I then decided to try to use Sun's compiler. The Sun Studio
12 compiler reports the following code, which is in the source
(gcc-4.3.1/gcc/c-common.c) ...

Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

I'm having a hard time tying to build gcc 4.3.1 on Solaris using the GNU
compilers. I then decided to try to use Sun's compiler. The Sun Studio
12 compiler reports the following code, which is in the source
(gcc-4.3.1/gcc/c-common.c) of gcc 4.3.1, is a syntax error.

I'm inclined to agree, as it is like no C I have ever met.

what is "C_COMMON_FIXED_TYPES (, fract);" supposed to mean? Could it be
written in a different way so the Sun compiler could understand it? Or
are Sun at fault?

So is this really C, or is it just a GNU ism, which prevents the GNU C
compiler compiling with a compiler able to compiler C ?? I thought one
was supposed to need a C compiler to compile gcc, but perhaps I was
mistaken.

Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

On 2008-06-10 07:37:28 +0100, Dave said:
> I'm having a hard time tying to build gcc 4.3.1 on Solaris using the
> GNU compilers. I then decided to try to use Sun's compiler. The Sun
> Studio 12 compiler reports the following code, which is in the source
> (gcc-4.3.1/gcc/c-common.c) of gcc 4.3.1, is a syntax error.
>
>
> I'm inclined to agree, as it is like no C I have ever met.

The ## stuff is normal ISO C token pasting, so SAT ## NAME ##
_type_node would get pre-processed as fract_type_node if SAT was not
set and NAME was fract.
> what is "C_COMMON_FIXED_TYPES (, fract);" supposed to mean? Could it
> be written in a different way so the Sun compiler could understand it?
> Or are Sun at fault?

I don't have time to check this carefully, but as far as I can see, it
does not crash. I should have posted a bit more I think. I posted
stdout, but did npt post stderr. I've put that below, but the only
difference is the error message I previously posted.

Even IF the code is legal, it is not easy to understand. I see no reason
to try to obviscate the code, unless one is entering a competition for
such a challenge.

Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

Dave wrote:
> I'm having a hard time tying to build gcc 4.3.1 on Solaris using the GNU
> compilers. I then decided to try to use Sun's compiler. The Sun Studio
> 12 compiler reports the following code, which is in the source
> (gcc-4.3.1/gcc/c-common.c) of gcc 4.3.1, is a syntax error.
>
>
> I'm inclined to agree, as it is like no C I have ever met.
>
>
> what is "C_COMMON_FIXED_TYPES (, fract);" supposed to mean? Could it be
> written in a different way so the Sun compiler could understand it? Or
> are Sun at fault?
>
>
> I'd certainly never write C code like this, but perhaps it is legal.
>
>
>
> #define C_COMMON_FIXED_MODE_TYPES(SAT,NAME) \

This macro has a different name from

>
> C_COMMON_FIXED_TYPES (, fract); /* line 2254 */

this one.

Se if you can find the correct macro definition. The errors you posted
later indicated that the preprocessor barfed, so the -E output isn't
much use.

Thank you for clearing that up. You would think they have more sence
than to do

IMHO, the gcc developers could do a lot worst than to stop adding
features and sort out why it builds so badly on many platforms - Solaris
is not the only one to have issues with gcc.

Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

In article <484fbfa8$0$87940$892e0abb@auth.newsreader.octanews .com> Thad Smith writes:
....
> The code invokes the macro with a missing first argument. That is valid
> C99, but undefined in C90 (see the recent CLC thread on "empty macro
> arguments").
>
> It seems amazing that GCC would require C99 features to compile.

Not realy true. GCC uses the GCC compiler extensions (that in this case
emerged in C99). It is well known that during the bootstrap process the
latter stages are in general not compilable by native compilers.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

Yes, you're right. This is a bug: empty macro arguments were
undefined in C89, but it was a common extension even then. I'll fix
this.

Andrew.

Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

Dave wrote:
> Thad Smith wrote:
>> Dave wrote:
>>> I'm having a hard time tying to build gcc 4.3.1 on Solaris using the
>>> GNU compilers. I then decided to try to use Sun's compiler. The Sun
>>> Studio 12 compiler reports the following code, which is in the source
>>> (gcc-4.3.1/gcc/c-common.c) of gcc 4.3.1, is a syntax error.
>>
>>> #define C_COMMON_FIXED_MODE_TYPES(SAT,NAME) \
>>> if (type1 == SAT ## NAME ## _type_node \
>>> || type1 == SAT ## u ## NAME ## _type_node) \
>>> return unsignedp ? SAT ## u ## NAME ## _type_node \
>>> : SAT ## NAME ## _type_node;
>>>
>>> C_COMMON_FIXED_TYPES (, fract); /* line 2254 */
>>> C_COMMON_FIXED_TYPES (sat_, fract);
>>> C_COMMON_FIXED_TYPES (, accum);
>>> C_COMMON_FIXED_TYPES (sat_, accum);
>>
>> The code invokes the macro with a missing first argument. That is
>> valid C99, but undefined in C90 (see the recent CLC thread on "empty
>> macro arguments").
>>
>> It seems amazing that GCC would require C99 features to compile.
>>
>
>
> Thank you for clearing that up. You would think they have more sence
> than to do
>
> IMHO, the gcc developers could do a lot worst than to stop adding
> features and sort out why it builds so badly on many platforms - Solaris
> is not the only one to have issues with gcc.
>
Sun cc is a C99 compiler (you can try using it in C99 mode by using the
c99 rather than cc driver).

--
Ian Collins.

Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

In gnu.gcc.help Andrew Haley wrote:
> In gnu.gcc.help Thad Smith wrote:
>
>> The code invokes the macro with a missing first argument. That is valid
>> C99, but undefined in C90 (see the recent CLC thread on "empty macro
>> arguments").
>
> Yes, you're right. This is a bug: empty macro arguments were
> undefined in C89, but it was a common extension even then. I'll fix
> this.

I have fixed it, and I have added a warning to gcc so that
if anyone ever uses empty macro arguments in the gcc source
the build will abort, even when building with gcc.

Andrew.

Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

Andrew Haley wrote:
> In gnu.gcc.help Andrew Haley wrote:
>> In gnu.gcc.help Thad Smith wrote:
>>
>>> The code invokes the macro with a missing first argument. That is valid
>>> C99, but undefined in C90 (see the recent CLC thread on "empty macro
>>> arguments").
>> Yes, you're right. This is a bug: empty macro arguments were
>> undefined in C89, but it was a common extension even then. I'll fix
>> this.
>
> I have fixed it, and I have added a warning to gcc so that
> if anyone ever uses empty macro arguments in the gcc source
> the build will abort, even when building with gcc.
>
> Andrew.

It's good to hear it is fixed, but there seems to be an overall problem
with gcc in that features are added, but it is difficult to build on
non-Linux systems. Building on SPARC is no easy task, with one having to
go to great lengths to find the right version of gcc to build it with
(Sun's compilers are incapable of building gcc).

Is it any wonder that places that keep Solaris binaries (Blastwave,
Sunfreeware) don't regularly update gcc like they do other programs. It
must seems too difficult/problematic to build, so people don't bother.

Just me 2p worth

Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

In gnu.gcc.help Dave wrote:
> Andrew Haley wrote:
>> In gnu.gcc.help Andrew Haley wrote:
>>> In gnu.gcc.help Thad Smith wrote:
>>>
>>>> The code invokes the macro with a missing first argument. That is valid
>>>> C99, but undefined in C90 (see the recent CLC thread on "empty macro
>>>> arguments").
>>> Yes, you're right. This is a bug: empty macro arguments were
>>> undefined in C89, but it was a common extension even then. I'll fix
>>> this.
>>
>> I have fixed it, and I have added a warning to gcc so that
>> if anyone ever uses empty macro arguments in the gcc source
>> the build will abort, even when building with gcc.
>
> It's good to hear it is fixed, but there seems to be an overall
> problem with gcc in that features are added, but it is difficult to
> build on non-Linux systems. Building on SPARC is no easy task, with
> one having to go to great lengths to find the right version of gcc
> to build it with (Sun's compilers are incapable of building gcc).

Well, that's bad. Our official position is that gcc needs an ISO-C89
compiler to build, and any use of language extensions to C89 in gcc
sources is a bug.

For any problem bootstrapping gcc with Sun's compilers the question is
whether Sun's tools are deficient in some way or gcc is incorrect. In
this particular case there wasn't any question, so I fixed gcc.
> Is it any wonder that places that keep Solaris binaries (Blastwave,
> Sunfreeware) don't regularly update gcc like they do other
> programs. It must seems too difficult/problematic to build, so
> people don't bother.

We want people to be able to build gcc on their systems. However some
ports are unmaintained simply because no gcc maintainer uses them.
The only way we can fix that is to ask people who do use these systems
to help us.

Andrew.

Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

Andrew Haley wrote:
> In gnu.gcc.help Dave wrote:
>> Andrew Haley wrote:
>>> In gnu.gcc.help Andrew Haley wrote:
>>>> In gnu.gcc.help Thad Smith wrote:
>>>>
>>>>> The code invokes the macro with a missing first argument. That is valid
>>>>> C99, but undefined in C90 (see the recent CLC thread on "empty macro
>>>>> arguments").
>>>> Yes, you're right. This is a bug: empty macro arguments were
>>>> undefined in C89, but it was a common extension even then. I'll fix
>>>> this.
>>> I have fixed it, and I have added a warning to gcc so that
>>> if anyone ever uses empty macro arguments in the gcc source
>>> the build will abort, even when building with gcc.
>> It's good to hear it is fixed, but there seems to be an overall
>> problem with gcc in that features are added, but it is difficult to
>> build on non-Linux systems. Building on SPARC is no easy task, with
>> one having to go to great lengths to find the right version of gcc
>> to build it with (Sun's compilers are incapable of building gcc).
>
> Well, that's bad. Our official position is that gcc needs an ISO-C89
> compiler to build, and any use of language extensions to C89 in gcc
> sources is a bug.
>
> For any problem bootstrapping gcc with Sun's compilers the question is
> whether Sun's tools are deficient in some way or gcc is incorrect. In
> this particular case there wasn't any question, so I fixed gcc.
>
>> Is it any wonder that places that keep Solaris binaries (Blastwave,
>> Sunfreeware) don't regularly update gcc like they do other
>> programs. It must seems too difficult/problematic to build, so
>> people don't bother.
>
> We want people to be able to build gcc on their systems. However some
> ports are unmaintained simply because no gcc maintainer uses them.
> The only way we can fix that is to ask people who do use these systems
> to help us.

Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

Andrew Haley wrote:
> Well, that's bad. Our official position is that gcc needs an ISO-C89
> compiler to build, and any use of language extensions to C89 in gcc
> sources is a bug.
>
> For any problem bootstrapping gcc with Sun's compilers the question is
> whether Sun's tools are deficient in some way or gcc is incorrect. In
> this particular case there wasn't any question, so I fixed gcc.
>
>> Is it any wonder that places that keep Solaris binaries (Blastwave,
>> Sunfreeware) don't regularly update gcc like they do other
>> programs. It must seems too difficult/problematic to build, so
>> people don't bother.
>
> We want people to be able to build gcc on their systems. However some
> ports are unmaintained simply because no gcc maintainer uses them.
> The only way we can fix that is to ask people who do use these systems
> to help us.
>
> Andrew.

I've reported bugs before, but nothing seems to happen. As it gets more
and more difficult to build, which it seems to do with every version,
you are less and less likely to find anyone willing to help maintain it.

If you have someone willing, I don't mind giving someone access to a Sun
Ultra 60 via SSH.

It's a real pain to try to find a compiler and set of options for gcc's
configure script which work.

For example, lets try 4.3.1 with no options to configure and see how far
it gets:

gcc used to pick up header files in /usr/local/include, so I would
expect it to find /usr/local/include/mpfr.h, which does exist, is the
only one around, and a late enough version.

$ ../gcc-4.3.1/configure
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking target system type... sparc-sun-solaris2.10
checking for a BSD-compatible install... ../gcc-4.3.1/install-sh -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gnatbind... no
checking for gnatmake... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16
checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... no
configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.0+.
Try the --with-gmp and/or --with-mpfr options to specify their locations.
Copies of these libraries' source code can be found at their respective
hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
See also http://gcc.gnu.org/install/prerequisites.html for additional info.
If you obtained GMP and/or MPFR from a vendor distribution package, make
sure that you have installed both the libraries and the header files.
They may be located in separate packages.

As you can see, it does not get too far. Messing around with almost
endless options to configure, and endless versions of gcc, one might get
it to build. But its far from straightforward.

The latest gcc I've managed to build is 4.2.0 and that did not work too
well.

I've stuck config.log below from my attempt at 4.3.1, just for your
interest.

Dave

-----------

$ more config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.59. Invocation command line was

Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

In gnu.gcc.help Dave wrote:
> Andrew Haley wrote:
>
>> Well, that's bad. Our official position is that gcc needs an ISO-C89
>> compiler to build, and any use of language extensions to C89 in gcc
>> sources is a bug.
>>
>> For any problem bootstrapping gcc with Sun's compilers the question is
>> whether Sun's tools are deficient in some way or gcc is incorrect. In
>> this particular case there wasn't any question, so I fixed gcc.
>>
>>> Is it any wonder that places that keep Solaris binaries (Blastwave,
>>> Sunfreeware) don't regularly update gcc like they do other
>>> programs. It must seems too difficult/problematic to build, so
>>> people don't bother.
>>
>> We want people to be able to build gcc on their systems. However some
>> ports are unmaintained simply because no gcc maintainer uses them.
>> The only way we can fix that is to ask people who do use these systems
>> to help us.
> I've reported bugs before, but nothing seems to happen. As it gets
> more and more difficult to build, which it seems to do with every
> version, you are less and less likely to find anyone willing to help
> maintain it.

Sure, I'm not denying that's a problem. The only way to make sure
that gcc gets fixed on these systems is to find someone who has one
and wants to keep gcc running on it.
> If you have someone willing, I don't mind giving someone access to a
> Sun Ultra 60 via SSH.
>
> It's a real pain to try to find a compiler and set of options for
> gcc's configure script which work.
>
> For example, lets try 4.3.1 with no options to configure and see how
> far it gets:
>
> checking for correct version of mpfr.h... no
> configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.0+.
> Try the --with-gmp and/or --with-mpfr options to specify their locations.
> Copies of these libraries' source code can be found at their respective
> hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
> See also http://gcc.gnu.org/install/prerequisites.html for additional info.
> If you obtained GMP and/or MPFR from a vendor distribution package, make
> sure that you have installed both the libraries and the header files.
> They may be located in separate packages.

I'm not sure why you think there's a problem here: gcc requires gmp
and mpfr, and if they aren't in the default include path for the
system, configure won't find them.

configure is telling you how to solve the problem. How could this be
done better?

Andrew.

Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

Andrew Haley wrote:
> I'm not sure why you think there's a problem here: gcc requires gmp
> and mpfr, and if they aren't in the default include path for the
> system, configure won't find them.
>
> configure is telling you how to solve the problem. How could this be
> done better?
>
> Andrew.

I was under the impression it would look in /usr/local/include for
header files, but looking closer I see that it is not in the compiler
search path.

Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

Dave wrote:
> Andrew Haley wrote:
>
>> I'm not sure why you think there's a problem here: gcc requires gmp
>> and mpfr, and if they aren't in the default include path for the
>> system, configure won't find them.
>>
>> configure is telling you how to solve the problem. How could this be
>> done better?
>>
>> Andrew.
>
>
> I was under the impression it would look in /usr/local/include for
> header files, but looking closer I see that it is not in the compiler
> search path.

Since /usr/local is not part of Solaris (it's a BSD thing) is there any
reason why gcc should look for it?

Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

On 2008-07-10 07:02:07 -0700, Andrew Haley said:
> In gnu.gcc.help Dave wrote:
>> Andrew Haley wrote:
>>> In gnu.gcc.help Andrew Haley wrote:
>>>> In gnu.gcc.help Thad Smith wrote:
>>>>
>>>>> The code invokes the macro with a missing first argument. That is valid
>>>>> C99, but undefined in C90 (see the recent CLC thread on "empty macro
>>>>> arguments").
>>>> Yes, you're right. This is a bug: empty macro arguments were
>>>> undefined in C89, but it was a common extension even then. I'll fix
>>>> this.
>>>
>>> I have fixed it, and I have added a warning to gcc so that
>>> if anyone ever uses empty macro arguments in the gcc source
>>> the build will abort, even when building with gcc.
>>
>> It's good to hear it is fixed, but there seems to be an overall
>> problem with gcc in that features are added, but it is difficult to
>> build on non-Linux systems. Building on SPARC is no easy task, with
>> one having to go to great lengths to find the right version of gcc
>> to build it with (Sun's compilers are incapable of building gcc).
>
> Well, that's bad. Our official position is that gcc needs an ISO-C89
> compiler to build, and any use of language extensions to C89 in gcc
> sources is a bug.
>
> For any problem bootstrapping gcc with Sun's compilers the question is
> whether Sun's tools are deficient in some way or gcc is incorrect. In
> this particular case there wasn't any question, so I fixed gcc.
>
>> Is it any wonder that places that keep Solaris binaries (Blastwave,
>> Sunfreeware) don't regularly update gcc like they do other
>> programs. It must seems too difficult/problematic to build, so
>> people don't bother.
>
> We want people to be able to build gcc on their systems. However some
> ports are unmaintained simply because no gcc maintainer uses them.
> The only way we can fix that is to ask people who do use these systems
> to help us.

How ironic, building GCC on SunOS/Solaris used to be one of the
canonical GCC ports. Now a release can come out and no one even
bothers to test bootstrapping it with Sun Studio 12 anymore?

I am trying to build 4.3.1 on Solaris 9 SPARC and am running into this
exact same problem (using Sun Studio 12 to do the initial bootstrap
phase).

One thing I hadn't seen mentioned in this thread is the "-xc99"
switch to Sun Studio 12's "cc", but trying this (CC="cc -xc99" before
"configure") still fails, in one of two ways:

(1) If you try using "-xc99" Sun's compilers treat it as "-xc99=all",
and they don't support "-xc99=libs" (part of "all") on Solaris 9.

(2) If you try using "-xc99=all,no_lib" it "compiles" but again returns
the same error as the O.P. got, i.e. it looks like this directive was
essentially a NOP instruction. Same thing for "-xc99=none" as well.

It looks like there is no way to trick the Sun Studio 12 C compiler to
compile that one "gcc/c-common.c" file due to this macro. Not on
Solaris 9 for SPARC, at least.

When can we see this "fix" you speak of, Andrew? Do we have to wait
for GCC 4.3.2? (I don't speak CVS)