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

**Chris Ridd** · Jun 27 '08, 07:40 PM

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 <foo@coo.comsai d:

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?

Hard to say.

>
I'd certainly never write C code like this, but perhaps it is legal.
>
>
>
#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);
>
>
>
>
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.
>
>
>
>
>
cc -c -g -DIN_GCC -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.3.1/gcc
-I../../gcc-4.3.1/gcc/. -I../../gcc-4.3.1/gcc/../include -I./../intl
-I../../gcc-4.3.1/gcc/../libcpp/include -I/usr/local/include
-I/usr/local/include -I/usr/local/include
-I../../gcc-4.3.1/gcc/../libdecnumber
-I../../gcc-4.3.1/gcc/../libdecnumber/dpd -I../libdecnumber
../../gcc-4.3.1/gcc/c-common.c -o c-common.o
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
short_fract_typ e_no...

I can't see any "short" in the macro you quoted. It may be worth adding
-E to the cc flags and looking more closely at the preprocessor output.

Cheers,

Chris

**Dave** · Jun 27 '08, 07:40 PM

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

Chris Ridd wrote:

On 2008-06-10 07:37:28 +0100, Dave <foo@coo.comsai d:
>

>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?

>
Hard to say.
>

>>
>I'd certainly never write C code like this, but perhaps it is legal.
>>
>>
>>
>#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);
>>
>>
>>
>>
>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.
>>
>>
>>
>>
>>
>cc -c -g -DIN_GCC -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.3.1/gcc
>-I../../gcc-4.3.1/gcc/. -I../../gcc-4.3.1/gcc/../include -I./../intl
>-I../../gcc-4.3.1/gcc/../libcpp/include -I/usr/local/include
>-I/usr/local/include -I/usr/local/include
>-I../../gcc-4.3.1/gcc/../libdecnumber
>-I../../gcc-4.3.1/gcc/../libdecnumber/dpd -I../libdecnumber
>../../gcc-4.3.1/gcc/c-common.c -o c-common.o
>"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
>short_fract_ty pe_no...

>
I can't see any "short" in the macro you quoted. It may be worth adding
-E to the cc flags and looking more closely at the preprocessor output.
>
Cheers,
>
Chris
>

I can't get anything useful from the preprocessor. Adding -E generates
tons of stuff on stdout, but it ends like this - i.e. the last appears
to be line 2253 - one line before the error.

if (type1 == integer_types [ itk_short ] || type1 == integer_types [
itk_unsigned_sh ort ])
return unsignedp ? integer_types [ itk_unsigned_sh ort ] :
integer_types [ itk_short ];
if (type1 == integer_types [ itk_long ] || type1 == integer_types [
itk_unsigned_lo ng ])
return unsignedp ? integer_types [ itk_unsigned_lo ng ] :
integer_types [ itk_long ];
if (type1 == integer_types [ itk_long_long ] || type1 ==
integer_types [ itk_unsigned_lo ng_long ])
return unsignedp ? integer_types [ itk_unsigned_lo ng_long ] :
integer_types [ itk_long_long ];
if (type1 == c_global_trees [ CTI_WIDEST_INT_ LIT_TYPE ] || type1 ==
c_global_trees [ CTI_WIDEST_UINT _LIT_TYPE ])
return unsignedp ? c_global_trees [ CTI_WIDEST_UINT _LIT_TYPE ] :
c_global_trees [ CTI_WIDEST_INT_ LIT_TYPE ];
# 2218
if (type1 == global_trees [ TI_INTTI_TYPE ] || type1 ==
global_trees [ TI_UINTTI_TYPE ])
return unsignedp ? global_trees [ TI_UINTTI_TYPE ] : global_trees
[ TI_INTTI_TYPE ];
# 2221
if (type1 == global_trees [ TI_INTDI_TYPE ] || type1 ==
global_trees [ TI_UINTDI_TYPE ])
return unsignedp ? global_trees [ TI_UINTDI_TYPE ] : global_trees
[ TI_INTDI_TYPE ];
if (type1 == global_trees [ TI_INTSI_TYPE ] || type1 ==
global_trees [ TI_UINTSI_TYPE ])
return unsignedp ? global_trees [ TI_UINTSI_TYPE ] : global_trees
[ TI_INTSI_TYPE ];
if (type1 == global_trees [ TI_INTHI_TYPE ] || type1 ==
global_trees [ TI_UINTHI_TYPE ])
return unsignedp ? global_trees [ TI_UINTHI_TYPE ] : global_trees
[ TI_INTHI_TYPE ];
if (type1 == global_trees [ TI_INTQI_TYPE ] || type1 ==
global_trees [ TI_UINTQI_TYPE ])
return unsignedp ? global_trees [ TI_UINTQI_TYPE ] : global_trees
[ TI_INTQI_TYPE ];

# 2247

# 2253

**Chris Ridd** · Jun 27 '08, 07:40 PM

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

On 2008-06-10 08:28:19 +0100, Dave <foo@coo.comsai d:

