Re: 'TREE_READONLY' for 'const' array in C vs. C++
On Tue, Apr 1, 2025 at 12:04 AM Thomas Schwinge wrote:
>
> Hi!
>
> In Nvidia PTX, "A state space is a storage area with particular
> characteristics. All variables reside in some state space. [...]".
> These include:
>
> .const Shared, read-only memory.
> .global Global memory, shared by all threads.
>
> Implemented via 'TARGET_ENCODE_SECTION_INFO', GCC/nvptx then uses
> special-cased instructions for accessing the respective memory regions.
>
> Now, given a 'const' array (with whatever element type; not interesting
> here), like:
>
> extern int * const arr[];
>
> ..., for GCC/C compilation, we access this as '.const' memory: GCC/nvptx
> 'DATA_AREA_CONST', but for GCC/C++ compilation, we access it as
> 'DATA_AREA_GLOBAL', and then fault at run time due to mismatch with the
> definition, which actually is '.const' for both C and C++ compilation.
>
> The difference is, when we get to 'TARGET_ENCODE_SECTION_INFO', that for
> C we've got 'TREE_READONLY(decl)', but for C++ we don't.
In C++ there could be runtime initializers for a const qualified
object. I think all
you need to do is make sure the logic that places the object in .const
vs. .global
is consistent with the logic deciding how to access it.
You could look at the symtab entry for a decl, there's the get_section
() method,
but I'm not sure we are adjusting this for all objects, it might be
just used for
comdats.
Richard.
>
> C:
>
> Breakpoint 3, nvptx_encode_section_info (decl=0x77824720,
> rtl=0x77843180, first=1) at ../../source-gcc/gcc/config/nvptx/nvptx.cc:468
> 468 {
> (gdb) call debug_tree(decl)
> type type 0x776fa5e8 int>
> readonly unsigned DI
> size
> unit-size
> align:64 warn_if_not_align:0 symtab:0 alias-set -1
> canonical-type 0x777f7d20>
> BLK
> align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x777f7f18>
> readonly used public external read BLK
> source-gcc/gcc/testsuite/gcc.target/nvptx/const-1-2.c:8:20
> align:64 warn_if_not_align:0 context 0x7783a100 source-gcc/gcc/testsuite/gcc.target/nvptx/const-1-2.c>
> (mem/u/c:BLK (symbol_ref:DI ("arr") ) [1
> arr+0 A64]) chain >
>
> Note 'readonly' ('TREE_READONLY') in the third-last line,
> and '/u' (RTL 'MEM_READONLY_P') in the last line.
>
> C++:
>
> Breakpoint 3, nvptx_encode_section_info (decl=0x7783fa18,
> rtl=0x77844a50, first=1) at ../../source-gcc/gcc/config/nvptx/nvptx.cc:468
> 468 {
> (gdb) call debug_tree(decl)
> type type 0x777015e8 int>
> readonly unsigned type_6 DI
> size
> unit-size
> align:64 warn_if_not_align:0 symtab:0 alias-set -1
> canonical-type 0x7782fe70>
> type_6 BLK
> align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x7782f738>
> used public external read decl_2 BLK
> source-gcc/gcc/testsuite/g++.target/nvptx/const-1-2.C:14:20
> align:64 warn_if_not_align:0 context 0x776fe000 source-gcc/gcc/testsuite/g++.target/nvptx/const-1-2.C>
> (mem/c:BLK (symbol_ref:DI ("arr") ) [1
> arr+0 A64]) chain >
>
> Note no 'readonly' ('!TREE_READONLY') in the third-last line,
> and no '/u' (RTL '!MEM_READONLY_P') in the last line.
>
> Is this difference expected?
>
>
> Now, for example, in 'gcc/config/avr/avr.cc', I found code like:
>
> tree node0 = node;
>
> /* For C++, we have to peel arrays in order to get correct
>determination of readonlyness. */
>
> do
> node0 = TREE_TYPE (node0);
> while (TREE_CODE (node0) == ARRAY_TYPE);
>
> if (error_mark_node == node0)
> return;
>
> [...]
>
> if (!TYPE_READONLY (node0)
> && !TREE_READONLY (node))
> {
>
> That is, in our case, instead of just looking at 'TREE_READONLY (node)',
> we need:
>
> if (TREE_READONLY (node) || TYPE_READONLY (node0))
> [DATA_AREA_CONST]
> else
> [DATA_AREA_GLOBAL]
>
> Is this indeed what we have to do? (It would appear to work in the case
> analyzed above, but I've not yet checked for other fallout.)
>
>
> Grüße
> Thomas
Re: GSoC mandatory step error
Hello, On Mon, Mar 31 2025, Leul Abiy via Gcc wrote: > Dear Sir/Madam, > > I just wanted to ask about the build of gcc. I know it is a required step > before applying to GCC for the GSoC 2025. However, I get an error. > > Here is the error: > > /home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/./prev-gcc/xg++ > -B/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/./prev-gcc/ > -B/home/stoplight/GitProjects/install_dir/x86_64-pc-linux-gnu/bin/ > -nostdinc++ > -B/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs > -B/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs > > -I/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu > > -I/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/prev-x86_64-pc-linux-gnu/libstdc++-v3/include > -I/home/stoplight/GitProjects/GCC-PROJECT/gcc/libstdc++-v3/libsupc++ > -L/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs > -L/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs > -fno-PIE -c -O -fno-checking -gtoggle -DIN_GCC-fno-exceptions > -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-error=narrowing > -Wwrite-strings -Wcast-qual -Wmissing-format-attribute > -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long > -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H > -fno-PIE -I. -I. -I../../../gcc -I../../../gcc/. -I../../../gcc/../include > -I../../../gcc/../libcpp/include -I../../../gcc/../libcody > -I../../../gcc/../libdecnumber -I../../../gcc/../libdecnumber/bid > -I../libdecnumber -I../../../gcc/../libbacktrace -o tree-tailcall.o -MT > tree-tailcall.o -MMD -MP -MF ./.deps/tree-tailcall.TPo > ../../../gcc/tree-tailcall.cc > ../../../gcc/tree-tailcall.cc: In function ‘void > find_tail_calls(basic_block, tailcall**, bool, bool&, bool)’: > ../../../gcc/tree-tailcall.cc:612:27: error: ‘stmt’ may be used > uninitialized [-Werror=maybe-uninitialized] > 612 | if ((stmt_could_throw_p (cfun, stmt) > |~~~^~~~ > ../../../gcc/tree-tailcall.cc:480:11: note: ‘stmt’ was declared here > 480 | gimple *stmt; > | ^~~~ > cc1plus: all warnings being treated as errors > make[3]: *** [Makefile:1210: tree-tailcall.o] Error 1 > make[3]: Leaving directory > '/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/gcc' > make[2]: *** [Makefile:5116: all-stage2-gcc] Error 2 > make[2]: Leaving directory > '/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object' > make[1]: *** [Makefile:25506: stage2-bubble] Error 2 > make[1]: Leaving directory > '/home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object' > make: *** [Makefile:25718: bootstrap] Error 2 > > ChatGPT doesn't seem to be able to fix it. Heh, good I'm still somewhat useful :-) The simple fix is to initialize the variable to nullptr in the source, of course. :-) > > I used this command for configure: ../../configure > --prefix=$HOME/GCC-Project/install_dir --enable-languages=c,c++. I did this > in a build/object folder in gcc folder. THe prefix is outside of the gcc > folder. THen I ran make BOOT_CFLAGS='-O' bootstrap. I tried rerunning it > with make CFLAGS="-Wno-error=maybe-uninitialized" > CXXFLAGS="-Wno-error=maybe-uninitialized" BOOT_CFLAGS='-O' bootstrap, but > it didn't work. Please let me know what I should do next. As a quick workaround, add --disable-werror to your configure line and the problem will go away. I regularly use this option when bootstrapping in some non-default way (such as with LTO). In the long run, if the problem persists when using the default compilation flags (which I assume is not the case), you'll have to fix it in order to be able to test your patches, even if it means modifying the code causing the problem upstream. But don't worry about it at this stage. By the way, why do you bootstrap with -O1? If you want a build suitable for developing, make sure you disable bootstrap instead. (Hint: Subsequent rebuilds of files when the current directory is the gcc subdirectory then has the magic effect of building them with -O0 -g which is very nice for debugging). > I really want to work for gcc this summer. > Good luck! Martin
Re: 'TREE_READONLY' for 'const' array in C vs. C++
On Tue, Apr 01, 2025 at 09:19:08AM +0200, Richard Biener via Gcc wrote: > On Tue, Apr 1, 2025 at 12:04 AM Thomas Schwinge > wrote: > > In Nvidia PTX, "A state space is a storage area with particular > > characteristics. All variables reside in some state space. [...]". > > These include: > > > > .const Shared, read-only memory. > > .global Global memory, shared by all threads. > > > > Implemented via 'TARGET_ENCODE_SECTION_INFO', GCC/nvptx then uses > > special-cased instructions for accessing the respective memory regions. > > > > Now, given a 'const' array (with whatever element type; not interesting > > here), like: > > > > extern int * const arr[]; > > > > ..., for GCC/C compilation, we access this as '.const' memory: GCC/nvptx > > 'DATA_AREA_CONST', but for GCC/C++ compilation, we access it as > > 'DATA_AREA_GLOBAL', and then fault at run time due to mismatch with the > > definition, which actually is '.const' for both C and C++ compilation. > > > > The difference is, when we get to 'TARGET_ENCODE_SECTION_INFO', that for > > C we've got 'TREE_READONLY(decl)', but for C++ we don't. > > In C++ there could be runtime initializers for a const qualified > object. I think all > you need to do is make sure the logic that places the object in .const > vs. .global > is consistent with the logic deciding how to access it. If it is extern, then for C++ you really don't know if it will be TREE_READONLY or not, that depends on whether it has runtime initialization or not and only the TU which defines it knows that. And deriving something from TYPE_READONLY of the ARRAY_TYPE or even from strip_array_types of the type does not work, that reflects whether it is const or not, I think it will still be set even if it has mutable members and doesn't say anything about runtime initialization. Jakub
Re: Does gcc have different inlining heuristics on different platforms?
On Mon, Mar 31, 2025 at 9:15 PM Eric Botcazou wrote: > > > You can see what -fuse-linker-plugin says, what gcc/auto-host.h contains > > for HAVE_LTO_PLUGIN. I don't know whether the BFD linker (or mold) > > supports linker plugins on windows. I do know that libiberty simple-object > > does not support PE, that is, at _least_ (DWARF) debuginfo will be subpar. > > Here's an excerpt of a LTO compilation with -Wl,--verbose=2 on native Windows: > > C:/GNATPRO/25.1/bin/../lib/gcc/x86_64-w64-mingw32/13.3.1/../../../../x86_64- > w64-mingw32/bin/ld.exe: C:\tmp\ccCnskmU.o (symbol from plugin): symbol `fma' OK, so I infer from '(symbol from plugin)' that linker plugin support is there and enabled by default. That should rule out inlining differences from that end. There is of course still the thing that PE and ELF have different visibility rules and handling of what is COMDAT in ELF, dependent on the programming language (C vs. C++) this would be also expected to produce different inlining. More details can always be gathered from comparing -fopt-info-inline or in even more detail from looking at the -fdump-ipa-inline[-details] dump (both from WPA stage, so make sure to specify those options at link time). Richard. > definition: DEF, visibility: DEFAULT, resolution: PREVAILING_DEF_IRONLY > C:/GNATPRO/25.1/bin/../lib/gcc/x86_64-w64-mingw32/13.3.1/../../../../x86_64- > w64-mingw32/bin/ld.exe: C:\tmp\ccCnskmU.o (symbol from plugin): symbol `main' > definition: DEF, visibility: DEFAULT, resolution: PREVAILING_DEF > C:/GNATPRO/25.1/bin/../lib/gcc/x86_64-w64-mingw32/13.3.1/../../../../x86_64- > w64-mingw32/bin/ld.exe: C:\tmp\ccCnskmU.o (symbol from plugin): symbol > `__fpclassify' definition: UNDEF, visibility: DEFAULT, resolution: > RESOLVED_EXEC > attempt to open C:\tmp\ccbENa6D.ltrans0.ltrans.o succeeded > C:\tmp\ccbENa6D.ltrans0.ltrans.o > > This is with GNU ld. > > -- > Eric Botcazou > >
Re: [GSoC] Tooling for running BPF GCC tests on a live kernel
Hello Piyush. > I’m resending this email from my university account as my previous > message isn’t showing in the GCC mailing list archives. I’ve cc’d the > project mentors in case this email also fails to deliver. Apologies > for any duplicate notifications, and thank you for your understanding. > > -- Forwarded message - > From: Piyush Raj > Date: Tue, 1 Apr 2025 at 01:46 > Subject: [GSoC] Tooling for running BPF GCC tests on a live kernel > To: > > Hello, > I am an engineering student with experience in DevOps and SRE, > particularly in Linux automation, virtualization, and CI/CD > optimization. I do not have a formal Computer Science background, but > I learn as I go. I have built my own Linux From Scratch distro [1] and > am currently working on a container runtime in Bash [2]. I will > graduate in May 2025 and want to use my free time to work on > interesting projects. > > I am a beginner in C and eBPF, but have previously compiled a custom > kernel with eBPF support for use with Kata Containers [3]. To better > understand these eBPF and GCC architectures, I am currently studying > the Kernel BPF documentation [4] and David’s guide on GCC [5]. Sounds like a quite good background. Have you built GCC from sources? > I found "Tooling for Running BPF GCC Tests on a Live Kernel" > interesting and intend to apply for it in GSoC 2025. Thank you for your interest in working in this project in particular. It is an important task, and would greatly help the maintenance of the BPF port in the compiler. The BPF verifier is very picky and rejects a great deal of compiled valid C code. This basically means that any legit change in the compiler, such as a new optimization or even a bug fix, can potentially make it to generate non-verifiable code. Thus having a way to detect such regressions is very important. > From my research > on the current BPF development landscape: > - Only the kernel has tests against a live kernel [6], while Clang and > GCC perform compile-time tests. Correct. > - BPF CI [7] mainly tests kernel patches for regressions against the > latest GCC and LLVM snapshots, so it does not help much in catching > regressions in GCC itself. Also correct. As explained above, compiler changes can make the verifier unhappy. But so can new selftests added to the kernel that produce unveifiable code. > - Another project, little-vm-helper [8] by Cilium, also uses a > VM-based approach for BPF testing. I wasn't aware of that project. It may be a good reference, or maybe not, depending. > If there are other BPF testing projects that I should look into, > please let me know. At the past LSFMM conference someone suggested us to look at virtme-ng. Daniel Xu, a BPF kernel developer (who I added in CC) also recommended we look at https://github.com/danobi/vmtest, which he wrote. > I have a few questions and would appreciate any guidance from the > community > > 1. Are there specific BPF features or functionalities that cannot be > effectively tested in a VM environment due to virtualization? I don't think so. > 2. Should the new BPF test suite focus only on execution tests for > programs, or can we also include kernel selftests? I would focus on compiler oriented tests, exercising source constructions that have proven to generate unverifiable code. In contrast the kernel selftests focus on exercising all the supported BPF features in the kernel. The main goal of the testing shall be detecting verification regressions. > 3. The GDB simulator currently lacks full support for BPF features. > How do GCC developers typically debug the BPF programs generated by > GCC? We just look at the generated code when there are verification failures and try to determine, from the kernel verifier's output, what led to generating such code. > Would attaching a GDB debugger to the virtual machine[9] serve as an > effective debugging strategy? I don't think that is currently a possibility. AFAIK you can connect GDB to a running kernel in say qemu, and debug the kernel code. But I dont think you can debug BPF-jitted code. It is an intriguing possibility, but I think out of scope of this particular GSOC project. > Additionally, would automating this process provide significant value > to developers? I don't understand. Automating what exactly? > I'm drafting a detailed proposal and will share it soon. Thank you! :) > Thank you, > Piyush Raj > > [1] https://github.com/PiyushRaj927/LinuxFromScratch/ > [2] https://github.com/PiyushRaj927/bashpod/ > [3] https://gist.github.com/PiyushRaj927/5eb49595a82d9ca5313ae11e16593b71 > [4] https://www.kernel.org/doc/html/latest/bpf/index.html > [5] https://gcc-newbies-guide.readthedocs.io/en/latest/ > [6] https://github.com/torvalds/linux/tree/master/tools/testing/selftests/bpf > [7] https://gcc.gnu.org/pipermail/gcc/2025-January/245395.html > [8]https://github.com/cilium/little-vm-helper > [9] Debugging the BPF VM: https://youtu.be/1GSgyvn4N7E?t=
Re: 'TREE_READONLY' for 'const' array in C vs. C++
On Tue, 1 Apr 2025, Richard Biener via Gcc wrote: > In C++ there could be runtime initializers for a const qualified > object. I think all > you need to do is make sure the logic that places the object in .const > vs. .global > is consistent with the logic deciding how to access it. I think it is misguided to implicitly use PTX .const memory space for all readonly data. CUDA constant memory is a specialized memory region, limited in size (64KB) with small dedicated caches (8 KB). It is intended for data that is accessed in a uniform manner by threads. It would be more appropriate to treat it like .shared memory (exposed in nvptx via an attribute). Alexander
