[Bug target/115874] New: sh.c appears to be missing include of stdio.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115874
Bug ID: 115874
Summary: sh.c appears to be missing include of stdio.h
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Target Milestone: ---
Target: sh-rtems6
Host: Cygwin
We have not seen this failure on Linux. stdio.h must be implicitly included.
This is the error on Cygwin. Is adding an include the right solution?
g++ -O2 -g -pipe
-I/home/jrs007/rtems-work/rtems-source-builder/rtems/build/tmp/sb-1049590/tools/rtems-default-tools/tmp/mkefs/include
-I/home/jrs007/rtems-work/rtems-source-builder/rtems/build/tmp/sb-1049590-internal/include
-fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual-DHAVE_CONFIG_H -I. -Ianalyzer
-I../../gcc-13.3.0/gcc -I../../gcc-13.3.0/gcc/analyzer
-I../../gcc-13.3.0/gcc/../include -I../../gcc-13.3.0/gcc/../libcpp/include
-I../../gcc-13.3.0/gcc/../libcody
-I/home/jrs007/rtems-work/rtems-source-builder/rtems/build/sh-rtems6-gcc-13.3.0-newlib-1ed1516-x86_64-pc-cygwin-1/gcc-13.3.0/mpc/src
-I../../gcc-13.3.0/gcc/../libdecnumber
-I../../gcc-13.3.0/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-13.3.0/gcc/../libbacktrace
-I/home/jrs007/rtems-work/rtems-source-builder/rtems/build/sh-rtems6-gcc-13.3.0-newlib-1ed1516-x86_64-pc-cygwin-1/build/./isl/include
-I/home/jrs007/rtems-work/rtems-source-builder/rtems/build/sh-rtems6-gcc-13.3.0-newlib-1ed1516-x86_64-pc-cygwin-1/gcc-13.3.0/isl/include
-o analyzer/call-string.o -MT analyzer/call-string.o -MMD -MP -MF
analyzer/.deps/call-string.TPo ../../gcc-13.3.0/gcc/analyzer/call-string.cc
In file included from ../../gcc-13.3.0/gcc/config/sh/sh.cc:28:
../../gcc-13.3.0/gcc/config/sh/sh.cc: In function ‘void sh_print_operand(FILE*,
rtx, int)’:
../../gcc-13.3.0/gcc/system.h:150:33: error: ‘fputs_unlocked’ was not declared
in this scope; did you mean ‘fputc_unlocked’?
150 | # define fputs(String, Stream) fputs_unlocked (String, Stream)
| ^~
../../gcc-13.3.0/gcc/config/sh/sh.cc:1180:11: note: in expansion of macro
‘fputs’
1180 | fputs ("/u", stream);
| ^
../../gcc-13.3.0/gcc/system.h:150:33: error: ‘fputs_unlocked’ was not declared
in this scope; did you mean ‘fputc_unlocked’?
150 | # define fputs(String, Stream) fputs_unlocked (String, Stream)
| ^~
../../gcc-13.3.0/gcc/config/sh/sh.cc:1186:11: note: in expansion of macro
‘fputs’
1186 | fputs ("\t! target: ", stream);
| ^
../../gcc-13.3.0/gcc/system.h:150:33: error: ‘fputs_unlocked’ was not declared
in this scope; did you mean ‘fputc_unlocked’?
150 | # define fputs(String, Stream) fputs_unlocked (String, Stream)
| ^~
../../gcc-13.3.0/gcc/config/sh/sh.cc:1203:11: note: in expansion of macro
‘fputs’
1203 | fputs (reg_names[regno], (stream));
| ^
../../gcc-13.3.0/gcc/system.h:150:33: error: ‘fputs_unlocked’ was not declared
in this scope; did you mean ‘fputc_unlocked’?
150 | # define fputs(String, Stream) fputs_unlocked (String, Stream)
| ^~
../../gcc-13.3.0/gcc/config/sh/sh.cc:1230:11: note: in expansion of macro
‘fputs’
1230 | fputs (reg_names[regno], (stream));
| ^
../../gcc-13.3.0/gcc/system.h:150:33: error: ‘fputs_unlocked’ was not declared
in this scope; did you mean ‘fputc_unlocked’?
150 | # define fputs(String, Stream) fputs_unlocked (String, Stream)
| ^~
../../gcc-13.3.0/gcc/config/sh/sh.cc:1257:11: note: in expansion of macro
‘fputs’
1257 | fputs (reg_names[REGNO (x) + 1], (stream));
| ^
../../gcc-13.3.0/gcc/system.h:150:33: error: ‘fputs_unlocked’ was not declared
in this scope; did you mean ‘fputc_unlocked’?
150 | # define fputs(String, Stream) fputs_unlocked (String, Stream)
| ^~
../../gcc-13.3.0/gcc/config/sh/sh.cc:1290:21: note: in expansion of macro
‘fputs’
1290 | case PLUS: fputs ("add", stream); break;
| ^
../../gcc-13.3.0/gcc/system.h:150:33: error: ‘fputs_unlocked’ was not declared
in this scope; did you mean ‘fputc_unlocked’?
150 | # define fputs(String, Stream) fputs_unlocked (String, Stream)
| ^~
../../gcc-13.3.0/gcc/config/sh/sh.cc:1309:28: note: in expansion of macro
‘fputs’
1309 | case E_QImode: fputs (".b", stream); break;
|^
../../gcc-13.3.0/gcc/system.h:150:33:
[Bug target/115874] sh.c appears to be missing include of stdio.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115874 Joel Sherrill changed: What|Removed |Added Host||cygwin Target||sh-rtems6 --- Comment #1 from Joel Sherrill --- I tried adding include of and then but never directly solved the problem. fputs_unlocked() is under a __GNU_VISIBLE guard. I added a define of _GNU_SOURCE above the include of but that didn't help.
[Bug target/115874] sh.c appears to be missing include of stdio.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115874 --- Comment #3 from Joel Sherrill --- config.h includes auto-host.h which appears to be defining the macros: /* Define to 1 if we found a declaration for 'fputc_unlocked', otherwise define to 0. */ #ifndef USED_FOR_TARGET #define HAVE_DECL_FPUTC_UNLOCKED 1 #endif /* Define to 1 if we found a declaration for 'fputs_unlocked', otherwise define to 0. */ #ifndef USED_FOR_TARGET #define HAVE_DECL_FPUTS_UNLOCKED 1 #endif If I add a #error before each of those defines, the compile gets there and hits the #error. I made this chance to sh.cc and got the #error: #include "config.h" #ifdef HAVE_DECL_FPUTS_UNLOCKED #error "joel" #endif I think that means the right feature macro is defined. What else might be wrong?
[Bug go/113143] Remove usage of ucontext.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143 Joel Sherrill changed: What|Removed |Added CC||joel at gcc dot gnu.org --- Comment #13 from Joel Sherrill --- RTEMS also had support for Go a long time ago -- it was a GSoC 2010 project. It worked until the dependency on was added. RTEMS has tracked the lack of needed for Go for 7 years (https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/2832). It was likely broken for a while before one of us filed the ticket. We use newlib and looking at the source Cygwin has its own . My msys2 install has that version of the file in /usr/include. RTEMS does not have . The ticket we have encourages porting the implementation from *BSD but that will only address a handful of the 18 architectures we currently support. I agree it is obsolete per POSIX and not universally supported. I also give Ian the benefit of doubt that there is no adequate replacement -- certainly not in POSIX. That leaves the solution of having an alternative in Go or an implementation that is easy to drop into OSes other than Linux or *BSD. Looks like neither RTEMS nor Haiku has seen someone step up as a volunteer in the long time this has been an issue.
[Bug target/118977] m68k mcf5282 undefined symbol __atomic_test_and_set from atomic_base.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118977 Joel Sherrill changed: What|Removed |Added Last reconfirmed||2025-5-3 Known to fail||14.0 Known to work||13.0 --- Comment #4 from Joel Sherrill --- I managed to narrow down the commit that broke this. RTEMS has some functions to support libatomic in libatomic/config/rtems. What tiny bit of magic are we missing for CPUs that don't have the instruction. Help providing __atomic_test_and_set is appreciated. commit 8e6757b30d0f3f13d47d0f842801a751ba6293c2 (HEAD) Author: Hans-Peter Nilsson Date: Sat Sep 23 05:06:52 2023 +0200 __atomic_test_and_set: Fall back to library, not non-atomic code Make __atomic_test_and_set consistent with other __atomic_ and __sync_ builtins: call a matching library function instead of emitting non-atomic code when the target has no direct insn support. There's special-case code handling targetm.atomic_test_and_set_trueval != 1 trying a modified maybe_emit_sync_lock_test_and_set. Previously, if that worked but its matching emit_store_flag_force returned NULL, we'd segfault later on. Now that the caller handles NULL, gcc_assert here instead. While the referenced PR:s are ARM-specific, the issue is general. PR target/107567 PR target/109166 * builtins.cc (expand_builtin) : Handle failure from expand_builtin_atomic_test_and_set. * optabs.cc (expand_atomic_test_and_set): When all attempts fail to generate atomic code through target support, return NULL instead of emitting non-atomic code. Also, for code handling targetm.atomic_test_and_set_trueval != 1, gcc_assert result from calling emit_store_flag_force instead of returning NULL.
[Bug target/118941] New: tic6x-elf: "Error: label not at start of execute packet" when building libstdc++ for C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118941 Bug ID: 118941 Summary: tic6x-elf: "Error: label not at start of execute packet" when building libstdc++ for C++23 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: joel at gcc dot gnu.org Target Milestone: --- Building with binutils-gdb, newlib-cygwin, and gcc (25256ec1df10f2eb183e1c1ab0c890e9fdd94384) from their respective masters as of 19 February 2025 in one-tree style, a build targeting tic6x-elf fails if C++ is enabled. When built for just C, gcc reports this as the version: tic6x-elf-gcc (GCC) 15.0.1 20250219 (experimental) After enabling C++, failure output is as follows: libtool: compile: /home/joel/test-gcc/b-tic6x-elf-gcc/./gcc/xgcc -shared-libgcc -B/home/joel/test-gcc/b-tic6x-elf-gcc/./gcc -nostdinc++ -L/home/joel/test-gcc/b-tic6x-elf-gcc/tic6x-elf/libstdc++-v3/src -L/home/joel/test-gcc/b-tic6x-elf-gcc/tic6x-elf/libstdc++-v3/src/.libs -L/home/joel/test-gcc/b-tic6x-elf-gcc/tic6x-elf/libstdc++-v3/libsupc++/.libs -nostdinc -B/home/joel/test-gcc/b-tic6x-elf-gcc/tic6x-elf/newlib/ -isystem /home/joel/test-gcc/b-tic6x-elf-gcc/tic6x-elf/newlib/targ-include -isystem /home/joel/test-gcc/gcc/newlib/libc/include -B/home/joel/test-gcc/b-tic6x-elf-gcc/tic6x-elf/libgloss/tic6x -L/home/joel/test-gcc/b-tic6x-elf-gcc/tic6x-elf/libgloss/libnosys -L/home/joel/test-gcc/gcc/libgloss/tic6x -B/home/joel/test-gcc/install-tic6x/tic6x-elf/bin/ -B/home/joel/test-gcc/install-tic6x/tic6x-elf/lib/ -isystem /home/joel/test-gcc/install-tic6x/tic6x-elf/include -isystem /home/joel/test-gcc/install-tic6x/tic6x-elf/sys-include -I/home/joel/test-gcc/gcc/libstdc++-v3/../libgcc -I/home/joel/test-gcc/b-tic6x-elf-gcc/tic6x-elf/libstdc++-v3/include/tic6x-elf -I/home/joel/test-gcc/b-tic6x-elf-gcc/tic6x-elf/libstdc++-v3/include -I/home/joel/test-gcc/gcc/libstdc++-v3/libsupc++ -std=gnu++23 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=19 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=stacktrace.lo -fimplicit-templates -g -O2 -c ../../../../../gcc/libstdc++-v3/src/c++23/stacktrace.cc -o stacktrace.o /tmp/ccZup7Rw.s: Assembler messages: /tmp/ccZup7Rw.s:44: Error: label not at start of execute packet /tmp/ccZup7Rw.s:76: Error: label not at start of execute packet /tmp/ccZup7Rw.s:92: Error: label not at start of execute packet make[5]: *** [Makefile:599: stacktrace.lo] Error 1 The output from the assembler looks similar to that in 114910 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910) . This may be another instance of the same failure. But I have no idea.
[Bug target/118977] m68k mcf5282 undefined symbol __atomic_test_and_set from atomic_base.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118977 --- Comment #2 from Joel Sherrill --- In reply to Andrew Pinski from comment #1) > >And our test compiles and links fine on that. > > That is because arm has defined in the libgcc. That symbol is not in the arm-rtems libgcc.a and I do not see this symbol in > So m68k will need to defined one and I suspect it will be specific to rtems > too.
[Bug target/118977] m68k mcf5282 undefined symbol __atomic_test_and_set from atomic_base.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118977 --- Comment #3 from Joel Sherrill --- Sorry. Submitted accidentally while incomplete. (In reply to Andrew Pinski from comment #1) > >And our test compiles and links fine on that. > > That is because arm has defined __atomic_test_and_set in the libgcc. That symbol is not in the arm-rtems libgcc.a and I do not see this symbol in config/m68k/atomic-linux.c or anywhere else. > > So m68k will need to defined one and I suspect it will be specific to rtems > too. I assumed that something would need to be implemented. I just don't see an example that provides that symbol. Advice appreciated.
[Bug target/118977] New: m68k mcf5282 undefined symbol __atomic_test_and_set from atomic_base.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118977 Bug ID: 118977 Summary: m68k mcf5282 undefined symbol __atomic_test_and_set from atomic_base.h Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: joel at gcc dot gnu.org Target Milestone: --- Target m68k-rtems but likely repeatable on m68k-elf GCC version: m68k-rtems7-gcc (GCC) 14.2.0 20240801 (RTEMS 7, RSB d5d9d1a4470134ea9292514c43d6a57402564578-modified, Newlib 1b3dcfd) This is the error from compiling and linking an RTEMS C++ test that targets "-mcpu=5282". Looking at a manual for that, it appears to be "ISA A" which doesn't include a test and set instruction. : /home/joel/rtems-work/tools/7/lib/gcc/m68k-rtems7/14.2.0/include/c++/bits/atomic_base.h:226:(.text.Init+0x19a): undefined reference to `__atomic_test_and_set' collect2: error: ld returned 1 exit status Looking at the file ./libstdc++-v3/include/bits/atomic_base.h, I see a couple of calls to that method. The test is located at https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/testsuites/sptests/spcxx01/init.cc?ref_type=heads. We do have libatomic.a installed and a grep shows it has variants of __atomic_test_and_set. $ m68k-rtems7-nm -g /home/joel/rtems-work/tools/7/lib/gcc/m68k-rtems7/14.2.0/m5208/libatomic.a | grep atomic_test_and_ U __atomic_test_and_set T __atomic_test_and_set_1 T __atomic_test_and_set_2 T __atomic_test_and_set_4 T __atomic_test_and_set_8 This set of symbols matches what is in an arm-rtems version of the library. And our test compiles and links fine on that.
[Bug other/105404] Update in-tree copy of zlib to zlib-1.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404 Joel Sherrill changed: What|Removed |Added CC||joel at gcc dot gnu.org --- Comment #16 from Joel Sherrill --- Over at RTEMS.org, we have a report from a Mac user that the gcc zlib needs updating or patched to build there. We are seeing this with GCC 13 but the version looks to be the same back to at least GCC 11. Just confirming that there are GCC/RTEMS users who noticed this and asked. We are not carrying a patch for GCC to be able to build this zlib on new MacOS. Updating GCC master to have a new zlib obviously will not help avoid the need for patches in the near future. But it's a good move.
