Using specs in a frontend
Hi.
I've been told on IRC to use specs to achieve some of the things I want
to do in libgccjit (for instance, instead of calling
host_detect_local_cpu which doesn't exist when cross-compiling).
I've been having some issues to do so.
Can I only call do_spec in specific places?
It works OK in lang_specific_pre_link, but I get a segfault in a jit
target hook. (I guess this could again be a bug with global variables in
libgccjit)
The second issue I have is how can I extract the information I want from
the spec I evaluate?
For instance, how could I get the file found by this:
do_spec("%:find-file(lto1)")
?
do_spec only returns an int, so do I need to call some other function?
Thanks for your help.
building generic tree to compare base classes at runtime
Hello, currently working on a tiny experimental compiler optimization in the C++ frontend. Trying to compare the base classes of 2 types at runtime, then if they are equal, statically cast the second operand's type to the first and the tree should return the now-casted ptr of the second operand, otherwise the tree should return a null ptr. I read the docs on the website describing the trees, but I did not find information on comparing runtime type info. Currently I am doing: //context: build_dynamic_cast_1 (location_t loc, tree type, tree expr, tsubst_flags_t complain) ... target_type = TYPE_MAIN_VARIANT (TREE_TYPE (type)); static_type = TYPE_MAIN_VARIANT (TREE_TYPE (exprtype)); td2 = get_tinfo_decl (target_type); td2 = cp_build_addr_expr (td2, complain); td3 = get_tinfo_decl (static_type); td3 = cp_build_addr_expr (td3, complain); ... // `expr` is what this code attempts to statically cast to the type of `type`, if their base type matches up tree cast_expr = cp_convert(type, build_static_cast(loc, type, expr, complain), complain); tree cond = build2 (NE_EXPR, boolean_type_node, td2, td3); tree null_ptr = cp_convert (type, nullptr_node, complain); tree result = build3 (COND_EXPR, type, cond, null_ptr, cast_expr); result = cp_convert(type, result, complain); return build_if_nonnull(expr, result, complain); the output GIMPLE and assembly don't look anything like what I am trying to achieve though. Does anyone know how the base classes should be compared from the runtime type info, should I be doing it manually with MEM_REF instead? I was unable to find documentation on this, as well as most of the tree building functions, sorry if stupid/unclear question. This e-mail and any attachments may contain information that is confidential and proprietary and otherwise protected from disclosure. If you are not the intended recipient of this e-mail, do not read, duplicate or redistribute it by any means. Please immediately delete it and any attachments and notify the sender that you have received it by mistake. Unintended recipients are prohibited from taking action on the basis of information in this e-mail or any attachments. The DRW Companies make no representations that this e-mail or any attachments are free of computer viruses or other defects.
gcc-16-20250706 is now available
Snapshot gcc-16-20250706 is now available on https://gcc.gnu.org/pub/gcc/snapshots/16-20250706/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 16 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 2a56f3c539b782b15ee76d5752921800ccc53eef You'll find: gcc-16-20250706.tar.xz Complete GCC SHA256=07da2c20abaef3fc53e985b1c55f80492d5290ebb63ba2410a2e814996d7c3b2 SHA1=cd14cb48cd65a97df75078c9027d0886e61f6e9d Diffs from 16-20250629 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-16 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: smtgcc mid-year update
On Wed, 2 Jul 2025, Sam James wrote: Please let me know if there are additional configurations you would like me to include in the testing. We sometimes get interesting bugs, especially with UBSAN (-fsanitize=undefined), with SAVE_EXPR. PR120471 is one example and PR120837 is another. These two are FE issues though, so may not really be applicable. It might be interesting to try -fhardened occasionally (which wraps up several options that distributions build with). I think anything that introduces instrumentation (so -fprofile-generate may be another candidate, or in a sense, -fnon-call-exceptions) could be interesting. I'll add this to my testing! But it may take a few weeks, as all of these flags emit builtins and internal functions that smtgcc does not support yet... /Krister
Re: building generic tree to compare base classes at runtime
I mean I now know I cannot compare the type info in this way, but are there any already implemented functions that let you retrieve the vtable and the address of the base class vtable from a type that someone could point me to? From: Gcc on behalf of Thomas de Bock via Gcc Sent: 06 July 2025 16:46:16 To: gcc@gcc.gnu.org Subject: [ext] building generic tree to compare base classes at runtime Hello, currently working on a tiny experimental compiler optimization in the C++ frontend. Trying to compare the base classes of 2 types at runtime, then if they are equal, statically cast the second operand's type to the first and the tree should return the now-casted ptr of the second operand, otherwise the tree should return a null ptr. I read the docs on the website describing the trees, but I did not find information on comparing runtime type info. Currently I am doing: //context: build_dynamic_cast_1 (location_t loc, tree type, tree expr, tsubst_flags_t complain) ... target_type = TYPE_MAIN_VARIANT (TREE_TYPE (type)); static_type = TYPE_MAIN_VARIANT (TREE_TYPE (exprtype)); td2 = get_tinfo_decl (target_type); td2 = cp_build_addr_expr (td2, complain); td3 = get_tinfo_decl (static_type); td3 = cp_build_addr_expr (td3, complain); ... // `expr` is what this code attempts to statically cast to the type of `type`, if their base type matches up tree cast_expr = cp_convert(type, build_static_cast(loc, type, expr, complain), complain); tree cond = build2 (NE_EXPR, boolean_type_node, td2, td3); tree null_ptr = cp_convert (type, nullptr_node, complain); tree result = build3 (COND_EXPR, type, cond, null_ptr, cast_expr); result = cp_convert(type, result, complain); return build_if_nonnull(expr, result, complain); the output GIMPLE and assembly don't look anything like what I am trying to achieve though. Does anyone know how the base classes should be compared from the runtime type info, should I be doing it manually with MEM_REF instead? I was unable to find documentation on this, as well as most of the tree building functions, sorry if stupid/unclear question. This e-mail and any attachments may contain information that is confidential and proprietary and otherwise protected from disclosure. If you are not the intended recipient of this e-mail, do not read, duplicate or redistribute it by any means. Please immediately delete it and any attachments and notify the sender that you have received it by mistake. Unintended recipients are prohibited from taking action on the basis of information in this e-mail or any attachments. The DRW Companies make no representations that this e-mail or any attachments are free of computer viruses or other defects.
Re: Compiler optimization help
mean I now know I cannot compare the type info in this way, but are there any already implemented functions that let you retrieve the vtable and the address of the base class vtable from a type that someone could point me to? From: Thomas de Bock Sent: 04 July 2025 15:27:19 To: gcc@gcc.gnu.org Subject: Compiler optimization help Hello, I'm looking to contribute to the project, hoping to implement the compiler optimization specified in: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164. Would appreciate any help/tips regarding what files I should look at to start working towards implementing something like this, cheers! This e-mail and any attachments may contain information that is confidential and proprietary and otherwise protected from disclosure. If you are not the intended recipient of this e-mail, do not read, duplicate or redistribute it by any means. Please immediately delete it and any attachments and notify the sender that you have received it by mistake. Unintended recipients are prohibited from taking action on the basis of information in this e-mail or any attachments. The DRW Companies make no representations that this e-mail or any attachments are free of computer viruses or other defects.
Re: GCC 12.5 Release Candidate available from gcc.gnu.org
> On 4 Jul 2025, at 08:53, Richard Biener via Gcc wrote: > > The first release candidate for GCC 12.5 is available from > > https://gcc.gnu.org/pub/gcc/snapshots/12.5.0-RC-20250704/ > ftp://gcc.gnu.org/pub/gcc/snapshots/12.5.0-RC-20250704/ > > and shortly its mirrors. It has been generated from git commit > r12-11250-gb71ac987cd1499. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux. > Please test it and report any issues to bugzilla. > > If all goes well, we'd like to release 12.5 on Friday, Jul 11th > and close the branch. I have tested this on a range of Darwin/macOS platforms and, unfortunately, identified that I have ommitted one backport that has considerable fallout on the latest macOS + latest Xcode. The newer OS tools now emit a warning for the use of an obsolete command line option - which leads to around 13k test fails (e.g. https://gcc.gnu.org/pipermail/gcc-testresults/2025-July/852085.html) The patch that’s needed is completely Darwin-local: r14-2269-g3c776fdf1a8258 This affects Darwin23 (macOS 14/Sonoma) and later OS versions that need the newer tools. I wonder if it would be possible to apply this, since the branch will now be closed and therefore there’s no opportunity to fix it in the future. thanks Iain
