Converting to ISO C89

Converting to ISO C89

[Mark Mitchell]

The SC has finally finished voting on ISO C89 conversion.  (The
mailing list for the SC experienced some problems, which caused things
to bog down a bit.)

The verdict is in: it is OK to assume ISO C89 in all code in GCC
proper.  (In other words, libiberty and/or other libraries are not
affected.)

So, patches to do ISO C conversions on the mainline are hereby
pre-approved with one caveat: I would appreciate it if people would
wait until GCC 3.3 is out the door.  The reason is that we're still
applying a lot of patches to both branches, and that process is tricky
enough without creating a lot of spurious merge conflicts.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: Converting to ISO C89

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| The SC has finally finished voting on ISO C89 conversion.  (The
| mailing list for the SC experienced some problems, which caused things
| to bog down a bit.)
| 
| The verdict is in: it is OK to assume ISO C89 in all code in GCC
| proper.  (In other words, libiberty and/or other libraries are not
| affected.)

Great! 

Is the topic on using C++ in the Java front-end handled by the SC?

Thanks,

| So, patches to do ISO C conversions on the mainline are hereby
| pre-approved with one caveat: I would appreciate it if people would
| wait until GCC 3.3 is out the door.  The reason is that we're still
| applying a lot of patches to both branches, and that process is tricky
| enough without creating a lot of spurious merge conflicts.

Seconded.

-- Gaby

Re: Converting to ISO C89

[Mark Mitchell]

> Great! 
> 
> Is the topic on using C++ in the Java front-end handled by the SC?

If necessary, the SC could deal with this.  

But it would be much better if there were consensus here first.

I think the topic of using C++ in gcj is different: it doesn't affect
the end-user.  Using C89 in GCC means that the user must start with a
C89 compiler; using C++ in gcj doesn't affect the set of tools the user
must have at all.  So, I think it's more a technical decision than an SC
decison.

That's just my opinion.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: Converting to ISO C89

[Kaveh R. Ghazi]

 > > Great! 
 > > 
 > > Is the topic on using C++ in the Java front-end handled by the SC?
 > 
 > If necessary, the SC could deal with this.  
 > 
 > But it would be much better if there were consensus here first.
 > 
 > I think the topic of using C++ in gcj is different: it doesn't affect
 > the end-user.  Using C89 in GCC means that the user must start with a
 > C89 compiler; using C++ in gcj doesn't affect the set of tools the
 > user must have at all.  So, I think it's more a technical decision
 > than an SC decison.

Agreed.

IMHO once we've decided to require ISO C89 to bootstrap, we should
remove gcc-isms from the cp/ dir and compile cc1plus during stage1.
We can perhaps condition cc1plus during stage1 iff java is enabled.

Then java (and all other) frontends can use C++ wherever it makes
sense.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Converting to ISO C89

[Raja R Harinath]

Hi,

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

>  > > Great! 
>  > > 
>  > > Is the topic on using C++ in the Java front-end handled by the SC?
>  > 
>  > If necessary, the SC could deal with this.  
>  > 
>  > But it would be much better if there were consensus here first.
>  > 
>  > I think the topic of using C++ in gcj is different: it doesn't affect
>  > the end-user.  Using C89 in GCC means that the user must start with a
>  > C89 compiler; using C++ in gcj doesn't affect the set of tools the
>  > user must have at all.  So, I think it's more a technical decision
>  > than an SC decison.
>
> Agreed.
>
> IMHO once we've decided to require ISO C89 to bootstrap, we should
> remove gcc-isms from the cp/ dir and compile cc1plus during stage1.
> We can perhaps condition cc1plus during stage1 iff java is enabled.

Hopefully the ISO C89 changes also make the source C++-safe.  In which
case, eventually there should be some way of running a stage2
bootstrap with that 'cc1plus' in addition to 'cc1'.  Running that
occasionally and comparing it with 'cc1' would ensure more uniformity.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu

Re: Converting to ISO C89

[Zack Weinberg]

Raja R Harinath <harinath@cs.umn.edu> writes:

> Hopefully the ISO C89 changes also make the source C++-safe.

It will not.  There is extensive use of identifiers which are C++
keywords, such as 'class' and 'delete'.  I do not think your
suggestion is useful enough to warrant changing all of these
identifiers.

