gcc/gcc-TEST
gcc/gcc-TEST
18
Fork 33
forked from gcc/gcc-mirror
Code Issues Pull requests 33 Wiki Activity Actions

libgccjit: Add a function to check if LTO is supported #103

Open
antoyo wants to merge 1 commit from antoyo/gcc:gccjit/detect-lto into trunk
pull from: antoyo/gcc:gccjit/detect-lto
merge into: gcc:trunk
Conversation 11 Commits 1 Files changed 6 +51
antoyo commented 2025-10-14 19:00:34 +00:00
Member
Copy link
gcc/jit/ChangeLog:

	* Make-lang.in: Define new variables.
	* docs/topics/compatibility.rst (LIBGCCJIT_ABI_36): New ABI tag.
	* docs/topics/compilation.rst: Document gcc_jit_is_lto_supported.
	* libgccjit.cc (gcc_jit_is_lto_supported): New function.
	* libgccjit.h (gcc_jit_is_lto_supported): New function.
	* libgccjit.map (LIBGCCJIT_ABI_36): New ABI tag.

CC: David Malcolm dmalcolm@redhat.com, jit@gcc.gnu.org

``` gcc/jit/ChangeLog: * Make-lang.in: Define new variables. * docs/topics/compatibility.rst (LIBGCCJIT_ABI_36): New ABI tag. * docs/topics/compilation.rst: Document gcc_jit_is_lto_supported. * libgccjit.cc (gcc_jit_is_lto_supported): New function. * libgccjit.h (gcc_jit_is_lto_supported): New function. * libgccjit.map (LIBGCCJIT_ABI_36): New ABI tag. ``` CC: David Malcolm <dmalcolm@redhat.com>, <jit@gcc.gnu.org> 
gcc/jit/ChangeLog:

	* Make-lang.in: Define new variables.
	* docs/topics/compatibility.rst (LIBGCCJIT_ABI_36): New ABI tag.
	* docs/topics/compilation.rst: Document gcc_jit_is_lto_supported.
	* libgccjit.cc (gcc_jit_is_lto_supported): New function.
	* libgccjit.h (gcc_jit_is_lto_supported): New function.
	* libgccjit.map (LIBGCCJIT_ABI_36): New ABI tag.
forge-bot commented 2025-10-14 19:00:53 +00:00
Member
Copy link

Welcome to Sourceware Forge

Hi @antoyo, and thanks for your PR. This bot helps you send your patch series to the mailing list.

Please follow these guidelines to ensure a smooth submission.

Writing a Good PR Description

  • If your PR has multiple commits, write a meaningful description. It becomes the cover letter.
  • For a single commit, you can leave the description empty if the commit message is clear.

To CC reviewers, add at the end of your PR description one or more lines like this:

CC: Revi Ewer <revi.ewer@example.com>, Ill Takalook <ill.takalook@example.net>

Avoid copy-pasting a CC list from a previous PR. Doing so may cause failure to send the emails properly.

We recommend reviewing your commit messages carefully before submitting.

This project expects a specific format.
See Submitting Patches for details

Submitting Your Patch

To submit, you must be authorized. Ask any permitted contributor to authorize you by commenting: /allow. This is anyone who has been /allowed before.

Once allowed, comment: /submit

Use /preview to see the emails before sending. (Requires a public forge email.)

Responding to Reviews

Watch for replies on the mailing list. If not subscribed, you can reply by:

  1. Visiting inbox.sourceware.org
  2. Clicking (raw) on the email
  3. Importing it into your mail client

For Gmail:

curl -g --user "<Email>:<Password>" \
  --url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txt

Updating Your PR

  1. Push new commits, rebase and force push changes to the same branch as needed
  2. Update the PR description with a “Changes since vX” section
  3. Comment again with: /submit

Need help?

Consider joining the gcc and gcc-patches mailing lists..
For real time communication, check the gcc irc channels.

Or join #overseers on Libera Chat, particularly if this automation is not working (stay online to get replies, IRC does not save messages if people are not online).

<!-- pr-welcome --> # Welcome to Sourceware Forge Hi @antoyo, and thanks for your PR. This bot helps you send your patch series to the mailing list. Please follow these guidelines to ensure a smooth submission. ## Writing a Good PR Description - If your PR has **multiple commits**, write a meaningful description. It becomes the cover letter. - For **a single commit**, you can leave the description empty if the commit message is clear. To CC reviewers, add at the end of your PR description one or more lines like this: ```text CC: Revi Ewer <revi.ewer@example.com>, Ill Takalook <ill.takalook@example.net> ``` Avoid copy-pasting a CC list from a previous PR. Doing so may cause failure to send the emails properly. We recommend reviewing your commit messages carefully before submitting. This project expects a specific format. See [Submitting Patches](https://gcc.gnu.org/contribute.html#patches) for details ## Submitting Your Patch To submit, you must be authorized. Ask any permitted contributor to authorize you by commenting: `/allow`. This is anyone who has been `/allow`ed before. Once allowed, comment: `/submit` Use `/preview` to see the emails before sending. (Requires a public forge email.) ## Responding to Reviews Watch for replies on the mailing list. If not subscribed, you can reply by: 1. Visiting [inbox.sourceware.org](https://inbox.sourceware.org) 2. Clicking `(raw)` on the email 3. Importing it into your mail client For Gmail: ```sh curl -g --user "<Email>:<Password>" \ --url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txt ``` ## Updating Your PR 1. Push new commits, rebase and force push changes to the same branch as needed 2. Update the PR description with a “Changes since vX” section 3. Comment again with: `/submit` ## Need help? Consider joining the [gcc and gcc-patches mailing lists.](https://gcc.gnu.org/lists.html). For real time communication, check the [gcc irc channels](https://gcc.gnu.org/wiki/GCConIRC). Or join [`#overseers`](https://web.libera.chat/#overseers) on Libera Chat, particularly if this automation is not working (stay online to get replies, IRC does not save messages if people are not online).
antoyo reviewed 2025-10-14 19:02:48 +00:00
gcc/jit/Make-lang.in
@ -130,6 +130,10 @@ jit.serial = $(LIBGCCJIT_FILENAME)
# Tell GNU make to ignore these if they exist.
.PHONY: jit
CFLAGS-jit/libgccjit.o += -DDEFAULT_TARGET_VERSION=\"$(version)\" \
antoyo commented 2025-10-14 19:02:48 +00:00
Author
Member
Copy link

This is a .in file, but I was unable to regenerate the file.
Am I doing something wrong or do the Make-lang.in files need not being regenerated?

This is a `.in` file, but I was unable to regenerate the file. Am I doing something wrong or do the `Make-lang.in` files need not being regenerated?
sjames commented 2025-10-14 19:30:14 +00:00
Member
Copy link

I don't think you need to regenerate anything after changing them indeed. You can verify it by running the autoregen.py script from https://sourceware.org/cgit/builder.

I don't think you need to regenerate anything after changing them indeed. You can verify it by running the `autoregen.py` script from https://sourceware.org/cgit/builder.
antoyo commented 2025-10-14 19:03:06 +00:00
Author
Member
Copy link

I'm not sure how to add a test for this.

I'm not sure how to add a test for this.
antoyo commented 2025-10-14 19:05:17 +00:00
Author
Member
Copy link

/submit

/submit
forge-bot commented 2025-10-14 19:05:45 +00:00
Member
Copy link

Version 1 of this pull request has been stored. It includes the following commits:

  • libgccjit: Add a function to check if LTO is supported - da9ff55248
<!-- pr-new-version --> Version 1 of this pull request has been stored. It includes the following commits: - libgccjit: Add a function to check if LTO is supported - da9ff55248bd9f945223bf254d42af2049863f06
forge-bot commented 2025-10-14 19:05:46 +00:00
Member
Copy link

Pull Request versions:

# Base Head
1 97da8fece1 da9ff55248 (diff)

In order to compare , clone this repository and run

PR=103
git fetch origin "refs/versioned_pull/${PR}/*:refs/versioned_pull/${PR}/*"
PRV1=1
PRV2=2
git range-diff "refs/versioned_pull/${PR}/${PRV1}/base..refs/versioned_pull/${PR}/${PRV1}/head"  "refs/versioned_pull/${PR}/${PRV2}/base..refs/versioned_pull/${PR}/${PRV2}/head"
<!-- pr-versions --> Pull Request versions: | # | Base | Head | | | - | ---- | ---- | - | | 1 | 97da8fece19caf0277c2be523520d09252821973 | da9ff55248bd9f945223bf254d42af2049863f06 | [(diff)](https://forge.sourceware.org/gcc/gcc-TEST.git/compare/97da8fece19caf0277c2be523520d09252821973...da9ff55248bd9f945223bf254d42af2049863f06) | In order to compare , clone this repository and run ``` PR=103 git fetch origin "refs/versioned_pull/${PR}/*:refs/versioned_pull/${PR}/*" PRV1=1 PRV2=2 git range-diff "refs/versioned_pull/${PR}/${PRV1}/base..refs/versioned_pull/${PR}/${PRV1}/head" "refs/versioned_pull/${PR}/${PRV2}/base..refs/versioned_pull/${PR}/${PRV2}/head" ```
forge-bot commented 2025-10-14 19:06:18 +00:00
Member
Copy link

