Re: Bad interaction between gcc and glibc's handling of GNU extension [GCC PR 115724]

2024-07-02 Thread Florian Weimer
* Jakub Jelinek:

> On Tue, Jul 02, 2024 at 12:54:09PM -0400, David Malcolm via Gcc wrote:
>> Back in 2007 glibc gained some logic to implement "error" and
>> "error_at_line" by splitting into zero and non-zero cases, with the
>> nonzero case calling a "noreturn" function [1].
>> 
>> This doesn't seem to work. I tested back to 4.8.1 with Compiler
>> Explorer [2], which seems to be the earliest GCC that supports -fdump-
>> tree-original=stderr.
>> 
>> What happens is that glibc's 
>> 
>> __extern_always_inline void
>> error (int __status, int __errnum, const char *__format, ...)
>> {
>>   if (__builtin_constant_p (__status) && __status != 0)
>> __error_noreturn (__status, __errnum, __format, __va_arg_pack ());
>>   else
>> __error_alias (__status, __errnum, __format, __va_arg_pack ());
>> }
>> 
>> comes out of GCC's C frontend as:
>> 
>> {
>>   if (0)
>> {
>>   __error_noreturn (__status, __errnum, __format, __builtin_va_arg_pack 
>> ());
>> }
>>   else
>> {
>>   __error_alias (__status, __errnum, __format, __builtin_va_arg_pack ());
>> }
>> }
>> 
>> since __status is not a builtin constant,
>
> At -O0 sure, that is how __builtin_constant_p works.
> The above is intended for optimized compilation, and I think it works just
> fine then.

And it's generally needed with optimization only, to suppress warnings
in unreachable code that only happen when optimization is turned on.


Re: What is the purpose of these two fixincludes?

2024-06-11 Thread Florian Weimer via Gcc
* Richard Biener via Gcc:

> But are they still needed?  Often headers already contain
> alternatives for standard conforming compilers or GCC can now
> deal with the contents.

I suspect that io_quotes_def and io_quotes_use in particular often get
applied spuriously.

Thanks,
Florian



Re: How to target a processor with very primitive addressing modes?

2024-06-10 Thread Florian Weimer via Gcc
* Jeff Law via Gcc:

> If he's got a CC register exposed prior to LRA and LRA needs to insert
> any code, that inserted code may clobber the CC state.  This is
> discussed in the reload-to-LRA transition wiki page.

Do you mean the CC0 conversion page?

  

Thanks,
Florian



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

2024-06-03 Thread Florian Weimer
* 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 stop the
> + * program using `__builtin_trap()`. It might not be possible for the
> + * program to continue after such a breakpoint.
> + *
> + * @since C++26
> + */
> +void
> +breakpoint() noexcept;

Would it make sense to have a special function symbol for this, on which
the debugger sets the breakpoint?  We already have this for a slightly
different purpose in glibc, see _dl_debug_state.

Otherwise you'll get crashes if the debugger detection delivers a false
positive (e.g. when running under an strace-equivalent if libstdc++
cannot check the process name).

Or is_debugger_present should perhaps read a volatile bool that is
updated by the debugger as needed, and not bother with any ptrace
checks.

Thanks,
Florian



Re: configure adds -std=gnu++11 to CXX variable

2024-05-28 Thread Florian Weimer via Gcc
* Paul Eggert:

> On 2024-05-27 03:35, Florian Weimer wrote:
>> Does this turn on experimental language modes by default?  That's
>> probably not what we want.
>
> What do C++ developers want these days? Autoconf should have a
> reasonable default, and C++11 is surely not a good default anymore.

It's still a good default for GCC 5.

GCC developers will correct me, but I think the default C++ dialect is
updated to a newer version once the implementation is reasonably
complete and bugs have been ironed out.

This is different from the C front end, where it took close to 40 years
(from the introduction of void * into C) to activate type checking for
pointer types by default.

>> It would be better to have an option to raise the C++ mode to at least a
>> certain revision, and otherwise use the default.
>
> That option is already available. For example, a builder who doesn't
> want C++23 can use './configure ac_cv_prog_cxx_cxx23=no', and a
> developer can discourage C++23 by putting ':
> ${ac_cv_prog_cxx_cxx23=no}' early in configure.ac.

But that is not the same thing.  If a project uses C++14 constructs,
wouldn't it make sense to tell configure to try to get (likely
experimental) support for it if the compiler does not enable C++14 by
default?  And if the system is already at C++17, leave it at that?

Setting C++14 unconditionally could be incompatible with used system
libraries, which assume C++17 support because the distribution is aware
that the system compiler supports C++17.

Thanks,
Florian



Re: configure adds -std=gnu++11 to CXX variable

2024-05-27 Thread Florian Weimer via Gcc
* Paul Eggert:

> diff --git a/NEWS b/NEWS
> index 20dbc173..4ba8f3fe 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -16,6 +16,10 @@ GNU Autoconf NEWS - User visible changes.
>C11 and later.  Programs can use AC_C_VARARRAYS and __STDC_NO_VLA__
>to use VLAs if available.
>  
> +*** AC_PROG_CXX now prefers C++23, C++20, C++17, C++14 if available.
> +  Older code may need to be updated, as some older features of C++ are
> +  removed in later standards.
> +

Does this turn on experimental language modes by default?  That's
probably not what we want.

It would be better to have an option to raise the C++ mode to at least a
certain revision, and otherwise use the default.  The default is more
likely to be supported by system libraries, and it's a bit less likely
that programmers use experimental, known-to-be-buggy features (language
and library) by accident.

Thanks,
Florian



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

2024-05-03 Thread Florian Weimer
* 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 the top, not as the last item of the C section.
>> How about this? OK for wwwdocs?
>
> This is fine for me as well, thanks.

For me as well.

Thanks,
Florian



Re: Updated Sourceware infrastructure plans

2024-04-23 Thread Florian Weimer via Gcc
* Jason Merrill:

> On Mon, Apr 22, 2024 at 11:42 AM Tom Tromey  wrote:
>
>  > "Frank" == Frank Ch Eigler  writes:
>
>  >> [...]  I suggest that a basic principle for such a system is that it
>  >> should be *easy* to obtain and maintain a local copy of the history
>  >> of all pull requests.  That includes all versions of a pull request,
>  >> if it gets rebased, and all versions of comments, if the system
>  >> allows editing comments.  A system that uses git as the source of
>  >> truth for all the pull request data and has refs [...]
>
>  Frank> Do you know of a system with these characteristics?
>
>  Based on:
>
>  https://gerrit-review.googlesource.com/Documentation/dev-design.html#_notedb
>
>  ... it sounds like this is what gerrit does.
>
> Someone mentioned earlier that gerrit was previously tried
> unsuccessfully.  I think this is a common pattern in GCC at least:
> someone has an idea for a workflow improvement, and gets it working,
> but it isn't widely adopted.

We used it for glibc briefly.  It failed in part because we were too
kind and didn't give negative feedback in the tool itself (making it
less useful for contributors), and because it was deployed on the side
alongside the usual mailing list patch submission process.

It may be worth a try again, but this time with brutally honest feedback
(-2 and whatnot).  On the other hand, Gerrit appears to require Bazel to
build, and as far as I understand it, setting up and maintaining a Bazel
build environment that meets our requirements (basically: no mystery
binaries) is a very big task.

Thanks,
Florian



Re: [RFC] Linux system call builtins

2024-04-08 Thread Florian Weimer via Gcc
* Alexander Monakov:

> On Mon, 8 Apr 2024, Florian Weimer via Gcc wrote:
>
>> * Matheus Afonso Martins Moreira via Gcc:
>> 
>> >   + It's stable
>> >
>> > This is one of the things which makes Linux unique
>> > in the operating system landscape: applications
>> > can target the kernel directly. Unlike in virtually
>> > every other operating system out there, the Linux kernel
>> > to user space binary interface is documented[2] as stable.
>> > Breaking it is considered a regression in the kernel.
>> > Therefore it makes sense for a compiler to target it.
>> > The same is not true for any other operating system.
>> 
>> There is quite a bit of variance in how the kernel is entered.  On
>> x86-64, one once popular mechanism is longer present in widely-used
>> kernels.
>
> I assume you're implicitly referencing the vsyscall mechanism, but on
> amd64 it's not useful to *enter the kernel*, right? It was useful for
> obtaining the result of certain syscalls without actually entering
> the kernel, like with vdso.

The implementation performed a standard system call if a pure userspace
implementation wasn't possible.  It wasn't intended as a general-purpose
way to enter the kernel (although it could be used as such, hence the
desire to remove it in some cases).

Thanks,
Florian



Re: [RFC] Linux system call builtins

2024-04-08 Thread Florian Weimer via Gcc
* Matheus Afonso Martins Moreira via Gcc:

>   + It's stable
>
> This is one of the things which makes Linux unique
> in the operating system landscape: applications
> can target the kernel directly. Unlike in virtually
> every other operating system out there, the Linux kernel
> to user space binary interface is documented[2] as stable.
> Breaking it is considered a regression in the kernel.
> Therefore it makes sense for a compiler to target it.
> The same is not true for any other operating system.

There is quite a bit of variance in how the kernel is entered.  On
x86-64, one once popular mechanism is longer present in widely-used
kernels.  For POWER, the preferred way changed over time.  Likewise for
i386.

>   + It's a calling convention
>
> GCC already supports many calling conventions
> via function attributes. On x86 alone[3] there's
> cdecl, fastcall, thiscall, stdcall, ms_abi, sysv_abi,
> Win32 specific hot patching hooks. So I believe this
> would not at all be a strange addition to the compiler.

But using a builtin obfuscates that relationship.  There is no
__builtin_call_ms_abi, is there?

Thanks,
Florian



Re: Sourceware mitigating and preventing the next xz-backdoor

2024-04-03 Thread Florian Weimer via Gcc
* Guinevere Larsen via Overseers:

> Beyond that, we (GDB) are already experimenting with approved-by, and
> I think glibc was doing the same.

The glibc project uses Reviewed-by:, but it's completely unrelated to
this.  Everyone still pushes their own patches, and there are no
technical countermeasures in place to ensure that the pushed version is
the reviewed version.

Thanks,
Florian



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

2024-04-02 Thread Florian Weimer
* 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 existing
> "scratch buffer", with arbitrary alignement, whereas alloca() was
> probably more likely to be naturally aligned.

This glibc change appears to be incorrect.  I think we need to preserve
ABI alignment for types than can be passed through the vararg interface.
I'm not sure if this easily possible, though.  Certainly needs a
discussion on libc-alpha.

Thanks,
Florian



Re: Builtin for consulting value analysis (better ffs() code gen)

2024-03-14 Thread Florian Weimer via Gcc
* Andrew Cooper via Gcc:

> Anyway - is there a way of doing this that I've managed to overlook?

Use __builtin_ffs?

I think there's some concern for GCC that some of the alternative x86-64
implementations do not follow the AMD and Intel behavior.

Thanks,
Florian



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

2024-02-19 Thread Florian Weimer
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, s, strlen (s));
+write (fd, s, strlen (s));
   }
 
 
@@ -103,7 +103,7 @@ disregarding error handling and short writes):
   void
   write_string (int fd, const char *s)
   {
-write (1, s, strlen (s));
+write (fd, s, strlen (s));
   }
 
 


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

2024-02-17 Thread Florian Weimer
---
 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
@@ -437,6 +437,49 @@ issues addressed in more recent versions.)  Versions 
before 2.69 may
 have generic probes (for example for standard C support) that rely on
 C features that were removed in C99 and thus fail with GCC 14.
 
+
+Older Autoconf versions (for example, Autoconf 2.13) generate core
+probes that are incompatible with C99.  These include the basic
+compiler functionality check:
+
+
+#include "confdefs.h"
+main(){return(0);}
+
+
+And a check for standard C compatibility:
+
+
+#define XOR(e, f) (((e) && !(f)) || (!(e) && (f)))
+int main () { int i; for (i = 0; i  256; i++)
+if (XOR (islower (i), ISLOWER (i)) || toupper (i) != TOUPPER (i)) exit(2);
+exit (0); }
+
+
+(Several variants with different line breaks and whitespace were in
+use.)  If it is not possible to port the configure script to current
+Autoconf, these issues can be patched directly:
+
+
+#include "confdefs.h"
+int main(){return(0);}
+
+
+And for the second probe:
+
+
+#define XOR(e, f) (((e) && !(f)) || (!(e) && (f)))
+int main () { int i; for (i = 0; i  256; i++)
+if (XOR (islower (i), ISLOWER (i)) || toupper (i) != TOUPPER (i)) return 
2;
+return 0; }
+
+
+There is a long tail of less frequent issues, involving keyword
+checking (for inline), and checks for dlopen
+and mmap.  A setvbuf probe was previously
+expected to fail at run time because it triggered undefined behavior,
+now it fails because of a compilation error.
+
 Turning errors back into warnings
 
 

base-commit: 1fcd61437d6a3d7bf24b993b09d525486dc9a2e5



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

2024-02-17 Thread Florian Weimer
---
 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/porting_to.html
@@ -213,19 +213,59 @@ in functions which are declared to return 
void, or
 return statements without expressions for functions
 returning a non-void type.
 
+
+Both function definitions below contain -Wreturn-mismatch
+errors:
+
+
+void
+do_something (int flag)
+{
+  if (!flag)
+return -1;
+  do_something_else ();
+}
+
+int
+unimplemented_function (void)
+{
+  puts ("unimplemented function foo called");
+}
+
+
+
 
 To address this, remove the incorrect expression (or turn it into a
 statement expression immediately prior to the return
 statements if the expression has side effects), or add a dummy return
-value, as appropriate.  If there is no suitable dummy return value,
-further changes may be needed to implement appropriate error handling.
+value, as appropriate.
+
+
+void
+do_something (int flag)
+{
+  if (!flag)
+return -1;
+  do_something_else ();
+}
+
+int
+unimplemented_function (void)
+{
+  puts ("unimplemented function foo called");
+  return 0;
+}
+
+
+If there is no suitable dummy return value, further changes may be
+needed to implement appropriate error handling.
 
 
 Previously, these mismatches were diagnosed as
 a -Wreturn-type warning.  This warning still exists, and
 is not treated as an error by default.  It now covers remaining
 potential correctness issues, such as reaching the closing
-brace } of function that does not
+brace } of a function that does not
 return void.
 
 

base-commit: 5ef0adf3098478600f0c108e07e568d864b4c731



[PATCH wwwdocs] CSS: Color markup for /

2024-02-17 Thread Florian Weimer
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
@@ -98,6 +98,10 @@ div.copyright p:nth-child(3) { margin-bottom: 0; }
 .blue{ color:blue; }
 .blackbg { color:white; background-color: #00; }
 
+/* Inline markup for differences. */
+ins { background-color: lightgreen }
+del { background-color: pink } 
+
 /* Quote an e-mail.  The first  has the sender, the second the quote. */
 blockquote.mail div:nth-child(2) { border-left: solid blue; padding-left: 4pt; 
}
 

base-commit: 848ebfb46379178be3b0307c2ef99f4012e40edd



Re: New feature: -fdump-gimple-nodes (once more, with feeling)

2024-02-16 Thread Florian Weimer via Gcc
* Andi Kleen via Gcc:

>> ***This is NodeNumber0
>> (0x7f12e13b0d00) NodeNumber0
>> tree_code: function_decl
>> tree_code_class: tcc_declaration
>
> My suggestion if you go this route would be to generate
> some standard format like YAML or JSON that other tools
> can easily parse.

And C++ code that emits equivalent GENERIC or GIMPLE, perhaps?

Thanks,
Florian



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

2024-02-15 Thread Florian Weimer
* 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 paragraphs in ...? Not strictly necessary any 
> more, now that we switched to HTML 5, though more consistent and explicit.

I've tried this now, and adds extra whitespace in some cases, for
example here:

“

In most cases, simply adding the missing int keyword
addresses the error.  For example, a flag variable like



  static initialized;



becomes:



  static int initialized;

”

I would have to nest the  in the , which suggests a complexity
that just isn't there.

Thanks,
Florian



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

2024-02-15 Thread Florian Weimer
* 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=int-conversion)
>
>> +It makes sense to address missing int type, implicit
>
> Should this be plural here ("int types") or some adding a 
> word such as "declaration"? Genuine question.

“missing int type[s]” seems to be okay.

>> +Some of them will be caused by missing types resulting
>> +in int, and the default int return type of
>> +implicitly declared functions.
>
> ...resulting in implicit int... or something like that?
> Not sure how to be phrase it.

I went with: “missing types [treated as] int”

>> +GCC no longer casts all pointer types to all other pointer types.
>
> Do you mean it no longer does so implicitly, or not at all? That is,
> there are now cases where even an explicit cast such as
>
>   foo_p = (foo_type*) bar_p
>
> no longer works? Or just
>
>   foo_p = bar_p
>
> no longer works for all combinations?

The latter, other reviewers noted it as well, and I've got this now:
“GCC no longer [allows implicitly casting] all pointer types to all”

>> +appropriate casts, and maybe consider using code void *
>> +in more places (particularly for old programs that predate the
>> +introduction of void into the C language).
>
> Here I got confused.
>
> At first I thought I was reading that void * should be used 
> for cases where void did not exist yet. Now I think I 
> understand: this is about programs where void * was not used 
> since it was not part of the language yet - and the encouragement is to 
> update such old code by using it. 
>
> If so, how about making the second case void *, too?

Makes sense.  Technically you can't have void * without void,
but I can see this may be confusing.

>> +#include stddef.h>
>
> I *think* we may need to use  here instead of plain '>', though I may 
> be wrong.

No, only  needs to be quoted.  This is true even for XML, not just
HTML5.  Do you want me to change these to ?

>> +
>> +int
>> +compare (const void *a1, const void *b1)
>> +{
>> +  char *const *a = a1;
>> +  char *const *b = b1;
>> +  return strcmp (*a, *b);
>> +}
>> +
>
> Great that you include this example here, that really helps!
>
> Just why "const void *a1" versus "char *const *a", that is, the different 
> placement of const?

It's the right type. 8-)  The examples uses an array of char *,
not const char *.

>> +unrelated to the actual objective of the probe.  These failed probes
>> +tend to consistently disable program features and their tests, which
>> +means that an unexpected probe failure may result in silently dropping
>> +features.
>
> Omit "consistently"? I'm not sure what it adds here. And simplify the 
> second half, something like
>
>   These failed probes tend to disable program features (and their tests), 
>   resulting in silently dropping features.

What about this?

   These failed probes tend to disable program features [together with]
   their tests[], resulting in silently dropping features.

This what I meant with “consistently”: implementations and tests are
gone, so the testsuite doesn't flag it.

>> +In cases where this is a concern, generated config.log,
>> +config.h and other source code files can be compared
>> +using https://www.gnu.org/software/diffutils/;>diff,
>> +to ensure there are no unexpected differences.
>
> I wouldn't link to GNU diffutils here; just refer to the diff 
> command - or even omit that aspect and leave it at "can be compared".

diff is really useful for that, manual comparison isn't. 8-)
I can drop the hyperlink.

>> +Some build systems do not pass the CFLAGS environment
>> +or make variable to all parts of the builds
>
> Is "make" a common variable? What is the context here?

Hmm, I meant to allude $(CFLAGS) here.

“CFLAGS [] variable to all parts of the builds” should be
sufficient.