What might be useful is an optional mode for the C compiler in which
function names get mangled as they would be in C++.  That would have
the effect of type-checking procedure calls across translation units
at link time.  To avoid mangling calls into libc it would have to be
switchable within each translation unit -- one plausible approach is
to recognize extern "C" and extern "C++" in C, another is #pragma.

(This extension would *not* provide function overloading in C; it
would affect only the DECL_ASSEMBLER_NAME of functions declared under
the special regime.)

zw

Re: Converting to ISO C89

[Falk Hueffner]

Zack Weinberg <zack@codesourcery.com> writes:

> Raja R Harinath <harinath@cs.umn.edu> writes:
> > Hopefully the ISO C89 changes also make the source C++-safe.
> 
> It will not.  There is extensive use of identifiers which are C++
> keywords, such as 'class' and 'delete'.  I do not think your
> suggestion is useful enough to warrant changing all of these
> identifiers.

Couldn't that be easily worked around with -Dclass=__class or
something?

-- 
	Falk

Re: Converting to ISO C89

[Raja R Harinath]

Hi,

Zack Weinberg <zack@codesourcery.com> writes:

> Raja R Harinath <harinath@cs.umn.edu> writes:
>
>> Hopefully the ISO C89 changes also make the source C++-safe.
>
> It will not.  There is extensive use of identifiers which are C++
> keywords, such as 'class' and 'delete'.  I do not think your
> suggestion is useful enough to warrant changing all of these
> identifiers.

Fair enough.

> What might be useful is an optional mode for the C compiler in which
> function names get mangled as they would be in C++.  That would have
> the effect of type-checking procedure calls across translation units
> at link time.  To avoid mangling calls into libc it would have to be
> switchable within each translation unit -- one plausible approach is
> to recognize extern "C" and extern "C++" in C, another is #pragma.

I was thinking more about optimization: ensure that there's no
abstraction penalty for using a C++ compiler on C code, and that both
the C and C++ compilers exploit the same optimization opportunities.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu

Re: Converting to ISO C89

[Zack Weinberg]

Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> writes:

> Zack Weinberg <zack@codesourcery.com> writes:
>
>> Raja R Harinath <harinath@cs.umn.edu> writes:
>> > Hopefully the ISO C89 changes also make the source C++-safe.
>> 
>> It will not.  There is extensive use of identifiers which are C++
>> keywords, such as 'class' and 'delete'.  I do not think your
>> suggestion is useful enough to warrant changing all of these
>> identifiers.
>
> Couldn't that be easily worked around with -Dclass=__class or
> something?

Is this not a cure worse than the disease?

zw

Re: Converting to ISO C89

[tm_gccmail]

On Tue, 25 Mar 2003, Raja R Harinath wrote:

> Hi,
> 
> Zack Weinberg <zack@codesourcery.com> writes:
> 
> > Raja R Harinath <harinath@cs.umn.edu> writes:
> >
> >> Hopefully the ISO C89 changes also make the source C++-safe.
> >
> > It will not.  There is extensive use of identifiers which are C++
> > keywords, such as 'class' and 'delete'.  I do not think your
> > suggestion is useful enough to warrant changing all of these
> > identifiers.
> 
> Fair enough.
> 
> > What might be useful is an optional mode for the C compiler in which
> > function names get mangled as they would be in C++.  That would have
> > the effect of type-checking procedure calls across translation units
> > at link time.  To avoid mangling calls into libc it would have to be
> > switchable within each translation unit -- one plausible approach is
> > to recognize extern "C" and extern "C++" in C, another is #pragma.
> 
> I was thinking more about optimization: ensure that there's no
> abstraction penalty for using a C++ compiler on C code, and that both
> the C and C++ compilers exploit the same optimization opportunities.
> 
> - Hari

IIRC, C code compiled as C++ needs to carry around stack unwinding
information whereas C code compiled as C does not.

Therefore, the abstraction penalty cannot be zero in terms of code size.

Toshi

Re: Converting to ISO C89

[Falk Hueffner]

Zack Weinberg <zack@codesourcery.com> writes:

> Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> writes:
> 
> > Zack Weinberg <zack@codesourcery.com> writes:
> >
> >> Raja R Harinath <harinath@cs.umn.edu> writes:
> >> > Hopefully the ISO C89 changes also make the source C++-safe.
> >> 
> >> It will not.  There is extensive use of identifiers which are C++
> >> keywords, such as 'class' and 'delete'.  I do not think your
> >> suggestion is useful enough to warrant changing all of these
> >> identifiers.
> >
> > Couldn't that be easily worked around with -Dclass=__class or
> > something?
> 
> Is this not a cure worse than the disease?

*shrug* I don't feel very strongly about this. It would be nice to
bootstrap gcc with g++ IMHO, because it might uncover bugs like
bootstraping gcc currently does. And identifers named after keywords
just don't seem like a major obstacle there. I'd expect other stuff,
like void* casts and enum conversions.

-- 
	Falk

Re: Converting to ISO C89

[Joe Buck]

On Tue, Mar 25, 2003 at 03:03:39PM -0800, tm_gccmail@mail.kloo.net wrote:
> > I was thinking more about optimization: ensure that there's no
> > abstraction penalty for using a C++ compiler on C code, and that both
> > the C and C++ compilers exploit the same optimization opportunities.
> > 
> > - Hari
> 
> IIRC, C code compiled as C++ needs to carry around stack unwinding
> information whereas C code compiled as C does not.

With GCC, this is an option: we can enable the stack unwinding information for C,
or disable it for C++.
 

Re: Converting to ISO C89

[Raja R Harinath]

<tm_gccmail@mail.kloo.net> writes:

> On Tue, 25 Mar 2003, Raja R Harinath wrote:
[snip stage2 bootstrap with C++ compiler]
>> I was thinking more about optimization: ensure that there's no
>> abstraction penalty for using a C++ compiler on C code, and that both
>> the C and C++ compilers exploit the same optimization opportunities.
>> 
>> - Hari
>
> IIRC, C code compiled as C++ needs to carry around stack unwinding
> information whereas C code compiled as C does not.
>
> Therefore, the abstraction penalty cannot be zero in terms of code size.

Since we know it is C code, we can compile with -fno-exceptions.  The
size of the CFG should not be significantly larger since there should
be no additional flows of control (hidden or otherwise).

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu

Re: Converting to ISO C89

[Joe Buck]

 
Raja R Harinath <harinath@cs.umn.edu> writes:
> >> > Hopefully the ISO C89 changes also make the source C++-safe.

Zack Weinberg <zack@codesourcery.com> writes:
> >> It will not.  There is extensive use of identifiers which are C++
> >> keywords, such as 'class' and 'delete'.  I do not think your
> >> suggestion is useful enough to warrant changing all of these
> >> identifiers.

Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> writes:
> > Couldn't that be easily worked around with -Dclass=__class or
> > something?
 
On Tue, Mar 25, 2003 at 02:01:54PM -0800, Zack Weinberg wrote:
> Is this not a cure worse than the disease?

As a "permanent" solution it would be fairly brittle.  But for the purpose of
an experiment, to see if any type errors can be found in GCC (due to prototype
mismatches or misuse of enums) it could be worth a shot.  It might not work
as well as expected, if some system header optionally defines a class if
__cplusplus is defined.
 

Re: Converting to ISO C89

[Zack Weinberg]

Joe Buck <jbuck@synopsys.com> writes:

> Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> writes:
>> > Couldn't that be easily worked around with -Dclass=__class or
>> > something?
>  
> On Tue, Mar 25, 2003 at 02:01:54PM -0800, Zack Weinberg wrote:
>> Is this not a cure worse than the disease?
>
> As a "permanent" solution it would be fairly brittle.  But for the purpose of
> an experiment, to see if any type errors can be found in GCC (due to prototype
> mismatches or misuse of enums) it could be worth a shot.  It might not work
> as well as expected, if some system header optionally defines a class if
> __cplusplus is defined.
>  

I'm all for experiments.  I'm just reluctant to do something this
brittle on a regular basis.

zw

Re: Converting to ISO C89

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| Raja R Harinath <harinath@cs.umn.edu> writes:
| 
| > Hopefully the ISO C89 changes also make the source C++-safe.
| 
| It will not.  There is extensive use of identifiers which are C++
| keywords, such as 'class' and 'delete'. 

Right.

| I do not think your
| suggestion is useful enough to warrant changing all of these
| identifiers.

I have plans to change those identifiers because, for feature works, I
want to be able to type-check the source with a more picly compielr
like g++.  I believe use of those identifiers are gratuitous
incompatibilities. 

-- Gaby

Re: Converting to ISO C89

[Gabriel Dos Reis]

Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> writes:

[...]

