Linking against libgcc.a on GNU/Linux
Would it be possible to turn libgcc_s.so into a linker script that links against libgcc.a and libgcc_s.so.1, and teach g++ not to link against libgcc.a explicitly anymore? I'm suggesting this because libtool uses -nostdlib when linking shared objects in C++ mode, and does not link against -lgcc, only -lgcc_s. This causes subtle problems if GCC generates code that actually needs libgcc.a, particularly if the main program uses the same symbols and gets the hidden definitions from libgcc.a. As far as I can tell, previous attempts to dissuade libtool from using -nostdlib have failed. It is also difficult to change libtool as it is deployed in package sources. It seems to me that the GCC workaround could be rolled out quite seamlessly. Thanks, Florian
Re: GCC turns &~ into | due to undefined bit-shift without warning
On 13/03/2019 03:25, Vincent Lefevre wrote: > On 2019-03-12 21:56:59 +0100, David Brown wrote: >> I disagree. To generate an unconditional error (rejecting the program), the >> compiler would need such proof - such as by tracing execution from main(). >> But to generate a warning activated specifically by the user, there is no >> such requirement. It's fine to give a warning based on the code written, >> rather than on code that the compiler knows without doubt will be executed. > > There's already a bug about spurious warnings on shift counts: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210 > You can divide code into three groups (with the exact divisions varying by compiler switches and version): 1. Code that the compiler knows for sure will run in every execution of the program, generally because it can track the code flow from main(). 2. Code that the compiler knows will /not/ run, due to things like constant propagation, inlining, etc. 3. Code that the compiler does not know if it will run or not. Code in group 1 here is usually quite small. Code in group 2 can be large, especially with C++ header libraries, templates, etc. The compiler will often eliminate such code and avoid generating any object code. gcc used to have a warning for when it found "group 2" code and eliminated it - that warning was removed as gcc got smarter, and the false positives were overwhelming. Most code is in group 3. I would say that if the compiler finds undefined behaviour in group 1 code, it should give an unconditional error message, almost regardless of compiler switches. (Many people will disagree with me here - that's okay. Fortunately for everyone else, I am not the one who decides these things in gcc!). Certainly that is standards-condoned behaviour. To be useful to the developer, warnings have to be applied to group 3 code. That does mean a risk of false positives - some code will be group 2 (never run) though the compiler doesn't know it. I am arguing here that a warning like this should be applied to group 3 code - you are suggesting it should only apply to group 1. The bug report you linked was for code in group 2 - code that the compiler can (or should be able to) see is never run. I can see it makes sense to disable or hide warnings from such code, but it may be useful to have them anyway. I expect people to have different preferences here. (I see in that bug report, solutions are complicated because C lets you "disable" a block by writing "if (0)", and then lets you jump into it from outside with labels and goto's. Perhaps that should automatically trigger a warning saying "Your code is made of spaghetti. Any other warnings may be unreliable with many false positives and false negatives".)
Re: [RFC] split of i386.c
On Tue, 2019-03-12 at 16:08 +0100, Martin Liška wrote: > Hi. > > I've thinking about the file split about quite some time, mainly > in context of PR84402. I would like to discuss if it's fine for > maintainers of the target to make such split and into which logical > components can the file be split? > > I'm suggesting something like: > - option-related and attribute-related stuff (i386-options.c - as > seen in patch) > - built-in related functions > - expansion/gen functions - still quite of lot of functions, would > make > sense to split into: > - scalar > - vector > - prologue/epilogue, GOT, PLT, symbol emission > - misc extensions like STV, TLS, CET, retpolines, multiversioning, .. > - helpers - commonly used functions, print_reg, ix86_print_operand, > .. > > I am volunteering to make the split, hopefully early in the next > stage1. > > Thoughts? IIRC we had a policy that new C++ source files (as opposed to tests) get a .cc extension, rather than .c I'm not sure if that applies in the case of a split like this one. Dave
Re: [RFC] split of i386.c
On Tue, Mar 12, 2019 at 9:54 PM Jeff Law wrote: > > On 3/12/19 2:50 PM, Eric Gallager wrote: > > On 3/12/19, Martin Liška wrote: > >> Hi. > >> > >> I've thinking about the file split about quite some time, mainly > >> in context of PR84402. I would like to discuss if it's fine for > >> maintainers of the target to make such split and into which logical > >> components can the file be split? > >> > >> I'm suggesting something like: > >> - option-related and attribute-related stuff (i386-options.c - as seen in > >> patch) > >> - built-in related functions > >> - expansion/gen functions - still quite of lot of functions, would make > >> sense to split into: > >> - scalar > >> - vector > >> - prologue/epilogue, GOT, PLT, symbol emission > >> - misc extensions like STV, TLS, CET, retpolines, multiversioning, .. > >> - helpers - commonly used functions, print_reg, ix86_print_operand, .. > >> > >> I am volunteering to make the split, hopefully early in the next stage1. > >> > >> Thoughts? > >> > >> Thanks, > >> Martin > >> > > > > I'm not a maintainer, but just as an onlooker I highly support this > > move; i386.c is way too long as it is. 7 pieces sounds like a good > > number of new files to split it into, too. > I trust your judgment on where/how to split and fully support the goals > behind splitting. Uros is the key person you need to get on board. I'm OK with the split, the file is getting huge and I think the suggested split would be beneficial. Uros.
Re: debugging libgo failures
On 3/12/19 3:28 PM, Ian Lance Taylor wrote: On Tue, Mar 12, 2019 at 11:20 AM Aldy Hernandez wrote: I have some libgo failures which I'm pretty sure I caused (see below for details), but I can't seem to figure out how to reproduce. Before I go down the rabbit hole, is there an easy way of reproducing say: FAIL: database/sql FAIL: net/http I'm used to scouring x86_64-pc-linux-gnu/libWHATEVER/testsuite/libWHATEVER.log and gaining insight on how to manually run tests. However, there's nothing in libgo/testsuite, and libgo/libgo.log just has a summary of tests. Ideally I'd like a way of building a test (with say -fdump-tree-all), and/or sticking gdb on the resulting executable. To run a test, cd to the libgo build directly (TARGET/libgo) and run `make database/sql/check`. To see the exact commands that it runs, including how the compiler is invoked, run `make GOTESTFLAGS=--trace database/sql/check`. To leave the directory behind with the test program, run `make GOTESTFLAGS=--keep database/sql/check`. That will leave a gotest/test directory. In that directory you can run `LD_LIBRARY_PATH=../../.libs ./a.out -test.short` to run the tests. You can run specific failing tests using a -test.run option. You can of course run gdb on the program. Hope that helps. Thank you very very much. This was exactly what I needed. Bug fixed, btw :). Is this information available somewhere in our docs or wiki? It'd be incredibly useful for others I bet. Thanks. Aldy
Re: Linking against libgcc.a on GNU/Linux
On Wed, 13 Mar 2019, Florian Weimer wrote: > Would it be possible to turn libgcc_s.so into a linker script that links > against libgcc.a and libgcc_s.so.1, and teach g++ not to link against > libgcc.a explicitly anymore? It is already a linker script on platforms using t-slibgcc-libgcc in libgcc/config.host. -- Joseph S. Myers jos...@codesourcery.com
BmExl幵XOdI真jL票eVDX
gcc@gcc.gnu.org： sSQxub电、微 1 3 7 =2 4 3 2= 0 0 7 7 刘NcO jfiC 06时52分49秒
