Re: Rust front-end
On Mon, Jun 27, 2022 at 4:52 PM Philip Herron wrote: > > Hi everyone, > > Since November 2020, I've worked full-time on the Rust front-end for > GCC, thanks to Open Source Security, Inc and Embecosm. As a result, I > am writing to this mailing list to seek feedback from the collective > experience here early to plan a path for upstreaming the front-end > into GCC. > > 1. What is the actual process of merging a prominent feature like this > upstream > - How do we review this? > - Do we create a "mega-commit" patch > - How long should we expect this review process to take > - Is there anything we can do to make this easier? Usually a new frontend is first proposed for merge and generally approved by the steering committee (which should also sort out legal issues). For the actual review process it's best to consult previous frontend merges - the most recent merged frontend was the D frontend and the modula2 frontend is in the process of being reviewed. To be able to focus on the possibly controversical pieces separating out changes to the generic GCC code base (such as driver or even middle-end) should be separated out. It would also be helpful to provide an overview of how a rust compile + link cycle works through the pieces in GCC (see the modula-2 case where that involved creating stub C++ code, compiling and linking that and how this is now done much more straight-forward). > 2. What sort of quality does the GCC community expect? > - I think it is essential that we can compile valid test cases from > a testsuite and real projects before merging. > - It seems reasonable that our error handling may not be 100% but be > expected to improve over time > - Upon merging, can features like Rust be marked as experimental Rust can be marked as experimental, sure. It would be not enabled to be built by default (and you can have a whitelist of supported targets). The most important part would be that the build works when enabled and that most of the existing testsuite passes so it can be used to regression test middle-end changes. If it is not useful at all for (basic) real-world usage then it might be not ready yet. > 3. How do GCC releases work? > - If you miss a window can we still merge code into the front-end? > - Can we merge without a borrow checker and backport this in the future? The rust frontend will not be part of the release critical pieces of the compiler (which includes the C and C++ frontends plus the set of primary and secondary targets) so it is up to the maintainers to decide what to merge and when. Release managers will generally ignore issues in Rust. > 4. What about the possibility of merging sooner rather than later, > which would help the project gain interest through the increased > visibility of it as part of the GCC family. > - Does this still allow for development churn, or will it cause friction? The parts where GCC and Rust overlap still need to be reviewed and _some_ usability for users should be provided. > 5. Does anyone have prior experience or advice they could give us? I suppose Ian (for the Go frontend) or Iain (for the D frontend) can give you hints. > For some context, my current project plan brings us to November 2022 > where we (unexpected events permitting) should be able to support > valid Rust code targeting Rustc version ~1.40 and reuse libcore, > liballoc and libstd. This date does not account for the borrow checker > feature and the proc macro crate, which we have a plan to implement, > but this will be a further six-month project. > > Regarding patch management, we currently do our development on GitHub: > https://github.com/Rust-GCC/gccrs; this means we can integrate our > issue tracking with the official Rust project by linking back to the > official Rust project's RFC issues, for example. The downside is that > when someone uses our compiler and hits an ICE, they will be directed > to the GCC Bugzilla, which is correct but can lead to a mismatch in > issue tracking. Nevertheless, I think it's essential to have the > GitHub link here to integrate with the broader Rust community. I > believe we can triage Rust issues on the Bugzilla and raise associated > ones on Github to manage this. > > From my perspective as the lead on this front-end, we are currently > under heavy development, so this means a fair amount of code churn > still, and I don't see this changing until we can successfully compile > the libcore crate later this year. Although I would love to see us > merged into GCC 13, I want to make sure this project is a success for > everyone, and this might mean pushing back to the next release window > to make sure this is manageable to produce a quality front-end to sit > alongside the others. If you want to target GCC 13 for experimental Rust support I suggest to get review on the overall design (where it touches GCC) and the changes necessary to driver and build changes. The core frontend itself will usually only get revie
can i purchase a gcc package
GCC 10.4 Released
The GNU Compiler Collection version 10.4 has been released. GCC 10.4 is a bug-fix release from the GCC 10 branch containing important fixes for regressions and serious bugs in GCC 10.3 with more than 209 bugs fixed since the previous release. This release is available from the FTP servers listed here: https://sourceware.org/pub/gcc/releases/gcc-10.4.0/ https://gcc.gnu.org/mirrors.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually!
Re: New ch_type value ELFCOMPRESS_ZSTD?
On 27 Jun 2022, Fangrui Song stated:
> I created https://groups.google.com/g/generic-abi/c/satyPkuMisk ("Add new
> ch_type value: ELFCOMPRESS_ZSTD") after I saw that on LLVM side, Cole Kissane
> proposes that we add Zstandard as new compression method (mainly for .debug*
> sections, but also for some LLVM internal things)
> https://discourse.llvm.org/t/rfc-zstandard-as-a-second-compression-method-to-llvm/63399
The next CTF format will be compressed with zstd too (if available),
fwiw. It's pretty obviously the right thing to go with these days for
anything but specialized use cases. So (though my opinion counts for
nothing) I think this is an excellent direction to go in.
(Of course, if zstd isn't folded into the binutils source tree like zlib
is, we have the interesting problem of what to do if it's not available
at build time. If zstd compression is optional, and not available in the
existing binutils, and gdb or objdump or something needs to read a
zstd-compressed debug section, what do we do? Error out? Whatever it is
we end up doing, I'll make libctf do the same thing in the same
situation.
Pointless detail: this will hardly ever impair use of things like ld
that must keep working because ld inputs are usually compiler output,
and the CTF in there is entirely uncompressed and undeduplicated. Only
using ld -r outputs as inputs to ld would be affected, and that's a rare
use case that is usually done as part of the same build process on the
same machine, and that use case would *also* keep working whether zstd
was available or not. The only case that might be impacted is users like
GDB being asked to read zstd-compressed sections when GDB was not
compiled with zstd support, and that's the same problem we'd have if the
same binary contained DWARF debuginfo and the same GDB were asked to
read it.)
--
NULL && (void)
libgompd output test
Hello,
for this test case,
1.#include
2.#include
3.int
4.main()
5.{
6. omp_set_num_threads (5);
7. #pragma omp parallel
8.{
9. int th = omp_get_thread_num ();
10. printf ("i am thread %d\n", th);
11.}
12. return 0;
13.}
Reading symbols from a.out...
OMPD GDB support loaded
Run 'ompd init' to start debugging
(gdb) ompd init
Temporary breakpoint 1 at 0x40115a: file pro.c, line 6.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Temporary breakpoint 1, main () at pro.c:6
6 omp_set_num_threads (5);
Loaded OMPD lib successfully!
(gdb) b 10
Breakpoint 2 at 0x401198: file pro.c, line 10.
(gdb) c
Continuing.
[New Thread 0x77d45700 (LWP 116224)]
[New Thread 0x77544700 (LWP 116225)]
[New Thread 0x76d43700 (LWP 116226)]
[Switching to Thread 0x77d45700 (LWP 116224)]
Thread 2 "a.out" hit Breakpoint -14, gomp_thread_start
(xdata=0x7fffd950) at ../../../gcc/libgomp/config/linux/sem.h:46
46 *sem = value * SEM_INC;
[New Thread 0x76542700 (LWP 116227)]
[Switching to Thread 0x77544700 (LWP 116225)]
Thread 3 "a.out" hit Breakpoint -14, gomp_thread_start
(xdata=0x7fffd9d0) at ../../../gcc/libgomp/config/linux/sem.h:46
46 *sem = value * SEM_INC;
[Switching to Thread 0x76d43700 (LWP 116226)]
Thread 4 "a.out" hit Breakpoint -14, gomp_thread_start
(xdata=0x7fffda50) at ../../../gcc/libgomp/config/linux/sem.h:46
46 *sem = value * SEM_INC;
[Switching to Thread 0x76542700 (LWP 116227)]
Thread 5 "a.out" hit Breakpoint -14, gomp_thread_start
(xdata=0x7fffdad0) at ../../../gcc/libgomp/config/linux/sem.h:46
46 *sem = value * SEM_INC;
Thread 5 "a.out" hit Breakpoint 2, main._omp_fn.0 () at pro.c:10
10printf ("i am thread %d\n", th);
(gdb) bt
#0 main._omp_fn.0 () at pro.c:10
#1 0x77f9dd8e in gomp_thread_start (xdata=) at
../../../gcc/libgomp/team.c:131
#2 0x77f48609 in start_thread (arg=) at
pthread_create.c:477
#3 0x77e6d133 in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) ompd icv
Initialized ICV map successfully for checking OMP API values.
ICVName Scope Value
===
cancel var address_space 0
max task priority var address_space 0
stack size var address_space 0
debug var address_space 0
OMP_DEBUGaddress_space enabled
display affinity varaddress_space 0
affinity format var address_space level %L thread
%i affinity %A
affinity format len var address_space 0
wait policy var address_space 4294967295
num teams var address_space 0
teams thread limit var address_space 0
spin count var address_space 30
num proc varaddress_space 8
throttled spin count varaddress_space 100
managed threads var address_space 5
END
the output of icv is for global icvs and environment variables are set.
The output may be mangled by the mailer.
How is this output?
The thread_handle patch is ready and will be under review today.
