Re: c++/4092: Use of ANSI features in gcc/cp/class.c

Re: c++/4092: Use of ANSI features in gcc/cp/class.c

[Franz Sirl]

The following reply was made to PR c++/4092; it has been noted by GNATS.

From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: rkl@connect.org.uk
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/4092: Use of ANSI features in gcc/cp/class.c
Date: Thu, 23 Aug 2001 16:34:07 +0200

 At 16:04 23.08.2001, rkl@connect.org.uk wrote:
 
 > >Number:         4092
 > >Category:       c++
 > >Synopsis:       Use of ANSI features in gcc/cp/class.c
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    unassigned
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Thu Aug 23 07:06:01 PDT 2001
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     rkl@connect.org.uk
 > >Release:        gcc 3.0.1
 > >Organization:
 > >Environment:
 >HP-UX 11.00, but applies to all platforms
 > >Description:
 >In gcc/cp/class.c, there's a few places where ANSI C
 >constructs are used, which prevents the source being
 >compiled with a K&R compiler (which you do need to do
 >for this file):
 >
 >Line 2382 (end of finish_struct_methods() function):
 >
 >     qsort (&TREE_VEC_ELT (method_vec, slot), len-slot, sizeof (tree),
 >            (int (*)(const void *, const void *))method_name_cmp);
 >
 >(the function prototype for method_name_cmp causes a K&R C
 >compiler to bomb out)
 >
 >Line 5463 (middle of finish_struct_1() function):
 >
 >       qsort (&TREE_VEC_ELT (field_vec, 0), n_fields, sizeof (tree),
 >              (int (*)(const void *, const void *))field_decl_cmp);
 >
 >(same problem as the one above)
 >
 >Line 4018 (layout_nonempty_base_or_field):
 >
 >       struct record_layout_info_s old_rli = *rli;
 >
 >(this assignment is illegal in K&R C)
 > >How-To-Repeat:
 >Build gcc 3.0.1 with a strictly K&R C compiler - you can
 >use the "standard" cc in HP-UX (or the HP-UX ANSI C with
 >CFLAGS="-Ac") to reproduce this. On a side note, it appears
 >to me that the gcc team don't actually do this - there
 >are other instances of K&R-illegal code in gcc 3.0.1 as
 >well (if I get the time, I'll file them, but this bug
 >should hopefully spark the developers to fix them all).
 >
 >Not allowing
 >K&R C compilers to build gcc 3.X is quite poor, IMHO,
 >especially since you could with 2.95.3.
 > >Fix:
 >Conditionalise the statements with "#ifdef __STDC__" - for
 >example, the first one in my source now reads:
 >
 >     qsort (&TREE_VEC_ELT (method_vec, slot), len-slot, sizeof (tree),
 >#ifdef __STDC__
 >            (int (*)(const void *, const void *))method_name_cmp);
 >#else
 >            method_name_cmp);
 >#endif
 > >Release-Note:
 > >Audit-Trail:
 > >Unformatted:
 
 Before you continue to file bugs, read the build instructions, you are 
 supposed to do a 'make bootstrap', not a simple 'make' for a native build.
 
 Franz.
 

Re: c++/4092: Use of ANSI features in gcc/cp/class.c

[aoliva]

Synopsis: Use of ANSI features in gcc/cp/class.c

State-Changed-From-To: open->closed
State-Changed-By: aoliva
State-Changed-When: Fri Aug 24 01:36:31 2001
State-Changed-Why:
    Not a bug.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=4092&database=gcc

Re: c++/4092: Use of ANSI features in gcc/cp/class.c

[Graham Stott]

The following reply was made to PR c++/4092; it has been noted by GNATS.