I can't get anything useful from the preprocessor. Adding -E generates
tons of stuff on stdout, but it ends like this - i.e. the last appears
to be line 2253 - one line before the error.
>
>
>
if (type1 == integer_types [ itk_short ] || type1 == integer_types
[ itk_unsigned_sh ort ])
return unsignedp ? integer_types [ itk_unsigned_sh ort ] :
integer_types [ itk_short ];
if (type1 == integer_types [ itk_long ] || type1 == integer_types
[ itk_unsigned_lo ng ])
return unsignedp ? integer_types [ itk_unsigned_lo ng ] :
integer_types [ itk_long ];
if (type1 == integer_types [ itk_long_long ] || type1 ==
integer_types [ itk_unsigned_lo ng_long ])
return unsignedp ? integer_types [ itk_unsigned_lo ng_long ] :
integer_types [ itk_long_long ];
if (type1 == c_global_trees [ CTI_WIDEST_INT_ LIT_TYPE ] || type1 ==
c_global_trees [ CTI_WIDEST_UINT _LIT_TYPE ])
return unsignedp ? c_global_trees [ CTI_WIDEST_UINT _LIT_TYPE ] :
c_global_trees [ CTI_WIDEST_INT_ LIT_TYPE ];
# 2218
if (type1 == global_trees [ TI_INTTI_TYPE ] || type1 ==
global_trees [ TI_UINTTI_TYPE ])
return unsignedp ? global_trees [ TI_UINTTI_TYPE ] :
global_trees [ TI_INTTI_TYPE ];
# 2221
if (type1 == global_trees [ TI_INTDI_TYPE ] || type1 ==
global_trees [ TI_UINTDI_TYPE ])
return unsignedp ? global_trees [ TI_UINTDI_TYPE ] :
global_trees [ TI_INTDI_TYPE ];
if (type1 == global_trees [ TI_INTSI_TYPE ] || type1 ==
global_trees [ TI_UINTSI_TYPE ])
return unsignedp ? global_trees [ TI_UINTSI_TYPE ] :
global_trees [ TI_INTSI_TYPE ];
if (type1 == global_trees [ TI_INTHI_TYPE ] || type1 ==
global_trees [ TI_UINTHI_TYPE ])
return unsignedp ? global_trees [ TI_UINTHI_TYPE ] :
global_trees [ TI_INTHI_TYPE ];
if (type1 == global_trees [ TI_INTQI_TYPE ] || type1 ==
global_trees [ TI_UINTQI_TYPE ])
return unsignedp ? global_trees [ TI_UINTQI_TYPE ] :
global_trees [ TI_INTQI_TYPE ];
>
# 2247
>
# 2253

Interesting - does the preprocessor exit with an error or crash?

Cheers,

Chris

**Dave** · Jun 27 '08, 07:40 PM

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

Chris Ridd wrote:

On 2008-06-10 08:28:19 +0100, Dave <foo@coo.comsai d:
>

>I can't get anything useful from the preprocessor. Adding -E generates
>tons of stuff on stdout, but it ends like this - i.e. the last appears
>to be line 2253 - one line before the error.
>>
>>
>>
> if (type1 == integer_types [ itk_short ] || type1 == integer_types
>[ itk_unsigned_sh ort ])
> return unsignedp ? integer_types [ itk_unsigned_sh ort ] :
>integer_type s [ itk_short ];
> if (type1 == integer_types [ itk_long ] || type1 == integer_types
>[ itk_unsigned_lo ng ])
> return unsignedp ? integer_types [ itk_unsigned_lo ng ] :
>integer_type s [ itk_long ];
> if (type1 == integer_types [ itk_long_long ] || type1 ==
>integer_type s [ itk_unsigned_lo ng_long ])
> return unsignedp ? integer_types [ itk_unsigned_lo ng_long ] :
>integer_type s [ itk_long_long ];
> if (type1 == c_global_trees [ CTI_WIDEST_INT_ LIT_TYPE ] || type1
>== c_global_trees [ CTI_WIDEST_UINT _LIT_TYPE ])
> return unsignedp ? c_global_trees [ CTI_WIDEST_UINT _LIT_TYPE ] :
>c_global_tre es [ CTI_WIDEST_INT_ LIT_TYPE ];
># 2218
> if (type1 == global_trees [ TI_INTTI_TYPE ] || type1 ==
>global_trees [ TI_UINTTI_TYPE ])
> return unsignedp ? global_trees [ TI_UINTTI_TYPE ] :
>global_trees [ TI_INTTI_TYPE ];
># 2221
> if (type1 == global_trees [ TI_INTDI_TYPE ] || type1 ==
>global_trees [ TI_UINTDI_TYPE ])
> return unsignedp ? global_trees [ TI_UINTDI_TYPE ] :
>global_trees [ TI_INTDI_TYPE ];
> if (type1 == global_trees [ TI_INTSI_TYPE ] || type1 ==
>global_trees [ TI_UINTSI_TYPE ])
> return unsignedp ? global_trees [ TI_UINTSI_TYPE ] :
>global_trees [ TI_INTSI_TYPE ];
> if (type1 == global_trees [ TI_INTHI_TYPE ] || type1 ==
>global_trees [ TI_UINTHI_TYPE ])
> return unsignedp ? global_trees [ TI_UINTHI_TYPE ] :
>global_trees [ TI_INTHI_TYPE ];
> if (type1 == global_trees [ TI_INTQI_TYPE ] || type1 ==
>global_trees [ TI_UINTQI_TYPE ])
> return unsignedp ? global_trees [ TI_UINTQI_TYPE ] :
>global_trees [ TI_INTQI_TYPE ];
>>
># 2247
>>
># 2253