| > > Couldn't that be easily worked around with -Dclass=__class or
| > > something?
| > 
| > Is this not a cure worse than the disease?
| 
| *shrug* I don't feel very strongly about this. It would be nice to
| bootstrap gcc with g++ IMHO, because it might uncover bugs like
| bootstraping gcc currently does.

Same here.  There not real technical reasons why we should be using
thos identifiers in cp/: that brings no real benefit; it is gratuitous. 

-- Gaby

Re: Converting to ISO C89

[Zack Weinberg]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> Zack Weinberg <zack@codesourcery.com> writes:
> | I do not think your
> | suggestion is useful enough to warrant changing all of these
> | identifiers.
>
> I have plans to change those identifiers because, for feature works, I
> want to be able to type-check the source with a more picly compielr
> like g++.  I believe use of those identifiers are gratuitous
> incompatibilities. 

I'm not going to stop you.

zw

Re: Converting to ISO C89

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

[...]

| The verdict is in: it is OK to assume ISO C89 in all code in GCC
| proper.  (In other words, libiberty and/or other libraries are not
| affected.)

This patchlet modifies the Makefile machinery to support that
decision.  OK to install?

-- Gaby
2003-03-30  Gabriel Dos Reis  <gdr@integrable-solutions.net>

	* Makefile.in (STRICT_WARN): Don't warn for ISO C constructs.
	(STRICT2_WARN): Likewise.

Index: Makefile.in
===================================================================
RCS file: /cvs/gcc/gcc/gcc/Makefile.in,v
retrieving revision 1.1026
diff -p -r1.1026 Makefile.in
*** Makefile.in	23 Mar 2003 20:13:50 -0000	1.1026
--- Makefile.in	30 Mar 2003 08:14:29 -0000
*************** coverageexts = .{da,bbg}
*** 141,148 ****
  # with other compilers.  This is partially controlled by configure in
  # stage1, as not all versions of gcc understand -Wno-long-long.
  LOOSE_WARN = -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
! STRICT_WARN = -Wtraditional @strict1_warn@
! STRICT2_WARN = -Wtraditional -pedantic -Wno-long-long @WERROR@
  
  # This is set by --enable-checking.  The idea is to catch forgotten
  # "extern" tags in header files.
--- 141,148 ----
  # with other compilers.  This is partially controlled by configure in
  # stage1, as not all versions of gcc understand -Wno-long-long.
  LOOSE_WARN = -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
! STRICT_WARN = @strict1_warn@
! STRICT2_WARN = -pedantic -Wno-long-long @WERROR@
  
  # This is set by --enable-checking.  The idea is to catch forgotten
  # "extern" tags in header files.
   

Re: Converting to ISO C89

[Mark Mitchell]

On Sun, 2003-03-30 at 00:15, Gabriel Dos Reis wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> 
> [...]
> 
> | The verdict is in: it is OK to assume ISO C89 in all code in GCC
> | proper.  (In other words, libiberty and/or other libraries are not
> | affected.)
> 
> This patchlet modifies the Makefile machinery to support that
> decision.  OK to install?

Yes, that's fine.

-- Mark

Re: Converting to ISO C89

[Zack Weinberg]

Mark Mitchell <mark@codesourcery.com> writes:

> On Sun, 2003-03-30 at 00:15, Gabriel Dos Reis wrote:
>> Mark Mitchell <mark@codesourcery.com> writes:
>> 
>> [...]
>> 
>> | The verdict is in: it is OK to assume ISO C89 in all code in GCC
>> | proper.  (In other words, libiberty and/or other libraries are not
>> | affected.)
>> 
>> This patchlet modifies the Makefile machinery to support that
>> decision.  OK to install?
>
> Yes, that's fine.

You can probably also dispense with some settings of <lang>-warn in
*/Make-lang.in now.

zw

Re: Converting to ISO C89

[Alexandre Oliva]

On Mar 25, 2003, "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> wrote:

> IMHO once we've decided to require ISO C89 to bootstrap, we should
> remove gcc-isms from the cp/ dir and compile cc1plus during stage1.
> We can perhaps condition cc1plus during stage1 iff java is enabled.

> Then java (and all other) frontends can use C++ wherever it makes
> sense.

It's not that simple, unfortunately.  Without libstdc++, there's not
much of C++ any language can possibly use.

/me thinks if we're to use C++ in the compiler, it makes more sense to
require a complete, functional C++ compiler upfront, and use it in all
stages.

At least until we've moved the bootstrap process to the top-level, and
arrange for C++ programs created by each stage to be runnable in the
build tree, this is the best way to proceed.  Unless we use libtool to
link such executables or set LD_LIBRARY_PATH so that each stage's C++
libraries are found, they won't run.  And I realize most people won't
like the notion of bringing libtool into the gcc/ build machinery,
so...

Well, I thought it was worth pointing out, even if a bit late :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Converting to ISO C89

[Zack Weinberg]

Alexandre Oliva <aoliva@redhat.com> writes:

> On Mar 25, 2003, "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> wrote:
>
>> IMHO once we've decided to require ISO C89 to bootstrap, we should
>> remove gcc-isms from the cp/ dir and compile cc1plus during stage1.
>> We can perhaps condition cc1plus during stage1 iff java is enabled.
>
>> Then java (and all other) frontends can use C++ wherever it makes
>> sense.
>
> It's not that simple, unfortunately.  Without libstdc++, there's not
> much of C++ any language can possibly use.

This is true, but I think Kaveh's patches are worthwhile anyway.

> /me thinks if we're to use C++ in the compiler, it makes more sense to
> require a complete, functional C++ compiler upfront, and use it in all
> stages.

Or we could do as I suggested before and bootstrap *only* the C (and
Ada, if requested) compiler, then build the other front ends with
their runtime libraries.

zw

Re: Converting to ISO C89

[Alexandre Oliva]

On Apr  5, 2003, Zack Weinberg <zack@codesourcery.com> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:

>> It's not that simple, unfortunately.  Without libstdc++, there's not
>> much of C++ any language can possibly use.

> This is true, but I think Kaveh's patches are worthwhile anyway.

