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

[Dave]

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) \
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_type_no...
"../../gcc-4.3.1/gcc/c-common.c", line 2254: syntax error before or at: ||
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
unsigned_short_frac...
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
unsigned_short_frac...
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
short_fract_type_no...
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token: fract_type_node

[Chris Ridd]

On 2008-06-10 07:37:28 +0100, Dave <fo*@coo.comsaid:

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

Chris Ridd wrote:

On 2008-06-10 07:37:28 +0100, Dave <fo*@coo.comsaid:

>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_type_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_short ])
return unsignedp ? integer_types [ itk_unsigned_short ] :
integer_types [ itk_short ];
if (type1 == integer_types [ itk_long ] || type1 == integer_types [
itk_unsigned_long ])
return unsignedp ? integer_types [ itk_unsigned_long ] :
integer_types [ itk_long ];
if (type1 == integer_types [ itk_long_long ] || type1 ==
integer_types [ itk_unsigned_long_long ])
return unsignedp ? integer_types [ itk_unsigned_long_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]

On 2008-06-10 08:28:19 +0100, Dave <fo*@coo.comsaid:

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_short ])
return unsignedp ? integer_types [ itk_unsigned_short ] :
integer_types [ itk_short ];
if (type1 == integer_types [ itk_long ] || type1 == integer_types
[ itk_unsigned_long ])
return unsignedp ? integer_types [ itk_unsigned_long ] :
integer_types [ itk_long ];
if (type1 == integer_types [ itk_long_long ] || type1 ==
integer_types [ itk_unsigned_long_long ])
return unsignedp ? integer_types [ itk_unsigned_long_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]

Chris Ridd wrote:

On 2008-06-10 08:28:19 +0100, Dave <fo*@coo.comsaid:

>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_short ])
return unsignedp ? integer_types [ itk_unsigned_short ] :
integer_types [ itk_short ];
if (type1 == integer_types [ itk_long ] || type1 == integer_types
[ itk_unsigned_long ])
return unsignedp ? integer_types [ itk_unsigned_long ] :
integer_types [ itk_long ];
if (type1 == integer_types [ itk_long_long ] || type1 ==
integer_types [ itk_unsigned_long_long ])
return unsignedp ? integer_types [ itk_unsigned_long_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

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_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:
unsigned_short_fract_type_node
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
short_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:
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_fract_type_node
"../../gcc-4.3.1/gcc/c-common.c", line 2254: invalid token:
unsigned_long_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:
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]

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]

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]

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]

In article <48***********************@auth.newsreader.octanew s.comThad Smith <Th*******@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, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Andrew Haley]

In gnu.gcc.help Thad Smith <Th*******@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]

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]

In gnu.gcc.help Andrew Haley <an******@littlepinkcloud.invalidwrote:

In gnu.gcc.help Thad Smith <Th*******@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]

Andrew Haley wrote:

In gnu.gcc.help Andrew Haley <an******@littlepinkcloud.invalidwrote:

>In gnu.gcc.help Thad Smith <Th*******@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]

In gnu.gcc.help Dave <fo*@coo.comwrote:

Andrew Haley wrote:

>In gnu.gcc.help Andrew Haley <an******@littlepinkcloud.invalidwrote:

>>In gnu.gcc.help Thad Smith <Th*******@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.]

Andrew Haley wrote:

In gnu.gcc.help Dave <fo*@coo.comwrote:

>Andrew Haley wrote:

>>In gnu.gcc.help Andrew Haley <an******@littlepinkcloud.invalidwrote:
In gnu.gcc.help Thad Smith <Th*******@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/

[Dave]

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.
$ grep VERSION_STRING /usr/local/include/mpfr.h
#define MPFR_VERSION_STRING "2.3.1"

But how wrong that assumption is....

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

$ ../gcc-4.3.1/configure

## --------- ##
## Platform. ##
## --------- ##

hostname = kestrel
uname -m = sun4u
uname -r = 5.10
uname -s = SunOS
uname -v = Generic_137111-01

/usr/bin/uname -p = sparc
/bin/uname -X = System = SunOS
Node = kestrel
Release = 5.10
KernelID = Generic_137111-01
Machine = sun4u
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 2

/bin/arch = sun4
/usr/bin/arch -k = sun4u
/usr/convex/getsysinfo = unknown
hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown

PATH: /usr/bin
PATH: /usr/openwin/bin
PATH: /usr/ucb
PATH: /opt/csw/bin
PATH: /opt/csw/gcc3/bin
PATH: /usr/local/bin
PATH: /usr/ccs/bin
PATH: /usr/sbin
PATH: .
PATH: /opt/csw/bin
PATH: /opt/csw/gcc4/bin
PATH: /usr/local/bin
PATH: /usr/ccs/bin
PATH: /opt/SUNWspci3/bin
PATH: .
## ----------- ##
## Core tests. ##
## ----------- ##

configure:1505: checking build system type
configure:1523: result: sparc-sun-solaris2.10
configure:1558: checking host system type
configure:1572: result: sparc-sun-solaris2.10
configure:1580: checking target system type
configure:1594: result: sparc-sun-solaris2.10
configure:1637: checking for a BSD-compatible install
configure:1692: result: ../gcc-4.3.1/install-sh -c
configure:1703: checking whether ln works
configure:1725: result: yes
configure:1729: checking whether ln -s works
configure:1733: result: yes
configure:2885: checking for gcc
configure:2901: found /opt/csw/gcc3/bin/gcc
configure:2911: result: gcc
configure:3155: checking for C compiler version
configure:3158: gcc --version </dev/null >&5
gcc (GCC) 3.4.5
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3161: $? = 0
configure:3163: gcc -v </dev/null >&5
Reading specs from /opt/csw/gcc3/lib/gcc/sparc-sun-solaris2.8/3.4.5/specs
Configured with: ../sources/gcc-3.4.5/configure --prefix=/opt/csw/gcc3
--with-local-prefix=/opt/csw --without-gnu-as --with-as=/usr/ccs/bin/as
--without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix
--enable-shared --enable-multilib --enable-nls --with-included-gettext
--with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib
--enable-languages=all
Thread model: posix
gcc version 3.4.5
configure:3166: $? = 0
configure:3168: gcc -V </dev/null >&5
gcc: `-V' option must have argument
configure:3171: $? = 1
configure:3194: checking for C compiler default output file name
configure:3197: gcc conftest.c >&5
configure:3200: $? = 0
configure:3246: result: a.out
configure:3251: checking whether the C compiler works
configure:3257: ./a.out
configure:3260: $? = 0
configure:3277: result: yes
configure:3284: checking whether we are cross compiling
configure:3286: result: no
configure:3289: checking for suffix of executables
configure:3291: gcc -o conftest conftest.c >&5
configure:3294: $? = 0
configure:3319: result:
configure:3325: checking for suffix of object files
configure:3346: gcc -c conftest.c >&5
configure:3349: $? = 0
configure:3371: result: o
configure:3375: checking whether we are using the GNU C compiler
configure:3399: gcc -c conftest.c >&5
configure:3405: $? = 0
configure:3409: test -z
|| test ! -s conftest.err
configure:3412: $? = 0
configure:3415: test -s conftest.o
configure:3418: $? = 0
configure:3431: result: yes
configure:3437: checking whether gcc accepts -g
configure:3458: gcc -c -g conftest.c >&5
configure:3464: $? = 0
configure:3468: test -z
|| test ! -s conftest.err
configure:3471: $? = 0
configure:3474: test -s conftest.o
configure:3477: $? = 0
configure:3488: result: yes
configure:3505: checking for gcc option to accept ANSI C
configure:3575: gcc -c -g -O2 conftest.c >&5
configure:3581: $? = 0
configure:3585: test -z
|| test ! -s conftest.err
configure:3588: $? = 0
configure:3591: test -s conftest.o
configure:3594: $? = 0
configure:3612: result: none needed
configure:3630: gcc -c -g -O2 conftest.c >&5
conftest.c:2: error: syntax error before "me"
configure:3636: $? = 1
configure: failed program was:
| #ifndef __cplusplus
| choke me
| #endif
configure:3821: checking for g++
configure:3837: found /opt/csw/gcc3/bin/g++
configure:3847: result: g++
configure:3863: checking for C++ compiler version
configure:3866: g++ --version </dev/null >&5
g++ (GCC) 3.4.5
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3869: $? = 0
configure:3871: g++ -v </dev/null >&5
Reading specs from /opt/csw/gcc3/lib/gcc/sparc-sun-solaris2.8/3.4.5/specs
Configured with: ../sources/gcc-3.4.5/configure --prefix=/opt/csw/gcc3
--with-local-prefix=/opt/csw --without-gnu-as --with-as=/usr/ccs/bin/as
--without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix
--enable-shared --enable-multilib --enable-nls --with-included-gettext
--with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib
--enable-languages=all
Thread model: posix
gcc version 3.4.5
configure:3874: $? = 0
configure:3876: g++ -V </dev/null >&5
g++: `-V' option must have argument
configure:3879: $? = 1
configure:3882: checking whether we are using the GNU C++ compiler
configure:3906: g++ -c conftest.cc >&5
configure:3912: $? = 0
configure:3916: test -z
|| test ! -s conftest.err
configure:3919: $? = 0
configure:3922: test -s conftest.o
configure:3925: $? = 0
configure:3938: result: yes
configure:3944: checking whether g++ accepts -g
configure:3965: g++ -c -g conftest.cc >&5
configure:3971: $? = 0
configure:3975: test -z
|| test ! -s conftest.err
configure:3978: $? = 0
configure:3981: test -s conftest.o
configure:3984: $? = 0
configure:3995: result: yes
configure:4037: g++ -c -g -O2 conftest.cc >&5
configure:4043: $? = 0
configure:4047: test -z
|| test ! -s conftest.err
configure:4050: $? = 0
configure:4053: test -s conftest.o
configure:4056: $? = 0
configure:4082: g++ -c -g -O2 conftest.cc >&5
conftest.cc: In function `int main()':
conftest.cc:13: error: `exit' was not declared in this scope
configure:4088: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h. */
|
| int
| main ()
| {
| exit (42);
| ;
| return 0;
| }
configure:4037: g++ -c -g -O2 conftest.cc >&5
configure:4043: $? = 0
configure:4047: test -z
|| test ! -s conftest.err
configure:4050: $? = 0
configure:4053: test -s conftest.o
configure:4056: $? = 0
configure:4082: g++ -c -g -O2 conftest.cc >&5
configure:4088: $? = 0
configure:4092: test -z
|| test ! -s conftest.err
configure:4095: $? = 0
configure:4098: test -s conftest.o
configure:4101: $? = 0
configure:4188: checking for gnatbind
configure:4215: result: no
configure:4268: checking for gnatmake
configure:4295: result: no
configure:4307: checking whether compiler driver understands Ada
configure:4330: result: no
configure:4339: checking how to compare bootstrapped objects
configure:4364: result: cmp $$f1 $$f2 16 16
configure:4484: checking for correct version of gmp.h
configure:4507: gcc -c -g -O2 conftest.c >&5
configure:4513: $? = 0
configure:4517: test -z
|| test ! -s conftest.err
configure:4520: $? = 0
configure:4523: test -s conftest.o
configure:4526: $? = 0
configure:4528: result: yes
configure:4542: checking for correct version of mpfr.h
configure:4573: gcc -o conftest -g -O2 conftest.c -lmpfr -lgmp >&5
conftest.c:13:22: mpfr.h: No such file or directory
conftest.c:18:40: missing binary operator before token "("
conftest.c: In function `main':
conftest.c:21: error: `mpfr_t' undeclared (first use in this function)
conftest.c:21: error: (Each undeclared identifier is reported only once
conftest.c:21: error: for each function it appears in.)
conftest.c:21: error: syntax error before "n"
conftest.c:24: error: `n' undeclared (first use in this function)
conftest.c:25: error: `x' undeclared (first use in this function)
conftest.c:26: error: `GMP_RNDN' undeclared (first use in this function)
configure:4579: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #ifdef __cplusplus
| extern "C" void std::exit (int) throw (); using std::exit;
| #endif
| /* end confdefs.h. */
| #include <gmp.h>
| #include <mpfr.h>
| int
| main ()
| {
|
| #if MPFR_VERSION < MPFR_VERSION_NUM(2,2,1)
| choke me
| #endif
| mpfr_t n;
| mpfr_t x;
| int t;
| mpfr_init (n);
| mpfr_init (x);
| mpfr_atan2 (n, n, x, GMP_RNDN);
| mpfr_erfc (n, x, GMP_RNDN);
| mpfr_subnormalize (x, t, GMP_RNDN);
|
| ;
| return 0;
| }
configure:4652: result: no
configure:4669: 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.

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=sparc-sun-solaris2.10
ac_cv_build_alias=sparc-sun-solaris2.10
ac_cv_c_compiler_gnu=yes
ac_cv_cxx_compiler_gnu=yes
ac_cv_env_AR_FOR_TARGET_set=
ac_cv_env_AR_FOR_TARGET_value=
ac_cv_env_AR_set=
ac_cv_env_AR_value=
ac_cv_env_AS_FOR_TARGET_set=
ac_cv_env_AS_FOR_TARGET_value=
ac_cv_env_AS_set=
ac_cv_env_AS_value=
ac_cv_env_CC_FOR_TARGET_set=
ac_cv_env_CC_FOR_TARGET_value=
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CXXFLAGS_set=
ac_cv_env_CXXFLAGS_value=
ac_cv_env_CXX_FOR_TARGET_set=
ac_cv_env_CXX_FOR_TARGET_value=
ac_cv_env_CXX_set=
ac_cv_env_CXX_value=
ac_cv_env_DLLTOOL_FOR_TARGET_set=
ac_cv_env_DLLTOOL_FOR_TARGET_value=
ac_cv_env_DLLTOOL_set=
ac_cv_env_DLLTOOL_value=
ac_cv_env_GCC_FOR_TARGET_set=
ac_cv_env_GCC_FOR_TARGET_value=
ac_cv_env_GCJ_FOR_TARGET_set=
ac_cv_env_GCJ_FOR_TARGET_value=
ac_cv_env_GFORTRAN_FOR_TARGET_set=
ac_cv_env_GFORTRAN_FOR_TARGET_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LD_FOR_TARGET_set=
ac_cv_env_LD_FOR_TARGET_value=
ac_cv_env_LD_set=
ac_cv_env_LD_value=
ac_cv_env_LIPO_FOR_TARGET_set=
ac_cv_env_LIPO_FOR_TARGET_value=
ac_cv_env_LIPO_set=
ac_cv_env_LIPO_value=
ac_cv_env_NM_FOR_TARGET_set=
ac_cv_env_NM_FOR_TARGET_value=
ac_cv_env_NM_set=
ac_cv_env_NM_value=
ac_cv_env_OBJCOPY_set=
ac_cv_env_OBJCOPY_value=
ac_cv_env_OBJDUMP_FOR_TARGET_set=
ac_cv_env_OBJDUMP_FOR_TARGET_value=
ac_cv_env_OBJDUMP_set=
ac_cv_env_OBJDUMP_value=
ac_cv_env_RANLIB_FOR_TARGET_set=
ac_cv_env_RANLIB_FOR_TARGET_value=
ac_cv_env_RANLIB_set=
ac_cv_env_RANLIB_value=
ac_cv_env_STRIP_FOR_TARGET_set=
ac_cv_env_STRIP_FOR_TARGET_value=
ac_cv_env_STRIP_set=
ac_cv_env_STRIP_value=
ac_cv_env_WINDMC_FOR_TARGET_set=
ac_cv_env_WINDMC_FOR_TARGET_value=
ac_cv_env_WINDMC_set=
ac_cv_env_WINDMC_value=
ac_cv_env_WINDRES_FOR_TARGET_set=
ac_cv_env_WINDRES_FOR_TARGET_value=
ac_cv_env_WINDRES_set=
ac_cv_env_WINDRES_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_exeext=
ac_cv_host=sparc-sun-solaris2.10
ac_cv_host_alias=sparc-sun-solaris2.10
ac_cv_objext=o
ac_cv_prog_ac_ct_CC=gcc
ac_cv_prog_ac_ct_CXX=g++
ac_cv_prog_ac_ct_GNATBIND=no
ac_cv_prog_ac_ct_GNATMAKE=no
ac_cv_prog_cc_g=yes
ac_cv_prog_cc_stdc=
ac_cv_prog_cxx_g=yes
ac_cv_target=sparc-sun-solaris2.10
ac_cv_target_alias=sparc-sun-solaris2.10
acx_cv_cc_gcc_supports_ada=no
acx_cv_prog_LN=ln
gcc_cv_prog_cmp_skip='cmp $$f1 $$f2 16 16'

## ----------------- ##
## Output variables. ##
## ----------------- ##

AR=''
AR_FOR_BUILD='$(AR)'
AR_FOR_TARGET=''
AS=''
AS_FOR_BUILD='$(AS)'
AS_FOR_TARGET=''
BISON=''
CC='gcc'
CC_FOR_BUILD='$(CC)'
CC_FOR_TARGET=''
CFLAGS='-g -O2'
CFLAGS_FOR_BUILD=''
COMPILER_AS_FOR_TARGET=''
COMPILER_LD_FOR_TARGET=''
COMPILER_NM_FOR_TARGET=''
CONFIGURE_GDB_TK=''
CPPFLAGS=''
CXX='g++'
CXXFLAGS='-g -O2'
CXXFLAGS_FOR_BUILD=''
CXX_FOR_BUILD='$(CXX)'
CXX_FOR_TARGET=''
DEBUG_PREFIX_CFLAGS_FOR_TARGET=''
DEFS=''
DLLTOOL=''
DLLTOOL_FOR_BUILD='$(DLLTOOL)'
DLLTOOL_FOR_TARGET=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EXEEXT=''
EXPECT=''
FLAGS_FOR_TARGET=''
FLEX=''
GCC_FOR_TARGET=''
GCJ_FOR_BUILD='$(GCJ)'
GCJ_FOR_TARGET=''
GDB_TK=''
GFORTRAN_FOR_BUILD='$(GFORTRAN)'
GFORTRAN_FOR_TARGET=''
GNATBIND='no'
GNATMAKE='no'
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_GDB_TK=''
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
LD='/usr/ccs/bin/ld'
LDFLAGS=''
LDFLAGS_FOR_BUILD=''
LD_FOR_BUILD='$(LD)'
LD_FOR_TARGET=''
LEX=''
LIBOBJS=''
LIBS=''
LIPO=''
LIPO_FOR_TARGET=''
LN='ln'
LN_S='ln -s'
LTLIBOBJS=''
M4=''
MAINT=''
MAINTAINER_MODE_FALSE=''
MAINTAINER_MODE_TRUE=''
MAKEINFO=''
NM=''
NM_FOR_BUILD='$(NM)'
NM_FOR_TARGET=''
OBJCOPY=''
OBJDUMP=''
OBJDUMP_FOR_TARGET=''
OBJEXT='o'
PACKAGE_BUGREPORT=''
PACKAGE_NAME=''
PACKAGE_STRING=''
PACKAGE_TARNAME=''
PACKAGE_VERSION=''
PATH_SEPARATOR=':'
RANLIB=''
RANLIB_FOR_BUILD='$(RANLIB)'
RANLIB_FOR_TARGET=''
RAW_CXX_FOR_TARGET=''
RPATH_ENVVAR=''
RUNTEST=''
SHELL='/bin/bash'
STRIP=''
STRIP_FOR_TARGET=''
SYSROOT_CFLAGS_FOR_TARGET=''
TOPLEVEL_CONFIGURE_ARGUMENTS='../gcc-4.3.1/configure'
WINDMC=''
WINDMC_FOR_BUILD='$(WINDMC)'
WINDMC_FOR_TARGET=''
WINDRES=''
WINDRES_FOR_BUILD='$(WINDRES)'
WINDRES_FOR_TARGET=''
YACC=''
ac_ct_CC='gcc'
ac_ct_CXX='g++'
ac_ct_GNATBIND='no'
ac_ct_GNATMAKE='no'
bindir='${exec_prefix}/bin'
build='sparc-sun-solaris2.10'
build_alias=''
build_configargs=''
build_configdirs='build-libiberty build-texinfo build-byacc build-flex
build-bison build-m4 build-fixincludes'
build_cpu='sparc'
build_libsubdir='build-sparc-sun-solaris2.10'
build_noncanonical='sparc-sun-solaris2.10'
build_os='solaris2.10'
build_subdir='build-sparc-sun-solaris2.10'
build_tooldir=''
build_vendor='sun'
config_shell='/bin/bash'
configdirs='intl mmalloc libiberty opcodes bfd readline tcl tk itcl
libgui zlib libcpp libdecnumber gmp mpfr texinfo byacc flex bison
binutils gas ld fixincludes gcc sid sim gdb make patch prms
send-pr gprof etc expect dejagnu ash bash bzip2 m4 autoconf automake
libtool diff rcs fileutils shellutils time textutils wdiff find uudecode
hello tar gzip indent recode release sed utils guile perl gawk findutils
gettext zip fastjar gnattools'
datadir='${prefix}/share'
datarootdir=''
do_compare='cmp $$f1 $$f2 16 16'
docdir=''
exec_prefix='NONE'
gmpinc=''
gmplibs='-lmpfr -lgmp'
host='sparc-sun-solaris2.10'
host_alias=''
host_configargs=''
host_cpu='sparc'
host_noncanonical='sparc-sun-solaris2.10'
host_os='solaris2.10'
host_subdir='.'
host_vendor='sun'
htmldir=''
includedir='${prefix}/include'
infodir='${prefix}/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localstatedir='${prefix}/var'
mandir='${prefix}/man'
oldincludedir='/usr/include'
pdfdir=''
prefix='NONE'
program_transform_name='s,y,y,'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
stage1_cflags=''
stage1_checking=''
stage1_languages=''
stage2_werror_flag=''
sysconfdir='${prefix}/etc'
target='sparc-sun-solaris2.10'
target_alias=''
target_configargs=''
target_cpu='sparc'
target_noncanonical='sparc-sun-solaris2.10'
target_os='solaris2.10'
target_subdir='sparc-sun-solaris2.10'
target_vendor='sun'
tooldir=''

## ------------- ##
## Output files. ##
## ------------- ##

alphaieee_frag=''
host_makefile_frag='config/mh-solaris'
ospace_frag=''
serialization_dependencies=''
target_makefile_frag=''

## ----------- ##
## confdefs.h. ##
## ----------- ##

#define PACKAGE_BUGREPORT ""
#define PACKAGE_NAME ""
#define PACKAGE_STRING ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#endif
#ifdef __cplusplus
extern "C" void std::exit (int) throw (); using std::exit;

configure: exit 1

[Andrew Haley]

In gnu.gcc.help Dave <fo*@coo.comwrote:

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.

[Dave]

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.

[Richard B. Gilbert]

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?

[=?UTF-8?Q?Riot_Nrrrd=E2=84=A2?=]

On 2008-07-10 07:02:07 -0700, Andrew Haley
<ap*@dhcp-10-15-16-109.yyz.redhat.comsaid:

In gnu.gcc.help Dave <fo*@coo.comwrote:

>Andrew Haley wrote:

>>In gnu.gcc.help Andrew Haley <an******@littlepinkcloud.invalidwrote:
In gnu.gcc.help Thad Smith <Th*******@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.

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)

[=?UTF-8?Q?Riot_Nrrrd=E2=84=A2?=]

On 2008-07-23 08:22:59 -0700, Riot Nrrrd <Fr****@public.comsaid:

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 or SVN)

Never mind - I see you posted the fix(es) to gcc-patches.

So it looks like your patches for both c-common.c *and* tree.c to
split the macros are necessary to work around this issue. Right?
(Anything else?)

[Dave]

Riot Nrrrd™ wrote:

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?

After an alful lot of f***ing about I mananged to build the latest gcc
(4.3.1), but not starting with Sun Studio - only gcc.
I think if I recall correctly I used 3.x (supplied with Solaris in
/usr/sfw/bin) to build 4.x, then used that to build 4.y, and that to
build 4.z....

Looking in /usr/local on my system I have several directories with gcc
in them (versions 4.2.0, 4.2.2, 4.2.4 and 4.3.1).

It seems a bit hit and miss finding what version will compile some other
version on Solaris. If it don't compile, try to find another version and
compile that. It's clear there is little quality control on Solaris, so
it's anyones guess what will work and what will not.

Anyway, this is what I finally used to build 4.3.1, but I can't recall
the compiler version I used.

$ gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.3.1/configure --prefix=/usr/local
--with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
--with-ld=/usr/local/bin/ld --enable-languages=c,c++,fortran
--with-gmp=/usr/local --with-mpfr=/usr/local
--with-libiconv-prefix=/usr/local
Thread model: posix
gcc version 4.3.1 (GCC
Note I build this using the GNU linker and assembler, not the Sun ones.
That was mainly since I need to compile some code with GNUisms, which
make use of GNU-specific linker options.

[Andrew Haley]

In gnu.gcc.help Riot Nrrrd? <Fr****@public.comwrote:

On 2008-07-23 08:22:59 -0700, Riot Nrrrd <Fr****@public.comsaid:

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 or SVN)

Never mind - I see you posted the fix(es) to gcc-patches.

So it looks like your patches for both c-common.c *and* tree.c to
split the macros are necessary to work around this issue. Right?
(Anything else?)

I think that's it. The only real way to be absolutely sure is to pull
the changes from SVN, though.

http://gcc.gnu.org/viewcvs?view=rev&revision=137413

Andrew.

[=?UTF-8?Q?Riot_Nrrrd=E2=84=A2?=]

On 2008-07-30 19:30:29 -0700, Andrew Haley
<an******@littlepinkcloud.invalidsaid:

In gnu.gcc.help Riot Nrrrd? <Fr****@public.comwrote:

>On 2008-07-23 08:22:59 -0700, Riot Nrrrd <Fr****@public.comsaid:

>>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 or SVN)

>Never mind - I see you posted the fix(es) to gcc-patches.

>So it looks like your patches for both c-common.c *and* tree.c to
split the macros are necessary to work around this issue. Right?
(Anything else?)

I think that's it. The only real way to be absolutely sure is to pull
the changes from SVN, though.

http://gcc.gnu.org/viewcvs?view=rev&revision=137413

Andrew,

With your patches I got much further, but ran aground on this:

gmake[5]: Entering directory
`/var/tmp/gcc-4.3.1/sparc-sun-solaris2.9/sparcv9/libjava'
gmake[5]: warning: -jN forced in submake: disabling jobserver mode.
gmake -j 2 create-headers
gmake[6]: Entering directory
`/var/tmp/gcc-4.3.1/sparc-sun-solaris2.9/sparcv9/libjava'
gmake[6]: warning: -jN forced in submake: disabling jobserver mode.
here=`pwd`; cd /usr/gnu/src/gcc-4.3.1/libjava/classpath/lib; \
find gnu java javax org sun -name .svn -prune -o -name
'*.class' -print | \
/var/tmp/gcc-4.3.1/sparc-sun-solaris2.9/libjava/scripts/jar
-cfM@ $here/libgcj-4.3.1.jar
echo gcjh.stamp
gmake[6]: Leaving directory
`/var/tmp/gcc-4.3.1/sparc-sun-solaris2.9/sparcv9/libjava'

