https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
Sam James changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
Florian Weimer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #22 from GCC Commits ---
The master branch has been updated by Florian Weimer :
https://gcc.gnu.org/g:55e94561e97ed0bce4774aa1c6b5d5d82209a379
commit r14-6033-g55e94561e97ed0bce4774aa1c6b5d5d82209a379
Author: Florian Weimer
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #21 from Sam James ---
Followers of this bug may be interested to learn:
1. Clang has made this change in LLVM 15 (as well as some other related
changes:
https://releases.llvm.org/15.0.0/tools/clang/docs/ReleaseNotes.html#improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #19 from Rich Felker ---
Re comment 17, non-prototype declarations might be error-prone, but they're
valid C and necessary for certain usage cases. The motivation for making this
error-by-default is that "implicit function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #18 from Rich Felker ---
Just to clarify, an "implicit function declaration" is use of a token that
could be an identifier as the operand of the function call operator (), with no
declaration for the identifier in scope. A non-prototy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #17 from Vincent Lefèvre ---
(In reply to Florian Weimer from comment #16)
> (In reply to Vincent Lefèvre from comment #15)
> > OK, but the issue is similar: in both cases, the parameters/arguments are
> > not checked, yielding undefi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #16 from Florian Weimer ---
(In reply to Vincent Lefèvre from comment #15)
> (In reply to Florian Weimer from comment #14)
> > (In reply to Vincent Lefèvre from comment #13)
> > > By "implicit function declarations", does this include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #15 from Vincent Lefèvre ---
(In reply to Florian Weimer from comment #14)
> (In reply to Vincent Lefèvre from comment #13)
> > By "implicit function declarations", does this include K&R style
> > declarations?
>
> No, there is nothi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #14 from Florian Weimer ---
(In reply to Vincent Lefèvre from comment #13)
> By "implicit function declarations", does this include K&R style
> declarations?
No, there is nothing implicit about them.
> I've found out a few days ago
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #13 from Vincent Lefèvre ---
By "implicit function declarations", does this include K&R style declarations?
I've found out a few days ago that GMP still uses K&R style declarations, and
that's in a configure script. The issue is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #11 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
See A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #9 from Florian Weimer ---
(In reply to Andreas Schwab from comment #8)
> What about cmake, metaconfig, meson, scons, ...
I hope that the more modern things get this correct and encourage more
high-level checks.
I plan to build Fedo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #8 from Andreas Schwab ---
What about cmake, metaconfig, meson, scons, ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #7 from Florian Weimer ---
(In reply to Jonathan Wakely from comment #5)
> Would an ugly but pragmatic approach be possible? e.g. if the first line of
> the translation unit is "/* confdefs.h */ then assume GCC is being invoked
> by c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #6 from Jonathan Wakely ---
But don't do that if -Werror=implicit-function-declaration was used explicitly,
because maybe the configure test is actually trying to detect that error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #5 from Jonathan Wakely ---
Would an ugly but pragmatic approach be possible? e.g. if the first line of the
translation unit is "/* confdefs.h */ then assume GCC is being invoked by
configure, and only warn instead of giving an error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #4 from Jonathan Wakely ---
And it doesn't help all the existing configure scripts, that won't get
regenerated even if a new autoconf is released.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #2 from Florian Weimer ---
Current util-linux is an example:
$ ./configure
[…]
checking wchar_t support... yes
[…]
$ ./configure CC="gcc -Werror=implicit-function-declaration"
[…]
configure: WARNING: wchar_t support not found; not bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
24 matches
Mail list logo