No dispute here.  I don't even know what patches you're talking about
(I'm lagging behind in gcc-patches :-(

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Converting to ISO C89

[Kaveh R. Ghazi]

 > From: Alexandre Oliva <aoliva@redhat.com>
 > 
 > On Apr  5, 2003, Zack Weinberg <zack@codesourcery.com> wrote:
 > 
 > > Alexandre Oliva <aoliva@redhat.com> writes:
 > 
 > >> It's not that simple, unfortunately.  Without libstdc++, there's not
 > >> much of C++ any language can possibly use.
 > 
 > > This is true, but I think Kaveh's patches are worthwhile anyway.
 > 
 > No dispute here.  I don't even know what patches you're talking about
 > (I'm lagging behind in gcc-patches :-(

Alex - you're right about libstdc++ and how crucial it is for most C++
programs.  However, the original motivation for this was Tom's posting
here: http://gcc.gnu.org/ml/gcc/2003-03/msg00146.html

If you read down near the bottom, you'll see that he mentions the C++
features he expected to use, namely "classes, destructors, and
exceptions."  He makes no mention of libstdc++ or STL, etc.  (Of
course, he may have simply left it out by mistake.  Tom?)

BTW, I found another use for being able to build cc1plus natively.
I've been seeing an error in the the sparc64-solaris2 testsuite run in
g++.dg/parse/stack1.C:
http://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00268.html

I couldn't debug it cause gdb doesn't seem to work on sparc64.  And I
can't reproduce the bug in a cross-compiler where gdb does work.  So
being able to compile cc1plus with native cc and use native dbx is a
bonus I hadn't counted on. :-)

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Converting to ISO C89

[Geoff Keating]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

> If you read down near the bottom, you'll see that he mentions the C++
> features he expected to use, namely "classes, destructors, and
> exceptions."  He makes no mention of libstdc++ or STL, etc.

Exceptions require at least libsupc++, which is part of libstdc++.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Converting to ISO C89

[Kaveh R. Ghazi]

 > From: Geoff Keating <geoffk@geoffk.org>
 > 
 > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
 > 
 > > If you read down near the bottom, you'll see that he mentions the C++
 > > features he expected to use, namely "classes, destructors, and
 > > exceptions."  He makes no mention of libstdc++ or STL, etc.
 > 
 > Exceptions require at least libsupc++, which is part of libstdc++.

Oh felgercarb.

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Converting to ISO C89

[Andrew Haley]

Mark Mitchell writes:
 > 
 > The SC has finally finished voting on ISO C89 conversion.  (The
 > mailing list for the SC experienced some problems, which caused things
 > to bog down a bit.)
 > 
 > The verdict is in: it is OK to assume ISO C89 in all code in GCC
 > proper.  (In other words, libiberty and/or other libraries are not
 > affected.)
 > 
 > So, patches to do ISO C conversions on the mainline are hereby
 > pre-approved with one caveat: I would appreciate it if people would
 > wait until GCC 3.3 is out the door.  The reason is that we're still
 > applying a lot of patches to both branches, and that process is tricky
 > enough without creating a lot of spurious merge conflicts.

I take it that new patches which are written in ISO C may be applied
to the 3.3 branch. 

Andrew.

Re: Converting to ISO C89

[Mark Mitchell]

On Thu, 2003-04-10 at 07:25, Andrew Haley wrote:
> Mark Mitchell writes:
>  > 
>  > The SC has finally finished voting on ISO C89 conversion.  (The
>  > mailing list for the SC experienced some problems, which caused things
>  > to bog down a bit.)
>  > 
>  > The verdict is in: it is OK to assume ISO C89 in all code in GCC
>  > proper.  (In other words, libiberty and/or other libraries are not
>  > affected.)
>  > 
>  > So, patches to do ISO C conversions on the mainline are hereby
>  > pre-approved with one caveat: I would appreciate it if people would
>  > wait until GCC 3.3 is out the door.  The reason is that we're still
>  > applying a lot of patches to both branches, and that process is tricky
>  > enough without creating a lot of spurious merge conflicts.
> 
> I take it that new patches which are written in ISO C may be applied
> to the 3.3 branch. 

I can't see why not.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: Converting to ISO C89

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| Mark Mitchell <mark@codesourcery.com> writes:
| 
| > On Sun, 2003-03-30 at 00:15, Gabriel Dos Reis wrote:
| >> Mark Mitchell <mark@codesourcery.com> writes:
| >> 
| >> [...]
| >> 
| >> | The verdict is in: it is OK to assume ISO C89 in all code in GCC
| >> | proper.  (In other words, libiberty and/or other libraries are not
| >> | affected.)
| >> 
| >> This patchlet modifies the Makefile machinery to support that
| >> decision.  OK to install?
| >
| > Yes, that's fine.
| 
| You can probably also dispense with some settings of <lang>-warn in
| */Make-lang.in now.

Will do so once I'm finished with preparing GCC-3.2.3 prerelease tarballs.

-- Gaby

Re: Converting to ISO C89

[Kaveh R. Ghazi]

 > | You can probably also dispense with some settings of <lang>-warn in
 > | */Make-lang.in now.
 > 
 > Will do so once I'm finished with preparing GCC-3.2.3 prerelease
 > tarballs.
 > -- Gaby

This can be tricky for some of the remaining cases.  One strategy is
to just take them out and see who complains.  Maybe they'll fix each
warning themselves. :-)  But here are some potential problems:

1.  Bison generated files.  Much of this was traditional warnings, but
    some versions of bison would additonally yield signed/unsigned
    warnings in their generated code.  You may want to test the
    several bison versions (1.28, 1.35, 1.50, 1.75, 1.875 ??) that are
    in use and see what happens.

2.  $(cpu).o files.  These would need a cross-compile check to one of
    each type to make sure there's nothing else besides traditional
    warnings.  I know of at least a few which had problems and I don't
    know if someone's cleaned them up in the mean time.

3.  Some of the remaining files get those "string too long" pedantic
    warnings or something else that's annoying but only for some
    platforms.  E.g. varasm.c, gcc.c, insn-conditions.c.  Again these
    would need multiple cross-compile checks to be sure.

For the cases where just one or two targets choke a file but others
pass, we could move the -Wno-error into a target dependent t-*
makefile fragment.  E.g. we do this in t-ia64 already.

Before anyone suggests it, I'd advise against turning off warnings
per-file with e.g. -Wno-sign-compare etc to work around these
problems.  It only lets more cruft creep in.

