On Wed, Dec 9, 2020 at 6:08 PM Jim Wilson <j...@sifive.com> wrote: > > On Tue, Dec 8, 2020 at 4:51 AM H.J. Lu via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: >> >> When SECTION_RETAIN is used, definitions marked with used attribute and >> unmarked definitions are placed in a section with the same name. Instead >> of issue an error: > > > Have you tested glibc builds with this patch? I noticed yesterday that your > earlier patch had broken glibc builds, and was about to raise a bug report > for that. I'm seeing > > In file included from <command-line>: > gconv_db.c: In function 'free_mem': > gconv_db.c:831:18: error: 'free_mem' causes a section type conflict with > 'free_derivation' > 831 | libc_freeres_fn (free_mem) > | ^~~~~~~~ > ./../include/libc-symbols.h:316:15: note: in definition of macro > 'libc_freeres_fn' > 316 | static void name (void) > | ^~~~ > gconv_db.c:174:1: note: 'free_derivation' was declared here > 174 | free_derivation (void *p) > | ^~~~~~~~~~~~~~~ > > This is because free_derivation and free_mem are in the same section, but > free_mem has attribute used and free_derivation does not. > > This patch is changing the error to a warning, which I think solves the > problem unless --enable-werror is used, which is probably good enough. We > could maybe decide that what glibc is doing is wrong and fix glibc to use > different section names or mark both functions as attribute used. >
I tested it with glibc build. Glibc build issue is the reason I didn't combine 2 patches into one. If GCC does issue a warning, which it should, we will change glibc. If we decide not to issue a warning, there is no need to change glibc. BTW, I believe glibc should be changed. -- H.J.
