Merge common attribute handling code between libgccjit and gcc/c-family #207
No reviewers
Labels
No labels
Compat/Breaking
Frontend/ada
Frontend/c
Frontend/c++
Frontend/rust
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
No milestone
No assignees
6 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gcc/gcc!207
Loading…
Reference in a new issue
No description provided.
Delete branch "imperio:attr-dedup"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is my third attempt at removing duplicated code between
libgccjitandgcc/c-familyand it seems like I was able to make it work with the help of @antoyo for the Makefile files in particular.So this is what I did: moving code from
gcc/c-family.ccintogcc/attr-handlers.cc, then I remove the duplicated code injit/dummy-frontend.cc. There is one exception though: since libgccjit implementation of themallocattribute is a sub-part of thegcc/c-family.ccimplementation, I created a newhandle_malloc_commonfunction which is called directly by libgccjit and called under a specific condition ingcc/c-family.cc.There are still duplicated code attributes remaining in libgccjit, but the patch is already big enough as it is so I stopped at this point.
CC: David Malcolm dmalcolm@redhat.com, josmyers@redhat.com, jit@gcc.gnu.org
Hi @imperio. This bot helps send your PR as a patch series to the mailing list.
Next steps
CC: Reviewer1 <revi.ewer@example.com>, Reviewer2 <an.other@example.com>./preview./submit.Changes since vXsection, and comment with/submitagain.See Submitting Patches and UsingForge.
Consider joining the gcc and gcc-patches mailing lists..
For real time communication, check the gcc irc channels.
Or join
#overseerson Libera Chat, particularly if this automation is not working (stay online to get replies, IRC does not save messages if people are not online).16473cc8e316abbee76a16abbee76a9e8128eca89e8128eca8e4440d96ebFinally fixed formatting (from old code mostly ^^').
e4440d96ebe6819e42a6e6819e42a6a9a4bb0893/preview
Sent patch series version 1 containing 1 patches to @imperio's email address.
Message Id of cover message is
<bmm.hkwr5r5oqi.gcc.gcc.imperio.207.1.0@forge-stage.sourceware.org>./submit
Version 1 of this pull request has been stored. It includes the following commits:
a9a4bb0893Sent patch series version 1 containing 1 patches to gcc-patches mailing list gcc-patches@gcc.gnu.org and cc'd David Malcolm dmalcolm@redhat.com, josmyers@redhat.com, jit@gcc.gnu.org.
Cover letter
The overall idea looks good to me from a libgccjit maintainer point-of-view, though I didn't painstakingly check every hunk of the move.
@jsm28 : what do you think from a C maintainer/global review POV?
ping @jsm28
The principle seems fine but the forge doesn't provide an obvious way to compare the moved code (the old version of c-attribs.cc with the new attr-handlers.cc file), and since CI is reporting conflicts with c-attribs.cc, clearly this pull request would need updating including updating the moved copy of any moved code that has changed in c-attribs.cc since work on this pull request started.
I'll take that as you globally approving the patch. Considering that it moves a lot of code around, it's very prone to bitrot. I'm fixing the merge conflict, but if another merge conflict happens before next review, I'll just wait for you to review the broken state as it's time consuming to keep up.
a9a4bb089305f10d80fdFixed merge conflict. Ping @jsm28
For the review, I can only recommend to check that the function in
attr-handlers.cchas the same code as the one removed fromc-attribs.cc. Not too sure how to make the review easier for you, though. Sorry. :-/05f10d80fdccf771b4dbThe code changes look good to me. Some of these functions will also be useful to the Rust frontend, so I'm in favor of the move and would like to see it merged.
Version 2 of this pull request has been stored. It includes the following commits:
ccf771b4dbPing @jsm28
Breaking a line after
DECL_P (in the relocatedvalidate_attr_argsis not the normal style used. Other than that reformatting, the move of C front-end code is OK. Note that I have not reviewed functions relocated from the JIT front end such ashandle_transaction_pure_attribute.Thanks! Then ping @dmalcolm :)
Thanks for the patch.
Note that
handle_transaction_pure_attributeis only used by libgccjit (c-attribs.cc useshandle_tm_attribute) so this probably shouldn't be in the shared file.The patch introduces some minor behavior changes to libgccjit for the following, but I believe only
"pure","const"and"returns_twice"are currently reachable (based onfn_attribute_to_stringin jit-playback.cc)dummy-frontend.cc can lose its definition of ATTR_EXCL after this patch (but we can defer this to a followup).
So I think this is OK from my POV, but @jsm28 might want you to drop the move of
handle_transaction_pure_attribute. Patch is probably good enough as-is if this has already been tested thoroughly (bootstrap + make check-jit; check-gcc/check-c++), given how much of a pain this is causing you. Hence marking as "approved" but note the above.ccf771b4dbb12c2494c6Moved
handle_transaction_pure_attributeback todummy-frontend.cc.Thanks for the review @dmalcolm ! I re-ran the testsuites (jit, C++ and C front-ends) and no new issue.
@ -494,3 +279,3 @@/* Handle a "transaction_pure" attribute. */static treetreePlease add back the
statichere.Done!
Version 3 of this pull request has been stored. It includes the following commits:
b12c2494c6b12c2494c66f44db8c8d@ -0,0 +204,4 @@the previous one. */const location_t curloc = input_location;const location_t prevloc = DECL_P (node[1]) ? DECL_SOURCE_LOCATION (node[1]) : curloc;The format checker doesn't error on this, but the original formatting was:
Done!
Version 4 of this pull request has been stored. It includes the following commits:
6f44db8c8d6f44db8c8d341cc1d0ccVersion 5 of this pull request has been stored. It includes the following commits:
341cc1d0cc341cc1d0cc8a16cf3552It was merged by @antoyo as commit
54df3a3d98. Closing then. Thanks everyone! I'll send follow-ups.Version 6 of this pull request has been stored. It includes the following commits:
8a16cf3552Pull Request versions:
ece564fdaaa9a4bb0893fc54ab94adccf771b4dbfc54ab94adb12c2494c6fc54ab94ad6f44db8c8dfc54ab94ad341cc1d0ccfc54ab94ad8a16cf3552In order to compare , clone this repository and run
Sent patch version 6 as a single email to gcc-patches mailing list gcc-patches@gcc.gnu.org and cc'd David Malcolm dmalcolm@redhat.com, josmyers@redhat.com, jit@gcc.gnu.org.
Cover letter
Pull request closed