>> +
>> +It is unclear at which point GCC can enable the C23 bool
>> +keyword by default (making the bool type available
>> +without including #include stdbool.h> explicitly).
>
> Does C every include some header files implicitly?

GCC does, for .  Not relevant here, though.

> For the benefit of the doubt: Okay, and thank you, modulo feedback from 
> Jonathan and my two responses.

Thank you for your review.

I need to add two more code examples to the Autoconf section, should I
post a v2 with that, or add that in a subsequent commit?

Florian



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

2024-02-15 Thread Florian Weimer
* 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
definition that does not include a function prototype declarator”.
Should I write “old-style function definition” instead?

>
>> +declared outside the parameter list.  Using the correct
>> +type maybe required to avoid int-conversion errors (see below).
>
> Something feels odd with this sentence?

The fix is to write “may[ ]be“, as suggested by other reviewers.

>> +Incorrectly spelled type names in function declarations are treated as
>> +errors in more cases, under a
>> +new -Wdeclaration-missing-parameter-type warning.  The
>> +second line in the following example is now treated as an error
>> +(previously this resulted in an unnamed warning):
>
> What is an "unnamed" warning? Can we simply omit "unnamed" here?

A warning not controlled by a specific -W… option.  I've made the
change.

>> +GCC will type-check function arguments after that, potentially
>> +requiring further changes.  (Previously, the function declaration was
>> +treated as not having no prototype.)
>
> That second sentence uses double negation, which logically is the same as 
> just the original statement.

Other reviews suggests to change it to “not having [a] prototype”.

>> +
>> +By default, GCC still accepts returning an expression of
>> +type void from within a function that itself
>> +returns void, as a GNU extension that matches C++ rules
>> +in this area.
>
> Does the GNU extension match C++ (standard rules)?

Yes.  Should I write “matches [standard] C++ rules”?

Thanks,
Florian



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

2024-02-15 Thread Florian Weimer
* 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_SYSTEM_EXTENSIONS.
”

 inclusion is a larger issue, I think, best addressed by
future diagnostics.

>> +
>> +When building library code on GNU systems, it was possible to call
>> +undefined (not just undeclared) functions and still run other code in
>> +the library, particularly if ELF lazy binding was used.  Only
>> +executing the undefined function call would result in a lazy binding
>> +error and program crash.
>
> Maybe explicitly refer to the bfd linker's relaxed behaviour so it
> sounds less mysterious.

Like this?

“

When building library code on GNU systems,
https://sourceware.org/binutils/docs-2.42/ld/Options.html#index-_002d_002dallow_002dshlib_002dundefined;>it
 was possible to call
  undefined (not just undeclared) functions
and still run other code in the library, particularly if ELF lazy binding
was used.  Only executing the undefined function call would result in a
lazy binding error and program crash.
”

Thanks,
Florian



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

2024-02-15 Thread Florian Weimer
* 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 know that those types are
> optional for conformance. I think they're supported for all targets
> that GCC supports, so maybe just omit the parenthesis.

Fair enough, I've droped the parentheses.  Thank you for your other
suggestions as well, I have applied them.

Florian



Re: Update on GCC 14 C type safety changes/warnings as errors

2024-02-02 Thread Florian Weimer via Gcc
* Martin Jambor:

> Given you probably have the most experience with it, can you please also
> suggest an entry to https://gcc.gnu.org/gcc-14/porting_to.html that
> would describe this change?  (I was thinking of proposing something
> myself, but I don't really know just how much verbose such an entry
> should be.)

Thank you for the reminder.  I veered somewhat on the verbose side and
submitted:

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


Florian



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

2024-02-02 Thread Florian Weimer
---
 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
@@ -24,6 +24,471 @@ porting to GCC 14. This document is an effort to identify 
common issues
 and provide solutions. Let us know if you have suggestions for improvements!
 
 
+C language issues
+
+Certain warnings are now errors
+
+https://archive.org/details/PC-Mag-1988-09-13/page/n115/mode/2up;>
+  Function prototyping was added, first to help enforce type checking
+  on both the types of the arguments passed to the function, and also
+  to check the assignment compatibility of the function return type.
+  
+Standard C: The ANSI Draft Grows Up.
+  PC Magazine, September 13, 1988, page 117.
+  
+
+
+The initial ISO C standard and its 1999 revision removed support for
+many C language features that were widely known as sources of
+application bugs due to accidental misuse.  For backwards
+compatibility, GCC 13 and earlier compiler versions diagnosed use of
+these features as warnings only.  Although these warnings have been
+enabled by default for many releases, experience shows that these
+warnings are easily ignored, resulting in difficult-to-diagnose bugs.
+In GCC 14, these issues are now reported as errors, and no output file
+is created, providing clearer feedback to programmers that something
+is wrong.
+
+
+Most components of the GNU project have already been fixed for
+compatibility, but not all of them have had releases since fixes were
+applied.  Programs that bundle parts
+of https://www.gnu.org/software/gnulib/;>gnulib or
+https://www.gnu.org/software/autoconf-archive/;>autoconf-archive
+may need to update these sources files from their upstream versions.
+
+
+Several GNU/Linux distributions have shared patches from their porting
+efforts on relevant upstream mailing lists and bug trackers, but of
+course there is a strong overlap between programs that have these
+historic C compatibility issues and are dormant today.
+
+Implicit int types 
(-Werror=implicit-int)
+
+In most cases, simply adding the missing int keyword
+addresses the error.  For example, a flag like
+
+
+  static initialized;
+
+
+might turn into:
+
+
+  static int initialized;
+
+
+If the return type of a function is omitted, the correct type to
+add could be int or void, depending on
+whether the function returns a value or not.
+
+In some cases, the previously implied int type
+was not correct.  This mostly happens in function definitions
+that are not prototypes, when argument types are not
+declared outside the parameter list.  Using the correct
+type maybe required to avoid int-conversion errors (see below).
+In the example below, the type of s should be
+const char *, not int:
+
+
+  write_string (fd, s)
+  {
+write (1, s, strlen (s));
+  }
+
+
+The corrected standard C source code might look like this (still
+disregarding error handling and short writes):
+
+
+  void
+  write_string (int fd, const char *s)
+  {
+write (1, s, strlen (s));
+  }
+
+
+Implicit function declarations 
(-Werror=implicit-function-declaration)
+
+It is no longer possible to call a function that has not been
+declared.  In general, the solution is to include a header file with
+an appropriate function prototype.  Note that GCC will perform further
+type checks based on the function prototype, which can reveal further
+type errors that require additional changes.
+
+
+For well-known functions declared in standard headers, GCC provides
+fix-it hints with the appropriate #include directives:
+
+
+error: implicit declaration of function ‘strlen’ 
[-Wimplicit-function-declaration]
+5 |   return strlen (s);
+  |  ^~
+note: include ‘string.h>’ or provide a declaration of ‘strlen’
+  +++ |+#include string.h>
+1 |
+
+
+
+On GNU systems, headers described in standards (such as the C
+standard, or POSIX) may require the definition of certain
+macros at the start of the compilation before all required
+function declarations are made available.
+See https://sourceware.org/glibc/manual/html_node/Feature-Test-Macros.html;>Feature
 Test Macros
+in the GNU C Library manual for details.
+
+
+Some programs are built with -std=c11 or
+similar -std options that do not contain the
+string gnu, but these programs still use POSIX or other
+extensions in standard C headers such as stdio.h>.
+The GNU C library automatically suppresses these extensions in
+standard C mode, which can result in implicit function declarations.
+To address this, the -std=c11 option can be
+dropped, -std=gnu11 can be used instead,
+or -std=c11 -D_DEFAULT_SOURCE can be used re-enable
+common extensions.
+
+
+If undeclared functions from the same project are called and there is
+yet no suitable shared header file, you should add a declaration to a
+header file 

Re: [lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact

2024-01-15 Thread Florian Weimer via Gcc
* Mathieu Desnoyers:

> On 2024-01-13 07:49, Florian Weimer via lttng-dev wrote:
>> This commit
>> commit 8abddb187b33480d8827f44ec655f45734a1749d
>> Author: Andrew Burgess 
>> Date:   Sat Aug 5 14:31:06 2023 +0200
>>  libgcc: support heap-based trampolines
>>   Add support for heap-based trampolines on x86_64-linux,
>> aarch64-linux,
>>  and x86_64-darwin. Implement the __builtin_nested_func_ptr_created and
>>  __builtin_nested_func_ptr_deleted functions for these targets.
>>   Co-Authored-By: Maxim Blinov 
>>  Co-Authored-By: Iain Sandoe 
>>  Co-Authored-By: Francois-Xavier Coudert 
>> added TLS usage to libgcc_s.so.1.  The way that libgcc_s is
>> currently
>> built, it ends up using a dynamic TLS variant on the Linux targets.
>> This means that there is no up-front TLS allocation with glibc (but
>> there would be one with musl).
>
> Trying to wrap my head around this:
>
> If I get this right, the previous behavior was that glibc did allocate
> global-dynamic variables from libraries which are preloaded and loaded
> on c startup as if they were initial-exec, but now that libgcc_s.so.1
> has a dynamic TLS variable, all those libraries loaded on c startup that
> have global-dynamic TLS do not get the initial allocation special
> treatment anymore. Is that more or less correct ?

Ahh.  I had forgotten about this aspect.  The allocation from the static
TLS area still happens as before.

> I've prepared a change for lttng-ust to move the lttng-ust libc wrapper
> "malloc nesting" guard variable from global-dynamic to initial-exec:
>
> https://review.lttng.org/c/lttng-ust/+/11677 Fix: libc wrapper: use 
> initial-exec for malloc_nesting TLS

I don't know if this is completely sufficient if there are other TLS
variables in the lttng stack.

> This should help for the infinite recursion issue, but if my understanding
> is correct about the impact of effectively changing the behavior used
> for global-dynamic variables in preloaded and on-startup-loaded libraries
> introduced by this libgcc change, I suspect we have other new issues here,
> such as problems with async-signal safety of other global-dynamic variables
> within LTTng-UST.

This didn't change, and the allocation is not done lazily (contrary to
what I might have written before).  But even on the __tls_get_addr fast
path, we check the TLS generation counter, and if that has changed, we
do extra bookkeeping work.  TLS usage in libgcc_s.so.1 means that in the
now-failing test, the generation counter changed.  Before bug 19924

  TLS performance degradation after dlopen 
  <https://sourceware.org/bugzilla/show_bug.cgi?id=19924>

was fixed, we did not do this bookkeeping work, which is why the problem
didn't occur.

General use of lttng should be fine, I think, only the malloc wrapper
has this problem.

> But moving all TLS variables used by lttng-ust from global-dynamic to
> initial-exec is tricky, because a prior attempt to do so introduced
> regressions in use-cases where lttng-ust was dlopen'd by Java or
> Python, AFAIU situations where the runtimes were already using most of
> the extra memory pool for dlopen'd libraries initial-exec variables,
> causing dlopen of lttng-ust to fail.

Oh, right, that makes it quite difficult.  Could you link a private copy
of the libraries into the wrapper that uses initial-exec TLS?

Thanks,
Florian



Re: New TLS usage in libgcc_s.so.1, compatibility impact

2024-01-15 Thread Florian Weimer via Gcc
* Iain Sandoe:

>> On 15 Jan 2024, at 15:35, Florian Weimer  wrote:
>> 
>> * Carlos O'Donell:
>> 
>>> I agree. TLS should be seen more like .bss/.data rather than something
>>> that is allocated with malloc().
>> 
>> There wasn't consensus regarding this in 2014.  See below.
>> 
>>> If we leak memory via TLS that is a glibc bug that we can deal with,
>> 
>> This is something that libgcc_s.so.1 does in GCC 14 if the heap
>> trampolines are used.
>
> Is there a GCC BZ for this?
> (if there is something we should address in GCC, it would be better sooner)

Sorry, I wanted to write a reproducer first.  With it, I found two more
issue.

  Memory (resource) leak in -ftrampoline-impl=heap
  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401>

  Incorrect symbol versions for __builtin_nested_func_ptr_created,
  __builtin_nested_func_ptr in libgcc_s.so.1
  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402>

  __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be
  dynamically linked by default
  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403>

Thanks,
Florian



Re: New TLS usage in libgcc_s.so.1, compatibility impact

2024-01-15 Thread Florian Weimer via Gcc
* Carlos O'Donell:

> I agree. TLS should be seen more like .bss/.data rather than something
> that is allocated with malloc().

There wasn't consensus regarding this in 2014.  See below.

> If we leak memory via TLS that is a glibc bug that we can deal with,

This is something that libgcc_s.so.1 does in GCC 14 if the heap
trampolines are used.

> but making it easier to find glibc bugs is also a benefit to the
> community, but not as valuable a benefit as making TLS correctly
> async-signal safe.
>
> Likewise we need to discuss when the memory is allocated, regardless
> of which allocator is used, including allocation up-front at dlopen()
> time.
>> [1] https://sourceware.org/pipermail/libc-alpha/2014-January/047931.html

The change conflated multiple issues: sanitizer support,
async-signal-safe TLS access, and eager allocation of all TLS-related
memory, so that subsequent accesses cannot fail.  My impression was the
main point of contention was eager allocation because it was perceived
as a breaking semantic change.  Nowadays, as long as we are willing to
maintain both allocator variants, we could offer a choice between them
controlled by a tunable.  For sanitizer compatibility, we could perform
eager allocation using malloc.  It's probably a good idea to do it this
way anyway because a separate mmap-based allocator would increase TLB
pressure.

Thanks,
Florian



New TLS usage in libgcc_s.so.1, compatibility impact

2024-01-13 Thread Florian Weimer via Gcc
This commit

commit 8abddb187b33480d8827f44ec655f45734a1749d
Author: Andrew Burgess 
Date:   Sat Aug 5 14:31:06 2023 +0200

libgcc: support heap-based trampolines

Add support for heap-based trampolines on x86_64-linux, aarch64-linux,
and x86_64-darwin. Implement the __builtin_nested_func_ptr_created and
__builtin_nested_func_ptr_deleted functions for these targets.

Co-Authored-By: Maxim Blinov 
Co-Authored-By: Iain Sandoe 
Co-Authored-By: Francois-Xavier Coudert 

added TLS usage to libgcc_s.so.1.  The way that libgcc_s is currently
built, it ends up using a dynamic TLS variant on the Linux targets.
This means that there is no up-front TLS allocation with glibc (but
there would be one with musl).

There is still a compatibility impact because glibc assigns a TLS module
ID upfront.  This seems to be what causes the
ust/libc-wrapper/test_libc-wrapper test in lttng-tools to fail.  We end
up with an infinite regress during process termination because
libgcc_s.so.1 has been loaded, resulting in a DTV update.  When this
happens, the bottom of the stack looks like this:

#4447 0x77f288f0 in free () from /lib64/liblttng-ust-libc-wrapper.so.1
#4448 0x77fdb142 in free (ptr=)
at ../include/rtld-malloc.h:50
#4449 _dl_update_slotinfo (req_modid=3, new_gen=2) at ../elf/dl-tls.c:822
#4450 0x77fdb214 in update_get_addr (ti=0x77f2bfc0, 
gen=) at ../elf/dl-tls.c:916
#4451 0x77fddccc in __tls_get_addr ()
at ../sysdeps/x86_64/tls_get_addr.S:55
#4452 0x77f288f0 in free () from /lib64/liblttng-ust-libc-wrapper.so.1
#4453 0x77fdb142 in free (ptr=)
at ../include/rtld-malloc.h:50
#4454 _dl_update_slotinfo (req_modid=2, new_gen=2) at ../elf/dl-tls.c:822
#4455 0x77fdb214 in update_get_addr (ti=0x77f39fa0, 
gen=) at ../elf/dl-tls.c:916
#4456 0x77fddccc in __tls_get_addr ()
at ../sysdeps/x86_64/tls_get_addr.S:55
#4457 0x77f36113 in lttng_ust_cancelstate_disable_push ()
   from /lib64/liblttng-ust-common.so.1
#4458 0x77f4c2e8 in ust_lock_nocheck () from /lib64/liblttng-ust.so.1
#4459 0x77f5175a in lttng_ust_cleanup () from /lib64/liblttng-ust.so.1
#4460 0x77fca0f2 in _dl_call_fini (
closure_map=closure_map@entry=0x77fbe000) at dl-call_fini.c:43
#4461 0x77fce06e in _dl_fini () at dl-fini.c:114
#4462 0x77d82fe6 in __run_exit_handlers () from /lib64/libc.so.6

Cc:ing  for awareness.

The issue also requires a recent glibc with changes to DTV management:
commit d2123d68275acc0f061e73d5f86ca504e0d5a344 ("elf: Fix slow tls
access after dlopen [BZ #19924]").  If I understand things correctly,
before this glibc change, we didn't deallocate the old DTV, so there was
no call to the free function.

On the glibc side, we should recommend that intercepting mallocs and its
dependencies use initial-exec TLS because that kind of TLS does not use
malloc.  If intercepting mallocs using dynamic TLS work at all, that's
totally by accident, and was in the past helped by glibc bug 19924.  (I
don't think there is anything special about libgcc_s.so.1 that triggers
the test failure above, it is just an object with dynamic TLS that is
implicitly loaded via dlopen at the right stage of the test.)  In this
particular case, we can also paper over the test failure in glibc by not
call free at all because the argument is a null pointer:

diff --git a/elf/dl-tls.c b/elf/dl-tls.c
index 7b3dd9ab60..14c71cbd06 100644
--- a/elf/dl-tls.c
+++ b/elf/dl-tls.c
@@ -819,7 +819,8 @@ _dl_update_slotinfo (unsigned long int req_modid, size_t 
new_gen)
 dtv entry free it.  Note: this is not AS-safe.  */
  /* XXX Ideally we will at some point create a memory
 pool.  */
- free (dtv[modid].pointer.to_free);
+ if (dtv[modid].pointer.to_free != NULL)
+   free (dtv[modid].pointer.to_free);
  dtv[modid].pointer.val = TLS_DTV_UNALLOCATED;
  dtv[modid].pointer.to_free = NULL;

As the comment hints, we shouldn't be using malloc for TLS memory at all
because it is not AS-safe, but that's a long-term change.  This change
seems rather specific to this particular test case failure because it
relies on libgcc_s.so.1 never using TLS before it gets unloaded.

Regarding the libgcc_s side, I'm not sure if the TLS usage there should
be considered a real problem, although I'm a bit nervous about it.
However, the current implementation caches one page of trampolines past
the outermost nested function pointer deallocation (otherwise creating
one function pointer per thread in a loop would be really expensive).
It looks to me that is never freed, so if the thread exits even with
proper unwinding (e.g., on glibc with code compiled with -fexceptions),
there is a memory leak.  Integration with glibc could avoid this issue,
and also help with the longjmp problem, and fix setcontext/swapcontext,
too.

Thanks,
Florian



Re: Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15

2023-12-17 Thread Florian Weimer via Gcc
* Andrew Pinski via Gcc:

> -fgnu-tm support has not been improved since GCC 5 or earlier. It is
> not even supported with LTO. Does it make sense to deprecate the
> support for GCC 14 and remove it in GCC 15?

Is this the stuff around libitm and that adds _ITM_registerTMCloneTable
and _ITM_deregisterTMCloneTable symbol references to *all* binaries
(whether they use transactional memory or not)?

Thanks,
Florian



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

2023-12-17 Thread Florian Weimer
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/113050
* c-common.cc (get_atomic_generic_size): Use
OPT_Wdiscarded_qualifiers instead of
OPT_Wincompatible_pointer_types.

---

Jonathan, I assume this was just an oversight in your patch, and there
is no fundamental reason to use -Wincompatible-pointer-types here?

Thanks,
Florian

 gcc/c-family/c-common.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index 0f1de44a348..6ea727f446f 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -7637,7 +7637,7 @@ get_atomic_generic_size (location_t loc, tree function,
return 0;
  }
else
- pedwarn (loc, OPT_Wincompatible_pointer_types, "argument %d "
+ pedwarn (loc, OPT_Wdiscarded_qualifiers, "argument %d "
   "of %qE discards % qualifier", x + 1,
   function);
  }
@@ -7651,7 +7651,7 @@ get_atomic_generic_size (location_t loc, tree function,
return 0;
  }
else
- pedwarn (loc, OPT_Wincompatible_pointer_types, "argument %d "
+ pedwarn (loc, OPT_Wdiscarded_qualifiers, "argument %d "
   "of %qE discards % qualifier", x + 1,
   function);
  }

base-commit: da70c5b17123b7c81155ef03fb4591b71a681344



Switching x86_64-linux-gnu to GNU2 TLS descriptors by default

2023-12-13 Thread Florian Weimer via Gcc
I feel like I have asked this before.  Currently, GCC uses calls to
__tls_get_addr to obtain the address of global-dynamic TLS variables.
On other architectures with support for GNU2 TLS descriptors, those are
used by default.

Should we flip the default to GNU2 descriptors?  Support has been
available in glibc for a long, long time.  Is there any other reason for
not doing this?  On the glibc side, the behavior regarding lazy
initialization and symbol binding does not change whether the old or new
interface is used.

Thanks,
Florian



-fcf-protection default on x86-64 (also for -fhardened)

2023-12-12 Thread Florian Weimer via Gcc
Currently, -fcf-protection defaults to both shadow stack and indirect
branch tracking (IBT) on x86_64-linux-gnu, and -fhardened follows that.
I think it should only enable shadow stack at this point.

I'm not sure if this is a good idea because there will likely be no
userspace support for IBT when GCC 14 releases, so these binaries will
not be tested.  They will carry markup that indicates compatibility with
IBT, though.  If there turns out to be a problem, we'd have to revision
the markup and disable IBT for all existing binaries (because we don't
know which ones have the toolchain fix applied).

I think we can keep the shadow stack markup because there will be ways
to test for compatibility fairly soon.  The risk is also fairly reduced
for shadow stack because there are no code generation changes in generic
code, while for IBT every function that has their address taken needs a
different prologue.

As far as I understand it, there won't be any i386 GNU/Linux support for
shadow stacks, so -fhardened shouldn't enable it on that target.
Furthermore, ENDBR32 is incompatible with the i386 baseline ISA because
it's a long NOP.

Thanks,
Florian



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

2023-12-12 Thread Florian Weimer
* 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 AVX-512 is leaning
heavily towards 256 bit vector length anyway.  That's not true for the
default tuning for -march=x86-64-v4, though, it prefers 512 bit vectors.
I've seen third-party reports that AMD Zen 4 does better in some ways
with 512 bit vectors than with 256 bit vectors (despite its 256-bit-wide
execution ports), but I have not tried to verify these observations.
Still, this suggests that restricting a post-x86-64-v3 level to 256 bit
vectors may not be an easy decision.

On the other hand, a new EVEX-capable level might bring earlier adoption
of EVEX capabilities to AMD CPUs, which still should be an improvement
over AVX2.  This could benefit AMD as well.  So I would really like to
see some AMD feedback here.

There's also the matter that time scales for EVEX adoption are so long
that by then, Intel CPUs may end up supporting and preferring 512 bit
vectors again.

Thanks,
Florian



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

2023-12-11 Thread Florian Weimer
* 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
>> hints for declarations like “void function (int32t);”.
>
> Feel free to open a PR.

Good idea, it's now:

  Spelling hint for typos in parameter types in function prototypes
  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112954>

Thanks,
Florian



Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

2023-12-10 Thread Florian Weimer via Gcc
* LIU Hao via Gcc:

> 在 2023/12/8 21:59, Florian Weimer via Gcc 写道:
>>[PATCH] libgcov: Call __builtin_fork instead of fork
>>
>> <https://inbox.sourceware.org/gcc-patches/87edg4epw5@oldenburg.str.redhat.com/>
>
> May I ask why it's not something like this?
>
> Even though there may be people who define `fork()` in global scope, it will 
> be semantically 
> different from the POSIX fork.
>
> ```
> diff --git a/libgcc/libgcov-interface.c b/libgcc/libgcov-interface.c
> index b2ee9308641..10ce8edc4fb 100644
> --- a/libgcc/libgcov-interface.c
> +++ b/libgcc/libgcov-interface.c
> @@ -174,7 +174,7 @@ __gcov_dump (void)
>
>   #endif /* L_gcov_dump */
>
> -#ifdef L_gcov_fork
> +#if defined L_gcov_fork && !defined _WIN32
>   /* A wrapper for the fork function.  We reset counters in the child
>  so that they are not counted twice.  */
>
> ```

Other systems probably have the same issue.  We just don't have an
autobuilder, or we have one and I haven't seen its error.

Thanks,
Florian



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

2023-12-08 Thread Florian Weimer
* 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 (__gcov_fork):
>
> Description missing (Use __builtin_fork instead of fork.).
>
> Ok with that change.

Fixed & pushed, thanks.

Florian



Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

2023-12-08 Thread Florian Weimer via Gcc
* Mark Wielaard:

> BTW. The gcc-fedora-mingw buildbot has been broken because of this
> issue for the last week:
>
> https://builder.sourceware.org/buildbot/#/builders/gcc-fedora-mingw
> ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork':
> ../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit
> declaration of function 'fork' [-Wimplicit-function-declaration]
>   185 |   pid = fork ();
>   | ^~~~
> make[2]: *** [Makefile:935: _gcov_fork.o] Error 1

Yes, that's why I submitted a patch:

  [PATCH] libgcov: Call __builtin_fork instead of fork
  


Thanks,
Florian



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

2023-12-07 Thread Florian Weimer
* 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:

  
  
  

(For perl, it looks like another change will be needed.)

This also includes changes that we imported through rebases after we
started tracking.

We do not have control over the release schedule for those upstream
projects, and of course there are many project which are more or less
dormant and have not made a release in many years.

Thanks,
Florian



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

2023-12-06 Thread Florian Weimer
* 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
>> a permerror), as the -std=gnu89 -fno-permissive test shows.
> Hi Florian,
> It seems this patch caused a fallout for
> gcc.dg/fixed-point/composite-type.c on arm, where the tests for
> warnings fail.
> For instance:
> FAIL: gcc.dg/fixed-point/composite-type.c  (test for warnings, line 71)
> Excess errors:
> /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.dg/fixed-point/composite-type.c:71:3:
> error: passing argument 1 of 'f2_sf' from incompatible pointer type
> [-Wincompatible-pointer-types]
> /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.dg/fixed-point/composite-type.c:71:3:
> error: passing argument 1 of 'f2_sf' from incompatible pointer type
> [-Wincompatible-pointer-types]
> (snipped rest)
>
> Should these warnings be now upgraded to dg-error ?

Right, a patch for this was posted (but I don't see it in the archives):

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, 42 minutes, 7 seconds ago)
Message-ID: <20231206022931.33437-1-yangyu...@loongson.cn>

Thanks,
Florian



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

2023-12-06 Thread Florian Weimer
* 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, 42 minutes, 7 seconds ago)
> Message-ID: <20231206022931.33437-1-yangyu...@loongson.cn>
>
> r14-6037 turned -Wincompatible-pointer-types into a permerror,
> which causes the following tests to fail.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.dg/fixed-point/composite-type.c: replace dg-warning with dg-error.
> ---
>  .../gcc.dg/fixed-point/composite-type.c   | 64 +--
>  1 file changed, 32 insertions(+), 32 deletions(-)

Looks reasonable to me, but I can't approve it.

Thanks,
Florian



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

2023-12-05 Thread Florian Weimer
* 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.h2023-12-05 11:19:24.409679808 +0100
 @@ -10,8 +10,8 @@ typedef GFC_INTEGER_2 GFC_LOGICAL_2;
#define HAVE_GFC_LOGICAL_2
#define HAVE_GFC_INTEGER_2
 -typedef int32_t GFC_INTEGER_4;
 -typedef uint32_t GFC_UINTEGER_4;
 +typedef long GFC_INTEGER_4;
 +typedef unsigned long GFC_UINTEGER_4;
>>>
>>> That doesn't look right for a 64-bit processor.  Presumably 4 means 4 bytes,
>> i686-linux is an ILP32 target, which I chose exactly because I
>> regularly build
>> it, had a tree with it around and because unlike 64-bit targets there are 2
>> standard 32-bit signed integer types.  Though, normally int32_t there is
>> int rather than long int and so the errors only appeared after this hack.
>> 
>
> My point is that on aarch64/x86_64 etc, this will make GFC_INTEGER_4 a
> 64-bit type, whereas previously it was 32-bit.

I think it's not part of the submission, it was for local testing only.
It confused me as well. 8-)

Thanks,
Florian



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

