On Fri, May 23, 2014 at 12:26:18PM -0600, Jeff Law wrote: > On 05/21/14 21:59, Rich Felker wrote: > >On Wed, May 21, 2014 at 11:17:53AM +0200, Richard Biener wrote: > >>On Wed, May 21, 2014 at 3:59 AM, Rich Felker <dal...@libc.org> wrote: > >>>Bug # 61144 is a regression in 4.9.0 that breaks building of musl libc > >>>due to aggressive and semantically-incorrect constant folding of weak > >>>aliases. The attached patch seems to fix the issue. A weak alias > >>>should never be a candidate for constant folding because it may always > >>>be replaced by a strong definition from another translation unit. > >>> > >>>For details see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 > >>> > >>>I do not have a copyright assignment on file but this patch should be > >>>sufficiently trivial not to require it. > >> > >>Please add a testcase. Also I wonder why it isn't better to generalize > > > >How should a testcase be done? On the PR there's a testcase that shows > >the problem in the generated code, but no automated check for it. > >Testing this is actually a bit of a pain unless you're allowed to run > >the generated program. > You can run the test program. Have it exit (0) on success, abort () > on failure if at all possible. Then drop the test source file into > gcc/testsuite/gcc.c-torture/execute/pr61144.c
The test needs to be two translation units linked together: one with a weak definition of the object as 0, and the other with a strong definition. The test should show the weak value being used rather than the strong one. But I'm not sure how this should be integrated with the build process. Is anyone from the gcc side willing to help on this? I'd really like to get it fixed before the bug propagates into more releases and makes longstanding weak alias semantics unreliable, but I'm not familiar with gcc internals well enough to know if my existing patch is the preferred fix or not, nor how to make a good test case. Rich
