Re: Question about symtab_node::order during LTO
On Tue, Oct 12, 2021 at 8:58 PM Erick Ochoa via Gcc wrote: > > Hi, > > I have an LTO pass which stores information collected during "generate > function summary" in a map which is symtab_node* -> data*. I know that > the symtab_node*s are encoded by an lto encoder and can be decoded > back during the "read function summary". I also am aware that other > optimizations might be removing or adding cgraph_node*s to the program > and my pass uses the insertion and removal hooks to analyze or drop > these accordingly. However, I am confused about different function > versions. My current understanding is that different versions of the > same function share the same cgraph_node*. Is this correct? No, they have a different cgraph_node. > If that's the case, that would mean that storing information on a map > where the key is the symtab_node* is probably not a good idea as a > specific version of the function might be dropped and in that case I > may be dropping information for all cases. > > This brings me to the field "order" in symtab_node. Is this field > constant through the linking process and can it be used to > differentiate between different versions of the same function? > > Thanks!
environment register / ABI
Hi all, does anybody know if all architectures support passing an environment pointer in their function call ABI? Are the some where this does not exist? Is there are table somewhere which lists the register (or stack slot) used for this for all architectures? Somehow I could not find this information easily. One could assemble this going through all the ports, but maybe it exists somewhere already. Best Martin
Re: Seeking help for contributions and joining open-source community
Hello, On Wed, Oct 13 2021, Vaibhav Malik via Gcc wrote: > Hey! > > I am an electrical engineering student. I came across the GNU octave a few > months back and I want to contribute to improving the existing open-source > projects and be part of the community. > > I would appreciate it if someone could help me set up and guide me about > what should I learn to get started. > > Could someone help me out? I am afraid you have reached a wrong mailing list. This one is about development of GNU Compiler Collection (GCC), not GNU Octave. In order to learn how to get involved in Octave development, have a look at: https://www.gnu.org/software/octave/get-involved Good luck, Martin
Re: Seeking help for contributions and joining open-source community
Thank you for letting me know. On Wed, 13 Oct 2021, 17:00 Martin Jambor, wrote: > Hello, > > On Wed, Oct 13 2021, Vaibhav Malik via Gcc wrote: > > Hey! > > > > I am an electrical engineering student. I came across the GNU octave a > few > > months back and I want to contribute to improving the existing > open-source > > projects and be part of the community. > > > > I would appreciate it if someone could help me set up and guide me about > > what should I learn to get started. > > > > Could someone help me out? > > I am afraid you have reached a wrong mailing list. This one is about > development of GNU Compiler Collection (GCC), not GNU Octave. > > In order to learn how to get involved in Octave development, have a look > at: > > https://www.gnu.org/software/octave/get-involved > > Good luck, > > Martin >
Re: environment register / ABI
Hello, On Wed, 13 Oct 2021, Martin Uecker wrote: > does anybody know if all architectures support passing > an environment pointer in their function call ABI? Define "environment pointer". I can imagine two things you could mean: the custom to pass envp as third argument to main() in hosted C programs: int main (int argc, char *argv[], char *envp[]); but then this is specific to main and more a question of process initialization than function call ABI. If you mean this the answer will most often be: if envp is passed to main (a question of the operating system or runtime environment, e.g. if there's something like an environment in the getenv() sense to start with), then it is passed like any other third argument of pointer type on the psABI in question, and that definition would be independend of the psABI. Or you could mean what normally would be called 'static chain', i.e. a pointer to the stack frame of outer functions for languages supporting nested functions. I could imagine this also be called environment. If you mean that, then it's indeed psABI specific, and possibly not all ABIs specify it (in which case GCC will probably have set a de-facto standard at least for unixy systems). The x86-64 psABI for instance does specify a register for this, which is separate from the normal argument passing registers. Other psABIs could say that it's passed like a hidden argument prepended to the formal list of args. Or do you mean something else entirely? It might also help to know the purpose of your question :) Ciao, Michael.
Re: environment register / ABI
Am Mittwoch, dem 13.10.2021 um 15:21 + schrieb Michael Matz: > Hello, > > On Wed, 13 Oct 2021, Martin Uecker wrote: > > > does anybody know if all architectures support passing > > an environment pointer in their function call ABI? > ... > > Or you could mean what normally would be called 'static chain', i.e. > a pointer to the stack frame of outer functions for languages > supporting nested functions. I could imagine this also be called > environment. Yes, sorry for not being clear. It is sometimes called environment pointer. > If you mean that, then it's indeed psABI specific, and possibly not > al ABIs specify it (in which case GCC will probably have set a de- > facto standard at least for unixy systems). The x86-64 psABI for > instance does specify a register for this, which is separate from > the normal argument passing registers. Other psABIs could say that > it's passed like a hidden argument prepended to the formal list of > args. > Yes, most architecture seem to define a register. I am wondering if there is a table or summary somewhere. > Or do you mean something else entirely? It might also help to know > the purpose of your question :) > There is currently no standard way to set or query the static chain from C although this is used by many other languages. Also function pointers in C usually can not store the static chain. I am going to propose to WG14 to add some kind of wide function pointer to address this. I am doing back ground research to understand whether this exists everywhere. Martin
Re: environment register / ABI
On Wed, 13 Oct 2021, Martin Uecker wrote: > There is currently no standard way to set or query > the static chain from C although this is used by > many other languages. Also function pointers in C > usually can not store the static chain. I am going > to propose to WG14 to add some kind of wide function > pointer to address this. I am doing back ground > research to understand whether this exists everywhere. This doesn't answer your actual question, but: Following discussions of atomics at the last WG14 meeting, I raised the question on the WG14 reflector (and C++ liaison list) of whether it would be useful to have a public list of C-relevant ABIs and their maintainer contacts and ABI-relevant new features in C language versions. I was thinking of such a list as being to help people do due diligence after making ABI-relevant C standard changes (contacting the main ABI maintainers to get them to add ABI specification for the new features) and to help ABI maintainers track new features for which they need to update their ABIs. But such a list could equally be relevant for such research as you mention above in advance of proposing a new feature. There weren't any replies to my message from anyone actually saying they'd find such a list useful. If you think such a list would be useful (for the community of people dealing with maintaining ABIs or ABI implementations or specifying new language features needing corresponding ABIs), then I'd encourage replying to my reflector message of 2 September to say so. Message of 2 September below, for reference of readers not on the WG14 reflector or C++ liaison list: == To expand on something I mentioned in the atomics discussion in today's WG14 meeting: When new ABI-relevant features have been added to C, the community of people involved in C implementations hasn't always done well at updating relevant ABIs to achieve consistency between implementations for those new features (where those implementations aim to allow mixing code built with different implementations for the same architecture/OS - this isn't relevant for all C implementations). Atomics are just one example where the ABI issues are more complicated than usual, and where actual incompatibilities have arisen between implementations as well as between C and C++. Should there be some maintained public list of C-relevant ABI documents (mainly, not entirely, psABI documents for various architectures), and of where they are maintained (if they are) / who the maintainer contacts are? What about lists of ABI-relevant new features in different C versions that ABIs may need to be updated for (and, for that matter, common extensions it may be helpful to consider in ABIs), or some mailing list or other location to help psABI maintainers (and other relevant ABI maintainers - for example, new features often need to be handled by debug info formats such as DWARF as well) track new features they need to pay attention to? Or guidance on issues to consider when writing a psABI document? Do such lists already exist somewhere? As an example of the sort of thing I might hope to find in such a list of ABI documents / contacts: * x86-64: PDFs https://gitlab.com/x86-psABIs/x86-64-ABI/-/wikis/x86-64-psABI repository https://gitlab.com/x86-psABIs/x86-64-ABI mailing list https://groups.google.com/g/x86-64-abi * i386: PDFs https://gitlab.com/x86-psABIs/i386-ABI/-/wikis/Intel386-psABI repository https://gitlab.com/x86-psABIs/i386-ABI/-/tree/hjl/x86/master mailing list https://groups.google.com/g/ia32-abi * Arm and AArch64: PDFs https://github.com/ARM-software/abi-aa/releases repository https://github.com/ARM-software/abi-aa * RISC-V: PDFs https://github.com/riscv/riscv-elf-psabi-doc/releases repository https://github.com/riscv/riscv-elf-psabi-doc (but hopefully covering more architectures than that). -- Joseph S. Myers jos...@codesourcery.com
Question about semantics of cgraph_node::prevailing_p
Hi, My current understanding of LTO is that the callgraph is very dynamic (i.e., optimizations might add or remove cgraph_nodes). A while back I encountered an issue where I couldn't print the cgraph_node::name of a function during the execute stage in LTO. I found that the only thing different was that these cgraph_nodes had a prevailing_p () returning false. There's only a few other places in the GCC sources that look at prevailing_p (ipa-fnsummary.c and ipa-prop.c) and both of them seem to drop information if the cgraph_node is not prevailing. I took this as guidance and in my optimization I dropped information from non-prevailing cgraph_nodes. (I figured out it must be something similar to the remove cgraph_hooks.) However, I am now revisiting whether this interpretation was correct or not. Can someone tell me what does cgraph_node::prevailing_p actually means? Also, is there a way to code an LTO test where a specific cgraph_node's prevailing_p returns false? That way I could probably verify the correctness of my analysis in the presence of non-prevailing_p cgraph_nodes. Thanks!
Error for unknown spec function 'dumps' when compiling GCC 11.X
Dear GCC community, when I try to compile a 11 Version of GCC I get while compiling in the directory …./gcc-11.2.0/host-x86_64-pc-linux-gnu/gcc the following: x86_64-pc-linux-gnu-g++ -std=c++11 -fno-PIE ….. ../.././gcc/cp/g++spec.c error occurs: x86_64-pc-linux-gnu-g++: fatal error: unknown spec function 'dumps' compilation terminated. I looked into the spec-file in that directory. There is the entry: *cpp_debug_options: %