From: Graham Stott <grahams@redhat.com>
To: rkl@connect.org.uk
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/4092: Use of ANSI features in gcc/cp/class.c
Date: Thu, 23 Aug 2001 16:49:31 +0100

 rkl@connect.org.uk wrote:
 > 
 > >Number:         4092
 > >Category:       c++
 > >Synopsis:       Use of ANSI features in gcc/cp/class.c
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    unassigned
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Thu Aug 23 07:06:01 PDT 2001
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     rkl@connect.org.uk
 > >Release:        gcc 3.0.1
 > >Organization:
 > >Environment:
 > HP-UX 11.00, but applies to all platforms
 > >Description:
 > In gcc/cp/class.c, there's a few places where ANSI C
 > constructs are used, which prevents the source being
 > compiled with a K&R compiler (which you do need to do
 > for this file):
 > 
 > Line 2382 (end of finish_struct_methods() function):
 > 
 >     qsort (&TREE_VEC_ELT (method_vec, slot), len-slot, sizeof (tree),
 >            (int (*)(const void *, const void *))method_name_cmp);
 > 
 > (the function prototype for method_name_cmp causes a K&R C
 > compiler to bomb out)
 > 
 > Line 5463 (middle of finish_struct_1() function):
 > 
 >       qsort (&TREE_VEC_ELT (field_vec, 0), n_fields, sizeof (tree),
 >              (int (*)(const void *, const void *))field_decl_cmp);
 > 
 > (same problem as the one above)
 > 
 > Line 4018 (layout_nonempty_base_or_field):
 > 
 >       struct record_layout_info_s old_rli = *rli;
 > 
 > (this assignment is illegal in K&R C)
 > >How-To-Repeat:
 > Build gcc 3.0.1 with a strictly K&R C compiler - you can
 > use the "standard" cc in HP-UX (or the HP-UX ANSI C with
 > CFLAGS="-Ac") to reproduce this. On a side note, it appears
 > to me that the gcc team don't actually do this - there
 > are other instances of K&R-illegal code in gcc 3.0.1 as
 > well (if I get the time, I'll file them, but this bug
 > should hopefully spark the developers to fix them all).
 > 
 > Not allowing
 > K&R C compilers to build gcc 3.X is quite poor, IMHO,
 > especially since you could with 2.95.3.
 > >Fix:
 > Conditionalise the statements with "#ifdef __STDC__" - for
 > example, the first one in my source now reads:
 > 
 >     qsort (&TREE_VEC_ELT (method_vec, slot), len-slot, sizeof (tree),
 > #ifdef __STDC__
 >            (int (*)(const void *, const void *))method_name_cmp);
 > #else
 >            method_name_cmp);
 > #endif
 > >Release-Note:
 > >Audit-Trail:
 > >Unformatted:
 
 Sorry but this is not a bug you need to use make bootstrap.
 
 Graham

c++/4092: Use of ANSI features in gcc/cp/class.c

[rkl]

>Number:         4092
>Category:       c++
>Synopsis:       Use of ANSI features in gcc/cp/class.c
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Aug 23 07:06:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     rkl@connect.org.uk
>Release:        gcc 3.0.1
>Organization:
>Environment:
HP-UX 11.00, but applies to all platforms
>Description:
In gcc/cp/class.c, there's a few places where ANSI C
constructs are used, which prevents the source being
compiled with a K&R compiler (which you do need to do
for this file):

Line 2382 (end of finish_struct_methods() function):

    qsort (&TREE_VEC_ELT (method_vec, slot), len-slot, sizeof (tree),
           (int (*)(const void *, const void *))method_name_cmp);

(the function prototype for method_name_cmp causes a K&R C
compiler to bomb out)

Line 5463 (middle of finish_struct_1() function):

      qsort (&TREE_VEC_ELT (field_vec, 0), n_fields, sizeof (tree),
             (int (*)(const void *, const void *))field_decl_cmp);

(same problem as the one above)

Line 4018 (layout_nonempty_base_or_field):

      struct record_layout_info_s old_rli = *rli;

(this assignment is illegal in K&R C)
>How-To-Repeat:
Build gcc 3.0.1 with a strictly K&R C compiler - you can
use the "standard" cc in HP-UX (or the HP-UX ANSI C with
CFLAGS="-Ac") to reproduce this. On a side note, it appears
to me that the gcc team don't actually do this - there
are other instances of K&R-illegal code in gcc 3.0.1 as
well (if I get the time, I'll file them, but this bug
should hopefully spark the developers to fix them all).

Not allowing
K&R C compilers to build gcc 3.X is quite poor, IMHO,
especially since you could with 2.95.3.
>Fix:
Conditionalise the statements with "#ifdef __STDC__" - for
example, the first one in my source now reads:

    qsort (&TREE_VEC_ELT (method_vec, slot), len-slot, sizeof (tree),
#ifdef __STDC__
           (int (*)(const void *, const void *))method_name_cmp);
#else
           method_name_cmp);
#endif
>Release-Note:
>Audit-Trail:
>Unformatted: