Re: More C type errors by default for GCC 14
* Jason Merrill: > As a compromise, it should be possible to error by default only in > cases where the implicit int (including as a return value) is either > the source or target of a non-value-preserving conversion, as those > are very likely to be bugs. That seems desirable for both camps. Not sure, malloc returning 31-bit pointers goes a long way towards maintaining int/pointer compatibility for 64-bit systems, too. People might actually have a working implicit-declared malloc on 64-bit today, and still argue against the changes. > A simpler change to catch this particular bug would be to make > -Wint-conversion an error by default iff the sizes differ. That doesn't address other bugs around implicitly-declared functions, such as the bool/int ABI incompatibility, or the lack of type checking for arguments. I don't see those programmer mistakes because I think it's easier to debug them on your own: swapped arguments are visible in the source code, and GDB probably gives you enough data as well. So I suspect that people figure this out on their own. They are still wasting time on this, but probably somewhat less. Thanks, Florian
[RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (May 18, 2023)
Hi all, Here is the agenda for tomorrow's RISC-V GNU toolchain meeting. If you have any topics want to discuss or share, please change the angenda/notes doc or let me know and I will update them, thanks. https://docs.google.com/document/d/1JSs-BSlPJ3QYbAb-Add1TlbYx0nOT1ur3jcsITIJ01U/edit# P.S. The meeting calendar .ics file has updated, please check and update it,thanks. Agenda: - New RISC-V ISA spec version - RV64-ILP32 supports introduce - Sub-extensions support status - Open discuss Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting. Topic: RISC-V GNU Toolchain Biweekly Sync-up Time: May 18, 2023 UTC+0 15:00 / PST 07:00 / CST 23:00 Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://calendar.google.com/calendar/ical/lm5bddk2krcmtv5iputjgqvoio%40group.calendar.google.com/public/basic.ics Join Zoom Meeting https://zoom.us/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09 Meeting ID: 893 9360 0951 Passcode: 899662 BEIJING, China 23:00pThu, May 18 2023 24:00a Fri, May 18 2023 PST/PDT, Pacific Standard Time (US) 8:00aThu, May 18 2023 9:00aThu, May 18 2023 PHILADELPHIA, United States, Pennsylvania 11:00aThu, May 18 2023 12:00aThu, May 18 2023 Paris, France 17:00pThu, May 18 2023 18:00pThu, May 18 2023BEGIN:VCALENDAR PRODID:-//zoom.us//iCalendar Event//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:PUBLISH CLASS:PUBLIC BEGIN:VTIMEZONE TZID:Asia/Singapore LAST-MODIFIED:20230104T023643Z TZURL:https://www.tzurl.org/zoneinfo-outlook/Asia/Singapore X-LIC-LOCATION:Asia/Singapore BEGIN:STANDARD TZNAME:+08 TZOFFSETFROM:+0800 TZOFFSETTO:+0800 DTSTART:19700101T00 END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20230215T105933Z DTSTART;TZID=Asia/Singapore:20230223T23 DTEND;TZID=Asia/Singapore:20230224T00 SUMMARY:RISC-V GNU Toolchain Biweekly Sync-up RRULE:FREQ=WEEKLY;WKST=SU;UNTIL=20231228T16;INTERVAL=2;BYDAY=TH UID:ZOOM89393600951 TZID:Asia/Singapore DESCRIPTION:Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting .\n\nJoin Zoom Meeting\nhttps://us02web.zoom.us/j/89393600951?pwd=ZFpWMk Z6Tm1TbUFXT1hZZjZZMHhRQT09\n\nMeeting ID: 893 9360 0951\nPasscode: 89966 2\nOne tap mobile\n+6531294892\,\,89393600951#\,\,\,\,*899662# Singapore \n+6531587288\,\,89393600951#\,\,\,\,*899662# Singapore\n\nDial by your location\n+65 3129 4892 Singapore\n+65 3158 7288 Singapo re\n+65 3165 1065 Singapore\n+65 3129 4891 Singapore\n +1 669 900 9128 US (San Jose)\n+1 669 444 9171 US\n +1 253 215 8782 US (Tacoma)\n+1 346 248 7799 US (Houston)\n +1 719 359 4580 US\n+1 253 205 0468 US\n+1 386 347 5 053 US\n+1 507 473 4847 US\n+1 564 217 2000 US\n +1 646 558 8656 US (New York)\n+1 646 931 3860 US\n+1 68 9 278 1000 US\n+1 301 715 8592 US (Washington DC)\n+1 30 5 224 1968 US\n+1 309 205 3325 US\n+1 312 626 6799 US (C hicago)\n+1 360 209 5623 US\nMeeting ID: 893 9360 0951\nPasscode : 899662\nFind your local number: https://us02web.zoom.us/u/kk9cyIPNJ\n\ n LOCATION:https://us02web.zoom.us/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZj ZZMHhRQT09 BEGIN:VALARM TRIGGER:-PT10M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR
LSP based on GCC
Dear GCC developers, Emacs 29, to be released soon, will come with a built-in client for the LSP protocol. This allows to enhance important Emacs features, such as at-point documentation, on-the-fly diagnostic annotations, finding definitions and uses of program identifiers, enhanced completion of symbols and code, etc., based on capabilities of LSP servers. The Emacs LSP client comes with support for many popular LSP servers OOTB and for all the programming languages supported by Emacs. However, all the available servers for C and C++ languages are based on Clang. AFAIU, this is because GCC does not yet have its own implementation of the LSP. I found this message posted to gcc-patches in 2017: https://gcc.gnu.org/legacy-ml/gcc-patches/2017-07/msg01448.html which described the initial implementation of LSP in GCC, but I seem to be unable to find out what happened with that since then. Are there plans for implementing the LSP in GCC? If so, which GCC version is expected to have this included? If there are no current plans for implementing LSP, I hope someone will work on that soon, given that Emacs can now use it, and because having a GCC-based LSP implementation will allow people to use their installed GCC as the basis for LSP features, instead of having to install yet another compiler. TIA
Re: LSP based on GCC
On Wed, 2023-05-17 at 17:28 +0300, Eli Zaretskii via Gcc wrote: > If there are no current plans for implementing LSP, I hope someone > will work on that soon, given that Emacs can now use it, and because > having a GCC-based LSP implementation will allow people to use their > installed GCC as the basis for LSP features, instead of having to > install yet another compiler. Just to note, existing LSP servers are stand-alone binaries: you don't need to install the compiler. The two main C/C++ LSP servers I'm aware of are clangd and ccls. Both of them are built from libclang, as you suggest, but you don't need a full clang installation to get them. You do need to install some Clang "resource" header files for intrinsics etc. but not the entire compiler (for example you don't need the STL or anything like that: they do work fine with the GCC STL). Nevertheless I wholeheartedly agree with your hopes Eli because using Clang-based LSP is annoying for people developing with GCC: First, when you're viewing code that is using #ifdefs to choose between compilers you always see the code for Clang as "active", even though you're using GCC as the compiler, since it's using the Clang built-in macros. More frustratingly, Clang has made some poor decisions around "compatibility": they tried to leverage the GNU ecosystem by emulating GCC features and arguments but sometimes break things. The most egregious example I'm aware of is that they look for GCC-named precompiled headers (.gch), even though the Clang PCH format is completely different. So if Clang (and the LSP servers built on it) find a .gch header file they will try to read it, fail, and give an error. I filed a bug about this in 2019 but it's been ignored. This means you need to modify your LSP server arguments to omit any PCH compiler command line arguments; for environments based on auto- generated definitions like compile_commands.json this is frustrating.
gcc-10-20230517 is now available
Snapshot gcc-10-20230517 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20230517/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision 7e273bdadbf78803f4f3e408476bea843a0d67e7 You'll find: gcc-10-20230517.tar.xz Complete GCC SHA256=0048733509ab6ff684ad6081b323ee861b3001ae608c97f97b1e756c3953ef4a SHA1=927df502c178e94a59cd8a29a16fd15d2109401b Diffs from 10-20230510 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: LSP based on GCC
On Wed, May 17, 2023 at 15:48:09 -0400, Paul Smith wrote: > More frustratingly, Clang has made some poor decisions around > "compatibility": they tried to leverage the GNU ecosystem by emulating > GCC features and arguments but sometimes break things. The most Alas, the cost of trying to make a compiler that can injest in-the-wild code. It's the reason "every" compiler claims various GCC things: too many projects ended up with `#error "Unknown compiler"` in their detections and fixing them when you're just trying to get off the ground is annoying. As far as I know, GCC is locked into never providing a single uniquely identifiable trait because other compilers would end up having to emulate it too once it gets used by projects. CMake basically just ends up with "it's GCC" if `__GNUC__` is defined and none of the other, more specific, preprocessor markers are present. We're kind of getting this again with the variety of different frontends available on top of Clang these days (Apple's Xcode build, upstream itself, Intel's frontend, IBM's LLVM-based frontend, the XL-alike Clang build, Fujitsu has one, ARM's, and who knows how many others are out there). Sometimes they've…forgotten to make something distinctive so that it can be detected reliably. > egregious example I'm aware of is that they look for GCC-named > precompiled headers (.gch), even though the Clang PCH format is > completely different. So if Clang (and the LSP servers built on it) > find a .gch header file they will try to read it, fail, and give an > error. I filed a bug about this in 2019 but it's been ignored. > > This means you need to modify your LSP server arguments to omit any PCH > compiler command line arguments; for environments based on auto- > generated definitions like compile_commands.json this is frustrating. FWIW, this is only going to get worse with C++ modules. --Ben
Re: LSP based on GCC
David Malcolm writes: > [...snip...] > I wrote that prototype, but I haven't touched it since 2017, and I > already have more than enough other work, alas. I'm happy to help if > someone wants to pick up the work and finish it. > > That patch kit did several things: > (a) adds a new "on the side" representation of source code locations > (b) adds a JSON implementation to gcc > (c) implements an LSP server on a port, implementing only the > "textDocument/definition" method. > > Not having quite enough source code location is a pet peeve of mine > within GCC's intermediate representation, as we lose a fair bit of > location information as we go from frontends to the tree/generic > representation (e.g. "exactly where was each brace?"). You mentioned 'cousin' tools in your original post, and I largely agree with your sentiment. Many parts of the job of an FE can be reused for many other purposes, evidently. Even beyond an LSP implementation. > Unfortunately the particular approach I came up with in (a) was > rejected by frontend maintainers, so I abandoned that part of the > work. I couldn't find the relevant messages. Mind sharing a message-id or archive link? > The part of (b) for storing JSON trees in memory and writing them out > is in GCC's source tree; the JSON-parsing code isn't yet, but I have a > relatively up-to-date refreshed version of that code in one of my > working copies which I can post to the list if it will be helpful. > > As for (c), doing it on a port is probably wrong, and working with > stdin/stdout seems a much better approach. AIUI, many editors (including Emacs' Eglot) also expect this (but I suspect many can leverage other methods of connecting too). ISTR Alexandre Oliva (CC added) mentioning leveraging GDB to implement various bits of LSP functionality, such as handling multiple TUs. This sounds like a good idea to me (at least at a high level), as it could lead to the hypothetical GNU toolchain LSP implementation being partially language-agnostic (naturally, some things like candidate lists would still need language support, as well as documentation parsing, ...), which would be quite handy. Do you happen to have any memory of that? Thanks in advance, have a lovely evening. -- Arsen Arsenović signature.asc Description: PGP signature
Taking Over MIPS Maintenance
Greetings all, I would like to self-nominate as the new GCC MIPS maintainer. Matthew Fortune is listed in MAINTAINERS as the current maintainer of GCC's MIPS Port. However, it has been years since he left MIPS Technologies and had since been inactive. I currently work for CIP United Inc., which is the exclusive licensor and operator of MIPS IPs in China, Hong Kong, and Macau. Part of our operations include maintaining open source software solutions for MIPS and we are looking to continue maintaining GCC's MIPS port. As the director of the company's software ecosystem department, I have been working with GCC and contributed code to the upstream repository since 2021. In September 2021, I was given write access to the repository: https://gcc.gnu.org/git/?p=gcc.git&a=search&h=HEAD&st=author&s=YunQiang+Su Please let me know about your thoughts on this proposal. Best Regards, YunQiang Su
