[Bug c/85678] -fno-common should be default

2023-04-24 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

--- Comment #17 from Sam James  ---
(In reply to David Brown from comment #15)
> This has been implemented in gcc 10, and -fno-common is now the default. 
> This "bug" can presumably now be closed.
> 
> Many thanks to the gcc developers here.

Done in r10-4867-g6271dd984d7f92.

[Bug c/85678] -fno-common should be default

2023-04-24 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

Sam James  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91093,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91092
 CC||sjames at gcc dot gnu.org

--- Comment #16 from Sam James  ---
For the record, this was done on the Clang side as
https://reviews.llvm.org/D75056.

Also adding -Wimplicit-function-declaration to See Also, along with
-Wimplicit-int and stricter prototypes given they're all related to the same
era + need care in distributions first (which Florian and I are working on).

(Maybe we want a tracker for these, not sure.)

[Bug c/85678] -fno-common should be default

2020-07-22 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c/85678] -fno-common should be default

2020-07-22 Thread david at westcontrol dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

David Brown  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #15 from David Brown  ---
This has been implemented in gcc 10, and -fno-common is now the default.  This
"bug" can presumably now be closed.

Many thanks to the gcc developers here.

[Bug c/85678] -fno-common should be default

2019-11-25 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82922

--- Comment #14 from Eric Gallager  ---
(In reply to David Brown from comment #11)
> Reliance on -fcommon has not been correct or compatible with any C standard
> (I don't think it was even right for K C).  If the code is written
> correctly (with at most one definition of all externally linked symbols)
> then -fcommon does not make it incorrect or conflict with the standards. 
> But if your code requires -fcommon to compile correctly, it does not conform
> to C89 or anything newer.
> 
> Personally, I'd like to see many old and dangerous C practices give errors
> by default.  Along with common symbols, I'd include non-prototype function
> declarations and definitions, and calling functions without declaring them. 
> These are the kind of thing you'd expect to see in pre-ANSI C - other than
> that, they  are probably errors in the code.  It is good that gcc still
> supports such code, but I think making them errors by default will reduce
> bugs in current code.  And surely that is worth the cost of adding a
> "-fold-code" flag to ancient build recipes?  (The "-fold-code" flag could
> probably also imply "-fno-strict-aliasing -fwrapv" to deal with other
> assumptions sometimes made in older code.)
> 
> There is precedence for this.  The default standard for gcc changed from
> "gnu89" to "gnu11".  While most "gnu89" code will compile with the same
> semantics in "gnu11" mode, there are a fair number of incompatibilities. 
> Changing the default to "-fno-common" (and ideally
> "-Werror=strict-prototypes -Werror=old-style-declaration
> -Werror=missing-parameter-type") would have a lot smaller impact than
> changing the default standard.

Related: bug 82922

[Bug c/85678] -fno-common should be default

2019-11-25 Thread fw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

--- Comment #13 from Florian Weimer  ---
(In reply to Wilco from comment #12)
> Giving errors on old-style code by default sounds like a good idea. We could
> add -std=legacy similar to Fortran to support building old K code (and
> that would enable -fcommon by default).

It's unfortunately not that simple. A lot of these changes (admittedly I've
only tried -Werror=implicit-function-declaration by default, something that
trips even experienced developers) tend to produce broken, but internally
consistent builds because autoconf checks give wrong results (and everything,
including the test suite, depends on those results). This was true for a
significant number of core GNU components until this year, including GCC
itself.

[Bug c/85678] -fno-common should be default

2019-11-25 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

--- Comment #12 from Wilco  ---
(In reply to David Brown from comment #11)

> Changing the default to "-fno-common" (and ideally
> "-Werror=strict-prototypes -Werror=old-style-declaration
> -Werror=missing-parameter-type") would have a lot smaller impact than
> changing the default standard.

Giving errors on old-style code by default sounds like a good idea. We could
add -std=legacy similar to Fortran to support building old K code (and that
would enable -fcommon by default).

[Bug c/85678] -fno-common should be default

2019-11-25 Thread david at westcontrol dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

--- Comment #11 from David Brown  ---
Reliance on -fcommon has not been correct or compatible with any C standard (I
don't think it was even right for K C).  If the code is written correctly
(with at most one definition of all externally linked symbols) then -fcommon
does not make it incorrect or conflict with the standards.  But if your code
requires -fcommon to compile correctly, it does not conform to C89 or anything
newer.

Personally, I'd like to see many old and dangerous C practices give errors by
default.  Along with common symbols, I'd include non-prototype function
declarations and definitions, and calling functions without declaring them. 
These are the kind of thing you'd expect to see in pre-ANSI C - other than
that, they  are probably errors in the code.  It is good that gcc still
supports such code, but I think making them errors by default will reduce bugs
in current code.  And surely that is worth the cost of adding a "-fold-code"
flag to ancient build recipes?  (The "-fold-code" flag could probably also
imply "-fno-strict-aliasing -fwrapv" to deal with other assumptions sometimes
made in older code.)

There is precedence for this.  The default standard for gcc changed from
"gnu89" to "gnu11".  While most "gnu89" code will compile with the same
semantics in "gnu11" mode, there are a fair number of incompatibilities. 
Changing the default to "-fno-common" (and ideally "-Werror=strict-prototypes
-Werror=old-style-declaration -Werror=missing-parameter-type") would have a lot
smaller impact than changing the default standard.

[Bug c/85678] -fno-common should be default

2019-11-25 Thread dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

--- Comment #10 from David Binderman  ---
(In reply to Jonathan Wakely from comment #9)
> C89 6.7p4 looks equivalent to C99 6.9p5, so I don't see why -std=c89 should
> imply -fcommon.

To reduce costs in upgrading to post-revision 278509 compilers.

-std=c89 implies old code. Old code relies on old behaviour. Providing
old behaviour by default means that compiler users don't have to
suddenly put "-fcommon" in all their old code Makefiles to get compilation.

I am not sure about intermediate cases like c99, but certainly
newer language standards (c11, ...) can adopt the new behaviour.

[Bug c/85678] -fno-common should be default

2019-11-25 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

--- Comment #9 from Jonathan Wakely  ---
C89 6.7p4 looks equivalent to C99 6.9p5, so I don't see why -std=c89 should
imply -fcommon. It's just as bad in C89 as in later standards.

[Bug c/85678] -fno-common should be default

2019-11-25 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

--- Comment #8 from Wilco  ---
(In reply to David Binderman from comment #7)
> (In reply to David Brown from comment #0)
> > Surely it is time to make "-fno-common" the default, at least when a modern
> > C standard is specified indicating that the code is modern?  People who need
> > the old behaviour can always get it with "-fcommon".
> 
> Interestingly, use of -std=c89 or -std=gnu89 doesn't also switch on -fcommon
> to get old behaviour.
> 
> So use of compiler flag indicating to compile code to old standards
> means implicit use of *new* standard for common.
> 
> Looks odd to me. Possible bug ?

If required, it would be feasible to keep the old behaviour for C89 indeed,
however -fno-common is not incompatible with C89 (embedded C compilers may not
even support -fcommon).

[Bug c/85678] -fno-common should be default

2019-11-25 Thread dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #7 from David Binderman  ---
(In reply to David Brown from comment #0)
> Surely it is time to make "-fno-common" the default, at least when a modern
> C standard is specified indicating that the code is modern?  People who need
> the old behaviour can always get it with "-fcommon".

Interestingly, use of -std=c89 or -std=gnu89 doesn't also switch on -fcommon
to get old behaviour.

So use of compiler flag indicating to compile code to old standards
means implicit use of *new* standard for common.

Looks odd to me. Possible bug ?

[Bug c/85678] -fno-common should be default

2019-10-25 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #6 from Wilco  ---
(In reply to Jonathan Wakely from comment #5)
> The other bug links to a patch to change the default:
> 
> https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01549.html

Updated patch: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01847.html

[Bug c/85678] -fno-common should be default

2019-10-25 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Jonathan Wakely  ---
The other bug links to a patch to change the default:

https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01549.html

[Bug c/85678] -fno-common should be default

2019-10-24 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

--- Comment #4 from Eric Gallager  ---
This keeps getting brought up in bug 91766 (already added as related from the
other end)

[Bug c/85678] -fno-common should be default

2018-05-08 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-08
Version|unknown |9.0
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Confirmed (and agreed).

[Bug c/85678] -fno-common should be default

2018-05-07 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

--- Comment #2 from Andrew Pinski  ---
https://gcc.gnu.org/ml/gcc/2017-09/msg00088.html

[Bug c/85678] -fno-common should be default

2018-05-07 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
I think this discussion has been had on either the main gcc mailing list or
gcc-patches recently, but I forget the link...