http://sourceware.org/bugzilla/show_bug.cgi?id=15901 Bug ID: 15901 Summary: Bessel functions y0, y1, yn are incorrect on non-positive values Product: glibc Version: 2.17 Status: NEW Severity: normal Priority: P2 Component: math Assignee: unassigned at sourceware dot org Reporter: vincent-srcware at vinc17 dot net yn(n,±0.0) on odd negative integer n gives -Inf, while the limit is +Inf. This incorrect result probably comes from a defect in POSIX[*] and should be changed. [*] http://austingroupbugs.net/view.php?id=714 yn(n,x) on negative values x gives -Inf instead of NaN. Though the value -Inf is currently allowed by POSIX, NaN is a much better result (and the only expected one according to general rules on undefined math functions), just like log(negative) or sqrt(negative) is NaN. I've posted a message about such values in the Austin Group list: http://permalink.gmane.org/gmane.comp.standards.posix.austin.general/7982 and replies would appear here: http://comments.gmane.org/gmane.comp.standards.posix.austin.general/7982 -- You are receiving this mail because: You are on the CC list for the bug. >From glibc-bugs-return-19420-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Aug 27 19:49:34 2013 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 25092 invoked by alias); 27 Aug 2013 19:49:34 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 25060 invoked by uid 48); 27 Aug 2013 19:49:30 -0000 From: "berardgui at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/15903] New: INITFIRST flag does not change fini order Date: Tue, 27 Aug 2013 19:49:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: berardgui at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-08/txt/msg00165.txt.bz2 Content-length: 1496 https://sourceware.org/bugzilla/show_bug.cgi?id903 Bug ID: 15903 Summary: INITFIRST flag does not change fini order Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: dynamic-link Assignee: unassigned at sourceware dot org Reporter: berardgui at gmail dot com Created attachment 7169 --> https://sourceware.org/bugzilla/attachment.cgi?idq69&actioníit git diff of an idea of a fix It looks like the INITFIRST flag is read by ld.so only for the init order and not during sorting the fini order. For instance, if I build a first library (lib1) with -z initfirst and a second one without, link an executable with these two libraries, and finally run it with LD_DEBUG, I have: 26457: calling init: ../lib1/lib1.so 26457: calling init: /lib64/ld-linux-x86-64.so.2 26457: calling init: /lib64/libc.so.6 26457: calling init: ../lib2/lib2.so 26457: calling fini: ./test [0] 26457: calling fini: ../lib1/lib1.so [0] 26457: calling fini: ../lib2/lib2.so [0] According to https://sourceware.org/binutils/docs/ld/Options.html the fini order should be the reverse order of the init order... Having a closer look to elf/dl-fini.c it seems that there is no check of the initfirst flag. Find attached an idea of a fix. -- You are receiving this mail because: You are on the CC list for the bug.