Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch
On 07/30/2016 02:10 AM, Manuel López-Ibáñez wrote: > What about my suggestion of forcing GCC to use the gnulib functions by > temporarily removing the system-wide functions? Would that be > equivalent testing to building on a host that requires the libiberty > version of a function? I don't think that in general that's equivalent, because many of gnulib's replacement headers will actually #include_next the original header, and then fix some detail. Thus it's not equivalent to the original header not existing. Thanks, Pedro Alves
Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch
On 07/31/2016 11:50 PM, Manuel López-Ibáñez wrote: > Oh well, Ayush does not have access to different hosts, thus I > guess it is better that he focuses his limited time on functions that > he can test. There are plenty of functions that are both in gnulib and > libiberty but not in glibc. > My experience on the gdb side is that these kinds of patches tend to move much faster if there's confidence they got wide host testing. I'm not a gcc maintainer, but I'd suggest: - Put the patches on a public branch (e.g., a personal branch in the gcc git mirror), and point at the branch in patch submissions. A branch is easier for the occasional passerby testing than downloading a patch and then curse a bit while trying to to figure out the base revision the patch was generated against, because it no longer applies cleanly on current trunk. - Explicitly call for testing help, pointing at the branch. This makes it possible for a global maintainer to reasonable call a timeout. As in, "as we've called for testing X ago, and clearly nobody cares, let's go ahead, and fix any fall out afterwards.") - Get access to the gcc compile farm and go the extra mile of testing the patches on a couple non-GNU/Linux hosts. For example, there are AIX and NetBSD boxes there. I sometimes do this on the gdb side, and it helps much with moving things along. - Still on the extra mile theme, install cross compilers, and cross build gcc for those. For example, Fedora has a mingw-w64 toolchain in the main repo, which makes it's easy to at least cross build for Windows. Thanks, Pedro Alves
Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch
On 31 July 2016 at 23:39, Joseph Myers wrote: > On Sat, 30 Jul 2016, Manuel López-Ibáñez wrote: > >> > Building for different targets is fairly irrelevant here; the issue is >> > building for different hosts, which is harder. >> >> What about my suggestion of forcing GCC to use the gnulib functions by >> temporarily removing the system-wide functions? Would that be >> equivalent testing to building on a host that requires the libiberty >> version of a function? > > That depends on the details of how the configure tests in question work; > if they test whether calls to a function can be linked, the function will > be detected as present even if the header has been removed. True. Oh well, Ayush does not have access to different hosts, thus I guess it is better that he focuses his limited time on functions that he can test. There are plenty of functions that are both in gnulib and libiberty but not in glibc. Cheers, Manuel.
Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch
On Sat, 30 Jul 2016, Manuel López-Ibáñez wrote: > > Building for different targets is fairly irrelevant here; the issue is > > building for different hosts, which is harder. > > What about my suggestion of forcing GCC to use the gnulib functions by > temporarily removing the system-wide functions? Would that be > equivalent testing to building on a host that requires the libiberty > version of a function? That depends on the details of how the configure tests in question work; if they test whether calls to a function can be linked, the function will be detected as present even if the header has been removed. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch
On 29 July 2016 at 23:10, Joseph Myers wrote: > On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote: > >> >> GCC can run on other systems besides OSX and GNU/Linux, how can you >> >> test that your change does not break anything on those systems? >> >> >> > Well I have access to these two systems only. How would you suggest I >> > test my patches on all possible systems? >> Maybe building contrib/config-list.mk could help ? AFAIK, it will cross build >> the gcc tree for different targets, but not run the testsuite, however >> I could be wrong. > > Building for different targets is fairly irrelevant here; the issue is > building for different hosts, which is harder. What about my suggestion of forcing GCC to use the gnulib functions by temporarily removing the system-wide functions? Would that be equivalent testing to building on a host that requires the libiberty version of a function? Cheers, Manuel.
Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch
On 30 July 2016 at 03:40, Joseph Myers wrote: > On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote: > >> >> GCC can run on other systems besides OSX and GNU/Linux, how can you >> >> test that your change does not break anything on those systems? >> >> >> > Well I have access to these two systems only. How would you suggest I >> > test my patches on all possible systems? >> Maybe building contrib/config-list.mk could help ? AFAIK, it will cross build >> the gcc tree for different targets, but not run the testsuite, however >> I could be wrong. > > Building for different targets is fairly irrelevant here; the issue is > building for different hosts, which is harder. > > (It's possible there are some portability interfaces only used on > particular targets, but that's not the main use case for libiberty in > GCC.) Ah indeed, libiberty/gnulib would be built for hosts. Thanks for pointing out! Thanks, Prathamesh > > -- > Joseph S. Myers > jos...@codesourcery.com
Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch
On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote: > >> GCC can run on other systems besides OSX and GNU/Linux, how can you > >> test that your change does not break anything on those systems? > >> > > Well I have access to these two systems only. How would you suggest I > > test my patches on all possible systems? > Maybe building contrib/config-list.mk could help ? AFAIK, it will cross build > the gcc tree for different targets, but not run the testsuite, however > I could be wrong. Building for different targets is fairly irrelevant here; the issue is building for different hosts, which is harder. (It's possible there are some portability interfaces only used on particular targets, but that's not the main use case for libiberty in GCC.) -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch
On Mon, 25 Jul 2016, Manuel López-Ibáñez wrote: > Also, are the files in gnulib and libiberty semantically identical? > The wiki page does not say anything about this. How did you check > this? The question is not whether they are semantically identical, but whether moving to the gnulib version avoids regressions. That is, for functions such as fnmatch based on the same underlying code: (a) make sure that the gnulib code is based on at least as recent a version of the underlying code as the libiberty version, and (b) make sure that libiberty doesn't have any local portability / functionality fixes missing from the gnulib version. (In practice I think such regressions from the gnulib move are very unlikely.) -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch
On 26 July 2016 at 19:21, ayush goel wrote: > On 26 July 2016 at 3:38:59 AM, Manuel López-Ibáñez > (lopeziba...@gmail.com) wrote: >> On 25 July 2016 at 18:18, ayush goel wrote: >> > On top of the previously filed patch for importing gnulib (the link >> > isn’t available on the archive yet, however this contains some of the >> > information: >> > http://gcc.1065356.n5.nabble.com/Importing-gnulib-into-the-gcc-tree-td1275807.html#a1279573) >> > now I have replaced another function from libiberty with the >> > corresponding version from gnulib. >> > Even though in both OSX and GNU/Linux, fnmatch is provided by the GNU >> > libc already, so the copy in libiberty is not used in your systems. >> > However since the objective is to replace whatever functions can be >> > leveraged by gnulib, these changes have been made. >> >> Why the change from "fnmatch.h" to ? > > Gnulib doesn’t contain a header for fnmatch. It itself relies on > glib’c fnmatch.h > >> >> Also, are the files in gnulib and libiberty semantically identical? >> The wiki page does not say anything about this. How did you check >> this? > > Well the online docs for libiberty and gnulib claim the same > definition for fnmatch. Apart from this I’ve manually gone through the > source code and they seem to be semantically similar. > Also the fact that the system builds fine and the tests also execute > fine could serve as a manifestation for the fact that they are > semantically same. >> >> GCC can run on other systems besides OSX and GNU/Linux, how can you >> test that your change does not break anything on those systems? >> > Well I have access to these two systems only. How would you suggest I > test my patches on all possible systems? Maybe building contrib/config-list.mk could help ? AFAIK, it will cross build the gcc tree for different targets, but not run the testsuite, however I could be wrong. Thanks, Prathamesh > >> Cheers, >> >> Manuel. >> > > -Ayush
Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch
On 26 July 2016 at 14:51, ayush goel wrote: > On 26 July 2016 at 3:38:59 AM, Manuel López-Ibáñez > (lopeziba...@gmail.com) wrote: >> Why the change from "fnmatch.h" to ? > > Gnulib doesn’t contain a header for fnmatch. It itself relies on > glib’c fnmatch.h I see two modules here: https://www.gnu.org/software/gnulib/MODULES.html#module=fnmatch https://www.gnu.org/software/gnulib/MODULES.html#module=fnmatch-gnu Both of them generate a header file if the one from glibc is not present or it is broken: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=modules/fnmatch Does GCC use the GNU extensions of fnmatch? If not, you probably only need fnmatch; otherwise you may need to also import fnmatch-gnu. >> Also, are the files in gnulib and libiberty semantically identical? >> The wiki page does not say anything about this. How did you check >> this? > > Well the online docs for libiberty and gnulib claim the same > definition for fnmatch. Apart from this I’ve manually gone through the > source code and they seem to be semantically similar. Ah, good! You should mention this in future submissions (and in the wiki page). > Also the fact that the system builds fine and the tests also execute > fine could serve as a manifestation for the fact that they are > semantically same. This is a necessary condition but not a sufficient condition. Unfortunately, comparing the two functions in detail is still necessary even if the tests succeed. >> GCC can run on other systems besides OSX and GNU/Linux, how can you >> test that your change does not break anything on those systems? >> > Well I have access to these two systems only. How would you suggest I > test my patches on all possible systems? Well, you could find fnmatch.h in your system and remove/rename it temporarily (also remove the libiberty versions under include/), then try to bootstrap and see what happens. If the system fnmatch.h is not used, the build system of gnulib should create a funmatch.h (check if it is created, otherwise GCC found a different fnmatch.h). Cheers, Manuel.
Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch
On 26 July 2016 at 3:38:59 AM, Manuel López-Ibáñez (lopeziba...@gmail.com) wrote: > On 25 July 2016 at 18:18, ayush goel wrote: > > On top of the previously filed patch for importing gnulib (the link > > isn’t available on the archive yet, however this contains some of the > > information: > > http://gcc.1065356.n5.nabble.com/Importing-gnulib-into-the-gcc-tree-td1275807.html#a1279573) > > now I have replaced another function from libiberty with the > > corresponding version from gnulib. > > Even though in both OSX and GNU/Linux, fnmatch is provided by the GNU > > libc already, so the copy in libiberty is not used in your systems. > > However since the objective is to replace whatever functions can be > > leveraged by gnulib, these changes have been made. > > Why the change from "fnmatch.h" to ? Gnulib doesn’t contain a header for fnmatch. It itself relies on glib’c fnmatch.h > > Also, are the files in gnulib and libiberty semantically identical? > The wiki page does not say anything about this. How did you check > this? Well the online docs for libiberty and gnulib claim the same definition for fnmatch. Apart from this I’ve manually gone through the source code and they seem to be semantically similar. Also the fact that the system builds fine and the tests also execute fine could serve as a manifestation for the fact that they are semantically same. > > GCC can run on other systems besides OSX and GNU/Linux, how can you > test that your change does not break anything on those systems? > Well I have access to these two systems only. How would you suggest I test my patches on all possible systems? > Cheers, > > Manuel. > -Ayush
Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch
On 25 July 2016 at 18:18, ayush goel wrote: > On top of the previously filed patch for importing gnulib (the link > isn’t available on the archive yet, however this contains some of the > information: > http://gcc.1065356.n5.nabble.com/Importing-gnulib-into-the-gcc-tree-td1275807.html#a1279573) > now I have replaced another function from libiberty with the > corresponding version from gnulib. > Even though in both OSX and GNU/Linux, fnmatch is provided by the GNU > libc already, so the copy in libiberty is not used in your systems. > However since the objective is to replace whatever functions can be > leveraged by gnulib, these changes have been made. Why the change from "fnmatch.h" to ? Also, are the files in gnulib and libiberty semantically identical? The wiki page does not say anything about this. How did you check this? GCC can run on other systems besides OSX and GNU/Linux, how can you test that your change does not break anything on those systems? Cheers, Manuel.
Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch
The link for that patch importing gnulib inside gcc’s tree: https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01302.html Apologies for the confusion. On 25 July 2016 at 10:48:20 PM, ayush goel (ayushgoel1...@gmail.com) wrote: > > On top of the previously filed patch for importing gnulib (the link isn’t > available on > the archive yet, however this contains some of the information: > http://gcc.1065356.n5.nabble.com/Importing-gnulib-into-the-gcc-tree-td1275807.html#a1279573) > now I have replaced another function from libiberty with the corresponding > version > from gnulib. > Even though in both OSX and GNU/Linux, fnmatch is provided by the GNU libc > already, so > the copy in libiberty is not used in your systems. However since the > objective is to replace > whatever functions can be leveraged by gnulib, these changes have been made. > > Tested and bootstrapped on x86_64(appledarwin,linux). > > Changelog: > 2016-07-25 Ayush Goel > > *src/gcc/genattrtab.c: included > *src/gcc/genautomata.c: included > *src/gcc/Makefile.in: removed dependency from libiberty’s fnmatch > *src/gnulib/update-gnulib.sh: Added fnmatch to list of modules imported from > gnulib > > Wiki link for more details: > https://gcc.gnu.org/wiki/replacelibibertywithgnulib > > -Ayush > > >
[PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch
On top of the previously filed patch for importing gnulib (the link isn’t available on the archive yet, however this contains some of the information: http://gcc.1065356.n5.nabble.com/Importing-gnulib-into-the-gcc-tree-td1275807.html#a1279573) now I have replaced another function from libiberty with the corresponding version from gnulib. Even though in both OSX and GNU/Linux, fnmatch is provided by the GNU libc already, so the copy in libiberty is not used in your systems. However since the objective is to replace whatever functions can be leveraged by gnulib, these changes have been made. Tested and bootstrapped on x86_64(appledarwin,linux). Changelog: 2016-07-25 Ayush Goel *src/gcc/genattrtab.c: included *src/gcc/genautomata.c: included *src/gcc/Makefile.in: removed dependency from libiberty’s fnmatch *src/gnulib/update-gnulib.sh: Added fnmatch to list of modules imported from gnulib Wiki link for more details: https://gcc.gnu.org/wiki/replacelibibertywithgnulib -Ayush importgnulib_fnmatch.patch Description: Binary data