I can help with the cross-compile testing if you like.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Converting to ISO C89

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| On Thu, 2003-04-10 at 07:25, Andrew Haley wrote:
| > Mark Mitchell writes:
| >  > 
| >  > The SC has finally finished voting on ISO C89 conversion.  (The
| >  > mailing list for the SC experienced some problems, which caused things
| >  > to bog down a bit.)
| >  > 
| >  > The verdict is in: it is OK to assume ISO C89 in all code in GCC
| >  > proper.  (In other words, libiberty and/or other libraries are not
| >  > affected.)
| >  > 
| >  > So, patches to do ISO C conversions on the mainline are hereby
| >  > pre-approved with one caveat: I would appreciate it if people would
| >  > wait until GCC 3.3 is out the door.  The reason is that we're still
| >  > applying a lot of patches to both branches, and that process is tricky
| >  > enough without creating a lot of spurious merge conflicts.
| > 
| > I take it that new patches which are written in ISO C may be applied
| > to the 3.3 branch. 
| 
| I can't see why not.

That means that you would also have to OK the patch

   http://gcc.gnu.org/ml/gcc/2003-03/msg01765.html

for gcc-3_3-branch.

-- Gaby

Re: Converting to ISO C89

[Mark Mitchell]

Good point.

Given that, I'd prefer not to see ISO C89 patches making their way into the
3.3 branch.  That seems like more disruption than we need at this point.

Thanks,

-- Mark

----- Original Message -----
From: "Gabriel Dos Reis" <gdr@integrable-solutions.net>
To: "Mark Mitchell" <mark@codesourcery.com>
Cc: "Andrew Haley" <aph@redhat.com>; <gcc@gcc.gnu.org>
Sent: Saturday, April 12, 2003 6:02 AM
Subject: Re: Converting to ISO C89


> Mark Mitchell <mark@codesourcery.com> writes:
>
> | On Thu, 2003-04-10 at 07:25, Andrew Haley wrote:
> | > Mark Mitchell writes:
> | >  >
> | >  > The SC has finally finished voting on ISO C89 conversion.  (The
> | >  > mailing list for the SC experienced some problems, which caused
things
> | >  > to bog down a bit.)
> | >  >
> | >  > The verdict is in: it is OK to assume ISO C89 in all code in GCC
> | >  > proper.  (In other words, libiberty and/or other libraries are not
> | >  > affected.)
> | >  >
> | >  > So, patches to do ISO C conversions on the mainline are hereby
> | >  > pre-approved with one caveat: I would appreciate it if people would
> | >  > wait until GCC 3.3 is out the door.  The reason is that we're still
> | >  > applying a lot of patches to both branches, and that process is
tricky
> | >  > enough without creating a lot of spurious merge conflicts.
> | >
> | > I take it that new patches which are written in ISO C may be applied
> | > to the 3.3 branch.
> |
> | I can't see why not.
>
> That means that you would also have to OK the patch
>
>    http://gcc.gnu.org/ml/gcc/2003-03/msg01765.html
>
> for gcc-3_3-branch.
>
> -- Gaby
>

Re: Converting to ISO C89

[Andrew Haley]

Mark Mitchell writes:
 > Good point.
 > 
 > Given that, I'd prefer not to see ISO C89 patches making their way into the
 > 3.3 branch.  That seems like more disruption than we need at this point.

Too late.  I've done it now, with http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01532.html.

We can convert that patch to K&R if needs be.  It'll only take ten minutes to do that.

Andrew.

Re: Converting to ISO C89

[Andrew Haley]

Andrew Haley writes:
 > Mark Mitchell writes:
 >  > Good point.
 >  > 
 >  > Given that, I'd prefer not to see ISO C89 patches making their way into the
 >  > 3.3 branch.  That seems like more disruption than we need at this point.
 > 
 > Too late.  I've done it now, with http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01532.html.
 > 
 > We can convert that patch to K&R if needs be.  It'll only take ten minutes to do that.

Should I convert this patch to K%R?

Andrew.

Re: Converting to ISO C89

[Kaveh R. Ghazi]

 > Andrew Haley writes:
 >  > Mark Mitchell writes:
 >  >  > Good point.
 >  >  > 
 >  >  > Given that, I'd prefer not to see ISO C89 patches making their way into the
 >  >  > 3.3 branch.  That seems like more disruption than we need at this point.
 >  > 
 >  > Too late.  I've done it now, with http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01532.html.
 >  > 
 >  > We can convert that patch to K&R if needs be.  It'll only take ten minutes to do that.
 > 
 > Should I convert this patch to K%R?
 > Andrew.

No.  Stuff in the language subdirs doesn't need to conform to K&R
style, regardless of the branch.  We don't pass -Wtraditional to the
java dir, for example.  If you're not getting a -Wtraditional warning,
don't worry about it.

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu