From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28754 invoked by alias); 24 Jan 2005 09:45:54 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 28622 invoked by uid 48); 24 Jan 2005 09:45:39 -0000 Date: Mon, 24 Jan 2005 09:45:00 -0000 Message-ID: <20050124094539.28621.qmail@sourceware.org> From: "pcarlini at suse dot de" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20021121063601.8670.jkanze@caicheuvreux.com> References: <20021121063601.8670.jkanze@caicheuvreux.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libstdc++/8670] Alignment problem in std::basic_string X-Bugzilla-Reason: CC X-SW-Source: 2005-01/txt/msg03483.txt.bz2 List-Id: ------- Additional Comments From pcarlini at suse dot de 2005-01-24 09:45 ------- > I have read the discussion on 17744 and 19163. Nothing there suggests > that there is any reason to prefer using an __attribute__ over using > the portable, stable, apparently already-working union approach, where > it serves. The union approach, contrariwise, is manifestly better > anywhere the __attribute__ feature is broken, which it is said still > to be, proposed patches notwithstanding. The feature its broken and the proposed patches don't fix it. Plenty of discussions on gcc-patches and elsewhere, no doubts about this. Also, there is an agreement about the maintainers that from now one, really we should concentrate our efforts in preparing a new implementation of basic_string: these alignment problems are not new, always been there. > Why should library fixes (specifically, 19495) wait unnecessarily on > fixes for compiler extensions -- more particularly, extensions unlikely > to be fixed in the older releases whose libraries we still maintain? > What am I missing? I'm still trying to figure out a simple, non-invasive, clean, way to implement your suggestions. We don't want loads of casts, or unions, additional instantiations (requiring loads of additional includes) and failing tests elsewhere (ext/array_allocator needs tweaks), uglyness, in a word. I'm still trying to figure whether we can achieve that within the current implementation and without subtracting too much energy to other projects (among which the new implementation itself): please be patient, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670