public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ncm-nospam at cantrip dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/8670] Alignment problem in std::basic_string
Date: Mon, 24 Jan 2005 03:42:00 -0000 [thread overview]
Message-ID: <20050124034224.20764.qmail@sourceware.org> (raw)
In-Reply-To: <20021121063601.8670.jkanze@caicheuvreux.com>
------- Additional Comments From ncm-nospam at cantrip dot org 2005-01-24 03:42 -------
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.
Furthermore, I have seen no suggestion that the __attribute__ approach
actually enables an alignment optimal for the actual template arguments,
as is easy when using a union. (That is not to say I don't believe it
can; it just doesn't appear to have been mentioned.) The discussion
seemed to suggest that there was no intention to align adaptively, but
only pessimistically. That seems wasteful.
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?
(Of course none of this is to suggest that the extension shouldn't
be fixed, too.)
--
What |Removed |Added
----------------------------------------------------------------------------
OtherBugsDependingO| |19495
nThis| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
next prev parent reply other threads:[~2005-01-24 3:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20021121063601.8670.jkanze@caicheuvreux.com>
2003-10-01 21:47 ` pinskia at gcc dot gnu dot org
2003-10-01 22:05 ` gdr at integrable-solutions dot net
2004-10-16 11:06 ` giovannibajo at libero dot it
2004-10-16 11:10 ` giovannibajo at libero dot it
2004-10-16 12:39 ` giovannibajo at libero dot it
2004-10-16 14:48 ` gdr at cs dot tamu dot edu
2004-10-16 15:14 ` giovannibajo at libero dot it
2004-10-16 20:09 ` pcarlini at suse dot de
2005-01-18 9:19 ` pcarlini at suse dot de
2005-01-21 17:46 ` ncm-nospam at cantrip dot org
2005-01-21 17:53 ` pcarlini at suse dot de
2005-01-23 3:52 ` ncm-nospam at cantrip dot org
2005-01-23 10:30 ` pcarlini at suse dot de
2005-01-24 3:42 ` ncm-nospam at cantrip dot org [this message]
2005-01-24 9:45 ` pcarlini at suse dot de
2005-01-24 11:06 ` pcarlini at suse dot de
2005-01-31 5:29 ` ncm-nospam at cantrip dot org
2005-04-01 13:32 ` pcarlini at suse dot de
[not found] <bug-8670-4113@http.gcc.gnu.org/bugzilla/>
2007-04-03 15:30 ` jamesc at dspsrv dot com
2007-04-03 18:26 ` pcarlini at suse dot de
[not found] <bug-8670-4@http.gcc.gnu.org/bugzilla/>
2023-11-08 16:45 ` redi at gcc dot gnu.org
2023-11-08 16:47 ` redi at gcc dot gnu.org
2023-11-08 19:00 ` redi at gcc dot gnu.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050124034224.20764.qmail@sourceware.org \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).