>
Interesting - does the preprocessor exit with an error or crash?
>
Cheers,
>
Chris
>

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.

# 2218
if (type1 == global_trees [ TI_INTTI_TYPE ] || type1 ==
global_trees [ TI_UINTTI_TYPE ])
return unsignedp ? global_trees [ TI_UINTTI_TYPE ] : global_trees
[ TI_INTTI_TYPE ];
# 2221
if (type1 == global_trees [ TI_INTDI_TYPE ] || type1 ==
global_trees [ TI_UINTDI_TYPE ])
return unsignedp ? global_trees [ TI_UINTDI_TYPE ] : global_trees
[ TI_INTDI_TYPE ];
if (type1 == global_trees [ TI_INTSI_TYPE ] || type1 ==
global_trees [ TI_UINTSI_TYPE ])
return unsignedp ? global_trees [ TI_UINTSI_TYPE ] : global_trees
[ TI_INTSI_TYPE ];
if (type1 == global_trees [ TI_INTHI_TYPE ] || type1 ==
global_trees [ TI_UINTHI_TYPE ])
return unsignedp ? global_trees [ TI_UINTHI_TYPE ] : global_trees
[ TI_INTHI_TYPE ];
if (type1 == global_trees [ TI_INTQI_TYPE ] || type1 ==
global_trees [ TI_UINTQI_TYPE ])
return unsignedp ? global_trees [ TI_UINTQI_TYPE ] : global_trees
[ TI_INTQI_TYPE ];

# 2247

# 2253

"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
short_fract_typ e_node
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
unsigned_short_ fract_type_node
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
unsigned_short_ fract_type_node
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
short_fract_typ e_node
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token: fract_type_node
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
unsigned_fract_ type_node
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
unsigned_fract_ type_node
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token: fract_type_node
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
long_fract_type _node
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
unsigned_long_f ract_type_node
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
unsigned_long_f ract_type_node
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
long_fract_type _node
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
long_long_fract _type_node
"../../gcc-4.3.1/gcc/c-common.c", line 2254: fatal: too many errors
cc: acomp failed for ../../gcc-4.3.1/gcc/c-common.c

**Ian Collins** · Jun 27 '08, 07:40 PM

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.

--
Ian Collins.

**Thad Smith** · Jun 27 '08, 07:41 PM

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.

#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.

--
Thad

**Dave** · Jun 27 '08, 07:41 PM

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

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.

**Dik T. Winter** · Jun 27 '08, 07:41 PM

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

In article <484fbfa8$0$879 40$892e0abb@aut h.newsreader.oc tanews.comThad Smith <ThadSmith@acm. orgwrites:
....

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/

**Andrew Haley** · Jun 27 '08, 07:41 PM

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

In gnu.gcc.help Thad Smith <ThadSmith@acm. orgwrote:

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").

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.

**Ian Collins** · Jun 27 '08, 07:41 PM

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.

**Andrew Haley** · Jul 9 '08, 08:25 PM

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

In gnu.gcc.help Andrew Haley <andrew29@littl epinkcloud.inva lidwrote:

In gnu.gcc.help Thad Smith <ThadSmith@acm. orgwrote:
>

>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.

**Dave** · Jul 9 '08, 09:15 PM

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 <andrew29@littl epinkcloud.inva lidwrote:

>In gnu.gcc.help Thad Smith <ThadSmith@acm. orgwrote:
>>

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

**Andrew Haley** · Jul 10 '08, 02:05 PM

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

In gnu.gcc.help Dave <foo@coo.comwro te:

Andrew Haley wrote:

>In gnu.gcc.help Andrew Haley <andrew29@littl epinkcloud.inva lidwrote:

>>In gnu.gcc.help Thad Smith <ThadSmith@acm. orgwrote:
>>>
>>>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.

**Thommy M.** · Jul 10 '08, 02:55 PM

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

Andrew Haley wrote:

In gnu.gcc.help Dave <foo@coo.comwro te:

>Andrew Haley wrote:

>>In gnu.gcc.help Andrew Haley <andrew29@littl epinkcloud.inva lidwrote:
>>>In gnu.gcc.help Thad Smith <ThadSmith@acm. orgwrote:
>>>>
>>>>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.

If 4.2 isn't too old to your taste there's a pretty descent one here:

http://cooltools.sunsource.net/gcc/

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

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

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment