Re: Questions related to creation of libgcov.so
On 08/24/2018 04:37 PM, Michael Matz wrote: > Hi, > > On Fri, 24 Aug 2018, Martin Liška wrote: > >> If I see correctly, for libgcc has following files: >> >> /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc_eh.a >> /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc.a >> /home/marxin/bin/gcc/lib64/libgcc_s.so.1 >> /home/marxin/bin/gcc/lib64/libgcc_s.so Hello. > > And with configure option --enable-version-specific-runtime-libs ? Then it will install following files: /home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/lib64/libgcc_s.so.1 /home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/lib64/libgcc_s.so /home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc_eh.a /home/marxin/bin/gcc2/lib64/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc.a > >> where the trick is done in gcc.c in init_gcc_specs function. >> For shared version, they use -lgcc_s while for static -lgcc. > > That's orthogonal. You shouldn't need that hack with libgcov (though it > might indeed be that you need to place the .so symlink and the .a file > into the same directory). > >> That explains why I had issues with current layout that static >> version was preferred. > > No, a shared library will always be preferred by the link editor (when not > using -static) _if_ the .so symlink (not the .so.1 files) can be found in > the search dirs (either before or in the same directory as the .a file). > In this case libgcov.so needs to be placed in some directory that's > searched by default by the link editor (when called from gcc). Ok, let me send final version of the patch. I'll move that into gcc-patches ML. Martin > > > Ciao, > Michael. >
Re: Static sem_item_optimizer instance in ipa-icf pass
On 08/16/2018 02:54 PM, Florian Rommel wrote: > Hi Martin, > > >> That can definitely done better, if I see correctly only reference from >> sem_item, sem_function and sem_variable >> is in sem_item::add_type. That can be removed. > > Yes, only sem_item::add_type uses this variable. Do you think the whole > static optimizer variable should be removed? > > >> Sure, that's strange. But I can't find the reference in current trunk. >> >> Can you please update to trunk and check the remaining problematic >> references? > > Okay, I got the current trunk and I believe that this is still existent. > The problem is that the function `sem_item_optimizer::parse_funcs_and_vars` > calls `sem_function::parse` which calls `sem_function::init` which calls > `sem_function::hash_stmt` which calls `sem_item::add_type` (a static member > function) which finally uses the static `optimizer` variable. > In short: `sem_item_optimizer::parse_funcs_and_vars` finally calls > `sem_item::add_type` > I retraced this in the source code and with gdb – this is not the simplest > code so I hope I got everything right. > However, this is not a separate issue from the one above. Hello. Good, got it, thanks for clarification. I'm going to prepare a patch this week. Martin > > > Regards > > Flo >
PowerPC -mspe Removed But Still in Docs
Hi Just wanting to confirm with someone PowerPC knowledgeable that the -mspe option was indeed removed on the master and the documentation needs to be updated to reflect this. Thanks. --joel
Re: PowerPC -mspe Removed But Still in Docs
Hi Joel, On Tue, Aug 28, 2018 at 04:21:25PM -0500, Joel Sherrill wrote: > Just wanting to confirm with someone PowerPC knowledgeable that > the -mspe option was indeed removed on the master and the > documentation needs to be updated to reflect this. I don't see it listed in the PowerPC options anywhere. It is still mentioned for the powerpcspe port. Do you see something else? Segher
Re: PowerPC -mspe Removed But Still in Docs
On Tue, Aug 28, 2018, 4:54 PM Segher Boessenkool wrote: > Hi Joel, > > On Tue, Aug 28, 2018 at 04:21:25PM -0500, Joel Sherrill wrote: > > Just wanting to confirm with someone PowerPC knowledgeable that > > the -mspe option was indeed removed on the master and the > > documentation needs to be updated to reflect this. > > I don't see it listed in the PowerPC options anywhere. It is still > mentioned for the powerpcspe port. Do you see something else? > Sorry. I forgot it might be in a the PowerPC SPE section. Just saw it and the heading was off the page in info. Then grep'ed the source. Didn't look at enough context. Is dropping the -mno-spe option with gcc 8 and lower equivalent to the current gcc master? We had it in some BSPs and I don't want them to break with gcc 8. Thanks. --joel > > Segher >
Re: Trying to convert to LRA, running into an ICE (infinite reload loop)
On Mon, Aug 20, 2018 at 11:01:29AM -0600, Jeff Law wrote: > On 08/20/2018 10:50 AM, Paul Koning wrote: > > The internals manual seems to say that memory subregs are an old mechanism > > that should still work, give or take. If indeed it breaks LRA perhaps the > > documentation should be updated to say that it is an obsolete mechanism > > that no longer works and needs to be disabled. > It's definitely not something we encourage. But many of the older ports > allow them. > > Essentially we know that subreg-mem will always need reloading. We want > to expose those insns to the first scheduling pass, so we don't create > them when the port has any scheduling bits defined. Even just a dummy > "everything is one cycle" description is sufficient. > > I'm not aware of anything that says you can't do subreg-mem with LRA. > It may be the case that you're dealing with the first port that's > tripped over this. So it seems getting rid of subreg of mem does not fix the problems Paul was having. Still. Can we get rid of it completely? Is there any reason left to allow subreg of mem? Segher
Re: Trying to convert to LRA, running into an ICE (infinite reload loop)
On 08/28/2018 05:40 PM, Segher Boessenkool wrote: > On Mon, Aug 20, 2018 at 11:01:29AM -0600, Jeff Law wrote: >> On 08/20/2018 10:50 AM, Paul Koning wrote: >>> The internals manual seems to say that memory subregs are an old mechanism >>> that should still work, give or take. If indeed it breaks LRA perhaps the >>> documentation should be updated to say that it is an obsolete mechanism >>> that no longer works and needs to be disabled. >> It's definitely not something we encourage. But many of the older ports >> allow them. >> >> Essentially we know that subreg-mem will always need reloading. We want >> to expose those insns to the first scheduling pass, so we don't create >> them when the port has any scheduling bits defined. Even just a dummy >> "everything is one cycle" description is sufficient. >> >> I'm not aware of anything that says you can't do subreg-mem with LRA. >> It may be the case that you're dealing with the first port that's >> tripped over this. > > So it seems getting rid of subreg of mem does not fix the problems Paul > was having. > > Still. Can we get rid of it completely? Is there any reason left to > allow subreg of mem? Can't hurt to try. Even some of the ancient ports that likely used to exploit it (m68k) have pipeline descriptions and thus no longer depend on it in any way shape or form. I'd look favorably on a patch to kill (subreg (mem)). Make sure to update the docs at the same time. Jeff
