Re: [COMMITTED] Doc: Document _Bool type as C90 extension [PR118118]

* Sandra Loosemore: > @@ -13698,6 +13699,17 @@ Forward-declaring an incomplete enum type without an > explicit > underlying type is supported as an extension in all GNU C dialects, > but is not supported at all in GNU C++. > > +@node Boolean Type > +@subsection Support for the @code{_Bool} Ty

Re: [PATCH, V3] PR target/118541 - Do not generate unordered fp cmoves for IEEE compares on PowerPC

* Michael Meissner: > On Mon, Mar 24, 2025 at 09:15:26PM +0100, Florian Weimer wrote: >> * Michael Meissner: >> >> > +enum reverse_cond_t { >> > + REVERSE_COND_ORDERED_OK, >> > + REVERSE_COND_NO_ORDERED >> > +}; >> >> This s

Re: [PATCH, V3] PR target/118541 - Do not generate unordered fp cmoves for IEEE compares on PowerPC

* Michael Meissner: > +enum reverse_cond_t { > + REVERSE_COND_ORDERED_OK, > + REVERSE_COND_NO_ORDERED > +}; This should probably be something like enum reverse_cond_t { ordered_ok, no_ordered, }; to inhibit implicit conversion to integer types and bool. (Completely untested.) > + > ex

Re: [PATCH][v2] add -[DU]_FORTIFY_SOURCE[=n] to DW_AT_producer

* Richard Biener: > @@ -3869,6 +3867,18 @@ gen_command_line_string (cl_decoded_option *options, >case OPT_fchecking_: > /* Ignore these. */ > continue; > + case OPT_D: > + case OPT_U: > + if (startswith (options[i].arg, "_FORTIFY_SOURCE") > + && (options[

Re: [PATCH][v2] add -[DU]_FORTIFY_SOURCE[=n] to DW_AT_producer

* Richard Biener: > On Fri, 14 Mar 2025, Florian Weimer wrote: > >> * Richard Biener: >> >> > @@ -3869,6 +3867,18 @@ gen_command_line_string (cl_decoded_option *options, >> >case OPT_fchecking_: >> >/* Ignore these. */ >> >co

Re: [PATCH][_Hashtable] Fix hash code cache usage

* Jonathan Wakely: >> I still think this is more confusing than necessary. If there isn't >> some general rule that empty objects can be considered stateless, that >> should be added somewhere, too. 8-) > > Could you submit an issue (or two)? > https://cplusplus.github.io/LWG/lwg-active.html#subm

Re: [PATCH][_Hashtable] Fix hash code cache usage

* Jonathan Wakely: > On Thu, 13 Mar 2025 at 09:24, Florian Weimer wrote: >> >> * Jonathan Wakely: >> >> > On Thu, 13 Mar 2025 at 06:50, Florian Weimer wrote: >> >> >> >> * François Dumont: >> >> >> &g

Re: [PATCH][_Hashtable] Fix hash code cache usage

* Jonathan Wakely: > On Thu, 13 Mar 2025 at 06:50, Florian Weimer wrote: >> >> * François Dumont: >> >> > + // Get hash code for a node that comes from another _Hashtable. >> > + // Reuse a cached hash code if the hash function is stateless,

Re: [PATCH][_Hashtable] Fix hash code cache usage

* François Dumont: > + // Get hash code for a node that comes from another _Hashtable. > + // Reuse a cached hash code if the hash function is stateless, > + // otherwise recalculate it using our own hash function. > + __hash_code > + _M_hash_code_ext(const __node_value_ty

Re: [FYI, PATCH v3] [testsuite] add x86 effective target

* Alexandre Oliva: > diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi > index 28338324f0724..d44c2e8cbe6a1 100644 > --- a/gcc/doc/sourcebuild.texi > +++ b/gcc/doc/sourcebuild.texi > @@ -2798,6 +2798,9 @@ Target supports the execution of @code{user_msr} > instructions. > @item vec

Re: The COBOL front end, version 3, now in 14 easy pieces (+NIST)

* James K. Lowden: > As I mentioned in other posts, IMO (IANAL) the copyright in > unimportant and probably unenforceable. The National Computing > Centre no longer exists, and the document was also published by NIST > which, as part of the US government, does not copyright its > publications. I

Re: The COBOL front end, version 3, now in 14 easy pieces (+NIST)

* Paul Koning: >> On Feb 21, 2025, at 1:59 PM, Florian Weimer wrote: >> >> * James K. Lowden: >> >>> As I mentioned in other posts, IMO (IANAL) the copyright in >>> unimportant and probably unenforceable. The National Computing >>> Centre no

Re: [PATCH] c: special-case some "bool" errors with C23 [PR117629]

* David Malcolm: > whereas with this patch we emit: > > t1.c:7:13: error: 'bool' cannot be defined via 'typedef' > 7 | typedef int bool; > | ^~~~ > t1.c:7:13: note: 'bool' is a keyword with '-std=c23' onwards > t1.c:7:1: warning: useless type name in empty declaration > 7

Re: [PATCH] csky: use quotes when referring to cpus and archs [PR90160]

* Jeff Law: > On 11/26/24 9:06 AM, David Malcolm wrote: >> OK for trunk? (caveat: not properly tested) >> gcc/ChangeLog: >> PR translation/90160 >> * config/csky/csky.cc (csky_configure_build_target): Use %qs when >> referring to cpu and arch names. >> (csky_option_override):

[PATCH COMMITTED] Remove Debian from SECURITY.txt

As requested by the Debian security team. * SECURITY.txt: Remove Debian. --- SECURITY.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/SECURITY.txt b/SECURITY.txt index 126603d4c22..b38425ea223 100644 --- a/SECURITY.txt +++ b/SECURITY.txt @@ -180,7 +180,6 @@ Reporting private secur

Re: [committed] c: Default to -std=gnu23

* Joseph Myers: > Change the default language version for C compilation from -std=gnu17 > to -std=gnu23. A few tests are updated to remove local definitions of > bool, true and false (where making such an unconditional test change > seemed to make more sense than changing the test conditionally e

[PATCH v2] c: Introduce -Wfree-labels

This is another recent GCC extension whose use is apparently difficult to spot in code reviews. The name of the option is due to Jonathan Wakely. Part of it could apply to C++ as well (for labels at the end of a compound statement). gcc/c-family/ * c-opts.cc (c_common_post_options): Ini

[PATCH] c: Implement -Wdeprecated-non-prototype

This warning covers the C23 incompibilities resulting from using () as parameter lists in function declarations. The warning name comes from Clang. The implementation is not perfect because GCC treats these two declarations as equivalent: void f (); void f (not_a_type); This is a bit confus

Re: [PATCH] c: Introduce -Wfree-labels

* Jakub Jelinek: > On Fri, Nov 15, 2024 at 08:13:28PM +0100, Florian Weimer wrote: >> * Andrew Pinski: >> >> > On Fri, Nov 15, 2024 at 9:13 AM Florian Weimer wrote: >> >> >> >> This is another recent GCC extension whose use is apparently >>

Re: [PATCH] c: Introduce -Wfree-labels

* Andrew Pinski: > On Fri, Nov 15, 2024 at 9:13 AM Florian Weimer wrote: >> >> This is another recent GCC extension whose use is apparently >> difficult to spot in code reviews. >> >> The name of the option is due to Jonathan Wakely. Part of it >> could

[PATCH] c: Introduce -Wfree-labels

This is another recent GCC extension whose use is apparently difficult to spot in code reviews. The name of the option is due to Jonathan Wakely. Part of it could apply to C++ as well (for labels at the end of a compound statement). gcc/c-family/ * c-opts.cc (c_common_post_options): Ini

[PATCH COMMITTED] Regenerate gcc/c-family/c.opt.urls

After commit 8833389e90d676baabb35c3e7a021a4f5444a5ba. gcc/c-family/ * c.opt.urls: Regenerate. --- gcc/c-family/c.opt.urls | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/c-family/c.opt.urls b/gcc/c-family/c.opt.urls index 3bfe2b86b24..04f8e2ee008 100644 --- a/gcc/c-family/c.

Re: [PATCH] Report the section name in case of section type conflicts

* Jeff Law: > On 11/14/24 11:42 AM, Florian Weimer wrote: >> The section name might the user a hint of what is going on. >> I tried to include the flags as well, but there didn't seem to be >> consensus about including the internal section flags in the diagnostics: >&

[PATCH] Report the section name in case of section type conflicts

The section name might the user a hint of what is going on. I tried to include the flags as well, but there didn't seem to be consensus about including the internal section flags in the diagnostics: [RFC PATCH] More detailed diagnostics for section type conflicts

[PATCH] c: Introduce -Wmissing-parameter-name

Empirically, omitted parameter names are difficult to catch in code review. With this change, projects can build with -Werror=missing-parameter-name, to avoid this unnecessary incompatibility with older GCC versions. The existing -pedantic-errors option is too broad for that because it also flags

Re: [WIP RFC] libstdc++: add module std

* Jason Merrill: > This patch is not ready for integration, but I'd like to get feedback on the > approach (and various specific questions below). > > -- 8< -- > > This patch introduces an installed source form of module std and std.compat. > To find them, we install a libstdc++.modules.json file

Re: [RFC PATCH] More detailed diagnostics for section type conflicts

* David Malcolm: > I'm not quite sure what you mean by "non-error" and "non-anchored".  Sorry, I'm not familiar with the appropriate terminology. > By "non-error", do you mean that this should this be a warning? If so, > use warning_at. You can use 0 for the option_id whilst prototyping. > Or

Re: [RFC PATCH] More detailed diagnostics for section type conflicts

* Richard Biener: >> + append (flags & SECTION_RELRO, "RELRO"); >> + append (flags & SECTION_EXCLUDE, "EXCLUDE"); >> + append (flags & SECTION_RETAIN, "RETAIN"); >> + append (flags & SECTION_LINK_ORDER, "LINK_ORDER"); > > I'm not sure printing these internal flags is of help to the user. Ther

Re: [RFC PATCH] More detailed diagnostics for section type conflicts

* Andrew Pinski: >> + append (flags & SECTION_CODE, "CODE"); > > I notice you capture result and it seems like you could also capture > flags and change this to: > append (SECTION_CODE, "CODE"); Thanks, I've made the change locally. Florian

[RFC PATCH] More detailed diagnostics for section type conflicts

Sometimes this is a user error, sometimes it is more of an ICE. In either case, more information about the conflict is helpful. I used to this to get a better idea about what is going on with PR116887. The original diagnostics look like this: dl-find_object.c: In function ‘_dlfo_process_initial’

Re: [PATCH] libstdc++: Implement C++26 features (P2546R5)

* Jonathan Wakely: > +/** Stop the program with a breakpoint or debug trap. > + * > + * The details of how a breakpoint is implemented are platform-specific. > + * Some systems provide a special instruction, such as `int3` in x86. > + * When no more appropriate mechanism is available, this will st

Re: [PATCH v2] gcc-14: Mention that some warnings are now errors

* Sebastian Huber: > On 03.05.24 17:06, Jonathan Wakely wrote: >>> I think it would be helpful to reference this change in the C >>> section. This warning to error change causes some issues with >>> legacy software. >> I agree it should be mentioned, but I would put it in the caveats >> section at

Re: [PATCH] libquadmath: printf: fix misaligned access on args

* Simon Chopin: > On x86, this compiles into movdqa which segfaults on unaligned access. > > This kind of failure has been seen when running against glibc 2.39, > which incidentally changed the printf implementation to move away from > alloca() for this data to instead append it at the end of an e

[PATCH wwwdocs COMMITTED] gcc-14: Fix unintentional error in -Wimplicit-int example

diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html index bbbaa25a..901a1653 100644 --- a/htdocs/gcc-14/porting_to.html +++ b/htdocs/gcc-14/porting_to.html @@ -92,7 +92,7 @@ below). In the example below, the type of s should be write_string (fd, s) { -write (1,

[PATCH wwwdocs] gcc-14: Some very common historic Autoconf probes that no longer work

--- htdocs/gcc-14/porting_to.html | 43 +++ 1 file changed, 43 insertions(+) diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html index 123b5e9f..ab65c5e7 100644 --- a/htdocs/gcc-14/porting_to.html +++ b/htdocs/gcc-14/porting_to.html @

[PATCH wwwdocs] gcc-14: Add code examples for -Wreturn-mismatch

--- htdocs/gcc-14/porting_to.html | 46 --- 1 file changed, 43 insertions(+), 3 deletions(-) diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html index bbbaa25a..123b5e9f 100644 --- a/htdocs/gcc-14/porting_to.html +++ b/htdocs/gcc-14/p

[PATCH wwwdocs] CSS: Color markup for /

In addition to underlines and strikethroughs. This makes it easier to spot the differences in example code changes. --- htdocs/gcc.css | 4 1 file changed, 4 insertions(+) diff --git a/htdocs/gcc.css b/htdocs/gcc.css index 77d01ee0..e32c4b93 100644 --- a/htdocs/gcc.css +++ b/htdocs/gcc.css

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

* Gerald Pfeifer: > On Fri, 2 Feb 2024, Florian Weimer wrote: >> +Certain warnings are now errors > > That's quite a nice description, thank you, Florian! > >> +The initial ISO C standard and its 1999 revision removed support for > > May I suggest to wrap paragr

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

* Gerald Pfeifer: > On Fri, 2 Feb 2024, Florian Weimer wrote: >> htdocs/gcc-14/porting_to.html | 465 >> ++ >> 1 file changed, 465 insertions(+) >> + >> +Using pointers as integers and vice versa >> (-Werror=

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

* Gerald Pfeifer: >> This mostly happens in function definitions >> +that are not prototypes > > Naive questions: Can definitions really be prototypes (in C)? Yes, I think so: definitions can be declarations, and function prototypes are declarations. The standard uses the phrase “function defin

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

* Sam James: > It's fine if you leave this out, but consider mentioning the common > pitfall of autoconf projects not including config.h consistently before > all inclues. We could also mention AC_USE_SYSTEM_EXTENSIONS. I added: “ Alternatively, projects using using Autoconf could enable AC_USE

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

* Jonathan Wakely: >>+To fix the remaining int-conversions issues, add casts >>+to an appropriate pointer or integer type. On GNU systems, the >>+standard (but generally optional) types > > I know what you mean here, but I'm not sure the parenthesis adds > clarity for anybody who doesn't already

[PATCH] Notes on the warnings-as-errors change in GCC 14

--- htdocs/gcc-14/porting_to.html | 465 ++ 1 file changed, 465 insertions(+) diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html index 3e4cedc3..4c8f9c8f 100644 --- a/htdocs/gcc-14/porting_to.html +++ b/htdocs/gcc-14/porting_to.html

[PATCH] c-family: Use -Wdiscarded-qualifiers for ignored qualifiers in __atomic_*

This matches other compiler diagnostics. No test updates are needed because c-c++-common/pr95378.c does not match a specific -W option. Fixes commit d2384b7b24f8557b66f6958a05ea99ff4307e75c ("c-family: check qualifiers of arguments to __atomic built-ins (PR 95378)"). gcc/c-family/ PR c/

Re: [RFC] Intel AVX10.1 Compiler Design and Support

* Richard Biener: > If it were possible I'd axe x86_64-v4. Maybe we should add a x86_64-v3.5 > that sits inbetween v3 and v4, offering AVX512 but restricted to 256bit > (and obviously not requiring more of the AVX512 features that v4 > requires). As far as I understand it, GCC's Intel tuning for

Re: [PATCH v3 11/11] c: Add new -Wdeclaration-missing-parameter-type permerror

* Marek Polacek: > On Mon, Nov 20, 2023 at 10:56:42AM +0100, Florian Weimer wrote: >> This used to be a warning, enabled by default, without its own option. > > I think this patch is OK now. > >> A subsequent change could improve diagnostics and provide spelling >&g

Re: [PATCH] libgcov: Call __builtin_fork instead of fork

* Jakub Jelinek: > On Sat, Dec 02, 2023 at 01:43:22PM +0100, Florian Weimer wrote: >> Some targets do not provide a prototype for fork, and compilation now >> fails with an implicit-function-declaration error. >> >> libgcc/ >> >> * libgcov-interface.c

Re: [PATCH] testsuite: Adjust for the new permerror -Wincompatible-pointer-types

* Yang Yujie: > With this patch, I also noticed a few errors in building unpatched older > software like expect-5.45.4, perl-5.28.3 and bash-5.0. Will this also be > the case when GCC 14 gets released? For Fedora, we keep pointers of the changes needed here:

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

* Prathamesh Kulkarni: > On Mon, 20 Nov 2023 at 15:28, Florian Weimer wrote: >> >> The change to build_conditional_expr drops the downgrade >> from a pedwarn to warning for builtins for C99 and later >> language dialects. It remains a warning in C89 mode (not >>

Re: [PATCH] testsuite: Adjust for the new permerror -Wincompatible-pointer-types

* Yang Yujie: > From: Yang Yujie > Subject: [PATCH] testsuite: Adjust for the new permerror > -Wincompatible-pointer-types > To: gcc-patches@gcc.gnu.org > Cc: r...@cebitec.uni-bielefeld.de, mikest...@comcast.net, fwei...@redhat.com, > Yang Yujie > Date: Wed, 6 Dec 2023 10:29:31 +0800 (9 hours

Re: [PATCH] libgfortran: Fix -Wincompatible-pointer-types errors

* Richard Earnshaw: > On 05/12/2023 10:51, Jakub Jelinek wrote: >> On Tue, Dec 05, 2023 at 10:47:34AM +, Richard Earnshaw wrote: The following patch makes libgfortran build on i686-linux after hacking up --- kinds.h.xx 2023-12-05 00:23:00.133365064 +0100 +++ kinds.h2

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

* Richard Earnshaw: > (I think it's this patch, not one of the others in the series). > > This breaks building libgfortran with newlib on arm and aarch64: > > > /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/list_read.c:2208:46: > error: pointer type mismatch in conditional expressi

Re: [committed] Fix gnu23-builtins-no-dfp

* Jeff Law: > Anyway, this test was the one I was most concerned about. Basically > we're testing that on a !dfp target that the builtins are not available. > It expects a warning, but gets an error by default now. I just > changed the test to use -fpermissive, so that the test behaves as i

[PATCH] libgcov: Call __builtin_fork instead of fork

Some targets do not provide a prototype for fork, and compilation now fails with an implicit-function-declaration error. libgcc/ * libgcov-interface.c (__gcov_fork): Generated code is the same on x86_64-linux-gnu. Okay for trunk? Thanks, Florian --- libgcc/libgcov-interface.c | 2 +-

Re: [PATCH] testsuite: Tweak some further tests for modern C changes

* Jakub Jelinek: > Hi! > > On IRC Richi mentioned some FAILs in gcc.target/x86_64 and in pr83126.c. > > The following patch fixes the former ones (they need recent binutils to > be enabled), for pr83126.c because I didn't have graphite configured I've > just verified that the test compiles (didn't

Re: [PATCH 2/6] c: Turn int-conversion warnings into permerrors

* Thomas Schwinge: > I'm not proposing a patch as I don't know whether you'd like to just > silence the diagnostic, fix (?) the test case, and/or add another > 'dg-error'-checking test case? (I've not yet looked at the history of > the test case.) Jakub just posted a patch: [PATCH] testsuite:

Re: [PATCH v3 00/11] : More warnings as errors by default

* Sam James: >>> But give Marek additional time to chime in, particularly given the >>> holidays this week in the US. Say through this time next week? >> >> [...] >> >> I'm also gathering some numbers regarding autoconf impact and potential >> silent miscompilation. > > I'd actually forgot about

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

* Jakub Jelinek: > On Thu, Nov 30, 2023 at 04:15:26PM -0500, Marek Polacek wrote: >> On Thu, Nov 30, 2023 at 10:11:31PM +0100, Florian Weimer wrote: >> > * Marek Polacek: >> > >> > > On Mon, Nov 20, 2023 at 10:56:36AM +0100, Florian Weimer wrote: >>

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

* Marek Polacek: > On Mon, Nov 20, 2023 at 10:56:36AM +0100, Florian Weimer wrote: >> --- a/gcc/doc/invoke.texi >> +++ b/gcc/doc/invoke.texi >> @@ -6183,6 +6183,7 @@ that have their own flag: >> @gccoptlist{ >> -Wimplicit-function-declaration

Re: [PATCH v3 05/11] c: Turn int-conversion warnings into permerrors

* Marek Polacek: >> permerror_init for -Wint-conversion warnings. > > A few extra whitespaces. >> * gcc.dg/assign-warn-4.c: New file. Extracted from >> assign-warn1.c. Expect int-cnversion errors. > > "int-conversion" (sorry about pointing out typos...) > >> * gcc.dg/dia

Re: [PATCH v3 04/11] Add tests for validating future C permerrors

* Marek Polacek: >> +void >> +implicit_function_declaration (void) >> +{ >> + f1 (); /* { dg-warning "'f1' \\\[-Wimplicit-function-declaration\\\]" } */ >> +} >> + >> +extern implicit_int_1; /* { dg-warning "'implicit_int_1' >> \\\[-Wimplicit-int\\\]" } */ > > Oy, these \ tend to get unwieldy.

Re: [PATCH v3 09/11] c: Turn -Wreturn-mismatch into a permerror

* Marek Polacek: > On Mon, Nov 20, 2023 at 10:56:30AM +0100, Florian Weimer wrote: >> gcc/ >> >> * doc/invoke.texi (Warning Options): Document changes. > > That's pretty vague :). How about "Document that -Wreturn-mismatch is a > permerror in

Re: [PATCH v3] RISC-V: Implement TLS Descriptors.

* Tatsuyuki Ishi: > There is, please see [1]. The vector register file handling is missing right > now as I’m not sure if we have agreed upon a calling convention for RVV. > [1]: > https://inbox.sourceware.org/libc-alpha/20230914084033.222120-1-ishitatsuy...@gmail.com/ Thank you, I have raised

Re: [PATCH v3] RISC-V: Implement TLS Descriptors.

* Tatsuyuki Ishi: > I've considered gating this behind a GAS feature test, but it seems > nontrivial especially for restricting the variants available at runtime. > Since TLS descriptors is not selected by default, I've decided to leave it > ungated. > > In other news, I have made some progress on

Re: [PATCH v3 00/11] : More warnings as errors by default

* Jeff Law: > On 11/20/23 02:55, Florian Weimer wrote: >> This revision addresses Marek's comment about handing >> -Wdeclaration-missing-parameter-type properly in conjunction with >> -fpermissive. A new test (permerror-fpermissive-nowarning.c) >> demonstrates t

[PATCH] gcc.misc-tests/linkage-y.c: Compatibility with C99+ system compilers

This program is compiled with an installed "cc" compiler, not the built GCC compiler, so it should be as compatible as possible across a wide range of compilers. gcc/testsuite/ * gcc.misc-tests/linkage-y.c (puts): Declare. (main): Add int return type and return 0. --- gcc/testsu

Re: [PATCH v3 11/11] c: Add new -Wdeclaration-missing-parameter-type permerror

* Eric Gallager: > On Mon, Nov 20, 2023 at 4:58 AM Florian Weimer wrote: >> >> This used to be a warning, enabled by default, without its own option. > > Right, I meant to ask: why create a new option of > -Wdeclaration-missing-parameter-type instead of reusing the existi

[PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

The change to build_conditional_expr drops the downgrade from a pedwarn to warning for builtins for C99 and later language dialects. It remains a warning in C89 mode (not a permerror), as the -std=gnu89 -fno-permissive test shows. gcc/ * doc/invoke.texi (Warning Options): Document change

[PATCH v3 06/11] c: Turn -Wimplicit-function-declaration into a permerror

In the future, it may make sense to avoid cascading errors from the implicit declaration, especially its assumed int return type. This change here only changes the kind of the diagnostic, not its wording or consequences. gcc/ * doc/invoke.texi (Warning Options): Document changes. gcc/c/

[PATCH v3 11/11] c: Add new -Wdeclaration-missing-parameter-type permerror

This used to be a warning, enabled by default, without its own option. A subsequent change could improve diagnostics and provide spelling hints for declarations like “void function (int32t);”. gcc/c-family/ * c.opt (Wdeclaration-missing-parameter-type): New. gcc/c/ChangeLog: PR

[PATCH v3 09/11] c: Turn -Wreturn-mismatch into a permerror

gcc/ * doc/invoke.texi (Warning Options): Document changes. gcc/c/ PR c/96284 * c-typeck.cc (c_finish_return): Use permerrors for OPT_Wreturn_mismatch diagnostics. gcc/testsuite/ * gcc.dg/permerror-default.c (return_mismatch_1) (return_mismatch_2

[PATCH v3 07/11] c: Turn -Wimplicit-int into a permerror

Most of these new permerrors are currently not diagnosed in system headers. gcc/ PR c/91093 PR c/96284 * doc/invoke.texi (Warning Options): Document changes. gcc/c/ * c-decl.cc (warn_defaults_to): Remove. (grok_declarator, start_function): Call permerror_

[PATCH v3 05/11] c: Turn int-conversion warnings into permerrors

gcc/ * doc/invoke.texi (Warning Options): Document changes. gcc/c/ PR c/96284 PR c/106416 * c-typeck.cc (build_conditional_expr): Use permerror_opt for pointer/integer type mismatches, based on -Wint-conversion. (pedwarn_permerror_init, permerror_i

[PATCH v3 04/11] Add tests for validating future C permerrors

The dg-error directives for gcc.dg/permerror-system.c can be generated using (for the most part at least): perl -ne 'print if s,.*(/\* \{ dg-error .*) } \*/$,$1 "" { target *-*-* } $. } */,' \ < gcc/testsuite/gcc.dg/permerror-default.c gcc/testsuite/ * gcc.dg/permerror-default.c: New

[PATCH v3 08/11] c: Do not ignore some forms of -Wimplicit-int in system headers

Most -Wimplicit-int warnings were unconditionally disabled for system headers. Only missing types for parameters in old-style function definitions resulted in warnings. This is inconsistent with the treatment of other permerrors, which are active in system headers. gcc/c/ * c-decl.cc (g

[PATCH v3 03/11] gm2: Add missing declaration of m2pim_M2RTS_Terminate to test

gcc/testsuite/ * gm2/link/externalscaffold/pass/scaffold.c (m2pim_M2RTS_Terminate): Declare. --- gcc/testsuite/gm2/link/externalscaffold/pass/scaffold.c | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/testsuite/gm2/link/externalscaffold/pass/scaffold.c b/gcc/testsuite/gm2

[PATCH v3 02/11] aarch64: Call named function in gcc.target/aarch64/aapcs64/ice_1.c

This test looks like it intends to pass a small struct argument through both a non-variadic and variadic argument, but due to the typo, it does not achieve that. gcc/testsuite/ * gcc.target/aarch64/aapcs64/ice_1.c (foo): Call named. --- gcc/testsuite/gcc.target/aarch64/aapcs64/ice_1.c |

[PATCH v3 01/11] aarch64: Avoid -Wincompatible-pointer-types warning in Linux unwinder

* config/aarch64/linux-unwind.h (aarch64_fallback_frame_state): Add cast to the expected type in sc assignment. --- libgcc/config/aarch64/linux-unwind.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/libgcc/config/aarch64/linux-unwind.h b/libgcc/co

[PATCH v3 00/11] : More warnings as errors by default

luding the precursor cleanup patches in this posting. Hopefully this will make the aarch64 tester happy. Thanks, Florian Florian Weimer (11): aarch64: Avoid -Wincompatible-pointer-types warning in Linux unwinder aarch64: Call named function in gcc.target/aarch64/aapcs64/ice_1.c gm2: Add missing decl

Re: [PATCH] c-family, middle-end: Add __builtin_c[lt]zg (arg, 0ULL) exception

* Richard Biener: > Ugh. First of all I don't like that the exception is applied during > folding. As for the problem of multi evaluation can't consumers use > stmt expressions for this, say > > {( auto __tem = value; __builtin_xyz (__tem, __typeof (__tem)); ... )} > > ? Thus use 'auto' to avoi

[PATCH COMMITTED] gcc.c-torture/execute/931004-13.c: Fix declaration of main

gcc/testsuite/ * gcc.c-torture/execute/931004-13.c (main): Fix mistakenly swapped int/void types. --- gcc/testsuite/gcc.c-torture/execute/931004-13.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/testsuite/gcc.c-torture/execute/931004-13.c b/gcc/tes

Re: [PATCH] C99 testsuite readiness: Cleanup of execute tests

* Jakub Jelinek: > So, I guess void main (int) could be ok in some implementations, but I don't > think that is the case of our. Florian, didn't you mean > int > main (void) > or > int > main () > instead? Exactly, it was a silly mistake. > Note, I'm using > int > main () > { > ... > } > in mos

Re: [PATCH] C99 testsuite readiness: Cleanup of execute tests

* Thomas Schwinge: > Hi Florian! > > Thanks for all your ongoing clean-up work! > > On 2023-11-10T23:07:55+0100, Florian Weimer wrote: >> This change updates the gcc.c-torture/execute/ to avoid obsolete >> language constructs. In the changed tests, use of th

Re: [PATCH v2 0/8] Turn some C warnings into errors by default

* Sam James: > When posting v3, I guess consider CCing the aarch64 maintainers (or just > pinging them separately)? I already pinged them, they are likely busy with posting their patches before stage 1 closes. > I'm not really sure how approval of (an earlier version of) this series > interacts

Re: [PATCH v2 5/8] c: Do not ignore some forms of -Wimplicit-int in system headers

* Sam James: > Florian Weimer writes: > >> Most -Wimplicit-int warnings were unconditionally disabled for system >> headers. Only missing types for parameters in old-style function >> definitions resulted in warnings. This is inconsistent with the >> treatment

Re: [PATCH v2 8/8] c: Add new -Wdeclaration-missing-parameter-type permerror

* Marek Polacek: > On Tue, Nov 14, 2023 at 06:50:58PM +0100, Florian Weimer wrote: >> --- a/gcc/c-family/c.opt >> +++ b/gcc/c-family/c.opt >> @@ -591,6 +591,10 @@ Wdeclaration-after-statement >> C ObjC Var(warn_declaration_after_statement) Init(-1) Warning >>

Re: [committed] testsuite: Ignore warning for unsupported option

; > Pushed to trunk as an obvious fix. > > gcc/testsuite/ChangeLog: > > * gcc.dg/20020206-1.c: Prune warning that > -fprefetch-loop-arrays is not supported. > > CC: Florian Weimer > Signed-off-by: Dimitar Dimitrov Ack, makes sense, thanks. Florian

[PATCH v2 8/8] c: Add new -Wdeclaration-missing-parameter-type permerror

This used to be a warning, enabled by default, without its own option. A subsequent change could improve diagnostics and provide spelling hints for declarations like “void function (int32t);”. gcc/c-family/ * c.opt (Wdeclaration-missing-parameter-type): New. gcc/c/ChangeLog: PR

[PATCH v2 5/8] c: Do not ignore some forms of -Wimplicit-int in system headers

Most -Wimplicit-int warnings were unconditionally disabled for system headers. Only missing types for parameters in old-style function definitions resulted in warnings. This is inconsistent with the treatment of other permerrors, which are active in system headers. gcc/c/ * c-decl.cc (g

[PATCH v2 7/8] c: Turn -Wincompatible-pointer-types into a permerror

The change to build_conditional_expr drops the downgrade from a pedwarn to warning for builtins. gcc/ * doc/invoke.texi (Warning Options): Document changes. gcc/c/ PR c/96284 * c-typeck.cc (build_conditional_expr): Upgrade most pointer type mismatches to a permer

[PATCH v2 6/8] c: Turn -Wreturn-mismatch into a permerror

gcc/ * doc/invoke.texi (Warning Options): Document changes. gcc/c/ PR c/96284 * c-typeck.cc (c_finish_return): Use permerrors for OPT_Wreturn_mismatch diagnostics. gcc/testsuite/ * gcc.dg/permerror-default.c (return_mismatch_1) (return_mismatch_2

[PATCH v2 4/8] c: Turn -Wimplicit-int into a permerror

Most of these new permerrors are currently not diagnosed in system headers. gcc/ PR c/91093 PR c/96284 * doc/invoke.texi (Warning Options): Document changes. gcc/c/ * c-decl.cc (warn_defaults_to): Remove. (grok_declarator, start_function): Call permerror_

[PATCH v2 3/8] c: Turn -Wimplicit-function-declaration into a permerror

In the future, it may make sense to avoid cascading errors from the implicit declaration, especially its assumed int return type. This change here only changes the kind of the diagnostic, not its wording or consequences. gcc/ * doc/invoke.texi (Warning Options): Document changes. gcc/c/

[PATCH v2 2/8] c: Turn int-conversion warnings into permerrors

gcc/ * doc/invoke.texi (Warning Options): Document changes. gcc/c/ PR c/96284 PR c/106416 * c-typeck.cc (build_conditional_expr): Use permerror_opt for pointer/integer type mismatches, based on -Wint-conversion. (pedwarn_permerror_init, permerror_i

[PATCH v2 1/8] Add tests for validating future C permerrors

The dg-error directives for gcc.dg/permerror-system.c can be generated using (for the most part at least): perl -ne 'print if s,.*(/\* \{ dg-error .*) } \*/$,$1 "" { target *-*-* } $. } */,' \ < gcc/testsuite/gcc.dg/permerror-default.c gcc/testsuite/ * gcc.dg/permerror-default.c: New

[PATCH v2 0/8] Turn some C warnings into errors by default

c-patches/874jhp3nwf@oldenburg.str.redhat.com/> Thanks, Florian Florian Weimer (8): Add tests for validating future C permerrors c: Turn int-conversion warnings into permerrors c: Turn -Wimplicit-function-declaration into a permerror c: Turn -Wimplicit-int into a permerror c: Do not ignore some for

Re: [PATCH 1/6] c-family: Introduce pedpermerror

* Florian Weimer: > It turns out that permerror_opt is not directly usable for > -fpermissive in the C front end. The front end uses pedwarn > extensively, and pedwarns are not overridable by -Wno-* options, > yet permerrors are. Add new pedpermerror helpers that turn into &

[PATCH 6/6] c: Turn -Wincompatible-pointer-types into a pedpermerror

gcc/ * doc/invoke.texi (Warning Options): Document changes. gcc/c/ * c-typeck.cc (build_conditional_expr): Use pedpermerror- equivalent for pointer type mismatches in conditional expression. (convert_for_assignment): Use pedpermerror and pedpermerr

[PATCH 5/6] c: Turn -Wreturn-mismatch into a pedpermerror

gcc/ * doc/invoke.texi (Warning Options): Document changes. gcc/c/ * c-typeck.cc (c_finish_return): Issue a permerror for mismatching pointers to builtins. For mismatching other pointers, issue a pedpermerror. gcc/testsuite/ * gcc.dg/20030906-1.c: Compi

[PATCH 3/6] c: Turn -Wimplicit-function-declaration into a pedpermerror

In the future, it may make sense to avoid cascading errors from the implicit declaration, especially its assumed int return type. This change here only changes the kind of the diagnostic, not its wording or consequences. gcc/c/ * doc/invoke.texi (Warning Options): Document changes. gcc/c

  1   2   3   4   5   6   >