"svn up" over ssh does not work
Hi, I am getting $ LANG=C svn up Updating '.': svn: E170013: Unable to connect to a repository at URL 'svn+ssh://tkoe...@gcc.gnu.org/svn/gcc/trunk' svn: E210002: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file. svn: E210002: Network connection closed unexpectedly read-only svn (without ssh) works. Anything wrong with the servers? Regards Thomas
Re: gcc generated memcpy calls symbol version
Actually, never mind, it's working fine: https://gist.github.com/wheybags/b7e4152daf76c72503e9e1f52f3dca3d and I have some other problem. On Fri, Jan 26, 2018 at 9:22 PM, H.J. Lu wrote: > On Fri, Jan 26, 2018 at 1:17 PM, Tom Mason wrote: > > I'm not entirely sure I understand that issue. From what I understand, > calls > > to a function in a shared library should always use the PLT? > > Also, I don't understand the purpose of applying hidden visibility to an > > extern symbol, > > There is no need for PLT since hidden symbol is defined locally. But > GCC ignores hidden visibility for libcalls, like memcpy. If GCC treats > them like normal calls, your scheme and my testcase should work. > > > > But anyway, doesn't matter terribly much if I understand :p > > > > On Fri, Jan 26, 2018 at 8:37 PM, H.J. Lu wrote: > >> > >> On Fri, Jan 26, 2018 at 12:29 PM, Tom Mason > wrote: > >> > Hi, > >> > I've got a project here: > >> > https://github.com/wheybags/glibc_version_header > >> > which uses .symver directives to link to a specified version of glibc, > >> > so > >> > long as it's older than the version on your system. > >> > This works, but a problem I'm having is that gcc itself will sometimes > >> > insert calls to memcpy (or memmove, memset and memcmp), as documented > >> > here: > >> > https://gcc.gnu.org/onlinedocs/gcc/Standards.html > >> > When it does so, it doesn't respect the .symver directives, and uses > the > >> > default version. > >> > Is there any way for me to force the version for these symbols aswell? > >> > I'm aware that I can disable the whole mechanism with -freestanding, > but > >> > I > >> > don't want to cripple the optimiser. > >> > >> I think this is related to: > >> > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220 > >> > >> -- > >> H.J. > > > > > > > > -- > H.J. >
Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode
Hi Andrew, > It might be worth checking what MPFR is linking with in the test suite. I > seemed to see it > linking with the system libs when built in tree, rather than the in tree > ones. that's certainly not the case on Solaris 10: unlike Solaris 11, there are no bundled gmp/mpfr/mpc present. > This seems a regression in the MPFR test suite compared with 3.1.6 It depends: without --disable-thread-safe (which is equivalent to 3.1.6), the tests PASS. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Unused GCC builtins
On 01/24/2018 07:09 AM, Jakub Jelinek wrote: On Wed, Jan 24, 2018 at 03:04:55PM +0100, Manuel Rigger wrote: In a second step, we also considered internal builtins and found that the vararg handling builtins (__builtin_va_start, __builtin_va_end, __builtin_va_arg, and __builtin_va_copy) are relied upon by many projects, even though they are undocumented in GCC's builtins API. Could they be added to the documentation? Why? What is documented is va_start/va_end/va_arg/va_copy, that is what people should use, the builtins are just internal implementation of those macros. There are a number of reasons why documenting visible APIs is helpful whether or not they are meant to be used by end users. Features that are not meant to be used should be documented as such. Mentioning that they are meant only for internal use makes their purpose clear and sets the right expectation about the level of support and portability between GCC versions. It also makes it clear that we didn't forget to document them by accident. The manual isn't just a reference for GCC users. It's also a helpful reference for developers of GCC-compatible compilers who are not allowed to read GCC source code due to copyright or licensing constraints, or for people maintaining or supporting their own GCC-based operating environments. Finally, it is also a reference for GCC developers. For all these reasons I think every built-in that can be used (intentionally or otherwise) deserves to be documented in the manual. Martin
