Created attachment 14434 [details] build.log.xz (12.1) Clang 16 will make -Wimplicit-function-declaration, -Wimplicit-int, -Wincompatible-function-pointer-declarations error by default. You can emulate its behaviour _mostly_ by just setting those in your *FLAGS. GDB 12 seems to have quite a large number of failures with Clang 16, unfortunately :( Originally reported downstream in Gentoo at https://bugs.gentoo.org/871543. For more information, see LWN.net [0] or LLVM's Discourse [1], gentoo-dev@ [2], or the (new) c-std-porting mailing list [3]. [0] https://lwn.net/Articles/913505/ [1] https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213 [2] https://archives.gentoo.org/gentoo-dev/message/dd9f2d3082b8b6f8dfbccb0639e6e240 [3] hosted at lists.linux.dev.
Created attachment 14435 [details] build.log.xz ("9999", master at 25e64b5276487ac8d95fc5030a1ba626883c7afd)
there's a couple of people already working on building things with clang. it's def not a priority, so i don't think it'll be fixed by GDB 13.
Sure. Just note that GCC 14 is likely to make two of these changes anyway (-Wimplicit-function-declaration and -Wimplicit-int).
considering GCC 13 probably won't be released for another ~6 months, and GCC 14 another ~year after that (~Apr 2024), i think we have plenty of time. no need to rush to get things into GDB 13 that should be cut any day now. (ftr, GDB 13 candidates build fine with current GCC 13 snapshots)
Also, releases, build without -Werror by default, so it's not the end of the world if there are benign warnings in releases.
> On 9 Nov 2022, at 15:38, simark at simark dot ca <sourceware-bugzilla@sourceware.org> wrote: > > https://sourceware.org/bugzilla/show_bug.cgi?id=29752 > > Simon Marchi <simark at simark dot ca> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |simark at simark dot ca > > --- Comment #5 from Simon Marchi <simark at simark dot ca> --- > Also, releases, build without -Werror by default, so it's not the end of the > world if there are benign warnings in releases. > They become errors by default. Not building with -Werror doesn't make a difference. You have to specifically negate it with -Wno... if you want to do that.
Ok, I re-read you original message and I understand what you mean. That's odd for compilers to decide for some diagnostics not to follow -W(no-)error. We currently add -Werror when development mode is on, that is outside of releases. We should perhaps use -Wno-error when development mode is off then.
(In reply to Mike Frysinger from comment #4) gcc 14 now does this, to be released in april 2024 or so indeed
i think all -Wimplicit-function-declaration issues are fixed the only -Wincompatible-function-pointer-types issue left is frv and its sem.c/queue logic. sem.c:24343:41: error: incompatible function pointer types passing 'void (SIM_CPU *, UINT, UDI)' (aka 'void (struct _sim_cpu *, unsigned int, unsigned long)') to parameter of type 'void (*)(SIM_CPU *, UINT, DI)' (aka 'void (*)(struct _sim_cpu *, unsigned int, long)') [-Wincompatible-function-pointer-types] sem.c is generated by CGEN code. not really sure where in the scheme files this comes from. but it's all related to a call like: sim_queue_fn_di_write (current_cpu, frvbf_h_acc40U_set, ... sim_queue_fn_di_write wants a func that has a param of (SIM_CPU*, UINT, DI), but frvbf_h_acc40U_set has a UDI. there isn't a sim_queue_fn_udi_write helper. we could change frvbf_h_acc40U_set to take a DI instead of UDI ? in practice, i don't think the sign is checked ? not sure tbh. and we don't have much of an FRV maintainer atm.
this change (and regenerating the files) fixes the warnings. --- a/cpu/frv.cpu +++ b/cpu/frv.cpu @@ -2933,7 +2933,7 @@ (name h-acc40U) (comment "40 bit unsigned accumulator") (attrs PROFILE VIRTUAL) - (type register UDI (64)) + (type register DI (64)) (indices extern-keyword acc-names) ; The accumlator is made up of two 32 bit registers, accgi/acci. ; We want to extract this as a combined 40 unsigned bits but not sure at all about the ramifications of it on the port.
forgot to loop in frv maintainer considering we're looking at a hard build failure here with newer compilers (where we can't turn it off with -W flags), i'm inclined to merge my patch in comment #10 (and with regenerated files). the unittests still pass, but i have no idea whether they provide coverage in this particular area. next gdb branch is schedule for Apr, so i'll move forward with my patch in Feb if no one has a better idea.
(In reply to Mike Frysinger from comment #11) > forgot to loop in frv maintainer I am afraid that email address hasn't been valid for 5 years. And the new address I have (from 2018) doesn't seem attached to a bugzilla account. I'll try emailing Dave.
i was using the e-mail address listed in MAINTAINERS files :/ i assume frv is being maintained at Redhat via some contract, and Dave was listed because of that rather than personal passion for frv :). is there someone new at Redhat who is responsible for it ? Nick is about the only other person i'd guess might know more.
Go ahead with the UDI->DI change. If the code builds, and still passes simulator smoke tests, it should be fine.
ok, pushed then, thx for checking