Sent patch series version 1 containing 1 patches to gcc-patches mailing list test-list@sourceware.org and cc'd David Malcolm dmalcolm@redhat.com, jit@gcc.gnu.org.
Cover letter

Sent patch series version 1 containing 1 patches to gcc-patches mailing list <test-list@sourceware.org> and cc'd David Malcolm <dmalcolm@redhat.com>, <jit@gcc.gnu.org>. [Cover letter](https://inbox.sourceware.org/test-list/176046874671.992.18142806602657506265.batrachomyomachia.gcc.gcc-TEST.103.1.0@forge-test.rdfm.org)
sjames reviewed 2025-10-14 19:30:22 +00:00
gcc/jit/libgccjit.cc
@ -4709,0 +4712,4 @@
{
#ifdef ENABLE_LTO
char lto1_path[PATH_MAX];
snprintf (lto1_path, sizeof (lto1_path), "%s%s/%s/lto1",
sjames commented 2025-10-14 19:28:41 +00:00
Member
Copy link

I'm a little bit surprised to see this -- why do you need to verify you can find lto1? Is there a scenario where you had GCC built with --enable-lto (=> ENABLE_LTO) but lto1 was missing (maybe broken packaging)?

I'm a little bit surprised to see this -- why do you need to verify you can find `lto1`? Is there a scenario where you had GCC built with `--enable-lto` (=> `ENABLE_LTO`) but `lto1` was missing (maybe broken packaging)?
antoyo commented 2025-10-14 20:10:42 +00:00
Author
Member
Copy link

I might be wrong here, but I was under the impression that we can just distribute libgccjit.so without the libexec stuff and it would just work while that would not work for gcc.
I guess we could assume that if LTO was enabled, that the lto frontend would be present, but since the LTO frontend is enabled by default, that could be error-prone.
What are your thoughts on this?

I might be wrong here, but I was under the impression that we can just distribute `libgccjit.so` without the libexec stuff and it would just work while that would not work for gcc. I guess we could assume that if LTO was enabled, that the lto frontend would be present, but since the LTO frontend is enabled by default, that could be error-prone. What are your thoughts on this?
sjames commented 2025-10-18 15:57:47 +00:00
Member
Copy link

I hadn't thought about that (i.e. people thinking it's a standalone library). I think the check is reasonable if you can imagine someone trying to do that. Just mention that as motivation in the commit message?

(Especially for the say, "CI case", where people might assume they can just grab the .so and not worry about anything else, dunno.)

I hadn't thought about that (i.e. people thinking it's a standalone library). I think the check is reasonable if you can imagine someone trying to do that. Just mention that as motivation in the commit message? (Especially for the say, "CI case", where people might assume they can just grab the .so and not worry about anything else, dunno.)
linaroci commented 2025-10-15 03:51:44 +00:00
First-time contributor
Copy link

CI state: success ✅
CI bot https://ci.linaro.org/job/tcwg_gnu_cross_build--master-arm-precommit/106/ : CI bot tcwg_gnu_cross_build--master-arm: Build results
See: https://ci.linaro.org/job/tcwg_gnu_cross_build--master-arm-precommit/106/artifact/artifacts/artifacts.precommit/notify/mail-body.txt

<!-- linaro-ci-status CI bot https://ci.linaro.org/job/tcwg_gnu_cross_build--master-arm-precommit/106/ --> CI state: success :white_check_mark: CI bot https://ci.linaro.org/job/tcwg_gnu_cross_build--master-arm-precommit/106/ : CI bot tcwg_gnu_cross_build--master-arm: Build results See: https://ci.linaro.org/job/tcwg_gnu_cross_build--master-arm-precommit/106/artifact/artifacts/artifacts.precommit/notify/mail-body.txt
linaroci commented 2025-10-26 11:08:40 +00:00
First-time contributor
Copy link

