From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20328 invoked by alias); 28 Nov 2011 19:46:43 -0000 Received: (qmail 20314 invoked by uid 22791); 28 Nov 2011 19:46:42 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_LG X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 Nov 2011 19:46:28 +0000 From: "j at uriah dot heep.sax.de" To: gcc-bugs@gcc.gnu.org Subject: [Bug driver/28718] Call to -lgcc added prior to user libraries Date: Mon, 28 Nov 2011 20:39:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: driver X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: j at uriah dot heep.sax.de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-11/txt/msg02694.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D28718 --- Comment #11 from Joerg Wunsch 2011-11-28 1= 9:45:51 UTC --- (In reply to comment #10) > J=C3=B6rg, could you prepare a list of functions that shall be excluded f= rom libgcc? > You can also answer to my mail "PR28718 Infos?" from 2011-11-10. Well, perhaps. However, the AVR-part is not the main subject of my complaint here. The subject of my complaint was/is that a call to *any* library is added *prior* to the list of user-supplied libaries (from -l options). The point of -l options is to give the users an override option, which is completely defeated by the current way libstdc++ is handled. The fact that the AVR (currently) lacks a libstdc++, and thus libgcc is linked instead, caused this bug to be escalated due to the side effects, but this is not the main point here. This becomes even more puzzling now: apparently, this reordering of the libraries *only* applies to -lm. When specifying any other library, the processing works as one would expect it to be. The code for this is in gcc/cp/g++spec.c, around line 270: /* Make sure -lstdc++ is before the math library, since libstdc++ itself uses those math routines. */ if (!saw_math && (args[i] & MATHLIB) && library > 0) { --j; saw_math =3D &decoded_options[i]; } OK, now the reason is clear. However, this doesn't handle the case very well where no libstdc++ is available at all: inserting libgcc in place of libstdc++ is just a simple workaround, and apparently a too simple one in our case. A correct implementation would not try to add anything at all when libstdc++ is unavailable (and thus have no need to reorder). I don't know how many targets are affected at all by the lack of libstdc++. If AVR is indeed the only target where this applies to, then the way you outlined (a configurable list of functions to omit from libgcc) might be the best compromise. (Sorry it took me so long to reply, Johan, but I knew it would take me some time to research all this again, and then create the reply.)