Frontend access to target-related options
Hi, I'm currently working on a Rust frontend for GCC. Rust has some language-level conditional compilation features based on the presence or lack of features in the target architecture (e.g. SSE, AVX, a static C runtime) as well as the target CPU architecture itself, target OS, and various other target-related information (such as pointer width and endianness). As such, the frontend parser requires this target-related option information to be available to it. I was wondering if there was an architecture-neutral way of accessing this data (if it is even stored). I've looked into options.h but I cannot figure out how to use it in an architecture-neutral way. Thanks, Theo
Re: Does gcc automatically lower optimization level for very large routines?
On Tue, Dec 31, 2019 at 09:25:01PM -0800, Andi Kleen wrote: > Would be useful to figure out in more details where the memory > consumption goes in your test case. > > Unfortunately gcc doesn't have a good general heap profiler, > but I usually do (if you're on Linux). Whoever causes most page > faults likely allocates most memory. > > perf record --call-graph dwarf -e page-faults gcc ... > perf report --no-children --percent-limit 5 --stdio > file.txt > > and post file.txt into a bug in bugzilla. There also is the last column of -ftime-report (amount of GC memory alocated in each pass), it often is helpful. Segher
Fixing gcc git logs
In the following git log entry, I made a typo on the PR number in the libgfortran ChangeLog file. I noticed this right after the git commit, while editing the git log. So I quit the edit without saving and git reported that the commit was aborted. Then I edited the my local ChangeLog file, did git add . and git commit again. In this case the git log edit started as usual and I recopied the correct text into my editor (VI) and saved it. The commit proceeded as I expected. Then I did the git svn dcommit Well the git log ended up like this. How to fix? How to avoid? The 90274 should have been 90374. The actual committed files are OK. Regards, Jerry commit 86e1d9f75bae096922664755d037f2a9d85e2a24 (HEAD -> trunk, svn/trunk, origin/trunk, origin/master) Author: jvdelisle Date: Thu Jan 2 00:57:31 2020 + PR 90374 d0.d, e0.d, es0.d, en0.d, g0.d and ew.d edit descriptors. PR libfortran/90274 * io/format.c (parse_format_list): Implement the E0 exponent width to provide smallest possible width for exponent fields. Refactor code for correct parsing and better readability of the code. * io/io.h (write_real_w0): Change interface to pass in pointer to fnode. * io/transfer.c: Update all calls to write_real_w0 to use the new interface. * io/write.c ((write_real_w0): Use the new interface with fnode to access both the decimal precision and exponent widths used in build_float_string. * io/write_float.def (build_float_string): Use the passed in exponent width to calculate the used width in the case of E0. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@279828 138bc75d-0d04-0410-961f-82ee72b054a4
Re: Proposal for the transition timetable for the move to GIT
On Dec 30, 2019, "Richard Earnshaw (lists)" wrote: > Right, (and wrong). You have to understand how the release branches and > tags are represented in CVS to understand why the SVN conversion is done > this way. I'm curious and ignorant, is the convoluted representation that Maxim described what SVN normally uses for tree copies, that any conversion tool from SVN to GIT thus ought to be able to figure out, or is it just an unusual artifact of the conversion from CVS to SVN, that we'd like to fix in the conversion from SVN to GIT with some specialized recovery for such errors in repos poorly converted from CVS? Thanks in advance for cluing me in, -- Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo Free Software Evangelist Stallman was right, but he's left :( GNU Toolchain EngineerFSMatrix: It was he who freed the first of us FSF & FSFLA board memberThe Savior shall return (true);
