* 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
* 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
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,
---
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
---
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
+++
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
+++
* 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
* 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
>> (-Werr
* 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
* 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
* 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
---
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
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
* 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
* Marek Polacek:
> On Mon, Nov 20, 2023 at 10:56:42AM +0100, Florian Weimer wrote:
>> This used to be a warning, enabled by default, without its own option.
>
> I think this patch is OK now.
>
>> A subsequent change could improve diagnostics and provide spelling
>&g
* 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
* 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:
* 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
>>
* 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
* 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.h
* 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
* 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
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 +-
* 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
* 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]
* 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
* 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:
>>
* 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
* 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...)
>
>> *
* 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.
* 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.
* 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
* 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
* 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
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.
---
* Eric Gallager:
> On Mon, Nov 20, 2023 at 4:58 AM Florian Weimer wrote:
>>
>> This used to be a warning, enabled by default, without its own option.
>
> Right, I meant to ask: why create a new option of
> -Wdeclaration-missing-parameter-type instead of reusing the existi
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
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/
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:
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)
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
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,
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
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
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
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 |
* 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
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
* 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
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
* 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
* 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
* 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
* 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
>> treatm
* 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
>>
bvious 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
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:
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
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
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
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)
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/
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,
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
ches/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
* 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 int
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
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:
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.
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
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.
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
e.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
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
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
* Eric Gallager:
>> diff --git a/gcc/testsuite/gcc.c-torture/compile/20080910-1.c
>> b/gcc/testsuite/gcc.c-torture/compile/20080910-1.c
>> index bf32775d401..911fb562790 100644
>> --- a/gcc/testsuite/gcc.c-torture/compile/20080910-1.c
>> +++ b/gcc/testsuite/gcc.c-torture/compile/20080910-1.c
>>
* Jeff Law:
> OK. Spot checked. It looked like -fpermissive was added for some as
> well, which is fine by me. Perhaps "Compile with -std=gnu89 and
> possibly -fpermissive as needed" or something similar in the
> ChangeLog.
There was one test that had -std=gnu89 -fpermissive. But
gcc/testsuite/
* gcc.c-torture/compile/386.c: Compile with -std=gnu89.
* gcc.c-torture/compile/BUG1.c: Likewise.
* gcc.c-torture/compile/BUG11.c: Likewise.
* gcc.c-torture/compile/BUG16.c: Likewise.
* gcc.c-torture/compile/BUG2.c: Likewise.
*
gcc/testsuite/
* gcc.c-torture/compile/BUG17.c (main): Add missing int
return type and missing void type.
* gcc.c-torture/compile/BUG18.c (main): Likewise. Call
__builtin_printf instead of printf.
* gcc.c-torture/compile/BUG21.c (Nase): Add missing void
gcc/testsuite/
* gcc.c-torture/compile/20080613-1.c (hop_sendmsg): Call
__builtin_memcpy instead of memcpy.
* gcc.c-torture/compile/complex-6.c (bar): Declare.
* gcc.c-torture/compile/pr23445.c (__brelse): Declare.
* gcc.c-torture/compile/pr23946.c
These tests use obsolete language constructs, but they are not
clearly targeting C89, either. So use -fpermissive to keep
future errors as warnings.
The reasons why obsolete constructs are used used vary from
test to test. Some tests deliberately exercise later stages
of the compiler that only
* config/aarch64/linux-unwind.h
(aarch64_fallback_frame_state): Add cast to the expected type
in sc assignment.
(Almost a v2, but the other issue was already fixed via in r14-4183.)
---
libgcc/config/aarch64/linux-unwind.h | 5 -
1 file changed, 4 insertions(+), 1
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
* Jakub Jelinek:
> On Wed, Nov 08, 2023 at 03:55:17PM +0100, Florian Weimer wrote:
>> * gcc.target/x86_64/abi/avx/avx-check.h (main): Call
>> __builtin_printf instead of printf.
>> * gcc.target/x86_64/abi/avx/test_passing_m256.c
>> (fun_check_
* gcc.target/x86_64/abi/avx/avx-check.h (main): Call
__builtin_printf instead of printf.
* gcc.target/x86_64/abi/avx/test_passing_m256.c
(fun_check_passing_m256_8_values): Add missing void return
type.
* gcc.target/x86_64/abi/avx512f/avx512f-check.h
gcc/testsuite/ChangeLog:
* gcc.dg/setjmp-7.c (_setjmp): Declare.
---
gcc/testsuite/gcc.dg/setjmp-7.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.dg/setjmp-7.c b/gcc/testsuite/gcc.dg/setjmp-7.c
index 44b5bcbfa9d..579542380ba 100644
---
* Alexander Monakov via Gcc-patches:
> diff --git a/gcc/testsuite/gcc.dg/setjmp-7.c b/gcc/testsuite/gcc.dg/setjmp-7.c
> new file mode 100644
> index 0..44b5bcbfa
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/setjmp-7.c
> @@ -0,0 +1,13 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2
gcc/testsuite/ChangeLog:
* gcc.dg/Wmissing-parameter-type.c: Build with -std=gnu89
to trigger the -Wmissing-parameter-type warning
and not the default -Wimplicit warning. Also match
against -Wmissing-parameter-type.
* gcc.dg/Wmissing-parameter-type.c:
* Florian Weimer:
> The existing -Wreturn-type option covers both constraint violations
> (which are mandatory to diagnose) and warnings that have known
> false positives. The new -Wreturn-mismatch warning is only about
> the constraint violations (missing or extra return
Future changes will treat some C front end warnings similar to
-Wnarrowing.
gcc/
* doc/invoke.texi (Warning Options): Mention C diagnostics
for -fpermissive.
gcc/c-family/
* c.opt (fpermissive): Enable for C and ObjC.
* c-opts.cc (c_common_post_options): Enable
This should be safe because this is a preprocessor test; it
should not exercise implicit function declarations.
* gcc.dg/cpp/wchar-1.c (main): Call __builtin_abort instead of
abort.
---
gcc/testsuite/gcc.dg/cpp/wchar-1.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Future changes will treat some C front end warnings similar to
-Wnarrowing.
gcc/
* doc/invoke.texi (Warning Options): Mention C diagnostics
for -fpermissive.
gcc/c-family/
* c.opt (fpermissive): Enable for C and ObjC.
* c-opts.cc (c_common_post_options): Enable
* Jakub Jelinek:
> On Mon, Nov 06, 2023 at 03:19:32PM +0100, Florian Weimer wrote:
>> * Jakub Jelinek:
>>
>> > On Mon, Nov 06, 2023 at 03:06:39PM +0100, Florian Weimer wrote:
>> >> Future changes will treat some C front end warnings similar to
* Jakub Jelinek:
> On Mon, Nov 06, 2023 at 03:06:39PM +0100, Florian Weimer wrote:
>> Future changes will treat some C front end warnings similar to
>> -Wnarrowing.
>>
>> gcc/
>>
>> * doc/invoke.texi (Warning Options): Mention C diagnostics
>&g
Future changes will treat some C front end warnings similar to
-Wnarrowing.
gcc/
* doc/invoke.texi (Warning Options): Mention C diagnostics
for -fpermissive.
gcc/c-family/
* c.opt (fpermissive): Enable for C and ObjC.
* c-opts.cc (set_std_c89): Enable
* Andrew Pinski:
> On Sun, Oct 22, 2023 at 12:47 AM Florian Weimer wrote:
>>
>> Current glibc headers only declare fputs_unlocked for _GNU_SOURCE.
>> Defining the macro avoids an implicit function declaration.
>
> This does not help targets that don't use glibc
Current glibc headers only declare fputs_unlocked for _GNU_SOURCE,
so define it to obtain an official prototype.
Add a fallback prototype declaration for other systems that do not
have fputs_unlocked. This seems to the most straightforward approach
to avoid an implicit function declaration,
Current glibc headers only declare fputs_unlocked for _GNU_SOURCE.
Defining the macro avoids an implicit function declaration.
gcc/testsuite/
* gcc.c-torture/execute/builtins/fputs.c (_GNU_SOURCE):
Define.
---
gcc/testsuite/gcc.c-torture/execute/builtins/fputs.c | 1 +
1 file
The main_test function returns void, so return with an expression
is a constraint violation. The test case still fails with this
change applied before the fix for PR 93262 in r14-4813.
gcc/testsuite/
* gcc.c-torture/execute/builtins/pr93262-chk.c (main_test):
Remove unnecessary
gcc/testsuite/
* gcc.c-torture/compile/2403-1.c: Compile with -std=gnu89.
* gcc.c-torture/compile/2511-1.c: Likewise.
* gcc.c-torture/compile/2804-1.c: Likewise.
* gcc.c-torture/compile/20020418-1.c: Likewise.
*
1 - 100 of 520 matches
Mail list logo