Use of register keyword for Globals
Hi In the SPARC port of RTEMS, there is a global variable assigned to a register for performance reasons. This is the near decade old line of code: register struct Per_CPU_Control *_SPARC_Per_CPU_current __asm__( "g6" ); Per https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables.html, this is still the correct way to accomplish this. But -pedantic and specifying C17 result in this warning: ../../../cpukit/score/cpu/sparc/include/rtems/score/cpuimpl.h:230:17: warning: file-scope declaration of '_SPARC_Per_CPU_current' specifies 'register' [-Wpedantic] 230 | register struct Per_CPU_Control *_SPARC_Per_CPU_current __asm__( "g6" ); | We do not want to move this pointer out of a register and the GCC docs section cited above doesn't mention anything about the register keyword being moved to reserved keyword in C17 and C++17 with undefined meaning. The example in the GCC manual is similar to our use. Is there more current guidance on having a global register variable? Other than disabling the pedantic warning around that one line, how should the warning be addressed? Thanks. --Joel Sherrill
Re: Use of register keyword for Globals
> Am 23.05.2025 um 17:06 schrieb Joel Sherrill via Gcc : > > Hi > > In the SPARC port of RTEMS, there is a global variable assigned to a > register for performance reasons. This is the near decade old line of code: > > register struct Per_CPU_Control *_SPARC_Per_CPU_current __asm__( "g6" ); > > Per https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables.html, this > is still the correct way to accomplish this. But -pedantic and specifying > C17 result in this warning: > > ../../../cpukit/score/cpu/sparc/include/rtems/score/cpuimpl.h:230:17: > warning: file-scope declaration of '_SPARC_Per_CPU_current' specifies > 'register' [-Wpedantic] > 230 | register struct Per_CPU_Control *_SPARC_Per_CPU_current __asm__( > "g6" ); > | > > We do not want to move this pointer out of a register and the GCC docs > section cited above doesn't mention anything about the register keyword > being moved to reserved keyword in C17 and C++17 with undefined meaning. > The example in the GCC manual is similar to our use. > > Is there more current guidance on having a global register variable? Other > than disabling the pedantic warning around that one line, how should the > warning be addressed? Does it work by writing __extension__ before it? This is a GNU extension, so complaining with -pedantic when compiling with -std=cXY as opposed to -std=gnuXY is what I would expect. Richard > > Thanks. > > --Joel Sherrill
Re: Use of register keyword for Globals
在 2025-5-23 23:03, Joel Sherrill via Gcc 写道:
Hi
In the SPARC port of RTEMS, there is a global variable assigned to a
register for performance reasons. This is the near decade old line of code:
register struct Per_CPU_Control *_SPARC_Per_CPU_current __asm__( "g6" );
+1 for this.
On ARM64, Windows uses X18 as a pointer to thread-specific data. We have this declaration which we can't
get rid of:
register struct _TEB *__mingw_current_teb __asm__("x18");
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Use of register keyword for Globals
On Fri, May 23, 2025 at 10:12 AM Richard Biener wrote: > > > > Am 23.05.2025 um 17:06 schrieb Joel Sherrill via Gcc : > > > > Hi > > > > In the SPARC port of RTEMS, there is a global variable assigned to a > > register for performance reasons. This is the near decade old line of > code: > > > > register struct Per_CPU_Control *_SPARC_Per_CPU_current __asm__( "g6" ); > > > > Per https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables.html, > this > > is still the correct way to accomplish this. But -pedantic and specifying > > C17 result in this warning: > > > > ../../../cpukit/score/cpu/sparc/include/rtems/score/cpuimpl.h:230:17: > > warning: file-scope declaration of '_SPARC_Per_CPU_current' specifies > > 'register' [-Wpedantic] > > 230 | register struct Per_CPU_Control *_SPARC_Per_CPU_current __asm__( > > "g6" ); > > | > > > > We do not want to move this pointer out of a register and the GCC docs > > section cited above doesn't mention anything about the register keyword > > being moved to reserved keyword in C17 and C++17 with undefined meaning. > > The example in the GCC manual is similar to our use. > > > > Is there more current guidance on having a global register variable? > Other > > than disabling the pedantic warning around that one line, how should the > > warning be addressed? > > Does it work by writing __extension__ before it? This is a GNU extension, > so complaining with -pedantic when compiling with -std=cXY as opposed to > -std=gnuXY is what I would expect. > Adding __extension__ did work. Thanks! Any idea if that's accepted by clang? Do you think the GCC documentation on this should include this? --Joel Sherrill > > Richard > > > > > Thanks. > > > > --Joel Sherrill >
Re: Use of register keyword for Globals
On Fri, May 23, 2025 at 12:33 PM Richard Biener wrote: > > > Am 23.05.2025 um 18:32 schrieb Joel Sherrill : > > > > > On Fri, May 23, 2025 at 10:12 AM Richard Biener < > richard.guent...@gmail.com> wrote: > >> >> >> > Am 23.05.2025 um 17:06 schrieb Joel Sherrill via Gcc : >> > >> > Hi >> > >> > In the SPARC port of RTEMS, there is a global variable assigned to a >> > register for performance reasons. This is the near decade old line of >> code: >> > >> > register struct Per_CPU_Control *_SPARC_Per_CPU_current __asm__( "g6" ); >> > >> > Per https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables.html, >> this >> > is still the correct way to accomplish this. But -pedantic and >> specifying >> > C17 result in this warning: >> > >> > ../../../cpukit/score/cpu/sparc/include/rtems/score/cpuimpl.h:230:17: >> > warning: file-scope declaration of '_SPARC_Per_CPU_current' specifies >> > 'register' [-Wpedantic] >> > 230 | register struct Per_CPU_Control *_SPARC_Per_CPU_current __asm__( >> > "g6" ); >> > | >> > >> > We do not want to move this pointer out of a register and the GCC docs >> > section cited above doesn't mention anything about the register keyword >> > being moved to reserved keyword in C17 and C++17 with undefined meaning. >> > The example in the GCC manual is similar to our use. >> > >> > Is there more current guidance on having a global register variable? >> Other >> > than disabling the pedantic warning around that one line, how should the >> > warning be addressed? >> >> Does it work by writing __extension__ before it? This is a GNU >> extension, so complaining with -pedantic when compiling with -std=cXY as >> opposed to -std=gnuXY is what I would expect. >> > > Adding __extension__ did work. Thanks! > > Any idea if that's accepted by clang? > > > It should be accepted. Whether or not it has the same effect on > diagnostics I do not know. > > Do you think the GCC documentation on this should include this? > > > If __extension__ is not cross-referenced from the -pedantic documentation > we should probably do so. Can you propose a patch? > I'll add it to my queue. --joel > > Richard > > > --Joel Sherrill > >> >> Richard >> >> > >> > Thanks. >> > >> > --Joel Sherrill >> >
GCC 14.3 Released
The GNU Compiler Collection version 14.3 has been released. GCC 14.3 is a bug-fix release from the GCC 14 branch containing important fixes for regressions and serious bugs in GCC 14.2 with more than 211 bugs fixed since the previous release. This release is available from the FTP servers listed here: https://sourceware.org/pub/gcc/releases/gcc-14.3.0/ https://gcc.gnu.org/mirrors.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually!
GCC 14.3.1 Status Report (2025-05-23)
Status == The GCC 14 branch is open again for regression and documentation fixes. Quality Data Priority # Change from last report --- --- P10- 1 P2 603- 15 P3 133+ 23 P4 216+ 4 P5 23 --- --- Total P1-P3 736+ 7 Total 975+ 11 Previous Report === https://gcc.gnu.org/pipermail/gcc/2025-May/246053.html
gcc-14-20250523 is now available
Snapshot gcc-14-20250523 is now available on https://gcc.gnu.org/pub/gcc/snapshots/14-20250523/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 14 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-14 revision 306cdb4df729079d7bd924e0023693181163e2e3 You'll find: gcc-14-20250523.tar.xz Complete GCC SHA256=96ac18fa1dec7fac40239cbc8b162230ffcf36a76152693ff2242ef3137a2158 SHA1=b6aa4687c0d98a63f749e57e58df3c2f64b5c9b9 Diffs from 14-20250516 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-14 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: Review for gcc-15/changes.html
Heiko Eißfeldt writes: > Hi, > > here is a patch for some mostly minor typos in > https://gcc.gnu.org/gcc-15/changes.html. > My fixes might be wrong of course, so they are just suggestions. > > Also, the linked page https://gcc.gnu.org/gcc-15/porting_to.html > contains the now outdated > "Note: GCC 15 has not been released yet, so this document is a > work-in-progress." > which is luckily not true anymore. Thanks for doing this. Do you plan to post an updated patch (ideally to gcc-patches)? > > Greetings and thanks, Heiko > > [2. text/x-patch; Changes_Rel15.0.html.diff]... > > [3. OpenPGP public key --- application/pgp-keys; > OpenPGP_0x6C5B5E2DE9D181E2.asc]...