CI state: fail ❌
CI bot https://ci.linaro.org/job/tcwg_gnu_cross_build--master-aarch64-precommit/97/ : CI bot tcwg_gnu_cross_build--master-aarch64: Patch failed to apply
See: https://ci.linaro.org/job/tcwg_gnu_cross_build--master-aarch64-precommit/97/artifact/artifacts/jenkins/precommit-forge-apply.log

<!-- linaro-ci-status CI bot https://ci.linaro.org/job/tcwg_gnu_cross_build--master-aarch64-precommit/97/ --> CI state: fail :x: CI bot https://ci.linaro.org/job/tcwg_gnu_cross_build--master-aarch64-precommit/97/ : CI bot tcwg_gnu_cross_build--master-aarch64: Patch failed to apply See: https://ci.linaro.org/job/tcwg_gnu_cross_build--master-aarch64-precommit/97/artifact/artifacts/jenkins/precommit-forge-apply.log
linaroci commented 2025-10-31 19:36:05 +00:00
First-time contributor
Copy link

CI state: fail ❌
CI bot https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-arm-precommit/103/ : CI bot tcwg_gnu_cross_check_gcc--master-arm: Patch failed to apply
See: https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-arm-precommit/103/artifact/artifacts/jenkins/precommit-forge-apply.log

<!-- linaro-ci-status CI bot https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-arm-precommit/103/ --> CI state: fail :x: CI bot https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-arm-precommit/103/ : CI bot tcwg_gnu_cross_check_gcc--master-arm: Patch failed to apply See: https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-arm-precommit/103/artifact/artifacts/jenkins/precommit-forge-apply.log
This pull request has changes conflicting with the target branch.
  • gcc/jit/docs/topics/compatibility.rst
  • gcc/jit/libgccjit.h
  • gcc/jit/libgccjit.map
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u gccjit/detect-lto:antoyo-gccjit/detect-lto
git switch antoyo-gccjit/detect-lto

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch trunk
git merge --no-ff antoyo-gccjit/detect-lto
git switch antoyo-gccjit/detect-lto
git rebase trunk
git switch trunk
git merge --ff-only antoyo-gccjit/detect-lto
git switch antoyo-gccjit/detect-lto
git rebase trunk
git switch trunk
git merge --no-ff antoyo-gccjit/detect-lto
git switch trunk
git merge --squash antoyo-gccjit/detect-lto
git switch trunk
git merge --ff-only antoyo-gccjit/detect-lto
git switch trunk
git merge antoyo-gccjit/detect-lto
git push origin trunk
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
Compat/Breaking

Breaking change that won't be backward compatible

  
Frontend/ada

   
Frontend/c

   
Frontend/c++

   
General/forge

Forgejo infrastructure

  
Kind/Bug

Something is not working

  
Kind/Documentation

Documentation changes

  
Kind/Enhancement

Improve existing functionality

  
Kind/Feature

New functionality

  
Kind/Security

This is security issue

  
Kind/Testing

Issue or pull request related to testing

  
Library/libgcc

   
Library/libstdc++

   
Midend/gimple

   
Midend/rtl

   
Midend/tree
  
Priority
Critical
The priority is critical

  
Priority
High
The priority is high

  
Priority
Low
The priority is low

  
Priority
Medium
The priority is medium

  
Reviewed
Confirmed
Issue has been confirmed

  
Reviewed
Duplicate
This issue or pull request already exists

  
Reviewed
Invalid
Invalid issue

  
Reviewed
Won't Fix
This issue won't be fixed

  
Status
Abandoned
Somebody has started to work on this but abandoned work

  
Status
Blocked
Something is blocking this issue or pull request

  
Status
Need More Info
Feedback is required to reproduce issue or to continue work

  
Target/aarch64

   
Target/arm

   
Target/i386
  
bug

Something is not working

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
help wanted

Need some help

  
invalid

Something is wrong

  
question

More information is needed

  
wontfix

This won't be fixed

No labels
Compat/Breaking
Frontend/ada
Frontend/c
Frontend/c++
General/forge
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Library/libgcc
Library/libstdc++
Midend/gimple
Midend/rtl
Midend/tree
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Target/aarch64
Target/arm
Target/i386
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
gcc/gcc-TEST!103
No description provided.