2023-12-05 Thread Florian Weimer
* 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 expression
> [-Wincompatible-pointer-types]
>  2208 |   dtp->common.iostat : 
>   |  ^
> /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/list_read.c:2208:27:
> note: first expression has type ‘GFC_INTEGER_4 *’ {aka ‘long int *’}
>  2208 |   dtp->common.iostat : 
>   |   ^~
> /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/list_read.c:2208:48:
> note: second expression has type ‘int *’
>  2208 |   dtp->common.iostat : 
>   |^
> /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/list_read.c:2224:34:
> error: passing argument 2 of ‘dtp->u.p.fdtio_ptr’ from incompatible
> pointer type [-Wincompatible-pointer-types]
>  2224 |   dtp->u.p.fdtio_ptr (p, , iotype, ,
>   |  ^
>   |  |
>   |  int *
> /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/list_read.c:2224:34:
> note: expected ‘GFC_INTEGER_4 *’ {aka ‘long int *’} but argument is of
> type ‘int *’
> /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/list_read.c:2225:31:
> error: passing argument 5 of ‘dtp->u.p.fdtio_ptr’ from incompatible
> pointer type [-Wincompatible-pointer-types]
>  2225 |   child_iostat, child_iomsg,
>   |   ^~~~
>   |   |
>   |   int *
> /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/list_read.c:2225:31:
> note: expected ‘GFC_INTEGER_4 *’ {aka ‘long int *’} but argument is of
> type ‘int *’

Presumably the fixes will look like this?

diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index db3330060ce..4fcc77dbf83 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -2987,13 +2987,13 @@ nml_read_obj (st_parameter_dt *dtp, namelist_info *nl, 
index_type offset,
/* If this object has a User Defined procedure, call it.  */
if (nl->dtio_sub != NULL)
  {
-   int unit = dtp->u.p.current_unit->unit_number;
+   GFC_INTEGER_4 unit = dtp->u.p.current_unit->unit_number;
char iotype[] = "NAMELIST";
gfc_charlen_type iotype_len = 8;
char tmp_iomsg[IOMSG_LEN] = "";
char *child_iomsg;
gfc_charlen_type child_iomsg_len;
-   int noiostat;
+   GFC_INTEGER_4 noiostat;
int *child_iostat = NULL;
gfc_full_array_i4 vlist;
formatted_dtio dtio_ptr = (formatted_dtio)nl->dtio_sub;


Apparently the targets I built define GFC_INTEGER_4 as int, so this
didn't show up.

Thanks,
Florian



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

2023-12-02 Thread Florian Weimer
* 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 it did 
> previously.

In these ambiguous cases, I cloned tests into -fpermissive and error
variants.  This might be appropriate here as well (or I should remove
the clones again if those are the wrong thing to do).


[PATCH] libgcov: Call __builtin_fork instead of fork

2023-12-02 Thread Florian Weimer
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 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/libgcov-interface.c b/libgcc/libgcov-interface.c
index b2ee9308641..d166e98510d 100644
--- a/libgcc/libgcov-interface.c
+++ b/libgcc/libgcov-interface.c
@@ -182,7 +182,7 @@ pid_t
 __gcov_fork (void)
 {
   pid_t pid;
-  pid = fork ();
+  pid = __builtin_fork ();
   if (pid == 0)
 {
   __GTHREAD_MUTEX_INIT_FUNCTION (&__gcov_mx);

base-commit: 193ef02a7f4f3e5349ad9cf8d3d4df466a99b677



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

2023-12-01 Thread Florian Weimer
* 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 without the patch) and that
> the gimple dump is identical with one from yesterday's gcc (as it was a
> tree-parloops.cc ICE, I guess identical gimple is all we care about
> and no need to verify it further).
>
> Ok for trunk?
>
> 2023-12-01  Jakub Jelinek  
>
>   * gcc.target/x86_64/abi/avx512fp16/m512h/test_passing_m512.c
>   (fun_check_passing_m512_8_values, fun_check_passing_m512h_8_values):
>   Add missing void return type.
>   * gcc.target/x86_64/abi/avx512fp16/m256h/test_passing_m256.c
>   (fun_check_passing_m256_8_values, fun_check_passing_m256h_8_values):
>   Likewise.
>   * gcc.dg/graphite/pr83126.c (ew): Add missing casts to __INTPTR_TYPE__
>   and then to int *.

Looks fine.  Sorry, I totally forgot to upgrade binutils and install
isl.

Thanks,
Florian



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

2023-12-01 Thread Florian Weimer
* 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: Tweak some further tests for modern C changes
  

Thanks,
Florian



Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

2023-12-01 Thread Florian Weimer via Gcc
* Richard Biener:

> On Fri, Dec 1, 2023 at 9:04 AM Florian Weimer via Gcc  wrote:
>>
>> I've received a report of a mingw build failure:
>>
>> ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork':
>> ../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit declaration 
>> of function 'fork' [-Wimplicit-function-declaration]
>>   185 |   pid = fork ();
>>   | ^~~~
>> make[2]: *** [Makefile:932: _gcov_fork.o] Error 1
>> make[2]: *** Waiting for unfinished jobs
>>
>> As far as I understand it, mingw doesn't have fork and doesn't declare
>> it in , so it's not clear to me how this has ever worked.  I
>> would expect a linker failure.  Maybe that doesn't happen because the
>> object containing a reference to fork is only ever pulled in if the
>> application calls the intercepted fork, which doesn't happen on mingw.
>>
>> What's the best way to fix this?  I expect it's going to impact other
>> targets (perhaps for different functions) because all of
>> libgcov-interface.c is built unconditionally.  I don't think we run
>> configure for the target, so we can't simply check for a definition of
>> the HAVE_FORK macro.
>
> This is wrapped inside
>
> #ifdef L_gcov_fork
> #endif
>
> grepping didn't find me what defines this, but it suggests the solution
> lies there ...

That's just the general libgcc/ coding style, which puts multiple
related functions into one C source file.  The file is compiled multiple
times with different -D options using Makefile rules like this one:

$(libgcov-interface-objects): %$(objext): $(srcdir)/libgcov-interface.c 
$(srcdir)/gcov.h $(srcdir)/libgcov.h
$(gcc_compile) -DL$* -c $(srcdir)/libgcov-interface.c

It looks like this is done to emulate -Wl,--gc-sections without separate
source files.  Unfortunately, this is all built unconditionally.

Thanks,
Florian



libgcov, fork, and mingw (and other targets without the full POSIX set)

2023-12-01 Thread Florian Weimer via Gcc
I've received a report of a mingw build failure:

../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork':
../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit declaration of 
function 'fork' [-Wimplicit-function-declaration]
  185 |   pid = fork ();
  | ^~~~
make[2]: *** [Makefile:932: _gcov_fork.o] Error 1
make[2]: *** Waiting for unfinished jobs

As far as I understand it, mingw doesn't have fork and doesn't declare
it in , so it's not clear to me how this has ever worked.  I
would expect a linker failure.  Maybe that doesn't happen because the
object containing a reference to fork is only ever pulled in if the
application calls the intercepted fork, which doesn't happen on mingw.

What's the best way to fix this?  I expect it's going to impact other
targets (perhaps for different functions) because all of
libgcov-interface.c is built unconditionally.  I don't think we run
configure for the target, so we can't simply check for a definition of
the HAVE_FORK macro.

Thanks,
Florian



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

2023-11-30 Thread Florian Weimer
* 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 another element here: FreeBSD 14 which was
> just released now ships with Clang 16 so we seem to be getting some
> activity from them which is a help.
>
> I've resumed our testing for configure diffs and am going to
> focus on that for now. It's just laborious because of how many errors
> are actually fine.

Marek has kindly posted his reviews, and I'm incorporating his
suggestions.

Meanwhile, I've posted some numbers to the gcc list:

  Update on GCC 14 C type safety changes/warnings as errors
  

Thanks,
Florian



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

2023-11-30 Thread Florian Weimer
* 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:
>> > >> --- a/gcc/doc/invoke.texi
>> > >> +++ b/gcc/doc/invoke.texi
>> > >> @@ -6183,6 +6183,7 @@ that have their own flag:
>> > >>  @gccoptlist{
>> > >>  -Wimplicit-function-declaration @r{(C)}
>> > >>  -Wimplicit-int @r{(C)}
>> > >> +-Wincompatible-pointer-types @r{(C)}
>> > >>  -Wint-conversion @r{(C)}
>> > >>  -Wnarrowing @r{(C++)}
>> > >>  -Wreturn-mismatch @r{(C)}
>> > >
>> > > BTW, should the C ones mention Objective-C as well?
>> > 
>> > Isn't there Objective-C++ as well?  I assumed it applied to both
>> > dialects.
>> 
>> I think we usually spell both, if they apply.  But you can leave it as it is.
>
> Seems we use (C and Objective-C only) (40 times) in preference to (C only)
> (4 times), (C++ and Objective-C++ only) (61 times) in preference to (6
> times), but (C and C++ only) (5 times) and never all 4 languages, even
> when I think it is very likely some switch would be C only, C++ only or
> C and C++ only.  And (C) is used just for Copyright ;)

So it should say “C and Objective-C only” for the C stuff, and “C++ and
Objective-C++ only” for -Wnarrowing?

Jason, does the -Wnarrowing aspect of -fpermissive apply to
Objective-C++ as well, or is it stuck at C++98?

Thanks,
Florian



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

2023-11-30 Thread Florian Weimer
* 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 @r{(C)}
>>  -Wimplicit-int @r{(C)}
>> +-Wincompatible-pointer-types @r{(C)}
>>  -Wint-conversion @r{(C)}
>>  -Wnarrowing @r{(C++)}
>>  -Wreturn-mismatch @r{(C)}
>
> BTW, should the C ones mention Objective-C as well?

Isn't there Objective-C++ as well?  I assumed it applied to both
dialects.

Thanks,
Florian



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

2023-11-30 Thread Florian Weimer
* 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/diagnostic-types-1.c: compile with -fpermissive.
>
> s/compile/Compile/

All fixed, thanks.

Florian



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

2023-11-30 Thread Florian Weimer
* 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.  You could probably just say
> { dg-warning {-Wimplicit-int} }

I wanted to have some more context for the other files that might get
the explict line number wrong.

>> +return incompatible_pointer_types; /* { dg-error "returning 'int \\\* 
>> \\\(\\\*\\\)\\\(int\\\)' from a function with incompatible return type 'int 
>> \\\*' \\\[-Wincompatible-pointer-types\\\]" } */
>
> And here maybe
> { dg-error {returning 'int \* \(\*\)\(int\)' from a function with 
> incompatible return type 'int \*' \[-Wincompatible-pointer-types\]} }
> could work the same.  But you don't have to go and change it; I don't
> want to make more work for you.

Oh, I'm not too familiar with Tcl.  I haven't seen single quotes being
used elsewhere.  I prefer not to change it unless there is another
reason to rework all this.  So … let's wait?

>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/permerror-system.c
>> @@ -0,0 +1,9 @@
>> +/* { dg-options "-isystem ${srcdir}" } */
>> +
>> +/* Test that permerrors appear in system headers.  */
>> +
>> +/* The dg-* directives in the header file are ignored.  No warnings are
>> +   expected.  */
>> +#include 
>
> Why not just #include "permerror-default.c"?

I wanted to make sure that the file is found through the -isystem path.

Thanks,
Florian



Update on GCC 14 C type safety changes/warnings as errors

2023-11-30 Thread Florian Weimer via Gcc
The patch series is currently under review:

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


Jeff as a global reviewer has delegated review to Marek.

The current series is based on an earlier suggestion to do as much as
possible in one transition.  The full list of upgraded warnings is:

  -Wimplicit-function-declaration
  -Wimplicit-int
  -Wint-conversion
  -Wreturn-mismatch (new, previously part of -Wreturn-types)
  -Wdeclaration-missing-parameter-type (new, previously unnamed)
  -Wincompatible-pointer-types

Fedora has a set of about 15,000 source packages which are built with a
GCC compiler in the buildroot.  Until recently, we only had experience
with dealing with -Wimplicit-function-declaration and -Wimplicit-int
issues.  We have implemented fixes or workaround in about 860 packages
for those two warnings.  Where possible, these fixes have been sent
upstream, but of course in many cases, upstream has been dormant for a
while or not around at all anymore.

We now have Fedora test builds with an instrumented GCC that covers all
the warnings listed above.  The data is skewed somewhat because we
underwent an unscheduled libxml2 API transition at the same time, and
also had a glibc crypt declaration regression initially.  I'm going with
the numbers I have today.  They include cleanups for about 50 packages
for various issues (most prominent ones being bash and xterm).

  autoconf
  all only
  implicit-function-declaration53   21
  implicit-int  20
  int-conversion   99   33
  return-mismatch  132
  declaration-missing-parameter-type00
  incompatible-pointer-types  374   50
  497   89

Numbers do not tally up because one package can have multiple issues.
The autoconf column counts packages where file-name based heuristics
suggest the critical errors are in autoconf-style feature probes, where
they are ignored and could silently alter the results.  My focus will be
on fixing those packages.

These numbers include a certain amount of false positives, especially
for implicit-function-declaration and incompatible-pointer-types, but
the GCC instrumentation has improved somewhat and now uses unrelated
errors (e.g., about unknown types, or incorrect number of function
errors) to suppress logging of the critical errors.

Looking at the numbers, everything seems quite doable except
incompatible-pointer-types.  (Keep in mind that these numbers are based
on over 15,000 packages.)  Instead of the incompatible-pointer-types
error, Clang only went with a subset (not yet implemented by GCC) called
incompatible-function-pointer-types, but I'm not sure if it would result
in a substantial amount of work reduction.  The status as a warning for
non-function pointers definitely hides real bugs (for example, an
out-of-bounds write in PyTables on 32-bit architectures).

I suggest we put in the incompatible-pointer-types upgrade for now
(pending review), and see how it goes in Fedora.  I plan to backport
these changes to GCC 13 as used in our current development version, so
that we can gain some feedback from package maintainers before we import
GCC 14 (which is expected to happen well before the GCC upstream
release).  If feedback is overly negative, I'm going to suggest that GCC
disables it again for the GCC 14 release, although that would run
counter to the request for one transition only.

Thoughts?

Excluded above are systemic issues related to Vala, which does not
produce valid C in many cases.  I will probably have to look into
teaching Vala to emit diagnostic pragmata in the generated C sources
because they are not expected to be valid C (although again, this really
seems to be hiding application bugs in some cases).

Thanks,
Florian



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

2023-11-23 Thread Florian Weimer
* 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 C99."?

Applied (with “in C99 and later”).

>>  * gcc.target/powerpc/conditional-return.c: Compile with
>>  -fpermissive due to expected-Wreturn-mismatch error.
>
> There seem to be some extra whitespaces after "expected".

Fixed.

>> @@ -7375,7 +7376,10 @@ Attempting to use the return value of a 
>> non-@code{void} function other
>>  than @code{main} that flows off the end by reaching the closing curly
>>  brace that terminates the function is undefined.
>>  
>> -This warning is specific to C and enabled by default.
>> +This warning is specific to C and enabled by default.  In C99 and later
>> +language dialects, it is treated as an error.  It an be downgraded
>
> an -> can

Fixed.

>> diff --git a/gcc/testsuite/gcc.target/powerpc/conditional-return.c 
>> b/gcc/testsuite/gcc.target/powerpc/conditional-return.c
>> index 6b3ef5f52ca..c6491216752 100644
>> --- a/gcc/testsuite/gcc.target/powerpc/conditional-return.c
>> +++ b/gcc/testsuite/gcc.target/powerpc/conditional-return.c
>> @@ -1,7 +1,7 @@
>>  /* Check that a conditional return is used.  */
>>  
>>  /* { dg-do compile } */
>> -/* { dg-options "-O2 -w" } */
>> +/* { dg-options "-O2 -fpermissive -w" } */
>>  
>>  /* { dg-final { scan-assembler {\mbeqlr\M} } } */
>>  
>
> These seem fine.
>
> Should we have a test for -Wno-error=return-mismatch and -Wno-return-mismatch?
> I didn't see those.

See gcc/testsuite/gcc.dg/permerror-noerror.c and
gcc/testsuite/gcc.dg/permerror-nowarning.c.  They don't show up in the
patch because the diagnostics don't change.

Thanks,
Florian



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

2023-11-23 Thread Florian Weimer
* 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 my concern on the other thread.

Thanks,
Florian



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

2023-11-23 Thread Florian Weimer
* 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 binutils side, and I'll try to
> update the GAS / ld patch set with relaxation included, by the end of this
> month.

Is there a glibc patch with the run-time implementation already?

I'm curious how you are going to implement saving the vector register
file

Thanks,
Florian



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

2023-11-22 Thread Florian Weimer
* 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 the expected behavior.  I added a test for -std=gnu89
>> -fno-permissive, too.
>> I'm including 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 declaration of m2pim_M2RTS_Terminate to test
>>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 forms of -Wimplicit-int in system headers
>>c: Turn -Wreturn-mismatch into a permerror
>>c: Turn -Wincompatible-pointer-types into a permerror
>>c: Add new -Wdeclaration-missing-parameter-type permerror

> The series is fine by me.

Thanks.

> But give Marek additional time to chime in, particularly given the
> holidays this week in the US.  Say through this time next week?

Yes, Marek and I spoke about it today.  I'll wait a bit longer for
feedback.

I'm also gathering some numbers regarding autoconf impact and potential
silent miscompilation.

Thanks,
Florian



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

2023-11-21 Thread Florian Weimer
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/testsuite/gcc.misc-tests/linkage-y.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/testsuite/gcc.misc-tests/linkage-y.c 
b/gcc/testsuite/gcc.misc-tests/linkage-y.c
index eaffa5e4bb7..4235325f2cb 100644
--- a/gcc/testsuite/gcc.misc-tests/linkage-y.c
+++ b/gcc/testsuite/gcc.misc-tests/linkage-y.c
@@ -1,8 +1,11 @@
 /* 920717-y.c */
 
 extern const char s[];
+extern int puts(const char *);
 
+int
 main()
 {
puts(s);
+   return 0;
 }

base-commit: 700d70e4a2874645ddb67a8a335131d83b242e69



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

2023-11-20 Thread Florian Weimer
* 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 existing
> -Wmissing-parameter-type for this?

It's documented as:

‘-Wmissing-parameter-type (C and Objective-C only)’
 A function parameter is declared without a type specifier in
 K functions:

  void foo(bar) { }

 This warning is also enabled by ‘-Wextra’.


What this doesn't say is that this has been subsumed by -Wimplicit-int
in C99 and later language modes.

Maybe we can tweak things such that -Wmissing-parameter-type controls
declarations only in C99 and later language modes, and turn just that
into a permerror.  But the situation is confusing enough already, which
is why I opted for the separate warning.

Thanks,
Florian



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

2023-11-20 Thread Florian Weimer
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 changes.

gcc/c/

PR c/96284
* c-typeck.cc (build_conditional_expr): Upgrade most pointer
type mismatches to a permerror.
(convert_for_assignment): Use permerror_opt and
permerror_init for OPT_Wincompatible_pointer_types warnings.

gcc/testsuite/

* gcc.dg/permerror-default.c (incompatible_pointer_types):
Expect new permerror.
* gcc.dg/permerror-gnu89-nopermissive.c
(incompatible_pointer_types):   Likewise.
* gcc.dg/permerror-pedantic.c (incompatible_pointer_types):
Likewise.
* gcc.dg/permerror-system.c: Likewise.
* gcc.dg/Wincompatible-pointer-types-2.c: Compile with
-fpermissivedue to expected errors.
* gcc.dg/Wincompatible-pointer-types-5.c: New test.  Copied
from gcc.dg/Wincompatible-pointer-types-2.c.  Expect errors.
* gcc.dg/anon-struct-11.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/anon-struct-11a.c: New test.  Copied from
gcc.dg/anon-struct-11.c.  Expect errors.
* gcc.dg/anon-struct-13.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/anon-struct-13a.c: New test.  Copied from
gcc.dg/anon-struct-13.c.  Expect errors.
* gcc.dg/builtin-arith-overflow-4.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/builtin-arith-overflow-4a.c: New test.  Copied from
gcc.dg/builtin-arith-overflow-4.c.  Expect errors.
* gcc.dg/c23-qual-4.c: Expect -Wincompatible-pointer-types errors.
* gcc.dg/dfp/composite-type.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/dfp/composite-type-2.c: New test.  Copied from
gcc.dg/dfp/composite-type.c.  Expect errors.
* gcc.dg/diag-aka-1.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/diag-aka-1a.c: New test.  Copied from gcc.dg/diag-aka-1a.c.
Expect errors.
* gcc.dg/enum-compat-1.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/enum-compat-2.c: New test.  Copied from
gcc.dg/enum-compat-1.c.  Expect errors.
* gcc.dg/func-ptr-conv-1.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/func-ptr-conv-2.c: New test.  Copied from
gcc.dg/func-ptr-conv-1.c.  Expect errors.
* gcc.dg/init-bad-7.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/init-bad-7a.c: New test.  Copied from gcc.dg/init-bad-7.c.
Expect errors.
* gcc.dg/noncompile/incomplete-3.c (foo): Expect
-Wincompatible-pointer-types error.
* gcc.dg/param-type-mismatch-2.c (test8): Likewise.
* gcc.dg/pointer-array-atomic.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/pointer-array-atomic-2.c: New test.  Copied from
gcc.dg/pointer-array-atomic.c.  Expect errors.
* gcc.dg/pointer-array-quals-1.c (test): Expect
-Wincompatible-pointer-types errors.
* gcc.dg/transparent-union-1.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/transparent-union-1a.c: New test.  Copied from
gcc.dg/transparent-union-1.c.  Expect errors.
* gcc.target/aarch64/acle/memtag_2a.c
(test_memtag_warning_return_qualifier): Expect additional
errors.
* gcc.target/aarch64/sve/acle/general-c/load_2.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_1.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_2.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_3.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_4.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_5.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_1.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_2.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_3.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_4.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/sizeless-1.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/sizeless-2.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_1.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_2.c (f1): Likewise.
   

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

2023-11-20 Thread Florian Weimer
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/

PR c/91092
PR c/96284
* c-decl.cc (implicit_decl_permerror): Rename from
implicit_decl_warning.  Call permerror_opt instead of
pedwarn and warning_at.
(implicitly_declare): Adjust callers.

gcc/testsuite/

* gcc.dg/permerror-default.c (implicit_function_declaration):
Expect the new permerror.
* gcc.dg/permerror-system.c: Likewise.
* c-c++-common/spellcheck-reserved.c (test, test_2): Expect
error instead of warning.
(f): Expect error instead of warning.
* gcc.dg/Wimplicit-function-declaration-c99.c: Compile with
-fpermissive due to expected warning.
* gcc.dg/Wimplicit-function-declaration-c99-2.c: New test.
Copied from gcc.dg/Wimplicit-function-declaration-c99.c.
Expect error.
* gcc.dg/missing-header-fixit-1.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-1a.c: New test.  Copied from
gcc.dg/missing-header-fixit-1.c, but expect error.
* gcc.dg/missing-header-fixit-2.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-2a.c: New test.  Copied from
gcc.dg/missing-header-fixit-2.c, but expect error.
* gcc.dg/missing-header-fixit-4.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-4a.c: New test.  Copied from
gcc.dg/missing-header-fixit-4.c, but expect error.
* gcc.dg/missing-header-fixit-5.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-5a.c: New test.  Copied from
gcc.dg/missing-header-fixit-5.c, but expect error.
* gcc.dg/pr61852.c: Expect implicit-function-declaration
error instead of warning.
* gcc.dg/spellcheck-identifiers-2.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-2a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers-2a.c.  Expect errors.
* gcc.dg/spellcheck-identifiers-3.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-3a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers-2a.c.  Expect errors.
* gcc.dg/spellcheck-identifiers-4.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-4a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers-2a.c.  Expect error.
* gcc.dg/spellcheck-identifiers.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-1a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers.c.  Expect errors.
* gcc.target/aarch64/sve/acle/general-c/ld1sh_gather_1.c (f1):
Expect error.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_index_1.c:
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_index_restricted_1.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_1.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_2.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_3.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_4.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_5.c:
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_1.c:
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_2.c:
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_3.c:
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_4.c:
(f1): Likewise.
---
 gcc/c/c-decl.cc   |  20 +--
 gcc/doc/invoke.texi   |   8 +-
 .../c-c++-common/spellcheck-reserved.c|   4 +-
 .../Wimplicit-function-declaration-c99-2.c|   7 +
 .../Wimplicit-function-declaration-c99.c  |   2 +-
 gcc/testsuite/gcc.dg/missing-header-fixit-1.c |   2 +-
 .../gcc.dg/missing-header-fixit-1a.c  |  37 +
 gcc/testsuite/gcc.dg/missing-header-fixit-2.c |   2 +-
 .../gcc.dg/missing-header-fixit-2a.c  |  31 
 gcc/testsuite/gcc.dg/missing-header-fixit-4.c |   2 +-
 .../gcc.dg/missing-header-fixit-4a.c  |  27 
 gcc/testsuite/gcc.dg/missing-header-fixit-5.c |   2 +-
 

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

2023-11-20 Thread Florian Weimer
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 other/44209
* c-decl.cc (grokparms): Issue permerror for
OPT_Wdeclaration_missing_parameter_type instead of a pedwarn.

gcc/ChangeLog:

* doc/invoke.texi (Warning Options): Document
-Wdeclaration-missing-parameter-type.

gcc/testsuite/ChangeLog:

* gcc.dg/permerror-default.c (missing_parameter_type):
Expect error.
* gcc.dg/permerror-fpermissive.c (missing_parameter_type):
Expect -Wdeclaration-missing-parameter-type warning.
* gcc.dg/permerror-gnu89-nopermissive.c (missing_parameter_type):
Expect -Wdeclaration-missing-parameter-type error.
* gcc.dg/permerror-gnu89-pedantic.c (missing_parameter_type):
Likewise.
* gcc.dg/permerror-gnu89.c (missing_parameter_type):
Expect -Wdeclaration-missing-parameter-type warning.
* gcc.dg/permerror-noerror.c: Add
-Wno-error=declaration-missing-parameter-type to build flags.
(missing_parameter_type): Expect
-Wdeclaration-missing-parameter-type warning.
* gcc.dg/permerror-nowarning.c: Build with
-Wno-declaration-missing-parameter-type.  Remove previously
expected warning.
* gcc.dg/permerror-fpermissive-nowarning.c: Likewise.
* gcc.dg/permerror-pedantic.c (missing_parameter_type):
Expect -Wdeclaration-missing-parameter-type error.
* gcc.dg/permerror-system.c (missing_parameter_type):
Likewise.
---
 gcc/c-family/c.opt  |  4 
 gcc/c/c-decl.cc |  6 --
 gcc/doc/invoke.texi | 17 -
 gcc/testsuite/gcc.dg/permerror-default.c|  2 +-
 .../gcc.dg/permerror-fpermissive-nowarning.c|  7 +--
 gcc/testsuite/gcc.dg/permerror-fpermissive.c|  2 +-
 .../gcc.dg/permerror-gnu89-nopermissive.c   |  2 +-
 gcc/testsuite/gcc.dg/permerror-gnu89-pedantic.c |  2 +-
 gcc/testsuite/gcc.dg/permerror-gnu89.c  |  2 +-
 gcc/testsuite/gcc.dg/permerror-noerror.c|  4 ++--
 gcc/testsuite/gcc.dg/permerror-nowarning.c  |  7 +--
 gcc/testsuite/gcc.dg/permerror-pedantic.c   |  2 +-
 gcc/testsuite/gcc.dg/permerror-system.c |  2 ++
 13 files changed, 36 insertions(+), 23 deletions(-)

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index b10c6057cd1..723e8c3e27b 100644
--- 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
 Warn when a declaration is found after a statement.
 
+Wdeclaration-missing-parameter-type
+C ObjC Var(warn_declaration_missing_parameter) Warning Init(1)
+Warn for missing parameter types in function declarations.
+
 Wdelete-incomplete
 C++ ObjC++ Var(warn_delete_incomplete) Init(1) Warning
 Warn when deleting a pointer to incomplete type.
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index d16958113a8..3d9bee54259 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -8337,8 +8337,10 @@ grokparms (struct c_arg_info *arg_info, bool 
funcdef_flag)
 {
   if (!funcdef_flag)
{
- pedwarn (input_location, 0, "parameter names (without types) in "
-  "function declaration");
+ permerror_opt (input_location,
+OPT_Wdeclaration_missing_parameter_type,
+"parameter names (without types) in "
+"function declaration");
  arg_info->parms = NULL_TREE;
}
   else
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index be33da71c44..7f5da45dcea 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -504,7 +504,8 @@ Objective-C and Objective-C++ Dialects}.
 
 @item C and Objective-C-only Warning Options
 @gccoptlist{-Wbad-function-cast  -Wmissing-declarations
--Wmissing-parameter-type -Wmissing-prototypes -Wmissing-variable-declarations
+-Wmissing-parameter-type -Wdeclaration-missing-parameter-type
+-Wmissing-prototypes -Wmissing-variable-declarations
 -Wnested-externs -Wold-style-declaration  -Wold-style-definition
 -Wstrict-prototypes  -Wtraditional  -Wtraditional-conversion
 -Wdeclaration-after-statement  -Wpointer-sign}
@@ -9734,6 +9735,20 @@ void foo(bar) @{ @}
 
 This warning is also enabled by @option{-Wextra}.
 
+@opindex Wno-declaration-missing-parameter-type
+@opindex Wdeclaration-missing-parameter-type
+@item -Wno-declaration-missing-parameter-type @r{(C and Objective-C only)}
+Do not warn if a function declaration contains a parameter name without
+a type.  Such function declarations do not provide a function prototype
+and prevent most type checking in function calls.
+
+This 

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

2023-11-20 Thread Florian Weimer
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): Expect new permerror.
* gcc.dg/permerror-gnu89-nopermissive.c (return_mismatch_1):
Likewise.
* gcc.dg/permerror-system.c: Likewise.
* gcc.dg/20030906-1.c: Compile with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/20030906-1a.c: New test.  Copied from
gcc.dg/20030906-1.c.  Expect the error.
* gcc.dg/20030906-2.c: Compile with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/20030906-2a.c: New test.  Copied from
gcc.dg/20030906-2.c.  Expect the error.
* gcc.dg/Wreturn-mismatch-1.c: Compile with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/Wreturn-mismatch-1a.c: New test.  Copied from
gcc.dg/Wreturn-mismatch-1.c.  Expect the error.
* gcc.dg/Wreturn-mismatch-2.c: Compile with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/Wreturn-mismatch-2a.c: New test.  Copied from
gcc.dg/Wreturn-mismatch-2.c.  Expect the error.
* gcc.dg/diagnostic-range-bad-return.c: Compile with
-fpermissive due to expected -Wreturn-mismatch error.
* gcc.dg/diagnostic-range-bad-return-2.c: New test.
Copied from gcc.dg/diagnostic-range-bad-return.c.  Expect the
error.
* gcc.dg/pr105635-2.c: Expect -Wreturn-mismatch error.
* gcc.dg/pr23075.c: Build with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/pr23075-2.c: New test.  Copied from gcc.dg/pr23075.c.
Expect the error.
* gcc.dg/pr29521.c: Compile with -fpermissive due to expected
-Wreturn-mismatch error.
* gcc.dg/pr29521-a.c: New test. Copied from gcc.dg/pr29521.c.
Expect error.
* gcc.dg/pr67730.c: Compile with -fpermissive due to expected
-Wreturn-mismatch error.
* gcc.dg/pr67730-a.c: New test.  Copied from
gcc.dg/pr67730-a.c.  Expect error.
* gcc.target/powerpc/conditional-return.c: Compile with
-fpermissive due to expected-Wreturn-mismatch error.
---
 gcc/c/c-typeck.cc |  4 +-
 gcc/doc/invoke.texi   |  6 ++-
 gcc/testsuite/gcc.dg/20030906-1.c |  2 +-
 gcc/testsuite/gcc.dg/20030906-1a.c| 21 
 gcc/testsuite/gcc.dg/20030906-2.c |  2 +-
 gcc/testsuite/gcc.dg/20030906-2a.c| 21 
 gcc/testsuite/gcc.dg/Wreturn-mismatch-1.c |  2 +-
 gcc/testsuite/gcc.dg/Wreturn-mismatch-1a.c| 40 ++
 gcc/testsuite/gcc.dg/Wreturn-mismatch-2.c |  2 +-
 gcc/testsuite/gcc.dg/Wreturn-mismatch-2a.c| 41 +++
 .../gcc.dg/diagnostic-range-bad-return-2.c| 52 +++
 .../gcc.dg/diagnostic-range-bad-return.c  |  2 +-
 gcc/testsuite/gcc.dg/permerror-default.c  |  4 +-
 .../gcc.dg/permerror-gnu89-nopermissive.c |  2 +-
 gcc/testsuite/gcc.dg/permerror-system.c   |  3 ++
 gcc/testsuite/gcc.dg/pr105635-2.c |  2 +-
 gcc/testsuite/gcc.dg/pr23075-2.c  | 14 +
 gcc/testsuite/gcc.dg/pr23075.c|  2 +-
 gcc/testsuite/gcc.dg/pr29521-a.c  | 15 ++
 gcc/testsuite/gcc.dg/pr29521.c|  2 +-
 gcc/testsuite/gcc.dg/pr67730-a.c  | 11 
 gcc/testsuite/gcc.dg/pr67730.c|  2 +-
 .../gcc.target/powerpc/conditional-return.c   |  2 +-
 23 files changed, 238 insertions(+), 16 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/20030906-1a.c
 create mode 100644 gcc/testsuite/gcc.dg/20030906-2a.c
 create mode 100644 gcc/testsuite/gcc.dg/Wreturn-mismatch-1a.c
 create mode 100644 gcc/testsuite/gcc.dg/Wreturn-mismatch-2a.c
 create mode 100644 gcc/testsuite/gcc.dg/diagnostic-range-bad-return-2.c
 create mode 100644 gcc/testsuite/gcc.dg/pr23075-2.c
 create mode 100644 gcc/testsuite/gcc.dg/pr29521-a.c
 create mode 100644 gcc/testsuite/gcc.dg/pr67730-a.c

diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index c7b35a27e3f..f4b700117ff 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -11205,7 +11205,7 @@ c_finish_return (location_t loc, tree retval, tree 
origtype)
  && valtype != NULL_TREE && TREE_CODE (valtype) != VOID_TYPE)
{
  no_warning = true;
- if (emit_diagnostic (flag_isoc99 ? DK_PEDWARN : DK_WARNING,
+ if (emit_diagnostic (flag_isoc99 ? DK_PERMERROR : DK_WARNING,
   loc, OPT_Wreturn_mismatch,
   "% with no value,"
   " in function returning non-void"))
@@ -11218,7 +11218,7 @@ c_finish_return (location_t loc, tree retval, tree 
origtype)
   

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

2023-11-20 Thread Florian Weimer
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_opt
instead of warn_defaults_to.
(store_parm_decls_oldstyle): Call permerror_opt for
OPT_Wimplicit_int.

gcc/testsuite/

* gcc.dg/permerror-default.c (implicit_int_1, implicit_int_2)
(implicit_int_3, implicit_int_4): Expect new permerror.
* gcc.dg/permerror-system.c: Expect a single new permerror.
* gcc.dg/Wimplicit-int-1.c: Compile with -fpermissive due to
expected warning.
* gcc.dg/Wimplicit-int-4.c: Likewise.
* gcc.dg/Wimplicit-int-1a.c: New test.  Copied from
gcc.dg/Wimplicit-int-1.c, but expect errors.
* gcc.dg/Wimplicit-int-4a.c: New test.  Copied from
gcc.dg/Wimplicit-int-4.c, but expect errors.
* gcc.dg/gnu23-attr-syntax-2.c: Compile with -fpermissive
due to expected implicit-int error.
* gcc.dg/gnu23-attr-syntax-3.c: New test.  Copied from
gcc.dg/gnu23-attr-syntax-2.c, but expect an error.
* gcc.dg/pr105635.c: Build with -fpermissive due to implicit
int.
* gcc.dg/pr105635-2.c: New test.  Copied from
gcc.dg/pr105635.c.  Expect implicit int error.
* gcc.dg/noncompile/pr79758.c: Build with -fpermissive due to
implicitint.
* gcc.dg/noncompile/pr79758-2.c: New test.  Copied from
gcc.dg/noncompile/pr79758.c.  Expect implicit int error.
---
 gcc/c/c-decl.cc | 43 ++---
 gcc/doc/invoke.texi |  7 +++-
 gcc/testsuite/gcc.dg/Wimplicit-int-1.c  |  2 +-
 gcc/testsuite/gcc.dg/Wimplicit-int-1a.c | 11 ++
 gcc/testsuite/gcc.dg/Wimplicit-int-4.c  |  2 +-
 gcc/testsuite/gcc.dg/Wimplicit-int-4a.c | 11 ++
 gcc/testsuite/gcc.dg/gnu23-attr-syntax-2.c  |  2 +-
 gcc/testsuite/gcc.dg/gnu23-attr-syntax-3.c  | 17 
 gcc/testsuite/gcc.dg/noncompile/pr79758-2.c |  6 +++
 gcc/testsuite/gcc.dg/noncompile/pr79758.c   |  1 +
 gcc/testsuite/gcc.dg/permerror-default.c| 12 +++---
 gcc/testsuite/gcc.dg/permerror-system.c |  2 +
 gcc/testsuite/gcc.dg/pr105635-2.c   | 11 ++
 gcc/testsuite/gcc.dg/pr105635.c |  2 +-
 14 files changed, 86 insertions(+), 43 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/Wimplicit-int-1a.c
 create mode 100644 gcc/testsuite/gcc.dg/Wimplicit-int-4a.c
 create mode 100644 gcc/testsuite/gcc.dg/gnu23-attr-syntax-3.c
 create mode 100644 gcc/testsuite/gcc.dg/noncompile/pr79758-2.c
 create mode 100644 gcc/testsuite/gcc.dg/pr105635-2.c

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 011f0bf0a69..893e24f7dc6 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -647,8 +647,6 @@ static tree grokdeclarator (const struct c_declarator *,
bool *, enum deprecated_states);
 static tree grokparms (struct c_arg_info *, bool);
 static void layout_array_type (tree);
-static void warn_defaults_to (location_t, int, const char *, ...)
-ATTRIBUTE_GCC_DIAG(3,4);
 static const char *header_for_builtin_fn (tree);
 
 /* T is a statement.  Add it to the statement-tree.  This is the
@@ -6570,23 +6568,6 @@ warn_variable_length_array (tree name, tree size)
 }
 }
 
-/* Print warning about defaulting to int if necessary.  */
-
-static void
-warn_defaults_to (location_t location, int opt, const char *gmsgid, ...)
-{
-  diagnostic_info diagnostic;
-  va_list ap;
-  rich_location richloc (line_table, location);
-
-  va_start (ap, gmsgid);
-  diagnostic_set_info (, gmsgid, , ,
-   flag_isoc99 ? DK_PEDWARN : DK_WARNING);
-  diagnostic.option_index = opt;
-  diagnostic_report_diagnostic (global_dc, );
-  va_end (ap);
-}
-
 /* Returns the smallest location != UNKNOWN_LOCATION in LOCATIONS,
considering only those c_declspec_words found in LIST, which
must be terminated by cdw_number_of_elements.  */
@@ -6875,12 +6856,12 @@ grokdeclarator (const struct c_declarator *declarator,
   else
{
  if (name)
-   warn_defaults_to (loc, OPT_Wimplicit_int,
- "type defaults to % in declaration "
- "of %qE", name);
+   permerror_opt (loc, OPT_Wimplicit_int,
+  "type defaults to % in declaration "
+  "of %qE", name);
  else
-   warn_defaults_to (loc, OPT_Wimplicit_int,
- "type defaults to % in type name");
+   permerror_opt (loc, OPT_Wimplicit_int,
+  "type defaults to % in type name");
}
 }
 
@@ -10290,10 +10271,10 @@ start_function (struct c_declspecs *declspecs, struct 
c_declarator *declarator,
 }
 
   if (warn_about_return_type)
-   

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

2023-11-20 Thread Florian Weimer
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_init): New function.
(pedwarn_init): Call pedwarn_permerror_init.
(convert_for_assignment): Use permerror_opt and
permerror_init for -Wint-conversion warnings.

gcc/testsuite/

* gcc.dg/permerror-default.c (int_conversion_1)
(int_conversion_2): Expect the new permerrors.
* gcc.dg/permerror-gnu89-nopermissive.c (int_conversion_1)
(int_conversion_2): Likewise.
* gcc.dg/permerror-system.c: Likewise.
* c-c++-common/pr77624-1.c (foo, bar): Expect
error instead of warning.
* gcc.dg/Wint-conversion-2.c: Compile with -fpermissive due
to expected int-conversion warning.
* gcc.dg/Wint-conversion-3.c: Likewise.
* gcc.dg/Wint-conversion-4.c: New test.  Based on
gcc.dg/Wint-conversion-3.c.  Expect int-conversion errors.
* gcc.dg/assign-warn-1.c: Compile with -fpermissive.
* gcc.dg/assign-warn-4.c: New file.  Extracted from
assign-warn1.c.  Expect int-cnversion errors.
* gcc.dg/diagnostic-types-1.c: compile with -fpermissive.
* gcc.dg/diagnostic-types-2.c: New file.  Extracted from
gcc.dg/diagnostic-types-1.c.  Expect some errors instead of
warnings.
* gcc.dg/gomp/pr35738.c: Compile with -fpermissive due to
expected int-conversion error.
* gcc.dg/gomp/pr35738-2.c: New test.  Based on
gcc.dg/gomp/pr35738.c.  Expect int-converison errors.
* gcc.dg/init-excess-3.c: Expect int-converison errors.
* gcc.dg/overflow-warn-1.c: Likewise.
* gcc.dg/overflow-warn-3.c: Likewise.
* gcc.dg/param-type-mismatch.c: Compile with -fpermissive.
* gcc.dg/param-type-mismatch-2.c: New test.  Copied from
gcc.dg/param-type-mismatch.c.  Expect errors.
* gcc.dg/pr61162-2.c: Compile with -fpermissive.
* gcc.dg/pr61162-3.c: New test. Extracted from
gcc.dg/pr61162-2.c.  Expect int-conversion errors.
* gcc.dg/spec-barrier-3.c: Use -fpermissive due to expected
int-conversion error.
* gcc.dg/spec-barrier-3a.c: New test.  Based on
gcc.dg/spec-barrier-3.c.  Expect int-conversion errors.
* gcc.target/aarch64/acle/memtag_2.c: Use -fpermissive due to expected
int-conversion error.
* gcc.target/aarch64/acle/memtag_2a.c: New test.  Copied from
gcc.target/aarch64/acle/memtag_2.c.  Expect error.
* gcc.target/aarch64/sve/acle/general-c/load_3.c (f1): Expect
error.
* gcc.target/aarch64/sve/acle/general-c/store_2.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_scatter_index_1.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/store_scatter_index_restricted_1.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_scatter_offset_2.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/store_scatter_offset_restricted_1.c
(f1): Likewise.
---
 gcc/c/c-typeck.cc |  97 +
 gcc/doc/invoke.texi   |   6 +
 gcc/testsuite/c-c++-common/pr77624-1.c|   4 +-
 gcc/testsuite/gcc.dg/Wint-conversion-2.c  |   2 +-
 gcc/testsuite/gcc.dg/Wint-conversion-3.c  |   2 +-
 gcc/testsuite/gcc.dg/Wint-conversion-4.c  |  14 ++
 gcc/testsuite/gcc.dg/assign-warn-1.c  |   2 +-
 gcc/testsuite/gcc.dg/assign-warn-4.c  |  21 ++
 gcc/testsuite/gcc.dg/diagnostic-types-1.c |   2 +-
 gcc/testsuite/gcc.dg/diagnostic-types-2.c |  24 +++
 gcc/testsuite/gcc.dg/gomp/pr35738-2.c |  18 ++
 gcc/testsuite/gcc.dg/gomp/pr35738.c   |   2 +-
 gcc/testsuite/gcc.dg/init-excess-3.c  |   4 +-
 gcc/testsuite/gcc.dg/overflow-warn-1.c|   4 +-
 gcc/testsuite/gcc.dg/overflow-warn-3.c|   4 +-
 gcc/testsuite/gcc.dg/param-type-mismatch-2.c  | 187 ++
 gcc/testsuite/gcc.dg/param-type-mismatch.c|   2 +-
 gcc/testsuite/gcc.dg/permerror-default.c  |  20 +-
 .../gcc.dg/permerror-gnu89-nopermissive.c |  20 +-
 gcc/testsuite/gcc.dg/permerror-system.c   |  13 +-
 gcc/testsuite/gcc.dg/pr61162-2.c  |   2 +-
 gcc/testsuite/gcc.dg/pr61162-3.c  |  13 ++
 gcc/testsuite/gcc.dg/spec-barrier-3.c |   2 +-
 gcc/testsuite/gcc.dg/spec-barrier-3a.c|  13 ++
 .../gcc.target/aarch64/acle/memtag_2.c|   4 +-
 .../gcc.target/aarch64/acle/memtag_2a.c   |  71 +++
 .../aarch64/sve/acle/general-c/load_3.c   |   2 +-
 .../aarch64/sve/acle/general-c/store_2.c  |   2 +-
 .../acle/general-c/store_scatter_index_1.c|   2 +-
 .../store_scatter_index_restricted_1.c|   

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

2023-11-20 Thread Florian Weimer
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 test.
* gcc.dg/permerror-fpermissive.c: Likewise.
* gcc.dg/permerror-fpermissive-nowarning.c: Likewise.
* gcc.dg/permerror-gnu89-nopermissive.c: Likewise.
No permerrors yet, so this matches gcc.dg/permerror-gnu89.c
for now.
* gcc.dg/permerror-gnu89-pedantic.c: New test.
* gcc.dg/permerror-gnu89.c: Likewise.
* gcc.dg/permerror-noerror.c: Likewise.
* gcc.dg/permerror-nowarning.c: Likewise.
* gcc.dg/permerror-pedantic.c: Likewise.
* gcc.dg/permerror-system.c: Likewise.
---
 gcc/testsuite/gcc.dg/permerror-default.c  | 85 +++
 .../gcc.dg/permerror-fpermissive-nowarning.c  | 11 +++
 gcc/testsuite/gcc.dg/permerror-fpermissive.c  | 85 +++
 .../gcc.dg/permerror-gnu89-nopermissive.c | 85 +++
 .../gcc.dg/permerror-gnu89-pedantic.c | 85 +++
 gcc/testsuite/gcc.dg/permerror-gnu89.c| 85 +++
 gcc/testsuite/gcc.dg/permerror-noerror.c  | 85 +++
 gcc/testsuite/gcc.dg/permerror-nowarning.c| 10 +++
 gcc/testsuite/gcc.dg/permerror-pedantic.c | 85 +++
 gcc/testsuite/gcc.dg/permerror-system.c   |  9 ++
 10 files changed, 625 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/permerror-default.c
 create mode 100644 gcc/testsuite/gcc.dg/permerror-fpermissive-nowarning.c
 create mode 100644 gcc/testsuite/gcc.dg/permerror-fpermissive.c
 create mode 100644 gcc/testsuite/gcc.dg/permerror-gnu89-nopermissive.c
 create mode 100644 gcc/testsuite/gcc.dg/permerror-gnu89-pedantic.c
 create mode 100644 gcc/testsuite/gcc.dg/permerror-gnu89.c
 create mode 100644 gcc/testsuite/gcc.dg/permerror-noerror.c
 create mode 100644 gcc/testsuite/gcc.dg/permerror-nowarning.c
 create mode 100644 gcc/testsuite/gcc.dg/permerror-pedantic.c
 create mode 100644 gcc/testsuite/gcc.dg/permerror-system.c

diff --git a/gcc/testsuite/gcc.dg/permerror-default.c 
b/gcc/testsuite/gcc.dg/permerror-default.c
new file mode 100644
index 000..ea0be1dc89f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/permerror-default.c
@@ -0,0 +1,85 @@
+/* { dg-options "" } */
+
+/* Overview test for C permerrors.  This test should be kept in sync with the
+   other permerror-* tests.  If new permerrors are added, test cases should be
+   added to this and the other files.  */
+
+void
+implicit_function_declaration (void)
+{
+  f1 (); /* { dg-warning "'f1' \\\[-Wimplicit-function-declaration\\\]" } */
+}
+
+extern implicit_int_1; /* { dg-warning "'implicit_int_1' 
\\\[-Wimplicit-int\\\]" } */
+typedef implicit_int_2; /* { dg-warning "'implicit_int_2' 
\\\[-Wimplicit-int\\\]" } */
+extern implicit_int_3 (void); /* { dg-warning "'implicit_int_3' 
\\\[-Wimplicit-int\\]" } */
+implicit_int_4 (i) /* { dg-warning "return type defaults to 'int' 
\\\[-Wimplicit-int\\\]" } */
+/* { dg-warning "type of 'i' defaults to 'int' \\\[-Wimplicit-int\\\]" "" { 
target *-*-*} .-1 } */
+{
+  (const) 0; /* { dg-warning "type defaults to 'int' in type name 
\\\[-Wimplicit-int\\\]" } */
+}
+
+extern int missing_parameter_type (i); /* { dg-warning "parameter names 
\\\(without types\\\) in function declaration\n" } */
+
+
+int *
+int_conversion_1 (int flag)
+{
+  void f2 (int *);
+  flag ? "1" : 1; /* { dg-warning "pointer/integer type mismatch in 
conditional expression \\\[-Wint-conversion\\\]" } */
+  flag ? 1 : "1"; /* { dg-warning "pointer/integer type mismatch in 
conditional expression \\\[-Wint-conversion\\\]" } */
+  f2 (flag); /* { dg-warning "passing argument 1 of 'f2' makes pointer from 
integer without a cast \\\[-Wint-conversion\\\]" } */
+  {
+int i1 =  /* { dg-warning "initialization of 'int' from 'int \\\*' 
makes integer from pointer without a cast \\\[-Wint-conversion\\\]" } */
+i1 =  /* { dg-warning "assignment to 'int' from 'int \\\*' makes 
integer from pointer without a cast \\\[-Wint-conversion\\\]" } */
+  }
+  return flag; /* { dg-warning "returning 'int' from a function with return 
type 'int \\\*' makes pointer from integer without a cast 
\\\[-Wint-conversion\\\]" } */
+}
+
+int
+int_conversion_2 (int flag)
+{
+  void f3 (int);
+  f3 (); /* { dg-warning "passing argument 1 of 'f3' makes integer from 
pointer without a cast \\\[-Wint-conversion\\\]" } */
+  {
+int *i1 = flag; /* { dg-warning "initialization of 'int \\\*' from 'int' 
makes pointer from integer without a cast \\\[-Wint-conversion\\\]" } */
+i1 = flag; /* { dg-warning "assignment to 'int \\\*' from 'int' makes 
pointer from integer without a cast \\\[-Wint-conversion\\\]" } */
+  }
+  return  /* { dg-warning "returning 'int \\\*' from a function with 
return type 'int' 

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

2023-11-20 Thread Florian Weimer
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 (grokdeclarator): Do not skip -Wimplicit-int
warnings or errors in system headers.

gcc/testsuite/

* gcc.dg/permerror-system.c: Expect all -Wimplicit-int
permerrors.
---
 gcc/c/c-decl.cc | 2 +-
 gcc/testsuite/gcc.dg/permerror-system.c | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 893e24f7dc6..d16958113a8 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -6845,7 +6845,7 @@ grokdeclarator (const struct c_declarator *declarator,
 
   /* Diagnose defaulting to "int".  */
 
-  if (declspecs->default_int_p && !in_system_header_at (input_location))
+  if (declspecs->default_int_p)
 {
   /* Issue a warning if this is an ISO C 99 program or if
 -Wreturn-type and this is a function, or if -Wimplicit;
diff --git a/gcc/testsuite/gcc.dg/permerror-system.c 
b/gcc/testsuite/gcc.dg/permerror-system.c
index 60c65ffc1d4..cad48c93f90 100644
--- a/gcc/testsuite/gcc.dg/permerror-system.c
+++ b/gcc/testsuite/gcc.dg/permerror-system.c
@@ -10,7 +10,12 @@
 
 /* { dg-error "'f1' \\\[-Wimplicit-function-declaration\\\]" "" { target *-*-* 
} 10 } */
 
+/* { dg-error "'implicit_int_1' \\\[-Wimplicit-int\\\]" "" { target *-*-* } 13 
} */
+/* { dg-error "'implicit_int_2' \\\[-Wimplicit-int\\\]" "" { target *-*-* } 14 
} */
+/* { dg-error "'implicit_int_3' \\\[-Wimplicit-int\\]" "" { target *-*-* } 15 
} */
+/* { dg-error "return type defaults to 'int' \\\[-Wimplicit-int\\\]" "" { 
target *-*-* } 16 } */
 /* { dg-error "type of 'i' defaults to 'int' \\\[-Wimplicit-int\\\]" "" { 
target *-*-*} 16 } */
+/* { dg-error "type defaults to 'int' in type name \\\[-Wimplicit-int\\\]" "" 
{ target *-*-* } 19 } */
 
 /* { dg-error "pointer/integer type mismatch in conditional expression 
\\\[-Wint-conversion\\\]" "" { target *-*-* } 29 } */
 /* { dg-error "pointer/integer type mismatch in conditional expression 
\\\[-Wint-conversion\\\]" "" { target *-*-* } 30 } */
-- 
2.42.0




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

2023-11-20 Thread Florian Weimer
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/link/externalscaffold/pass/scaffold.c
index 2bd3587f6c7..2df0368b983 100644
--- a/gcc/testsuite/gm2/link/externalscaffold/pass/scaffold.c
+++ b/gcc/testsuite/gm2/link/externalscaffold/pass/scaffold.c
@@ -6,6 +6,7 @@ extern  void m2pim_M2_M2RTS_init (int argc, char *argv[]);
 extern  void m2pim_M2_M2RTS_fini (void);
 extern  void m2pim_M2_RTExceptions_init (int argc, char *argv[]);
 extern  void m2pim_M2_RTExceptions_fini (void);
+extern  void m2pim_M2RTS_Terminate (void);
 extern  void _M2_hello_init (int argc, char *argv[]);
 extern  void _M2_hello_fini (void);
 
-- 
2.42.0




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

2023-11-20 Thread Florian Weimer
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 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/ice_1.c 
b/gcc/testsuite/gcc.target/aarch64/aapcs64/ice_1.c
index 906ccebf616..edc35db2f6e 100644
--- a/gcc/testsuite/gcc.target/aarch64/aapcs64/ice_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/ice_1.c
@@ -16,6 +16,6 @@ void unnamed (int, ...);
 
 void foo ()
 {
-  name (0, );
+  named (0, );
   unnamed (0, );
 }
-- 
2.42.0




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

2023-11-20 Thread Florian Weimer
* 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/config/aarch64/linux-unwind.h
index 00eba866049..18b3df71e7b 100644
--- a/libgcc/config/aarch64/linux-unwind.h
+++ b/libgcc/config/aarch64/linux-unwind.h
@@ -77,7 +77,10 @@ aarch64_fallback_frame_state (struct _Unwind_Context 
*context,
 }
 
   rt_ = context->cfa;
-  sc = _->uc.uc_mcontext;
+  /* Historically, the uc_mcontext member was of type struct sigcontext, but
+ glibc uses a different type now with member names in the implementation
+ namespace.  */
+  sc = (struct sigcontext *) _->uc.uc_mcontext;
 
 /* This define duplicates the definition in aarch64.md */
 #define SP_REGNUM 31
-- 
2.42.0




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

2023-11-20 Thread Florian Weimer
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 the expected behavior.  I added a test for -std=gnu89
-fno-permissive, too.

I'm including 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 declaration of m2pim_M2RTS_Terminate to test
  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 forms of -Wimplicit-int in system headers
  c: Turn -Wreturn-mismatch into a permerror
  c: Turn -Wincompatible-pointer-types into a permerror
  c: Add new -Wdeclaration-missing-parameter-type permerror

 gcc/c-family/c.opt|   4 +
 gcc/c/c-decl.cc   |  71 +++
 gcc/c/c-typeck.cc | 164 ---
 gcc/doc/invoke.texi   |  50 -
 gcc/testsuite/c-c++-common/pr77624-1.c|   4 +-
 .../c-c++-common/spellcheck-reserved.c|   4 +-
 gcc/testsuite/gcc.dg/20030906-1.c |   2 +-
 gcc/testsuite/gcc.dg/20030906-1a.c|  21 ++
 gcc/testsuite/gcc.dg/20030906-2.c |   2 +-
 gcc/testsuite/gcc.dg/20030906-2a.c|  21 ++
 .../Wimplicit-function-declaration-c99-2.c|   7 +
 .../Wimplicit-function-declaration-c99.c  |   2 +-
 gcc/testsuite/gcc.dg/Wimplicit-int-1.c|   2 +-
 gcc/testsuite/gcc.dg/Wimplicit-int-1a.c   |  11 ++
 gcc/testsuite/gcc.dg/Wimplicit-int-4.c|   2 +-
 gcc/testsuite/gcc.dg/Wimplicit-int-4a.c   |  11 ++
 .../gcc.dg/Wincompatible-pointer-types-2.c|   2 +-
 .../gcc.dg/Wincompatible-pointer-types-5.c|  10 +
 gcc/testsuite/gcc.dg/Wint-conversion-2.c  |   2 +-
 gcc/testsuite/gcc.dg/Wint-conversion-3.c  |   2 +-
 gcc/testsuite/gcc.dg/Wint-conversion-4.c  |  14 ++
 gcc/testsuite/gcc.dg/Wreturn-mismatch-1.c |   2 +-
 gcc/testsuite/gcc.dg/Wreturn-mismatch-1a.c|  40 
 gcc/testsuite/gcc.dg/Wreturn-mismatch-2.c |   2 +-
 gcc/testsuite/gcc.dg/Wreturn-mismatch-2a.c|  41 
 gcc/testsuite/gcc.dg/anon-struct-11.c |   5 +-
 gcc/testsuite/gcc.dg/anon-struct-11a.c| 111 +++
 gcc/testsuite/gcc.dg/anon-struct-13.c |   2 +-
 gcc/testsuite/gcc.dg/anon-struct-13a.c|  76 +++
 gcc/testsuite/gcc.dg/assign-warn-1.c  |   2 +-
 gcc/testsuite/gcc.dg/assign-warn-4.c  |  21 ++
 .../gcc.dg/builtin-arith-overflow-4.c |   2 +-
 .../gcc.dg/builtin-arith-overflow-4a.c|  43 
 gcc/testsuite/gcc.dg/c23-qual-4.c |   6 +-
 gcc/testsuite/gcc.dg/dfp/composite-type-2.c   |  58 ++
 gcc/testsuite/gcc.dg/dfp/composite-type.c |   2 +-
 gcc/testsuite/gcc.dg/diag-aka-1.c |   2 +-
 gcc/testsuite/gcc.dg/diag-aka-1a.c|  29 +++
 .../gcc.dg/diagnostic-range-bad-return-2.c|  52 +
 .../gcc.dg/diagnostic-range-bad-return.c  |   2 +-
 gcc/testsuite/gcc.dg/diagnostic-types-1.c |   2 +-
 gcc/testsuite/gcc.dg/diagnostic-types-2.c |  24 +++
 gcc/testsuite/gcc.dg/enum-compat-1.c  |   2 +-
 gcc/testsuite/gcc.dg/enum-compat-2.c  |  32 +++
 gcc/testsuite/gcc.dg/func-ptr-conv-1.c|   2 +-
 gcc/testsuite/gcc.dg/func-ptr-conv-2.c|  56 ++
 gcc/testsuite/gcc.dg/gnu23-attr-syntax-2.c|   2 +-
 gcc/testsuite/gcc.dg/gnu23-attr-syntax-3.c|  17 ++
 gcc/testsuite/gcc.dg/gomp/pr35738-2.c |  18 ++
 gcc/testsuite/gcc.dg/gomp/pr35738.c   |   2 +-
 gcc/testsuite/gcc.dg/init-bad-7.c |   2 +-
 gcc/testsuite/gcc.dg/init-bad-7a.c|  12 ++
 gcc/testsuite/gcc.dg/init-excess-3.c  |   4 +-
 gcc/testsuite/gcc.dg/missing-header-fixit-1.c |   2 +-
 .../gcc.dg/missing-header-fixit-1a.c  |  37 
 gcc/testsuite/gcc.dg/missing-header-fixit-2.c |   2 +-
 .../gcc.dg/missing-header-fixit-2a.c  |  31 +++
 gcc/testsuite/gcc.dg/missing-header-fixit-4.c |   2 +-
 .../gcc.dg/missing-header-fixit-4a.c  |  27 +++
 gcc/testsuite/gcc.dg/missing-header-fixit-5.c |   2 +-
 .../gcc.dg/missing-header-fixit-5a.c  |  42 
 .../gcc.dg/noncompile/incomplete-3.c  |   2 +-
 gcc/testsuite/gcc.dg/noncompile/pr79758-2.c   |   6 +
 gcc/testsuite/gcc.dg/noncompile/pr79758.c |   1 +
 gcc/testsuite/gcc.dg/overflow-warn-1.c|   4 +-
 gcc/testsuite/gcc.dg/overflow-warn-3.c|   4 +-
 gcc/testsuite/gcc.dg/param-type-mismatch-2.c  | 187 ++
 gcc/testsuite/gcc.dg/param-type-mismatch.c|   2 +-
 gcc/testsuite/gcc.dg/permerror-default.c  |  85

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

2023-11-20 Thread Florian Weimer
* 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 avoid spelling 'value' multiple times?

{( … )} cannot be used in a constant expression, but the new macros are
supposed to be usable there.

Thanks,
Florian



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

2023-11-16 Thread Florian Weimer
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/testsuite/gcc.c-torture/execute/931004-13.c
index 8b79679087c..e8c0c81076c 100644
--- a/gcc/testsuite/gcc.c-torture/execute/931004-13.c
+++ b/gcc/testsuite/gcc.c-torture/execute/931004-13.c
@@ -43,8 +43,8 @@ f (int n, struct tiny x, struct tiny y, struct tiny z, long l)
 abort ();
 }
 
-void
-main (int)
+int
+main (void)
 {
   struct tiny x[3];
   x[0].c = 10;

base-commit: 5f1105612b592650566a54846dd5f9ccdfed01a9



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

2023-11-16 Thread Florian Weimer
* 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 most tests and I hope it should be fine both in the pre-C23 way and in
> C23.

It should remain acceptable.  Some people push for warnings on
int main () { … }, which is why I added the void if I was adding
the return type anyway.  But it seems that warning about that
seems unlikely for GCC at least.

Thanks,
Florian



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

2023-11-16 Thread Florian Weimer
* 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 the features
>> appears to be accidental, and updating allows the tests run with
>> the default compiler flags.
>
>> --- a/gcc/testsuite/gcc.c-torture/execute/931004-13.c
>> +++ b/gcc/testsuite/gcc.c-torture/execute/931004-13.c
>
>> @@ -42,7 +43,8 @@ f (int n, struct tiny x, struct tiny y, struct tiny z, 
>> long l)
>>  abort ();
>>  }
>>
>> -main ()
>> +void
>> +main (int)
>>  {
>>struct tiny x[3];
>>x[0].c = 10;
>
> The nvptx back end doesn't like that one:
>
> PASS: gcc.c-torture/execute/931004-13.c   -O0  (test for excess errors)
> [-PASS:-]{+FAIL:+} gcc.c-torture/execute/931004-13.c   -O0  execution test
> [...]
>
> error   : Prototype doesn't match for 'main' [...]
>
> I'll add handling for this case in (I suppose)
> 'gcc/config/nvptx/nvptx.cc:write_fn_proto_1' if that indeed is a
> conforming declaration of 'main', but is it really?

Sorry about that.  My change was invalid, I swapped int/void by
accident.  Too many edits in too short a period.  I will fix it as
obvious.

Thanks,
Florian



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

2023-11-14 Thread Florian Weimer
* 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 with stage 3 ending on Friday.

The posting date of the patch is what counts, not whether it's been
reviewed and pushed.

Thanks,
Florian



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

2023-11-14 Thread Florian Weimer
* 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 of other permerrors, which are active in system headers.
>
> The situation with system headers is kind of a mess still. I went
> looking for a bug for the -Wimplicit-int behaviour but I only found
> PR78000 for -Wimplicit-function-declaration. But in the bug, Joseph
> makes the same observation.
>
> I don't suppose he'll want to block on that at this late point though.
>
> Do you know offhand what Clang's behaviour is wrt warnings in system
> headers?

Clang ignores these new errors in system headers by default.  I don't
know if that's deliberate or a bug.  Our permerrors are deliberately
active in system headers.  As the test shows, -Wimplicit-int really was
the outlier here because of that check outside the permerror machinery.

I expect system headers are quite clean actually because they have to be
for C++ compatibility.  Some things have improved in the last 25 years.

Thanks,
Florian



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

2023-11-14 Thread Florian Weimer
* 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
>>  Warn when a declaration is found after a statement.
>>  
>> +Wdeclaration-missing-parameter-type
>> +C ObjC Warning
>> +Warn for missing parameter types in function declarations.
>> +
>
> This doesn't have Var(warn_declaration_missing_parameter), so
> -fpermissive -Wno-declaration-missing-parameter-type still warns
> for
>
>   void foo (i);
>
> where I think the warning should be suppressed.  Is that expected?
> It would be nice to have a test for that combination.

Okay, I'll send a v3 tomorrow with this change and a test.  I had no
idea that this was necessary. 8-/

Thanks,
Florian



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

2023-11-14 Thread Florian Weimer
* Dimitar Dimitrov:

> The -w option was used in gcc.dg/20020206-1.c to ignore warnings if the
> '-fprefetch-loop-arrays' option is not supported by target.
>
> When commit r14-5380-g5c432b0efab54e removed the -w option, some targets
> (arm-none-eabi, pru and possibly others) started failing the test:
>
>   cc1: warning: '-fprefetch-loop-arrays' not supported for this target
>   FAIL: gcc.dg/20020206-1.c (test for excess errors)
>
> Fix by instructing DejaGnu to prune the '-fprefetch-loop-arrays'
> warning.
>
> 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

2023-11-14 Thread Florian Weimer
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 other/44209
* c-decl.cc (grokparms): Issue permerror for
OPT_Wdeclaration_missing_parameter_type instead of a pedwarn.

gcc/ChangeLog:

* doc/invoke.texi (Warning Options): Document
-Wdeclaration-missing-parameter-type

gcc/testsuite/ChangeLog:

* gcc.dg/permerror-default.c (missing_parameter_type):
Expect error.
* gcc.dg/permerror-fpermissive.c (missing_parameter_type):
Expect -Wdeclaration-missing-parameter-type warning.
* gcc.dg/permerror-gnu89-pedantic.c (missing_parameter_type):
Expect -Wdeclaration-missing-parameter-type error.
* gcc.dg/permerror-gnu89.c (missing_parameter_type):
Expect -Wdeclaration-missing-parameter-type warning.
* gcc.dg/permerror-noerror.c: Add
-Wno-error=declaration-missing-parameter-type to build flags.
(missing_parameter_type): Expect
-Wdeclaration-missing-parameter-type warning.
* gcc.dg/permerror-pedantic.c (missing_parameter_type):
Expect -Wdeclaration-missing-parameter-type error.
---
 gcc/c-family/c.opt  |  4 
 gcc/c/c-decl.cc |  6 --
 gcc/doc/invoke.texi | 17 -
 gcc/testsuite/gcc.dg/permerror-default.c|  2 +-
 gcc/testsuite/gcc.dg/permerror-fpermissive.c|  2 +-
 gcc/testsuite/gcc.dg/permerror-gnu89-pedantic.c |  2 +-
 gcc/testsuite/gcc.dg/permerror-gnu89.c  |  2 +-
 gcc/testsuite/gcc.dg/permerror-noerror.c|  4 ++--
 gcc/testsuite/gcc.dg/permerror-pedantic.c   |  2 +-
 gcc/testsuite/gcc.dg/permerror-system.c |  2 ++
 10 files changed, 33 insertions(+), 10 deletions(-)

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index b10c6057cd1..723985ec5d0 100644
--- 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
 Warn when a declaration is found after a statement.
 
+Wdeclaration-missing-parameter-type
+C ObjC Warning
+Warn for missing parameter types in function declarations.
+
 Wdelete-incomplete
 C++ ObjC++ Var(warn_delete_incomplete) Init(1) Warning
 Warn when deleting a pointer to incomplete type.
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index d16958113a8..3d9bee54259 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -8337,8 +8337,10 @@ grokparms (struct c_arg_info *arg_info, bool 
funcdef_flag)
 {
   if (!funcdef_flag)
{
- pedwarn (input_location, 0, "parameter names (without types) in "
-  "function declaration");
+ permerror_opt (input_location,
+OPT_Wdeclaration_missing_parameter_type,
+"parameter names (without types) in "
+"function declaration");
  arg_info->parms = NULL_TREE;
}
   else
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index c492ef7ba0c..66804bfe120 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -502,7 +502,8 @@ Objective-C and Objective-C++ Dialects}.
 
 @item C and Objective-C-only Warning Options
 @gccoptlist{-Wbad-function-cast  -Wmissing-declarations
--Wmissing-parameter-type -Wmissing-prototypes -Wmissing-variable-declarations
+-Wmissing-parameter-type -Wdeclaration-missing-parameter-type
+-Wmissing-prototypes -Wmissing-variable-declarations
 -Wnested-externs -Wold-style-declaration  -Wold-style-definition
 -Wstrict-prototypes  -Wtraditional  -Wtraditional-conversion
 -Wdeclaration-after-statement  -Wpointer-sign}
@@ -9732,6 +9733,20 @@ void foo(bar) @{ @}
 
 This warning is also enabled by @option{-Wextra}.
 
+@opindex Wno-declaration-missing-parameter-type
+@opindex Wdeclaration-missing-parameter-type
+@item -Wno-declaration-missing-parameter-type @r{(C and Objective-C only)}
+Do not warn if a function declaration contains a parameter name without
+a type.  Such function declarations do not provide a function prototype
+and prevent most type checking in function calls.
+
+This warning is enabled by default.  In C99 and later dialects of C, it
+is treated as an error.  The error can be downgraded to a warning using
+@option{-fpermissive} (along with certain other errors), or for this
+error alone, with @option{-Wno-error=declaration-missing-parameter-type}.
+
+This warning is upgraded to an error by @option{-pedantic-errors}.
+
 @opindex Wmissing-prototypes
 @opindex Wno-missing-prototypes
 @item -Wmissing-prototypes @r{(C and Objective-C only)}
diff --git a/gcc/testsuite/gcc.dg/permerror-default.c 
b/gcc/testsuite/gcc.dg/permerror-default.c
index 45b58b0131d..c674d689081 100644

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

2023-11-14 Thread Florian Weimer
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 (grokdeclarator): Do not skip -Wimplicit-int
warnings or errors in system headers.

gcc/testsuite/

* gcc.dg/permerror-system.c: Expect all -Wimplicit-int
permerrors.
---
 gcc/c/c-decl.cc | 2 +-
 gcc/testsuite/gcc.dg/permerror-system.c | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 893e24f7dc6..d16958113a8 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -6845,7 +6845,7 @@ grokdeclarator (const struct c_declarator *declarator,
 
   /* Diagnose defaulting to "int".  */
 
-  if (declspecs->default_int_p && !in_system_header_at (input_location))
+  if (declspecs->default_int_p)
 {
   /* Issue a warning if this is an ISO C 99 program or if
 -Wreturn-type and this is a function, or if -Wimplicit;
diff --git a/gcc/testsuite/gcc.dg/permerror-system.c 
b/gcc/testsuite/gcc.dg/permerror-system.c
index 60c65ffc1d4..cad48c93f90 100644
--- a/gcc/testsuite/gcc.dg/permerror-system.c
+++ b/gcc/testsuite/gcc.dg/permerror-system.c
@@ -10,7 +10,12 @@
 
 /* { dg-error "'f1' \\\[-Wimplicit-function-declaration\\\]" "" { target *-*-* 
} 10 } */
 
+/* { dg-error "'implicit_int_1' \\\[-Wimplicit-int\\\]" "" { target *-*-* } 13 
} */
+/* { dg-error "'implicit_int_2' \\\[-Wimplicit-int\\\]" "" { target *-*-* } 14 
} */
+/* { dg-error "'implicit_int_3' \\\[-Wimplicit-int\\]" "" { target *-*-* } 15 
} */
+/* { dg-error "return type defaults to 'int' \\\[-Wimplicit-int\\\]" "" { 
target *-*-* } 16 } */
 /* { dg-error "type of 'i' defaults to 'int' \\\[-Wimplicit-int\\\]" "" { 
target *-*-*} 16 } */
+/* { dg-error "type defaults to 'int' in type name \\\[-Wimplicit-int\\\]" "" 
{ target *-*-* } 19 } */
 
 /* { dg-error "pointer/integer type mismatch in conditional expression 
\\\[-Wint-conversion\\\]" "" { target *-*-* } 29 } */
 /* { dg-error "pointer/integer type mismatch in conditional expression 
\\\[-Wint-conversion\\\]" "" { target *-*-* } 30 } */
-- 
2.41.0




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

2023-11-14 Thread Florian Weimer
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 permerror.
(convert_for_assignment): Use permerror_opt and
permerror_init for OPT_Wincompatible_pointer_types warnings.

gcc/testsuite/

* gcc.dg/permerror-default.c (incompatible_pointer_types):
Expect new permerror.
* gcc.dg/permerror-pedantic.c (incompatible_pointer_types):
Likewise.
* gcc.dg/permerror-system.c: Likewise.
* gcc.dg/Wincompatible-pointer-types-2.c: Compile with
-fpermissivedue to expected errors.
* gcc.dg/Wincompatible-pointer-types-5.c: New test.  Copied
from gcc.dg/Wincompatible-pointer-types-2.c.  Expect errors.
* gcc.dg/anon-struct-11.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/anon-struct-11a.c: New test.  Copied from
gcc.dg/anon-struct-11.c.  Expect errors.
* gcc.dg/anon-struct-13.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/anon-struct-13a.c: New test.  Copied from
gcc.dg/anon-struct-13.c.  Expect errors.
* gcc.dg/builtin-arith-overflow-4.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/builtin-arith-overflow-4a.c: New test.  Copied from
gcc.dg/builtin-arith-overflow-4.c.  Expect errors.
* gcc.dg/c23-qual-4.c: Expect -Wincompatible-pointer-types errors.
* gcc.dg/dfp/composite-type.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/dfp/composite-type-2.c: New test.  Copied from
gcc.dg/dfp/composite-type.c.  Expect errors.
* gcc.dg/diag-aka-1.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/diag-aka-1a.c: New test.  Copied from gcc.dg/diag-aka-1a.c.
Expect errors.
* gcc.dg/enum-compat-1.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/enum-compat-2.c: New test.  Copied from
gcc.dg/enum-compat-1.c.  Expect errors.
* gcc.dg/func-ptr-conv-1.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/func-ptr-conv-2.c: New test.  Copied from
gcc.dg/func-ptr-conv-1.c.  Expect errors.
* gcc.dg/init-bad-7.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/init-bad-7a.c: New test.  Copied from gcc.dg/init-bad-7.c.
Expect errors.
* gcc.dg/noncompile/incomplete-3.c (foo): Expect
-Wincompatible-pointer-types error.
* gcc.dg/param-type-mismatch-2.c (test8): Likewise.
* gcc.dg/pointer-array-atomic.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/pointer-array-atomic-2.c: New test.  Copied from
gcc.dg/pointer-array-atomic.c.  Expect errors.
* gcc.dg/pointer-array-quals-1.c (test): Expect
-Wincompatible-pointer-types errors.
* gcc.dg/transparent-union-1.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/transparent-union-1a.c: New test.  Copied from
gcc.dg/transparent-union-1.c.  Expect errors.
* gcc.target/aarch64/acle/memtag_2a.c
(test_memtag_warning_return_qualifier): Expect additional
errors.
* gcc.target/aarch64/sve/acle/general-c/load_2.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_1.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_2.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_3.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_4.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_5.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_1.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_2.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_3.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_4.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/sizeless-1.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/sizeless-2.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_1.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_2.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_scatter_index_1.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/store_scatter_index_restricted_1.c
(f1): Likewise.
* 

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

2023-11-14 Thread Florian Weimer
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_opt
instead of warn_defaults_to.
(store_parm_decls_oldstyle): Call permerror_opt for
OPT_Wimplicit_int.

gcc/testsuite/

* gcc.dg/permerror-default.c (implicit_int_1, implicit_int_2)
(implicit_int_3, implicit_int_4): Expect new permerror.
* gcc.dg/permerror-system.c: Expect a single new permerror.
* gcc.dg/Wimplicit-int-1.c: Compile with -fpermissive due to
expected warning.
* gcc.dg/Wimplicit-int-4.c: Likewise.
* gcc.dg/Wimplicit-int-1a.c: New test.  Copied from
gcc.dg/Wimplicit-int-1.c, but expect errors.
* gcc.dg/Wimplicit-int-4a.c: New test.  Copied from
gcc.dg/Wimplicit-int-4.c, but expect errors.
* gcc.dg/gnu23-attr-syntax-2.c: Compile with -fpermissive
due to expected implicit-int error.
* gcc.dg/gnu23-attr-syntax-3.c: New test.  Copied from
gcc.dg/gnu23-attr-syntax-2.c, but expect an error.
* gcc.dg/pr105635.c: Build with -fpermissive due to implicit
int.
* gcc.dg/pr105635-2.c: New test.  Copied from
gcc.dg/pr105635.c.  Expect implicit int error.
* gcc.dg/noncompile/pr79758.c: Build with -fpermissive due to
implicitint.
* gcc.dg/noncompile/pr79758-2.c: New test.  Copied from
gcc.dg/noncompile/pr79758.c.  Expect implicit int error.
---
 gcc/c/c-decl.cc | 43 ++---
 gcc/doc/invoke.texi |  7 +++-
 gcc/testsuite/gcc.dg/Wimplicit-int-1.c  |  2 +-
 gcc/testsuite/gcc.dg/Wimplicit-int-1a.c | 11 ++
 gcc/testsuite/gcc.dg/Wimplicit-int-4.c  |  2 +-
 gcc/testsuite/gcc.dg/Wimplicit-int-4a.c | 11 ++
 gcc/testsuite/gcc.dg/gnu23-attr-syntax-2.c  |  2 +-
 gcc/testsuite/gcc.dg/gnu23-attr-syntax-3.c  | 17 
 gcc/testsuite/gcc.dg/noncompile/pr79758-2.c |  6 +++
 gcc/testsuite/gcc.dg/noncompile/pr79758.c   |  1 +
 gcc/testsuite/gcc.dg/permerror-default.c| 12 +++---
 gcc/testsuite/gcc.dg/permerror-system.c |  2 +
 gcc/testsuite/gcc.dg/pr105635-2.c   | 11 ++
 gcc/testsuite/gcc.dg/pr105635.c |  2 +-
 14 files changed, 86 insertions(+), 43 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/Wimplicit-int-1a.c
 create mode 100644 gcc/testsuite/gcc.dg/Wimplicit-int-4a.c
 create mode 100644 gcc/testsuite/gcc.dg/gnu23-attr-syntax-3.c
 create mode 100644 gcc/testsuite/gcc.dg/noncompile/pr79758-2.c
 create mode 100644 gcc/testsuite/gcc.dg/pr105635-2.c

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 011f0bf0a69..893e24f7dc6 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -647,8 +647,6 @@ static tree grokdeclarator (const struct c_declarator *,
bool *, enum deprecated_states);
 static tree grokparms (struct c_arg_info *, bool);
 static void layout_array_type (tree);
-static void warn_defaults_to (location_t, int, const char *, ...)
-ATTRIBUTE_GCC_DIAG(3,4);
 static const char *header_for_builtin_fn (tree);
 
 /* T is a statement.  Add it to the statement-tree.  This is the
@@ -6570,23 +6568,6 @@ warn_variable_length_array (tree name, tree size)
 }
 }
 
-/* Print warning about defaulting to int if necessary.  */
-
-static void
-warn_defaults_to (location_t location, int opt, const char *gmsgid, ...)
-{
-  diagnostic_info diagnostic;
-  va_list ap;
-  rich_location richloc (line_table, location);
-
-  va_start (ap, gmsgid);
-  diagnostic_set_info (, gmsgid, , ,
-   flag_isoc99 ? DK_PEDWARN : DK_WARNING);
-  diagnostic.option_index = opt;
-  diagnostic_report_diagnostic (global_dc, );
-  va_end (ap);
-}
-
 /* Returns the smallest location != UNKNOWN_LOCATION in LOCATIONS,
considering only those c_declspec_words found in LIST, which
must be terminated by cdw_number_of_elements.  */
@@ -6875,12 +6856,12 @@ grokdeclarator (const struct c_declarator *declarator,
   else
{
  if (name)
-   warn_defaults_to (loc, OPT_Wimplicit_int,
- "type defaults to % in declaration "
- "of %qE", name);
+   permerror_opt (loc, OPT_Wimplicit_int,
+  "type defaults to % in declaration "
+  "of %qE", name);
  else
-   warn_defaults_to (loc, OPT_Wimplicit_int,
- "type defaults to % in type name");
+   permerror_opt (loc, OPT_Wimplicit_int,
+  "type defaults to % in type name");
}
 }
 
@@ -10290,10 +10271,10 @@ start_function (struct c_declspecs *declspecs, struct 
c_declarator *declarator,
 }
 
   if (warn_about_return_type)
-   

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

2023-11-14 Thread Florian Weimer
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): Expect new permerror.
* gcc.dg/permerror-system.c: Likewise.
* gcc.dg/20030906-1.c: Compile with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/20030906-1a.c: New test.  Copied from
gcc.dg/20030906-1.c.  Expect the error.
* gcc.dg/20030906-2.c: Compile with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/20030906-2a.c: New test.  Copied from
gcc.dg/20030906-2.c.  Expect the error.
* gcc.dg/Wreturn-mismatch-1.c: Compile with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/Wreturn-mismatch-1a.c: New test.  Copied from
gcc.dg/Wreturn-mismatch-1.c.  Expect the error.
* gcc.dg/Wreturn-mismatch-2.c: Compile with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/Wreturn-mismatch-2a.c: New test.  Copied from
gcc.dg/Wreturn-mismatch-2.c.  Expect the error.
* gcc.dg/diagnostic-range-bad-return.c: Compile with
-fpermissive due to expected -Wreturn-mismatch error.
* gcc.dg/diagnostic-range-bad-return-2.c: New test.
Copied from gcc.dg/diagnostic-range-bad-return.c.  Expect the
error.
* gcc.dg/pr105635-2.c: Expect -Wreturn-mismatch error.
* gcc.dg/pr23075.c: Build with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/pr23075-2.c: New test.  Copied from gcc.dg/pr23075.c.
Expect the error.
* gcc.dg/pr29521.c: Compile with -fpermissive due to expected
-Wreturn-mismatch error.
* gcc.dg/pr29521-a.c: New test. Copied from gcc.dg/pr29521.c.
Expect error.
* gcc.dg/pr67730.c: Compile with -fpermissive due to expected
-Wreturn-mismatch error.
* gcc.dg/pr67730-a.c: New test.  Copied from
gcc.dg/pr67730-a.c.  Expect error.
* gcc.target/powerpc/conditional-return.c: Compile with
-fpermissive due to expected-Wreturn-mismatch error.
---
 gcc/c/c-typeck.cc |  4 +-
 gcc/doc/invoke.texi   |  6 ++-
 gcc/testsuite/gcc.dg/20030906-1.c |  2 +-
 gcc/testsuite/gcc.dg/20030906-1a.c| 21 
 gcc/testsuite/gcc.dg/20030906-2.c |  2 +-
 gcc/testsuite/gcc.dg/20030906-2a.c| 21 
 gcc/testsuite/gcc.dg/Wreturn-mismatch-1.c |  2 +-
 gcc/testsuite/gcc.dg/Wreturn-mismatch-1a.c| 40 ++
 gcc/testsuite/gcc.dg/Wreturn-mismatch-2.c |  2 +-
 gcc/testsuite/gcc.dg/Wreturn-mismatch-2a.c| 41 +++
 .../gcc.dg/diagnostic-range-bad-return-2.c| 52 +++
 .../gcc.dg/diagnostic-range-bad-return.c  |  2 +-
 gcc/testsuite/gcc.dg/permerror-default.c  |  4 +-
 gcc/testsuite/gcc.dg/permerror-system.c   |  3 ++
 gcc/testsuite/gcc.dg/pr105635-2.c |  2 +-
 gcc/testsuite/gcc.dg/pr23075-2.c  | 14 +
 gcc/testsuite/gcc.dg/pr23075.c|  2 +-
 gcc/testsuite/gcc.dg/pr29521-a.c  | 15 ++
 gcc/testsuite/gcc.dg/pr29521.c|  2 +-
 gcc/testsuite/gcc.dg/pr67730-a.c  | 11 
 gcc/testsuite/gcc.dg/pr67730.c|  2 +-
 .../gcc.target/powerpc/conditional-return.c   |  2 +-
 22 files changed, 237 insertions(+), 15 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/20030906-1a.c
 create mode 100644 gcc/testsuite/gcc.dg/20030906-2a.c
 create mode 100644 gcc/testsuite/gcc.dg/Wreturn-mismatch-1a.c
 create mode 100644 gcc/testsuite/gcc.dg/Wreturn-mismatch-2a.c
 create mode 100644 gcc/testsuite/gcc.dg/diagnostic-range-bad-return-2.c
 create mode 100644 gcc/testsuite/gcc.dg/pr23075-2.c
 create mode 100644 gcc/testsuite/gcc.dg/pr29521-a.c
 create mode 100644 gcc/testsuite/gcc.dg/pr67730-a.c

diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index c7b35a27e3f..f4b700117ff 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -11205,7 +11205,7 @@ c_finish_return (location_t loc, tree retval, tree 
origtype)
  && valtype != NULL_TREE && TREE_CODE (valtype) != VOID_TYPE)
{
  no_warning = true;
- if (emit_diagnostic (flag_isoc99 ? DK_PEDWARN : DK_WARNING,
+ if (emit_diagnostic (flag_isoc99 ? DK_PERMERROR : DK_WARNING,
   loc, OPT_Wreturn_mismatch,
   "% with no value,"
   " in function returning non-void"))
@@ -11218,7 +11218,7 @@ c_finish_return (location_t loc, tree retval, tree 
origtype)
   current_function_returns_null = 1;
   bool warned_here;
   if (TREE_CODE (TREE_TYPE (retval)) != VOID_TYPE)
-   warned_here = pedwarn
+ 

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

2023-11-14 Thread Florian Weimer
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/

PR c/91092
PR c/96284
* c-decl.cc (implicit_decl_permerror): Rename from
implicit_decl_warning.  Call permerror_opt instead of
pedwarn and warning_at.
(implicitly_declare): Adjust callers.

gcc/testsuite/

* gcc.dg/permerror-default.c (implicit_function_declaration):
Expect the new permerror.
* gcc.dg/permerror-system.c: Likewise.
* c-c++-common/spellcheck-reserved.c (test, test_2): Expect
error instead of warning.
(f): Expect error instead of warning.
* gcc.dg/Wimplicit-function-declaration-c99.c: Compile with
-fpermissive due to expected warning.
* gcc.dg/Wimplicit-function-declaration-c99-2.c: New test.
Copied from gcc.dg/Wimplicit-function-declaration-c99.c.
Expect error.
* gcc.dg/missing-header-fixit-1.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-1a.c: New test.  Copied from
gcc.dg/missing-header-fixit-1.c, but expect error.
* gcc.dg/missing-header-fixit-2.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-2a.c: New test.  Copied from
gcc.dg/missing-header-fixit-2.c, but expect error.
* gcc.dg/missing-header-fixit-4.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-4a.c: New test.  Copied from
gcc.dg/missing-header-fixit-4.c, but expect error.
* gcc.dg/missing-header-fixit-5.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-5a.c: New test.  Copied from
gcc.dg/missing-header-fixit-5.c, but expect error.
* gcc.dg/pr61852.c: Expect implicit-function-declaration
error instead of warning.
* gcc.dg/spellcheck-identifiers-2.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-2a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers-2a.c.  Expect errors.
* gcc.dg/spellcheck-identifiers-3.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-3a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers-2a.c.  Expect errors.
* gcc.dg/spellcheck-identifiers-4.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-4a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers-2a.c.  Expect error.
* gcc.dg/spellcheck-identifiers.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-1a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers.c.  Expect errors.
* gcc.target/aarch64/sve/acle/general-c/ld1sh_gather_1.c (f1):
Expect error.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_index_1.c:
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_index_restricted_1.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_1.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_2.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_3.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_4.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_5.c:
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_1.c:
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_2.c:
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_3.c:
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_4.c:
(f1): Likewise.
---
 gcc/c/c-decl.cc   |  20 +--
 gcc/doc/invoke.texi   |   8 +-
 .../c-c++-common/spellcheck-reserved.c|   4 +-
 .../Wimplicit-function-declaration-c99-2.c|   7 +
 .../Wimplicit-function-declaration-c99.c  |   2 +-
 gcc/testsuite/gcc.dg/missing-header-fixit-1.c |   2 +-
 .../gcc.dg/missing-header-fixit-1a.c  |  37 +
 gcc/testsuite/gcc.dg/missing-header-fixit-2.c |   2 +-
 .../gcc.dg/missing-header-fixit-2a.c  |  31 
 gcc/testsuite/gcc.dg/missing-header-fixit-4.c |   2 +-
 .../gcc.dg/missing-header-fixit-4a.c  |  27 
 gcc/testsuite/gcc.dg/missing-header-fixit-5.c |   2 +-
 

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

2023-11-14 Thread Florian Weimer
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_init): New function.
(pedwarn_init): Call pedwarn_permerror_init.
(convert_for_assignment): Use permerror_opt and
permerror_init for -Wint-conversion warnings.

gcc/testsuite/

* gcc.dg/permerror-default.c (int_conversion_1)
(int_conversion_2): Expect the new permerrors.
* gcc.dg/permerror-system.c: Likewise.
* c-c++-common/pr77624-1.c (foo, bar): Expect
error instead of warning.
* gcc.dg/Wint-conversion-2.c: Compile with -fpermissive due
to expected int-conversion warning.
* gcc.dg/Wint-conversion-3.c: Likewise.
* gcc.dg/Wint-conversion-4.c: New test.  Based on
gcc.dg/Wint-conversion-3.c.  Expect int-conversion errors.
* gcc.dg/assign-warn-1.c: Compile with -fpermissive.
* gcc.dg/assign-warn-4.c: New file.  Extracted from
assign-warn1.c.  Expect int-cnversion errors.
* gcc.dg/diagnostic-types-1.c: compile with -fpermissive.
* gcc.dg/diagnostic-types-2.c: New file.  Extracted from
gcc.dg/diagnostic-types-1.c.  Expect some errors instead of
warnings.
* gcc.dg/gomp/pr35738.c: Compile with -fpermissive due to
expected int-conversion error.
* gcc.dg/gomp/pr35738-2.c: New test.  Based on
gcc.dg/gomp/pr35738.c.  Expect int-converison errors.
* gcc.dg/init-excess-3.c: Expect int-converison errors.
* gcc.dg/overflow-warn-1.c: Likewise.
* gcc.dg/overflow-warn-3.c: Likewise.
* gcc.dg/param-type-mismatch.c: Compile with -fpermissive.
* gcc.dg/param-type-mismatch-2.c: New test.  Copied from
gcc.dg/param-type-mismatch.c.  Expect errors.
* gcc.dg/pr61162-2.c: Compile with -fpermissive.
* gcc.dg/pr61162-3.c: New test. Extracted from
gcc.dg/pr61162-2.c.  Expect int-conversion errors.
* gcc.dg/spec-barrier-3.c: Use -fpermissive due to expected
int-conversion error.
* gcc.dg/spec-barrier-3a.c: New test.  Based on
gcc.dg/spec-barrier-3.c.  Expect int-conversion errors.
* gcc.target/aarch64/acle/memtag_2.c: Use -fpermissive due to expected
int-conversion error.
* gcc.target/aarch64/acle/memtag_2a.c: New test.  Copied from
gcc.target/aarch64/acle/memtag_2.c.  Expect error.
* gcc.target/aarch64/sve/acle/general-c/load_3.c (f1): Expect
error.
* gcc.target/aarch64/sve/acle/general-c/store_2.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_scatter_index_1.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/store_scatter_index_restricted_1.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_scatter_offset_2.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/store_scatter_offset_restricted_1.c
(f1): Likewise.
---
 gcc/c/c-typeck.cc |  97 +
 gcc/doc/invoke.texi   |   6 +
 gcc/testsuite/c-c++-common/pr77624-1.c|   4 +-
 gcc/testsuite/gcc.dg/Wint-conversion-2.c  |   2 +-
 gcc/testsuite/gcc.dg/Wint-conversion-3.c  |   2 +-
 gcc/testsuite/gcc.dg/Wint-conversion-4.c  |  14 ++
 gcc/testsuite/gcc.dg/assign-warn-1.c  |   2 +-
 gcc/testsuite/gcc.dg/assign-warn-4.c  |  21 ++
 gcc/testsuite/gcc.dg/diagnostic-types-1.c |   2 +-
 gcc/testsuite/gcc.dg/diagnostic-types-2.c |  24 +++
 gcc/testsuite/gcc.dg/gomp/pr35738-2.c |  18 ++
 gcc/testsuite/gcc.dg/gomp/pr35738.c   |   2 +-
 gcc/testsuite/gcc.dg/init-excess-3.c  |   4 +-
 gcc/testsuite/gcc.dg/overflow-warn-1.c|   4 +-
 gcc/testsuite/gcc.dg/overflow-warn-3.c|   4 +-
 gcc/testsuite/gcc.dg/param-type-mismatch-2.c  | 187 ++
 gcc/testsuite/gcc.dg/param-type-mismatch.c|   2 +-
 gcc/testsuite/gcc.dg/permerror-default.c  |  20 +-
 gcc/testsuite/gcc.dg/permerror-system.c   |  13 +-
 gcc/testsuite/gcc.dg/pr61162-2.c  |   2 +-
 gcc/testsuite/gcc.dg/pr61162-3.c  |  13 ++
 gcc/testsuite/gcc.dg/spec-barrier-3.c |   2 +-
 gcc/testsuite/gcc.dg/spec-barrier-3a.c|  13 ++
 .../gcc.target/aarch64/acle/memtag_2.c|   4 +-
 .../gcc.target/aarch64/acle/memtag_2a.c   |  71 +++
 .../aarch64/sve/acle/general-c/load_3.c   |   2 +-
 .../aarch64/sve/acle/general-c/store_2.c  |   2 +-
 .../acle/general-c/store_scatter_index_1.c|   2 +-
 .../store_scatter_index_restricted_1.c|   2 +-
 .../acle/general-c/store_scatter_offset_2.c   |   2 +-
 .../store_scatter_offset_restricted_1.c   |   2 +-
 31 files changed, 473 insertions(+), 72 

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

2023-11-14 Thread Florian Weimer
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 test.
* gcc.dg/permerror-fpermissive.c: Likewise.
* gcc.dg/permerror-gnu89-pedantic.c: Likewise.
* gcc.dg/permerror-gnu89.c: Likewise.
* gcc.dg/permerror-noerror.c: Likewise.
* gcc.dg/permerror-pedantic.c: Likewise.
* gcc.dg/permerror-system.c: Likewise.
---
 gcc/testsuite/gcc.dg/permerror-default.c  | 85 +++
 gcc/testsuite/gcc.dg/permerror-fpermissive.c  | 85 +++
 .../gcc.dg/permerror-gnu89-pedantic.c | 85 +++
 gcc/testsuite/gcc.dg/permerror-gnu89.c| 85 +++
 gcc/testsuite/gcc.dg/permerror-noerror.c  | 85 +++
 gcc/testsuite/gcc.dg/permerror-pedantic.c | 85 +++
 gcc/testsuite/gcc.dg/permerror-system.c   |  9 ++
 7 files changed, 519 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/permerror-default.c
 create mode 100644 gcc/testsuite/gcc.dg/permerror-fpermissive.c
 create mode 100644 gcc/testsuite/gcc.dg/permerror-gnu89-pedantic.c
 create mode 100644 gcc/testsuite/gcc.dg/permerror-gnu89.c
 create mode 100644 gcc/testsuite/gcc.dg/permerror-noerror.c
 create mode 100644 gcc/testsuite/gcc.dg/permerror-pedantic.c
 create mode 100644 gcc/testsuite/gcc.dg/permerror-system.c

diff --git a/gcc/testsuite/gcc.dg/permerror-default.c 
b/gcc/testsuite/gcc.dg/permerror-default.c
new file mode 100644
index 000..ea0be1dc89f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/permerror-default.c
@@ -0,0 +1,85 @@
+/* { dg-options "" } */
+
+/* Overview test for C permerrors.  This test should be kept in sync with the
+   other permerror-* tests.  If new permerrors are added, test cases should be
+   added to this and the other files.  */
+
+void
+implicit_function_declaration (void)
+{
+  f1 (); /* { dg-warning "'f1' \\\[-Wimplicit-function-declaration\\\]" } */
+}
+
+extern implicit_int_1; /* { dg-warning "'implicit_int_1' 
\\\[-Wimplicit-int\\\]" } */
+typedef implicit_int_2; /* { dg-warning "'implicit_int_2' 
\\\[-Wimplicit-int\\\]" } */
+extern implicit_int_3 (void); /* { dg-warning "'implicit_int_3' 
\\\[-Wimplicit-int\\]" } */
+implicit_int_4 (i) /* { dg-warning "return type defaults to 'int' 
\\\[-Wimplicit-int\\\]" } */
+/* { dg-warning "type of 'i' defaults to 'int' \\\[-Wimplicit-int\\\]" "" { 
target *-*-*} .-1 } */
+{
+  (const) 0; /* { dg-warning "type defaults to 'int' in type name 
\\\[-Wimplicit-int\\\]" } */
+}
+
+extern int missing_parameter_type (i); /* { dg-warning "parameter names 
\\\(without types\\\) in function declaration\n" } */
+
+
+int *
+int_conversion_1 (int flag)
+{
+  void f2 (int *);
+  flag ? "1" : 1; /* { dg-warning "pointer/integer type mismatch in 
conditional expression \\\[-Wint-conversion\\\]" } */
+  flag ? 1 : "1"; /* { dg-warning "pointer/integer type mismatch in 
conditional expression \\\[-Wint-conversion\\\]" } */
+  f2 (flag); /* { dg-warning "passing argument 1 of 'f2' makes pointer from 
integer without a cast \\\[-Wint-conversion\\\]" } */
+  {
+int i1 =  /* { dg-warning "initialization of 'int' from 'int \\\*' 
makes integer from pointer without a cast \\\[-Wint-conversion\\\]" } */
+i1 =  /* { dg-warning "assignment to 'int' from 'int \\\*' makes 
integer from pointer without a cast \\\[-Wint-conversion\\\]" } */
+  }
+  return flag; /* { dg-warning "returning 'int' from a function with return 
type 'int \\\*' makes pointer from integer without a cast 
\\\[-Wint-conversion\\\]" } */
+}
+
+int
+int_conversion_2 (int flag)
+{
+  void f3 (int);
+  f3 (); /* { dg-warning "passing argument 1 of 'f3' makes integer from 
pointer without a cast \\\[-Wint-conversion\\\]" } */
+  {
+int *i1 = flag; /* { dg-warning "initialization of 'int \\\*' from 'int' 
makes pointer from integer without a cast \\\[-Wint-conversion\\\]" } */
+i1 = flag; /* { dg-warning "assignment to 'int \\\*' from 'int' makes 
pointer from integer without a cast \\\[-Wint-conversion\\\]" } */
+  }
+  return  /* { dg-warning "returning 'int \\\*' from a function with 
return type 'int' makes integer from pointer without a cast 
\\\[-Wint-conversion\\\]" } */
+}
+
+int *
+incompatible_pointer_types (int flag)
+{
+  void f4 (int *);
+  flag ? __builtin_abs : __builtin_labs; /* { dg-warning "pointer type 
mismatch in conditional expression \\\[-Wincompatible-pointer-types\\\]" } */
+  {
+int *p1 = __builtin_abs; /* { dg-warning "initialization of 'int \\\*' 
from pointer to '__builtin_abs' with incompatible type 'int 
\\\(\\\*\\\)\\\(int\\\)' \\\[-Wincompatible-pointer-types\\\]" } */
+p1 = __builtin_abs; /* { dg-warning "assignment to 'int \\\*' from pointer 
to '__builtin_abs' with incompatible type 'int 

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

2023-11-14 Thread Florian Weimer
This new series covers:

  -Wint-conversion
  -Wimplicit-function-declaration
  -Wimplicit-int
  -Wreturn-mismatch
  -Wincompatible-pointer-types
  -Wdeclaration-missing-parameter-type (new)

There are now gcc.dg/permerror-*.c tests which track the graduation of
warnings to errors.

It turns out that pedpermerror was indeed unnecessary, and I can use
permerror_opt directly (or DK_PERMERROR in case I call one of the
low-level functions).

While working on this I found out that -Wimplicit-int is mostly
ineffective in system headers, so I fixed that for consistency.  I also
added a new -Wdeclaration-missing-parameter-type warning because missing
types in parameter lists in function declarations (as opposed to
old-style function definitions) are not covered by -Wimplicit-int, and
probably shouldn't be because the omitted types are not necessarily int.

This still depends on a couple of unreviewed patches.  In particular, I
do not want to break the AArch64 bootstrap, so the first patch looks
like a blocker.

  [PATCH] aarch64: Avoid -Wincompatible-pointer-types warning in Linux unwinder
  
<https://inbox.sourceware.org/gcc-patches/874jht5tsq@oldenburg.str.redhat.com/>

  [PATCH] aarch64: Call named function in gcc.target/aarch64/aapcs64/ice_1.c
  
<https://inbox.sourceware.org/gcc-patches/87r0kx6eez@oldenburg.str.redhat.com/>

  [PATCH] gm2: Add missing declaration of m2pim_M2RTS_Terminate to test
  
<https://inbox.sourceware.org/gcc-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 forms of -Wimplicit-int in system headers
  c: Turn -Wreturn-mismatch into a permerror
  c: Turn -Wincompatible-pointer-types into a permerror
  c: Add new -Wdeclaration-missing-parameter-type permerror

 gcc/c-family/c.opt|   4 +
 gcc/c/c-decl.cc   |  71 +++
 gcc/c/c-typeck.cc | 164 ---
 gcc/doc/invoke.texi   |  50 -
 gcc/testsuite/c-c++-common/pr77624-1.c|   4 +-
 .../c-c++-common/spellcheck-reserved.c|   4 +-
 gcc/testsuite/gcc.dg/20030906-1.c |   2 +-
 gcc/testsuite/gcc.dg/20030906-1a.c|  21 ++
 gcc/testsuite/gcc.dg/20030906-2.c |   2 +-
 gcc/testsuite/gcc.dg/20030906-2a.c|  21 ++
 .../Wimplicit-function-declaration-c99-2.c|   7 +
 .../Wimplicit-function-declaration-c99.c  |   2 +-
 gcc/testsuite/gcc.dg/Wimplicit-int-1.c|   2 +-
 gcc/testsuite/gcc.dg/Wimplicit-int-1a.c   |  11 ++
 gcc/testsuite/gcc.dg/Wimplicit-int-4.c|   2 +-
 gcc/testsuite/gcc.dg/Wimplicit-int-4a.c   |  11 ++
 .../gcc.dg/Wincompatible-pointer-types-2.c|   2 +-
 .../gcc.dg/Wincompatible-pointer-types-5.c|  10 +
 gcc/testsuite/gcc.dg/Wint-conversion-2.c  |   2 +-
 gcc/testsuite/gcc.dg/Wint-conversion-3.c  |   2 +-
 gcc/testsuite/gcc.dg/Wint-conversion-4.c  |  14 ++
 gcc/testsuite/gcc.dg/Wreturn-mismatch-1.c |   2 +-
 gcc/testsuite/gcc.dg/Wreturn-mismatch-1a.c|  40 
 gcc/testsuite/gcc.dg/Wreturn-mismatch-2.c |   2 +-
 gcc/testsuite/gcc.dg/Wreturn-mismatch-2a.c|  41 
 gcc/testsuite/gcc.dg/anon-struct-11.c |   5 +-
 gcc/testsuite/gcc.dg/anon-struct-11a.c| 111 +++
 gcc/testsuite/gcc.dg/anon-struct-13.c |   2 +-
 gcc/testsuite/gcc.dg/anon-struct-13a.c|  76 +++
 gcc/testsuite/gcc.dg/assign-warn-1.c  |   2 +-
 gcc/testsuite/gcc.dg/assign-warn-4.c  |  21 ++
 .../gcc.dg/builtin-arith-overflow-4.c |   2 +-
 .../gcc.dg/builtin-arith-overflow-4a.c|  43 
 gcc/testsuite/gcc.dg/c23-qual-4.c |   6 +-
 gcc/testsuite/gcc.dg/dfp/composite-type-2.c   |  58 ++
 gcc/testsuite/gcc.dg/dfp/composite-type.c |   2 +-
 gcc/testsuite/gcc.dg/diag-aka-1.c |   2 +-
 gcc/testsuite/gcc.dg/diag-aka-1a.c|  29 +++
 .../gcc.dg/diagnostic-range-bad-return-2.c|  52 +
 .../gcc.dg/diagnostic-range-bad-return.c  |   2 +-
 gcc/testsuite/gcc.dg/diagnostic-types-1.c |   2 +-
 gcc/testsuite/gcc.dg/diagnostic-types-2.c |  24 +++
 gcc/testsuite/gcc.dg/enum-compat-1.c  |   2 +-
 gcc/testsuite/gcc.dg/enum-compat-2.c  |  32 +++
 gcc/testsuite/gcc.dg/func-ptr-conv-1.c|   2 +-
 gcc/testsuite/gcc.dg/func-ptr-conv-2.c|  56 ++
 gcc/testsuite/gcc.dg/gnu23-attr-syntax-2.c|   2 +-
 gcc/testsuite/gcc.dg/gnu23-attr-syntax-3.c|  17 ++
 gcc/testsuite/gcc.dg/gomp/pr35738-2.c |  18 ++
 gcc/testsuite/gcc.dg/gomp/pr35738.c   |   2 +-
 gcc/testsuite/gcc.dg/init-bad-7.c |   2 +-
 gcc/testsuite/gcc.dg/init-bad-7a.c|  12 ++
 gcc/testsuite/gcc.dg/init-excess-

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

2023-11-13 Thread Florian Weimer
* 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
> pedwarns if -pedantic-errors is active.
>
> Due to the dependency on flag_pedantic_errors, the new helpers
> are specific to the C-family front ends.  For implementing the
> rich location variant, export emit_diagnostic_valist from
> gcc/diagnostic.cc in parallel to its location_t variant.
>
> gcc/
>
>   * diagnostic-core.h (emit_diagnostic_valist): Declare function.
>   * diagnostic.cc (emit_diagnostic_valist): Define it.
>
> gcc/c-family/
>
>   * c-common.h (pedpermerror): Declare functions.
>   * c-warn.cc (pedpermerror): Define them.

Jason suggested off-list that this shouldn't be necessary, and the
description of -pedantic-errors is wrong (it is possible to undo
-pedantic-errors effects with -Wno-error=…).  The permerror_opt
interface should already do what I need.

It turns out that I was very unlucky and picked -Wreturn-type for my
tests.

This:

long i = "abc";
volatile j;
int f (void) { return; }

Gives, with GCC 13:

$ gcc -pedantic-errors -Wno-error=implicit-int -Wno-error=int-conversion 
-Wno-error=return-type test.c
test.c:1:10: warning: initialization of ‘long int’ from ‘char *’ makes integer 
from pointer without a cast [-Wint-conversion]
1 | long i = "abc";
  |  ^
test.c:2:10: warning: type defaults to ‘int’ in declaration of ‘j’ 
[-Wimplicit-int]
2 | volatile j;
  |  ^
test.c: In function ‘f’:
test.c:3:16: error: ‘return’ with no value, in function returning non-void
3 | int f (void) { return; }
  |^~
test.c:3:5: note: declared here
3 | int f (void) { return; }
  | ^

This happens because we drop the OPT_Wreturn_type in some cases:

  if (flag_isoc99)
warned_here = pedwarn
  (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0,
   "% with no value, in function returning non-void");
  else
warned_here = warning_at
  (loc, OPT_Wreturn_type,
   "% with no value, in function returning non-void");

And for the other direction:

  if (TREE_CODE (TREE_TYPE (retval)) != VOID_TYPE)
warned_here = pedwarn
  (xloc, warn_return_type >= 0 ? OPT_Wreturn_type : 0,
   "% with a value, in function returning void");

I think with the -Wreturn-mismatch split, we can drop the
warn_return_type >= 0 condition, and then permerror_opt should indeed
do the right thing.

I'll write the kitchen sink test now, use that to verify this theory,
and repost as appropriate.

Thanks,
Florian



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

2023-11-13 Thread Florian Weimer
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
pedpermerror_init for OPT_Wincompatible_pointer_types
warnings.

gcc/testsuite/

* gcc.dg/Wincompatible-pointer-types-2.c: Compile with
-fpermissivedue to expected errors.
* gcc.dg/Wincompatible-pointer-types-4.c: Likewise.
* gcc.dg/Wincompatible-pointer-types-5.c: New test.  Copied
from gcc.dg/Wincompatible-pointer-types-2.c.  Expect errors.
* gcc.dg/Wincompatible-pointer-types-6.c: New test.  Copied
from gcc.dg/Wincompatible-pointer-types-4.c.  Expect errors.
* gcc.dg/anon-struct-11.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/anon-struct-11a.c: New test.  Copied from
gcc.dg/anon-struct-11.c.  Expect errors.
* gcc.dg/anon-struct-13.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/anon-struct-13a.c: New test.  Copied from
gcc.dg/anon-struct-13.c.  Expect errors.
* gcc.dg/builtin-arith-overflow-4.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/builtin-arith-overflow-4a.c: New test.  Copied from
gcc.dg/builtin-arith-overflow-4.c.  Expect errors.
* gcc.dg/c23-qual-4.c: Expect -Wincompatible-pointer-types errors.
* gcc.dg/dfp/composite-type.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/dfp/composite-type-2.c: New test.  Copied from
gcc.dg/dfp/composite-type.c.  Expect errors.
* gcc.dg/diag-aka-1.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/diag-aka-1a.c: New test.  Copied from gcc.dg/diag-aka-1a.c.
Expect errors.
* gcc.dg/enum-compat-1.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/enum-compat-2.c: New test.  Copied from
gcc.dg/enum-compat-1.c.  Expect errors.
* gcc.dg/func-ptr-conv-1.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/func-ptr-conv-2.c: New test.  Copied from
gcc.dg/func-ptr-conv-1.c.  Expect errors.
* gcc.dg/init-bad-7.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/init-bad-7a.c: New test.  Copied from gcc.dg/init-bad-7.c.
Expect errors.
* gcc.dg/noncompile/incomplete-3.c (foo): Expect
-Wincompatible-pointer-types error.
* gcc.dg/param-type-mismatch-2.c (test8): Likewise.
* gcc.dg/pointer-array-atomic.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/pointer-array-atomic-2.c: New test.  Copied from
gcc.dg/pointer-array-atomic.c.  Expect errors.
* gcc.dg/pointer-array-quals-1.c (test): Expect
-Wincompatible-pointer-types errors.
* gcc.dg/transparent-union-1.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/transparent-union-1a.c: New test.  Copied from
gcc.dg/transparent-union-1.c.  Expect errors.
* gcc.target/aarch64/acle/memtag_2a.c
(test_memtag_warning_return_qualifier): Expect additional
errors.
* gcc.target/aarch64/sve/acle/general-c/load_2.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_1.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_2.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_3.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_4.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_5.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_1.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_2.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_3.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_4.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/sizeless-1.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/sizeless-2.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_1.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_2.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_scatter_index_1.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/store_scatter_index_restricted_1.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_scatter_offset_2.c
(f1): Likewise.
* 

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

2023-11-13 Thread Florian Weimer
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: Compile with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/20030906-1a.c: New test.  Copied from
gcc.dg/20030906-1.c.  Expect the error.
* gcc.dg/20030906-2.c: Compile with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/20030906-2a.c: New test.  Copied from
gcc.dg/20030906-2.c.  Expect the error.
* gcc.dg/Wreturn-mismatch-1.c: Compile with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/Wreturn-mismatch-1a.c: New test.  Copied from
gcc.dg/Wreturn-mismatch-1.c.  Expect the error.
* gcc.dg/Wreturn-mismatch-2.c: Compile with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/Wreturn-mismatch-2a.c: New test.  Copied from
gcc.dg/Wreturn-mismatch-2.c.  Expect the error.
* gcc.dg/diagnostic-range-bad-return.c: Compile with
-fpermissive due to expected -Wreturn-mismatch error.
* gcc.dg/diagnostic-range-bad-return-2.c: New test.
Copied from gcc.dg/diagnostic-range-bad-return.c.  Expect the
error.
* gcc.dg/pr105635-2.c: Expect -Wreturn-mismatch error.
* gcc.dg/pr23075.c: Build with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/pr23075-2.c: New test.  Copied from gcc.dg/pr23075.c.
Expect the error.
* gcc.dg/pr29521.c: Compile with -fpermissive due to expected
-Wreturn-mismatch error.
* gcc.dg/pr29521-a.c: New test. Copied from gcc.dg/pr29521.c.
Expect error.
* gcc.dg/pr67730.c: Compile with -fpermissive due to expected
-Wreturn-mismatch error.
* gcc.dg/pr67730-a.c: New test.  Copied from
gcc.dg/pr67730-a.c.  Expect error.
* gcc.target/powerpc/conditional-return.c: Compile with
-fpermissive due to expected-Wreturn-mismatch error.
---
 gcc/c/c-typeck.cc |  6 ++-
 gcc/doc/invoke.texi   |  6 ++-
 gcc/testsuite/gcc.dg/20030906-1.c |  2 +-
 gcc/testsuite/gcc.dg/20030906-1a.c| 21 
 gcc/testsuite/gcc.dg/20030906-2.c |  2 +-
 gcc/testsuite/gcc.dg/20030906-2a.c| 21 
 gcc/testsuite/gcc.dg/Wreturn-mismatch-1.c |  2 +-
 gcc/testsuite/gcc.dg/Wreturn-mismatch-1a.c| 40 ++
 gcc/testsuite/gcc.dg/Wreturn-mismatch-2.c |  2 +-
 gcc/testsuite/gcc.dg/Wreturn-mismatch-2a.c| 41 +++
 .../gcc.dg/diagnostic-range-bad-return-2.c| 52 +++
 .../gcc.dg/diagnostic-range-bad-return.c  |  2 +-
 gcc/testsuite/gcc.dg/pr105635-2.c |  2 +-
 gcc/testsuite/gcc.dg/pr23075-2.c  | 14 +
 gcc/testsuite/gcc.dg/pr23075.c|  2 +-
 gcc/testsuite/gcc.dg/pr29521-a.c  | 15 ++
 gcc/testsuite/gcc.dg/pr29521.c|  2 +-
 gcc/testsuite/gcc.dg/pr67730-a.c  | 11 
 gcc/testsuite/gcc.dg/pr67730.c|  2 +-
 .../gcc.target/powerpc/conditional-return.c   |  2 +-
 20 files changed, 234 insertions(+), 13 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/20030906-1a.c
 create mode 100644 gcc/testsuite/gcc.dg/20030906-2a.c
 create mode 100644 gcc/testsuite/gcc.dg/Wreturn-mismatch-1a.c
 create mode 100644 gcc/testsuite/gcc.dg/Wreturn-mismatch-2a.c
 create mode 100644 gcc/testsuite/gcc.dg/diagnostic-range-bad-return-2.c
 create mode 100644 gcc/testsuite/gcc.dg/pr23075-2.c
 create mode 100644 gcc/testsuite/gcc.dg/pr29521-a.c
 create mode 100644 gcc/testsuite/gcc.dg/pr67730-a.c

diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 9d7bdbb4523..be376758b82 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -11192,7 +11192,9 @@ c_finish_return (location_t loc, tree retval, tree 
origtype)
  && valtype != NULL_TREE && TREE_CODE (valtype) != VOID_TYPE)
{
  no_warning = true;
- if (emit_diagnostic (flag_isoc99 ? DK_PEDWARN : DK_WARNING,
+ if (emit_diagnostic (flag_isoc99 && !flag_pedantic_errors
+  ? DK_PERMERROR
+  : flag_isoc99 ? DK_PEDWARN : DK_WARNING,
   loc, OPT_Wreturn_mismatch,
   "% with no value,"
   " in function returning non-void"))
@@ -11205,7 +11207,7 @@ c_finish_return (location_t loc, tree retval, tree 
origtype)
   current_function_returns_null = 1;
   bool warned_here;
   if (TREE_CODE (TREE_TYPE (retval)) != VOID_TYPE)
-   warned_here = pedwarn
+   warned_here = pedpermerror
  (xloc, OPT_Wreturn_mismatch,
   "% with a value, in 

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

2023-11-13 Thread Florian Weimer
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/

* c-decl.cc (implicit_decl_pedpermerror): Rename from
implicit_decl_warning.  Call pedpermerror instead of
pedwarn and warning_at.
(implicitly_declare): Adjust callers.

gcc/testsuite/

* c-c++-common/spellcheck-reserved.c (test, test_2): Expect
error instead of warning.
(f): Expect error instead of warning.
* gcc.dg/Wimplicit-function-declaration-c99.c: Compile with
-fpermissive due to expected warning.
* gcc.dg/Wimplicit-function-declaration-c99-2.c: New test.
Copied from gcc.dg/Wimplicit-function-declaration-c99.c.
Expect error.
* gcc.dg/missing-header-fixit-1.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-1a.c: New test.  Copied from
gcc.dg/missing-header-fixit-1.c, but expect error.
* gcc.dg/missing-header-fixit-2.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-2a.c: New test.  Copied from
gcc.dg/missing-header-fixit-2.c, but expect error.
* gcc.dg/missing-header-fixit-4.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-4a.c: New test.  Copied from
gcc.dg/missing-header-fixit-4.c, but expect error.
* gcc.dg/missing-header-fixit-5.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-5a.c: New test.  Copied from
gcc.dg/missing-header-fixit-5.c, but expect error.
* gcc.dg/pr61852.c: Expect implicit-function-declaration
error instead of warning.
* gcc.dg/spellcheck-identifiers-2.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-2a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers-2a.c.  Expect errors.
* gcc.dg/spellcheck-identifiers-3.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-3a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers-2a.c.  Expect errors.
* gcc.dg/spellcheck-identifiers-4.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-4a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers-2a.c.  Expect error.
* gcc.dg/spellcheck-identifiers.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-1a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers.c.  Expect errors.
* gcc.target/aarch64/sve/acle/general-c/ld1sh_gather_1.c (f1):
Expect error.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_index_1.c:
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_index_restricted_1.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_1.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_2.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_3.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_4.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_5.c:
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_1.c:
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_2.c:
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_3.c:
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_4.c:
(f1): Likewise.
---
 gcc/c/c-decl.cc   |  20 +--
 gcc/doc/invoke.texi   |   8 +-
 .../c-c++-common/spellcheck-reserved.c|   4 +-
 .../Wimplicit-function-declaration-c99-2.c|   7 +
 .../Wimplicit-function-declaration-c99.c  |   2 +-
 gcc/testsuite/gcc.dg/missing-header-fixit-1.c |   2 +-
 .../gcc.dg/missing-header-fixit-1a.c  |  37 +
 gcc/testsuite/gcc.dg/missing-header-fixit-2.c |   2 +-
 .../gcc.dg/missing-header-fixit-2a.c  |  31 
 gcc/testsuite/gcc.dg/missing-header-fixit-4.c |   2 +-
 .../gcc.dg/missing-header-fixit-4a.c  |  27 
 gcc/testsuite/gcc.dg/missing-header-fixit-5.c |   2 +-
 .../gcc.dg/missing-header-fixit-5a.c  |  42 ++
 gcc/testsuite/gcc.dg/pr61852.c|   4 +-
 .../gcc.dg/spellcheck-identifiers-1a.c| 136 ++
 

[PATCH 4/6] c: Turn -Wimplicit-int into a pedpermerror

2023-11-13 Thread Florian Weimer
There is a missed opportunity here to issue spelling diagnostics
in prototype declarations (e.g., for “extern int foo (int32t);”).

gcc/

* doc/invoke.texi (Warning Options): Document changes.

gcc/c/

* c-decl.cc (warn_defaults_to): Call emit_diagnostic_valist
instead of reimplementing it. Issue a pedpermerror for C99
and later.
(store_parm_decls_oldstyle): Call pedpermerror for
OPT_Wimplicit_int.

gcc/testsuite/

* gcc.dg/Wimplicit-int-1.c: Compile with -fpermissive due to
expected warning.
* gcc.dg/Wimplicit-int-4.c: Likewise.
* gcc.dg/Wimplicit-int-1a.c: New test.  Copied from
gcc.dg/Wimplicit-int-1.c, but expect errors.
* gcc.dg/Wimplicit-int-4a.c: New test.  Copied from
gcc.dg/Wimplicit-int-4.c, but expect errors.
* gcc.dg/gnu23-attr-syntax-2.c: Compile with -fpermissive
due to expected implicit-int error.
* gcc.dg/gnu23-attr-syntax-3.c: New test.  Copied from
gcc.dg/gnu23-attr-syntax-2.c, but expect an error.
* gcc.dg/pr105635.c: Build with -fpermissive due to implicit
int.
* gcc.dg/pr105635-2.c: New test.  Copied from
gcc.dg/pr105635.c.  Expect implicit int error.
* gcc.dg/noncompile/pr79758.c: Build with -fpermissive due to
implicitint.
* gcc.dg/noncompile/pr79758-2.c: New test.  Copied from
gcc.dg/noncompile/pr79758.c.  Expect implicit int error.
---
 gcc/c/c-decl.cc | 20 +++-
 gcc/doc/invoke.texi |  7 +--
 gcc/testsuite/gcc.dg/Wimplicit-int-1.c  |  2 +-
 gcc/testsuite/gcc.dg/Wimplicit-int-1a.c | 11 +++
 gcc/testsuite/gcc.dg/Wimplicit-int-4.c  |  2 +-
 gcc/testsuite/gcc.dg/Wimplicit-int-4a.c | 11 +++
 gcc/testsuite/gcc.dg/gnu23-attr-syntax-2.c  |  2 +-
 gcc/testsuite/gcc.dg/gnu23-attr-syntax-3.c  | 17 +
 gcc/testsuite/gcc.dg/noncompile/pr79758-2.c |  6 ++
 gcc/testsuite/gcc.dg/noncompile/pr79758.c   |  1 +
 gcc/testsuite/gcc.dg/pr105635-2.c   | 11 +++
 gcc/testsuite/gcc.dg/pr105635.c |  2 +-
 12 files changed, 77 insertions(+), 15 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/Wimplicit-int-1a.c
 create mode 100644 gcc/testsuite/gcc.dg/Wimplicit-int-4a.c
 create mode 100644 gcc/testsuite/gcc.dg/gnu23-attr-syntax-3.c
 create mode 100644 gcc/testsuite/gcc.dg/noncompile/pr79758-2.c
 create mode 100644 gcc/testsuite/gcc.dg/pr105635-2.c

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index e8387bfa984..f787d213cfe 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -6577,16 +6577,18 @@ warn_defaults_to (location_t location, int opt, const 
char *gmsgid, ...)
 {
   diagnostic_info diagnostic;
   va_list ap;
-  rich_location richloc (line_table, location);
+  diagnostic_t kind;
 
   va_start (ap, gmsgid);
-  diagnostic_set_info (, gmsgid, , ,
-   flag_isoc99 ? DK_PEDWARN : DK_WARNING);
-  diagnostic.option_index = opt;
-  diagnostic_report_diagnostic (global_dc, );
+  if (flag_isoc99 && !flag_pedantic_errors && opt)
+kind = DK_PERMERROR;
+  else if (flag_isoc99)
+kind = DK_PEDWARN;
+  else
+kind = DK_WARNING;
+  emit_diagnostic_valist (kind, location, opt, gmsgid, );
   va_end (ap);
 }
-
 /* Returns the smallest location != UNKNOWN_LOCATION in LOCATIONS,
considering only those c_declspec_words found in LIST, which
must be terminated by cdw_number_of_elements.  */
@@ -10635,9 +10637,9 @@ store_parm_decls_oldstyle (tree fndecl, const struct 
c_arg_info *arg_info)
  warn_if_shadowing (decl);
 
  if (flag_isoc99)
-   pedwarn (DECL_SOURCE_LOCATION (decl),
-OPT_Wimplicit_int, "type of %qD defaults to %",
-decl);
+   pedpermerror (DECL_SOURCE_LOCATION (decl),
+ OPT_Wimplicit_int, "type of %qD defaults to %",
+ decl);
  else
warning_at (DECL_SOURCE_LOCATION (decl),
OPT_Wmissing_parameter_type,
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 1a15af29f01..3a1b9b00f24 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -6180,6 +6180,7 @@ that have their own flag:
 
 @gccoptlist{
 -Wimplicit-function-declaration @r{(C)}
+-Wimplicit-int @r{(C)}
 -Wint-conversion @r{(C)}
 -Wnarrowing @r{(C++)}
 }
@@ -6851,8 +6852,10 @@ This warning is enabled by @option{-Wall} in C++.
 @opindex Wno-implicit-int
 @item -Wno-implicit-int @r{(C and Objective-C only)}
 This option controls warnings when a declaration does not specify a type.
-This warning is enabled by default in C99 and later dialects of C,
-and also by @option{-Wall}.
+This warning is enabled by default, as an error, in C99 and later
+dialects of C, and also by @option{-Wall}.  The error can be downgraded
+to a warning using @option{-fpermissive} (along with certain other
+errors), 

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

2023-11-13 Thread Florian Weimer
gcc/

* doc/invoke.texi (Warning Options): Document changes.

gcc/c/

* c-typeck.cc (build_conditional_expr): Use pedpermerror for
pointer/integer type mismatches, based on -Wint-conversion.
(pedwarn_pedpermerror_init, permerror_init): New function.
(pedwarn_init): Call pedwarn_pedpermerror_init.
(convert_for_assignment): Use pedpermerror and
pedpermerror_init for -Wint-conversion  warnings.

gcc/testsuite/

* c-c++-common/pr77624-1.c (foo, bar): Expect
error instead of warning.
* gcc.dg/Wint-conversion-2.c: Compile with -fpermissive due
to expected int-conversion warning.
* gcc.dg/Wint-conversion-3.c: Likewise.
* gcc.dg/Wint-conversion-4.c: New test.  Based on
gcc.dg/Wint-conversion-3.c.  Expect int-conversion errors.
* gcc.dg/assign-warn-1.c: Compile with -fpermissive.
* gcc.dg/assign-warn-4.c: New file.  Extracted from
assign-warn1.c.  Expect int-cnversion errors.
* gcc.dg/diagnostic-types-1.c: compile with -fpermissive.
* gcc.dg/diagnostic-types-2.c: New file.  Extracted from
gcc.dg/diagnostic-types-1.c.  Expect some errors instead of
warnings.
* gcc.dg/gomp/pr35738.c: Compile with -fpermissive due to
expected int-conversion error.
* gcc.dg/gomp/pr35738-2.c: New test.  Based on
gcc.dg/gomp/pr35738.c.  Expect int-converison errors.
* gcc.dg/init-excess-3.c: Expect int-converison errors.
* gcc.dg/overflow-warn-1.c: Likewise.
* gcc.dg/overflow-warn-3.c: Likewise.
* gcc.dg/param-type-mismatch.c: Compile with -fpermissive.
* gcc.dg/param-type-mismatch-2.c: New test.  Copied from
gcc.dg/param-type-mismatch.c.  Expect errors.
* gcc.dg/pr61162-2.c: Compile with -fpermissive.
* gcc.dg/pr61162-3.c: New test. Extracted from
gcc.dg/pr61162-2.c.  Expect int-conversion errors.
* gcc.dg/spec-barrier-3.c: Use -fpermissive due to expected
int-conversion error.
* gcc.dg/spec-barrier-3a.c: New test.  Based on
gcc.dg/spec-barrier-3.c.  Expect int-conversion errors.
* gcc.target/aarch64/acle/memtag_2.c: Use -fpermissive due to expected
int-conversion error.
* gcc.target/aarch64/acle/memtag_2a.c: New test.  Copied from
gcc.target/aarch64/acle/memtag_2.c.  Expect error.
* gcc.target/aarch64/sve/acle/general-c/load_3.c (f1): Expect
error.
* gcc.target/aarch64/sve/acle/general-c/store_2.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_scatter_index_1.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/store_scatter_index_restricted_1.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_scatter_offset_2.c
(f1): Likewise.
* 
gcc.target/aarch64/sve/acle/general-c/store_scatter_offset_restricted_1.c
(f1): Likewise.
---
 gcc/c/c-typeck.cc |  98 +
 gcc/doc/invoke.texi   |   6 +
 gcc/testsuite/c-c++-common/pr77624-1.c|   4 +-
 gcc/testsuite/gcc.dg/Wint-conversion-2.c  |   2 +-
 gcc/testsuite/gcc.dg/Wint-conversion-3.c  |   2 +-
 gcc/testsuite/gcc.dg/Wint-conversion-4.c  |  14 ++
 gcc/testsuite/gcc.dg/assign-warn-1.c  |   2 +-
 gcc/testsuite/gcc.dg/assign-warn-4.c  |  21 ++
 gcc/testsuite/gcc.dg/diagnostic-types-1.c |   2 +-
 gcc/testsuite/gcc.dg/diagnostic-types-2.c |  24 +++
 gcc/testsuite/gcc.dg/gomp/pr35738-2.c |  18 ++
 gcc/testsuite/gcc.dg/gomp/pr35738.c   |   2 +-
 gcc/testsuite/gcc.dg/init-excess-3.c  |   4 +-
 gcc/testsuite/gcc.dg/overflow-warn-1.c|   4 +-
 gcc/testsuite/gcc.dg/overflow-warn-3.c|   4 +-
 gcc/testsuite/gcc.dg/param-type-mismatch-2.c  | 187 ++
 gcc/testsuite/gcc.dg/param-type-mismatch.c|   2 +-
 gcc/testsuite/gcc.dg/pr61162-2.c  |   2 +-
 gcc/testsuite/gcc.dg/pr61162-3.c  |  13 ++
 gcc/testsuite/gcc.dg/spec-barrier-3.c |   2 +-
 gcc/testsuite/gcc.dg/spec-barrier-3a.c|  13 ++
 .../gcc.target/aarch64/acle/memtag_2.c|   4 +-
 .../gcc.target/aarch64/acle/memtag_2a.c   |  71 +++
 .../aarch64/sve/acle/general-c/load_3.c   |   2 +-
 .../aarch64/sve/acle/general-c/store_2.c  |   2 +-
 .../acle/general-c/store_scatter_index_1.c|   2 +-
 .../store_scatter_index_restricted_1.c|   2 +-
 .../acle/general-c/store_scatter_offset_2.c   |   2 +-
 .../store_scatter_offset_restricted_1.c   |   2 +-
 29 files changed, 452 insertions(+), 61 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/Wint-conversion-4.c
 create mode 100644 gcc/testsuite/gcc.dg/assign-warn-4.c
 create mode 100644 gcc/testsuite/gcc.dg/diagnostic-types-2.c
 create mode 100644 gcc/testsuite/gcc.dg/gomp/pr35738-2.c
 create mode 100644 

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

2023-11-13 Thread 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
pedwarns if -pedantic-errors is active.

Due to the dependency on flag_pedantic_errors, the new helpers
are specific to the C-family front ends.  For implementing the
rich location variant, export emit_diagnostic_valist from
gcc/diagnostic.cc in parallel to its location_t variant.

gcc/

* diagnostic-core.h (emit_diagnostic_valist): Declare function.
* diagnostic.cc (emit_diagnostic_valist): Define it.

gcc/c-family/

* c-common.h (pedpermerror): Declare functions.
* c-warn.cc (pedpermerror): Define them.
---
 gcc/c-family/c-common.h |  4 
 gcc/c-family/c-warn.cc  | 34 ++
 gcc/diagnostic-core.h   |  3 +++
 gcc/diagnostic.cc   |  7 +++
 4 files changed, 48 insertions(+)

diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index b57e83d7c5d..789e0bf2459 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1486,6 +1486,10 @@ extern void warn_for_address_or_pointer_of_packed_member 
(tree, tree);
 extern void warn_parm_array_mismatch (location_t, tree, tree);
 extern void maybe_warn_sizeof_array_div (location_t, tree, tree, tree, tree);
 extern void do_warn_array_compare (location_t, tree_code, tree, tree);
+extern bool pedpermerror (location_t, int, const char *,
+ ...) ATTRIBUTE_GCC_DIAG(3,4);
+extern bool pedpermerror (rich_location *, int, const char *,
+ ...) ATTRIBUTE_GCC_DIAG(3,4);
 
 /* Places where an lvalue, or modifiable lvalue, may be required.
Used to select diagnostic messages in lvalue_error and
diff --git a/gcc/c-family/c-warn.cc b/gcc/c-family/c-warn.cc
index b1bd8ba9f42..475a3e4b42e 100644
--- a/gcc/c-family/c-warn.cc
+++ b/gcc/c-family/c-warn.cc
@@ -3932,3 +3932,37 @@ check_for_xor_used_as_pow (location_t lhs_loc, tree 
lhs_val,
  lhs_uhwi, lhs_uhwi);
 }
 }
+
+/* If !flag_pedantic_errors, equivalent to permerror_opt, otherwise to
+   pedwarn.  */
+
+bool
+pedpermerror (location_t location, int opt, const char *gmsgid, ...)
+{
+  auto_diagnostic_group d;
+  va_list ap;
+  va_start (ap, gmsgid);
+  rich_location richloc (line_table, location);
+  bool ret = emit_diagnostic_valist (flag_pedantic_errors
+? DK_PEDWARN : DK_PERMERROR,
+location, opt, gmsgid, );
+  va_end (ap);
+  return ret;
+}
+
+/* Same as "pedpermerror" above, but at RICHLOC.  */
+
+bool
+pedpermerror (rich_location *richloc, int opt, const char *gmsgid, ...)
+{
+  gcc_assert (richloc);
+
+  auto_diagnostic_group d;
+  va_list ap;
+  va_start (ap, gmsgid);
+  bool ret = emit_diagnostic_valist (flag_pedantic_errors
+? DK_PEDWARN : DK_PERMERROR,
+richloc, opt, gmsgid, );
+  va_end (ap);
+  return ret;
+}
diff --git a/gcc/diagnostic-core.h b/gcc/diagnostic-core.h
index 04eba3d140e..eac775fb573 100644
--- a/gcc/diagnostic-core.h
+++ b/gcc/diagnostic-core.h
@@ -121,6 +121,9 @@ extern bool emit_diagnostic (diagnostic_t, location_t, int,
 const char *, ...) ATTRIBUTE_GCC_DIAG(4,5);
 extern bool emit_diagnostic (diagnostic_t, rich_location *, int,
 const char *, ...) ATTRIBUTE_GCC_DIAG(4,5);
+extern bool emit_diagnostic_valist (diagnostic_t, rich_location *, int,
+   const char *,
+   va_list *) ATTRIBUTE_GCC_DIAG (4,0);
 extern bool emit_diagnostic_valist (diagnostic_t, location_t, int, const char 
*,
va_list *) ATTRIBUTE_GCC_DIAG (4,0);
 extern bool seen_error (void);
diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
index addd6606eaa..6e73343dbdb 100644
--- a/gcc/diagnostic.cc
+++ b/gcc/diagnostic.cc
@@ -1829,6 +1829,13 @@ emit_diagnostic_valist (diagnostic_t kind, location_t 
location, int opt,
   return diagnostic_impl (, NULL, opt, gmsgid, ap, kind);
 }
 
+bool
+emit_diagnostic_valist (diagnostic_t kind, rich_location *richloc, int opt,
+   const char *gmsgid, va_list *ap)
+{
+  return diagnostic_impl (richloc, NULL, opt, gmsgid, ap, kind);
+}
+
 /* An informative note at LOCATION.  Use this for additional details on an 
error
message.  */
 void
-- 
2.41.0




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

2023-11-13 Thread Florian Weimer
This patch series converts the following warnings into errors by
default:

  -Wint-conversion
  -Wimplicit-function-declaration
  -Wimplicit-int
  -Wreturn-mismatch
  -Wincompatible-pointer-types

As explained in the first commit, I decided not to use permerror_opt
because it does not exhibit the existing behavior for -pedantic-errors.

The impact on existing sources of the last commit is not really known to
me at this point.  I plan to start a Fedora build later this week with
an instrumented compiler, to see how much of a compatible impact it will
be.  The first conversion pass through Fedora only covered
-Wimplicit-function-declaration, -Wimplicit-int.  I started looking at
-Wint-conversion, and it did not seem to be too bad, so I think
including it should be fine.  I'm more worried about
-Wincompatible-pointer-types.

I have not yet added a new overview test for -fpermissive.  Such a test
should trigger all the dozen or so places where I introduced
pedpermerror, and see what happens under multiple dialects, each with
-fpermissive and without, and maybe also with and withoyt for
-pedantic-errors in -std=gnu89 and default modes.  I plan to do this
once I get some initial feedback on the direction of these series
because this test would likely be obsolete fairly quickly if changes to
the diagnostics are required.  I did copy some existing tests to test
both the error and warning (-fpermissive) diagnostics, and adjusted
others to expect errors, so there is already quite a bit coverage
without that overview test.

Right now, this series breaks the build on aarch64-linux-gnu due to an
incompatible pointer assignment in libgcc:

  [PATCH] aarch64: Avoid -Wincompatible-pointer-types warning in Linux unwinder
  
<https://inbox.sourceware.org/gcc-patches/874jht5tsq@oldenburg.str.redhat.com/>

Other targets had the same issue previously, but I've already fixed most
of them (I hope).  There could of course be similar issues lurking in
target-specific code, or even in system headers.

With the recent testsuite fixes, the testsuite should be fairly clean
despite these changes.  I verified that on i686-linux-gnu,
powerpc64-linux-gnu, and x86_64-linux-gnu.  There is one
aarch64-linux-gnu testsuite change I'd like the AArch64 maintainers to
review:

  [PATCH] aarch64: Call named function in gcc.target/aarch64/aapcs64/ice_1.c
  
<https://inbox.sourceware.org/gcc-patches/87r0kx6eez@oldenburg.str.redhat.com/>

Recently, I also found a problem in the gm2 testsuite:

  [PATCH] gm2: Add missing declaration of m2pim_M2RTS_Terminate to test
  
<https://inbox.sourceware.org/gcc-patches/874jhp3nwf@oldenburg.str.redhat.com/>

Thanks,
Florian


Florian Weimer (6):
  c-family: Introduce pedpermerror
  c: Turn int-conversion warnings into permerrors
  c: Turn -Wimplicit-function-declaration into a pedpermerror
  c: Turn -Wimplicit-int into a pedpermerror
  c: Turn -Wreturn-mismatch into a pedpermerror
  c: Turn -Wincompatible-pointer-types into a pedpermerror

 gcc/c-family/c-common.h   |   4 +
 gcc/c-family/c-warn.cc|  34 
 gcc/c/c-decl.cc   |  40 ++--
 gcc/c/c-typeck.cc | 164 +--
 gcc/diagnostic-core.h |   3 +
 gcc/diagnostic.cc |   7 +
 gcc/doc/invoke.texi   |  33 +++-
 gcc/testsuite/c-c++-common/pr77624-1.c|   4 +-
 .../c-c++-common/spellcheck-reserved.c|   4 +-
 gcc/testsuite/gcc.dg/20030906-1.c |   2 +-
 gcc/testsuite/gcc.dg/20030906-1a.c|  21 ++
 gcc/testsuite/gcc.dg/20030906-2.c |   2 +-
 gcc/testsuite/gcc.dg/20030906-2a.c|  21 ++
 .../Wimplicit-function-declaration-c99-2.c|   7 +
 .../Wimplicit-function-declaration-c99.c  |   2 +-
 gcc/testsuite/gcc.dg/Wimplicit-int-1.c|   2 +-
 gcc/testsuite/gcc.dg/Wimplicit-int-1a.c   |  11 ++
 gcc/testsuite/gcc.dg/Wimplicit-int-4.c|   2 +-
 gcc/testsuite/gcc.dg/Wimplicit-int-4a.c   |  11 ++
 .../gcc.dg/Wincompatible-pointer-types-2.c|   2 +-
 .../gcc.dg/Wincompatible-pointer-types-4.c|   2 +-
 .../gcc.dg/Wincompatible-pointer-types-5.c|  10 +
 .../gcc.dg/Wincompatible-pointer-types-6.c|  10 +
 gcc/testsuite/gcc.dg/Wint-conversion-2.c  |   2 +-
 gcc/testsuite/gcc.dg/Wint-conversion-3.c  |   2 +-
 gcc/testsuite/gcc.dg/Wint-conversion-4.c  |  14 ++
 gcc/testsuite/gcc.dg/Wreturn-mismatch-1.c |   2 +-
 gcc/testsuite/gcc.dg/Wreturn-mismatch-1a.c|  40 
 gcc/testsuite/gcc.dg/Wreturn-mismatch-2.c |   2 +-
 gcc/testsuite/gcc.dg/Wreturn-mismatch-2a.c|  41 
 gcc/testsuite/gcc.dg/anon-struct-11.c |   5 +-
 gcc/testsuite/gcc.dg/anon-struct-11a.c| 111 +++
 gcc/testsuite/gcc.dg/anon-struct-13.c |   2 +-
 gcc/testsuite/gcc.dg/anon-struct-13a.c|  76 +++
 gcc/testsuite/gcc.dg/assign-warn-1.c 

[PATCH] gm2: Add missing declaration of m2pim_M2RTS_Terminate to test

2023-11-13 Thread Florian Weimer
Needed for C99 testsuite compatibility.

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/link/externalscaffold/pass/scaffold.c
index 2bd3587f6c7..2df0368b983 100644
--- a/gcc/testsuite/gm2/link/externalscaffold/pass/scaffold.c
+++ b/gcc/testsuite/gm2/link/externalscaffold/pass/scaffold.c
@@ -6,6 +6,7 @@ extern  void m2pim_M2_M2RTS_init (int argc, char *argv[]);
 extern  void m2pim_M2_M2RTS_fini (void);
 extern  void m2pim_M2_RTExceptions_init (int argc, char *argv[]);
 extern  void m2pim_M2_RTExceptions_fini (void);
+extern  void m2pim_M2RTS_Terminate (void);
 extern  void _M2_hello_init (int argc, char *argv[]);
 extern  void _M2_hello_fini (void);
 

base-commit: 9d471cd993e47dcbe91946beb529134565c58185



Re: Principles of the C99 testsuite conversion

2023-11-13 Thread Florian Weimer
These changes are now in, for i686-linux-gnu, powerpc64le-linux-gnu,
x86_64-linux-gnu.  For aarch64-linux-gnu, there's one change that would
benefit from maintainer review:

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


(On aarch64-linux-gnu, we also need a libgcc fix, but that is a
different matter.)

Thanks,
Florian



  1   2   3   4   5   6   7   8   9   10   >