[fork update] 2024-10-24 #3218
[fork update] 2024-10-24 #3218
Conversation
You can't just drop all upstream changes to |
|
I suppose it'd help if I wrote down how I'm doing these merges. (..., and sorry for my recent non-activity...) |
no worries Thomas! I know you've been busy and gccrs shouldn't be a priority so it's perfectly understandable :) but yes, it'd be extremely helpful if you could write down your process for these. and btw, I don't think this dropped all changes to gcc/rust - IIUC it only checked out our versions in the case of merge conflicts, which should be okay? this branch has changes that were made upstream but not merged here |
|
so do you take all commits that affect |
CohenArthur
force-pushed
the
merge-upstream-2024-10-24
branch
from
3c82c16
to
a540c15
Compare
I may have suggested this to @CohenArthur sorry. If we track upstream changes and correctly apply them, that should work (and the traffic from upstream is rather low...). Do you see other issues with this? We're using something similar (of course with some difference) for the Ada frontend. |
I think it does drop all changes. It would only drop in case of conflict if you provide a path to a conflicting file. If you give it a path, it will checkout recursively from there. |
|
I'm not sure there's an easy way to find all commits which were applied upstream but not submitted here... we need to do a better job of applying them here as soon as they come in upstream I guess. I'll try and find a list of them |
If you have the last commit upstreamed, you should be able to compare the current upstream gcc tree with the old gccrs tree. Or is it too naive? |
|
I think that would work, I was looking at all the differences between the two branches but yeah I should probably look at the differences until the last upstreamed commit |
CohenArthur
force-pushed
the
merge-upstream-2024-10-24
branch
from
a540c15
to
f387d3e
Compare
|
Alright, this is completely different now. I took all of the commits present upstream but not in GitHub, and cherry-picked them separately and fixed all the merge conflicts (by either Does that seem alright? |
sounds good, I think. Yes, the last part should be fixedup if you don't want to resolve the conflict again when sending those back in GCC.... But it means rewriting history, which is probably not a good idea. Don't know how @tschwinge handled that ? Or maybe there was no such changes? |
|
Yeah, I was thinking of rewriting our history slightly. It's only one or two commits so I'm thinking it's okay. I don't know if this is what we did as well, but it would avoid build failures upstream for these commits |
CohenArthur
force-pushed
the
merge-upstream-2024-10-24
branch
from
f387d3e
to
92a109e
Compare
|
But in order to autosquash the fixup I'd have to rebase on a veeeeeeeery old commit |
|
However, doing a |
|
Yeah, rewriting history for commits that have already |
No, I suggest to not do it in this way: the cherry-picking will cause every upstream GCC commit to get a new SHA-1 object name (Git commit ID), and therefore be "detached" from its upstream GCC commit, which is likely to cause confusion. Instead, what I've been doing, is as follows, quickly: On the GCC/Rust master branch: ..., and skip through all commits, until you note something that "requires attention" for GCC/Rust. For example, global changes that require corresponding changes, or upstream commits to Yes, that's quite a bit of work, and yes, that cannot really be automated very much. I routinely do the "note" part during my every-day catch-up with GCC upstream for my GCC work branches. (So, I have a text file with all the GCC upstream commits that potentially require attention.) I have failed, in the past several months, to execute this list... :-/ |
Ah, I guess that part I got right then, by looking at commits which touch
Hmmm... that is a lot of work indeed :< I'm not sure what we could do to make it easier/scriptable and do it more often.
No worries. Honestly, it's a huge burden that shouldn't fall on just one person - hence we should try and improve the process. This isn't something that should rely on you, or occupy a lot of your time. It's quite unfair you've had to deal with this on your own all this time!!! |
Unfortunately, I concur with there not being a better way of doing this, really. EDIT: Or, well, you could take the Go (or IIRC D) approach, where they have a README that essentially says "don't touch this, send changes to X", and I always interpreted that as a risk of any changes being clobbered on imports. |
I must mention that at AdaCore, we are using automated scripts to update several branches from upstream gcc (usually 3), do nightly builds + testsuite runs, with the same goal as Arthur: use a frontend developed on a different gcc base with latest gcc while maintaining both changes from gcc and the main dev (gccrs github). But it's true that changes from upstream to the frontend don't keep their original git rev (but everything is tracked) and there's still some manual tracking to bring changes from gcc to our internal dev branches. And it probably only works smoothly because changes to the frontend coming from upstream gcc are rare (same as gccrs) (wouldn't work for a high traffic FE, or any other central part of the compiler). |
When the callee is versioned but the caller is not, we should not inline the callee into the caller, to prevent the default version of the callee from being inlined into a not versioned caller. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_can_inline_p): Refuse to inline when callee is versioned but caller is not.
…ence-returning functions As Jakub suggested, use STRIP_REFERENCE_REF instead of doing it manually as r15-4800-geb828a1e380e7b did. gcc/cp/ChangeLog: * decl.cc (omp_declare_variant_finalize_one): Use STRIP_REFERENCE_REF instead of doing it manually.
I have been taking a look at boolean handing once more in the vectorizer.
There are two situation to consider:
1. when the boolean being created are created from comparing data inputs then
for the resulting vector boolean we need to know the vector type and the
precision. In this case, when we have an operation such as NOT on the data
element, this has to be lowered to XOR because the truncation to the vector
precision needs to be explicit.
2. when the boolean being created comes from another boolean operation, then
we don't need to lower NOT, as the precision doesn't change. We don't do
any lowering for these (as denoted in check_bool_pattern) and instead the
precision is copied from the element feeding the boolean statement during
VF analysis.
For early break gcond lowering in order to correctly handle the second scenario
above we punted the lowering of VECT_SCALAR_BOOLEAN_TYPE_P comparisons that were
already in the right shape. e.g. e != 0 where e is a boolean does not need any
lowering.
The issue however is that the statement feeding e may need to be lowered in the
case where it's a data expression.
This patch changes a bit how we do the lowering. We now always emit an
additional compare. e.g. if the input is;
if (e != 0)
where is a boolean we would punt on thi before, but now we generate
f = e != 0
if (f != 0)
We then use the same infrastructre as recog_bool to ask it to lower f, and in
doing so handle and boolean conversions that need to be lowered.
Because we now guarantee that f is an internal def we can also simplify the
SLP building code.
When e is a boolean, the precision we build for f needs to reflect the precision
of the operation feeding e. To get this value we use integer_type_for_mask the
same way recog_bool does, and if it's defined (e.g. we have a data conversions
somewhere) we pass that precision on instead. This gets us the correct VF
on the newly lowered boolean expressions.
gcc/ChangeLog:
PR tree-optimization/117176
* tree-vect-patterns.cc (vect_recog_gcond_pattern): Lower all gconds.
* tree-vect-slp.cc (vect_analyze_slp): No longer check for in vect def.
gcc/testsuite/ChangeLog:
PR tree-optimization/117176
* gcc.dg/vect/vect-early-break_130-pr117176.c: New test.
This was fixed by r12-8835-ge8d5f3a1b5a583 which surely made it latent but richi points out it was likely an instance of PR90348. -fstack-reuse continues to be a menace, so let's add the testcase. gcc/testsuite/ChangeLog: PR middle-end/90348 PR tree-optimization/106073 * gcc.dg/pr106073.c: New test.
The function body checks for f3 only ran with -mcmodel explicitly set which meant I missed a regression in my local testing of: commit b039d06 Author: Craig Blackmore <[email protected]> Date: Fri Oct 18 09:17:21 2024 -0600 [PATCH 3/7] RISC-V: Fix vector memcpy smaller LMUL generation The failure showed up in the rivos CI and it is due to f3 now using LMUL m1 instead of m8. I have reworked the test to make it more robust and maintainable. This allowed most of the special casing of command line arguments to be removed. It also fixes an issue where some targets would enable multiple versions of the function body check e.g. `-march=rv32gcv -mcmodel=medany`. Changes since v1: Added missing ChangeLog. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/cpymem-1.c: Fix and rework f3.
Fix some noise seen in "make selftest-valgrind". gcc/ChangeLog: * diagnostic.cc (diagnostic_context::finish): Delete and reset m_option_mgr. Signed-off-by: David Malcolm <[email protected]>
gcc/ChangeLog: * opts-diagnostic.cc (output_factory::handler::handler): Use std::move on name. Signed-off-by: David Malcolm <[email protected]>
This patch adds a new class lazy_diagnostic_path for use when creating rich_location instances, to allow deferring expensive computations until the path is actually used (when a diagnostic using the rich_location is emitted). gcc/ChangeLog: * Makefile.in (OBJS): Add lazy-diagnostic-path.o. * lazy-diagnostic-path.cc: New file. * lazy-diagnostic-path.h: New file. * selftest-diagnostic.cc: Include "diagnostic-format.h". (test_diagnostic_context::test_diagnostic_context): Turn off flushing for the output format's printer. * selftest-run-tests.cc (selftest::run_tests): Call selftest::lazy_diagnostic_path_cc_tests. * selftest.h (selftest::lazy_diagnostic_path_cc_tests): New decl. Signed-off-by: David Malcolm <[email protected]>
|
Updated with Thomas' method: |
git merge gcc/trunk && git checkout --ours gcc/rust libgrust