[Bug testsuite/108675] FAIL: gcc.c-torture/execute/builtins/*printf.c when stdio.h includes definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108675
--- Comment #6 from Zack Weinberg ---
Note that what you (mingw) have in this header is a pretty serious
anti-optimization. Functions that call __builtin_va_start cannot be inlined
under any circumstances whatsoever (try tagging it
__attribute__((always_inline)) and see what happens) so you're emitting a
redundant copy of this function in every translation unit that calls fprintf,
and you're not getting any actual codegen improvement in exchange.
You _could_ do like glibc bits/stdio2.h
__mingw_ovr
__attribute__((__format__ (gnu_printf, 1, 2))) __MINGW_ATTRIB_NONNULL(1)
int printf (const char *__format, ...)
{
return __mingw_fprintf(stdout, __format, __builtin_va_arg_pack());
}
but this doesn't let you synthesize a direct call to __mingw_vfprintf.
I'd recommend scrapping the entire mess, abandoning the idea of getting direct
calls to v*printf/v*scanf, and using asm() symbol renaming to add the __mingw_
prefix. That should also avoid stepping on the GCC testcases' toes.
[Bug c++/41233] Templated conversion operator produces symbol name that won't demangle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41233 --- Comment #10 from Zack Weinberg --- The examples found by other people still don't demangle, though... $ c++filt --version 2>&1 | head -n1 GNU c++filt (GNU Binutils for Debian) 2.39 $ c++filt <<\EOF _ZNK3FooIPvEcvS_IT_EIiEEv _ZN5vnullcv3vecIT_T0_T1_EI10double_int7va_heap6vl_ptrEEv EOF _ZNK3FooIPvEcvS_IT_EIiEEv _ZN5vnullcv3vecIT_T0_T1_EI10double_int7va_heap6vl_ptrEEv
[Bug c/44179] warn about sizeof(char) and sizeof('x')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44179
--- Comment #3 from Zack Weinberg ---
It's come to my attention that people fairly often write `sizeof('x')` (or some
other character constant), _expecting_ it to evaluate as `sizeof(char)`. But
this is only true in C++. In C, `sizeof('x')` evaluates as `sizeof(int)`.
See
http://codesearch.debian.net/search?q=filetype%3Ac+%5Cbsizeof%5Cs*%5C%28%5Cs*%27&literal=0
for many examples.
It's probably more important to warn about this than about `sizeof(char)`
itself.
[Bug c/118853] New: -fmax-errors=N does not stop parsing after the Nth error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118853 Bug ID: 118853 Summary: -fmax-errors=N does not stop parsing after the Nth error Product: gcc Version: 14.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zack+srcbugz at owlfolio dot org Target Milestone: --- Created attachment 60479 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60479&action=edit Shell script that demonstrates the problem The documentation makes it sound like -fmax-errors=N will cause GCC to exit immediately after printing the Nth error. This is not what happens; GCC seems instead to continue processing until it reaches either the end of the file or the N+1'th error, and *then* it exits. If there was an N+1'th error, it is not printed. In contrast, -Wfatal-errors causes GCC to exit immediately after printing the first error. This is observable if you have a very long (perhaps machine-generated) source file with an error near the beginning. The attached shell script generates such a source file and times execution of your choice of compiler with -fsyntax-only + (-Wfatal-errors, -fmax-errors=1, nothing). Observe that the execution time for the latter two is much longer than the execution time for -Wfatal-errors. I can see how "-fmax-errors=2" could be understood to mean "halt processing if _more than_ two errors are encountered", but that's not what the manual says it does, and also in that case it should print the third error before giving up, and also in that case -fmax-errors=0 should do what -Wfatal-errors does. I think user expectations are more likely to be that -fmax-errors=N stops processing immediately after printing the Nth error, as is currently the case for -Wfatal-errors with one error.