[...]

echo /usr/gnu/src/gcc-4.3.1/libjava/classpath/lib/java/util/*.class >
java/util.list
gmake[5]: *** No rule to make target
`classpath/external/jsr166/java/util/concurrent/atomic/AtomicMarkableReference.java',
needed by
`java/util/concurrent/atomic.list'. Stop.
gmake[5]: *** Waiting for unfinished jobs....
echo
/usr/gnu/src/gcc-4.3.1/libjava/classpath/lib/java/util/concurrent/*.class

java/util/concurrent.list

gmake[5]: Leaving directory
`/var/tmp/gcc-4.3.1/sparc-sun-solaris2.9/sparcv9/libjava'
gmake[4]: *** [all-recursive] Error 1
gmake[4]: Leaving directory
`/var/tmp/gcc-4.3.1/sparc-sun-solaris2.9/sparcv9/libjava'
gmake[3]: *** [multi-do] Error 1
gmake[3]: Leaving directory `/var/tmp/gcc-4.3.1/sparc-sun-solaris2.9/libjava'
gmake[2]: *** [all-multi] Error 2
gmake[2]: Leaving directory `/var/tmp/gcc-4.3.1/sparc-sun-solaris2.9/libjava'
gmake[1]: *** [all-target-libjava] Error 2
gmake[1]: Leaving directory `/var/tmp/gcc-4.3.1'
gmake: *** [bootstrap] Error 2

So I checked the source directory:

[14:49] solaris9:/<9+>concurrent/atomic % pwd
/usr/src/gnu/gcc-4.3.1/libjava/classpath/external/jsr166/java/util/concurrent/atomic

[14:49]

solaris9:/<9+>concurrent/atomic % ls AtomicMarkableReference*
AtomicMarkableReference.jav

Great, so the file is there but the extension is wrong! I checked the
original GCC 4.3.1 tarball:

[14:52] solaris9:/<2>src/tarfiles % gtar -tzpf gcc-4.3.1.tar.gz | grep
AtomicMarkableReference.jav
gcc-4.3.1/libjava/classpath/external/jsr166/java/util/concurrent/atomic/AtomicMarkableReference.jav

How

the heck does a mis-named file get past QC into the GCC distribution???

[=?UTF-8?Q?Riot_Nrrrd=E2=84=A2?=]

On 2008-08-06 14:54:37 -0700, Riot Nrrrdâ„¢ <Fr****@public.comsaid:

With your patches I got much further, but ran aground on this:

echo /usr/gnu/src/gcc-4.3.1/libjava/classpath/lib/java/util/*.class >
java/util.list
gmake[5]: *** No rule to make target
`classpath/external/jsr166/java/util/concurrent/atomic/AtomicMarkableReference.java',
needed by
`java/util/concurrent/atomic.list'. Stop.
[14:49] solaris9:/<9+>concurrent/atomic % pwd
/usr/src/gnu/gcc-4.3.1/libjava/classpath/external/jsr166/java/util/concurrent/atomic

[14:49]
solaris9:/<9+>concurrent/atomic

>
% ls AtomicMarkableReference*
AtomicMarkableReference.jav

Great, so the file is there but the extension is wrong! I checked the
original GCC 4.3.1 tarball:

[14:52] solaris9:/<2>src/tarfiles % gtar -tzpf gcc-4.3.1.tar.gz | grep
AtomicMarkableReference.jav
gcc-4.3.1/libjava/classpath/external/jsr166/java/util/concurrent/atomic/AtomicMarkableReference.jav

How

>
the heck does a mis-named file get past QC into the GCC distribution???

Ignore this post (arggh, Unison doesn't implement Cancel), I was being
retarded.

I thought I'd unbundled the source with GNU tar and apparently I
hadn't, and ran aground on the 100 character filename limit and some of
the src files got their names chopped off. Nuked the whole lot and
re-extracted. Stay tuned ...

[mommycalled]

On Jul 23, 10:22 am, Riot Nrrrd™ <[e-mail]:

On 2008-07-10 07:02:07 -0700, Andrew Haley
<[e-mail]:

In gnu.gcc.help Dave <[e-mail]:

Andrew Haley wrote:
In gnu.gcc.help Andrew Haley <[e-mail]:
In gnu.gcc.help Thad Smith <[e-mail]:

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

Once again the stupid linux weenies claiming to know all about
everything, who cann't get software written without adding their own
little bit of extension to fundamental tools. Of course when they add
their own little tweak it breaks every other tool. As usual the
response is "My tweak should have been part of the definition they
just didn't listen to me" I run into this more and more. A major
scientific package won't compile on anything but DeadRat because the
developers made use of all sorts of DeadRat-only features. Net result
it won't run on SUSE and you cann't compile it on anything but DeadRat
without rewriting majors chunks of it.

[Richard B. Gilbert]

mo*********@gmail.com wrote:

On Jul 23, 10:22 am, Riot Nrrrd™ <[e-mail]:

>On 2008-07-10 07:02:07 -0700, Andrew Haley
<[e-mail]:

>>In gnu.gcc.help Dave <[e-mail]:
Andrew Haley wrote:
In gnu.gcc.help Andrew Haley <[e-mail]:
>In gnu.gcc.help Thad Smith <[e-mail]:
>>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)

Once again the stupid linux weenies claiming to know all about
everything, who cann't get software written without adding their own
little bit of extension to fundamental tools. Of course when they add
their own little tweak it breaks every other tool. As usual the
response is "My tweak should have been part of the definition they
just didn't listen to me" I run into this more and more. A major
scientific package won't compile on anything but DeadRat because the
developers made use of all sorts of DeadRat-only features. Net result
it won't run on SUSE and you cann't compile it on anything but DeadRat
without rewriting majors chunks of it.

Well, complete creative freedom and standards don't mix too well. Since
a Linux package that rhymes with DeadRat is free and not terribly fussy
about what hardware it runs on, using the software in question should
not be too great a hardship! The copy I bought, years ago, cost me $100
US for which I got about 10 CD-ROMS with executable software, sources,
and some documentation. If I had wanted to, I could have downloaded it
for free but with no support. "Support" consisted of about 25 GB of
patches over the course of a year.

Or, if you just CAN'T STAND IT, you can do the major rewrite. . . .

[mommycalled]

On Aug 8, 2:07 pm, "Richard B. Gilbert" <[e-mail]>
wrote:

[e-mail] wrote:

On Jul 23, 10:22 am, Riot Nrrrd™ <[e-mail]:

On 2008-07-10 07:02:07 -0700, Andrew Haley
<[e-mail]:

>In gnu.gcc.help Dave <[e-mail]:
Andrew Haley wrote:
In gnu.gcc.help Andrew Haley <[e-mail]:
In gnu.gcc.help Thad Smith <[e-mail]:
>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)

Once again the stupid linux weenies claiming to know all about
everything, who cann't get software written without adding their own
little bit of extension to fundamental tools. Of course when they add
their own little tweak it breaks every other tool. As usual the
response is "My tweak should have been part of the definition they
just didn't listen to me" I run into this more and more. A major
scientific package won't compile on anything but DeadRat because the
developers made use of all sorts of DeadRat-only features. Net result
it won't run on SUSE and you cann't compile it on anything but DeadRat
without rewriting majors chunks of it.

Well, complete creative freedom and standards don't mix too well. Since
a Linux package that rhymes with DeadRat is free and not terribly fussy
about what hardware it runs on, using the software in question should
not be too great a hardship! The copy I bought, years ago, cost me $100
US for which I got about 10 CD-ROMS with executable software, sources,
and some documentation. If I had wanted to, I could have downloaded it
for free but with no support. "Support" consisted of about 25 GB of
patches over the course of a year.

Or, if you just CAN'T STAND IT, you can do the major rewrite. . . .

DeadRat not fussy!!! I'd like some of the stuff you're smoke'n