public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bernd Edlinger <bernd.edlinger@hotmail.de>
To: Joseph Myers <joseph@codesourcery.com>
Cc: Paul Eggert <eggert@cs.ucla.edu>,
	Florian Weimer <fweimer@redhat.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: Make max_align_t respect _Float128 [version 2]
Date: Tue, 06 Sep 2016 18:14:00 -0000	[thread overview]
Message-ID: <AM4PR0701MB21626599D35AB842690FC1EAE4F90@AM4PR0701MB2162.eurprd07.prod.outlook.com> (raw)

Hi,

I'd like to share some of my thoughts about the max_align_t,
if you don't mind.

I think that for _Float128 to become a fundamental data type,
it is *not* sufficient that gcc supports it alone, because glibc
needs to support also all the necessary math library functions.

When that is done, glibc can also increase the malloc alignment.
That will mean that programs built for glibc-2.24 will not
run on old glibc installations.

I think that glibc-2.24 will still have to support older
gcc versions, and should make malloc alignment be fixed,
even if an application is built using an old gcc version,
or am I wrong, which is possible here?

I have some doubt that it will work to change max_align_t's
alignment only based on the gcc version, I mean
there should be a way to allow the max_align_t keep at
8 bytes if the existing glibc will not support 16 bytes.

I *think*, there should be some kind of hand-shake in the
max_align_t to enable __float128 when gcc supports that,
*and* glibc supports that at the same time.

Like, maybe including some glibc-header, that defines some
macro, what the real malloc alignment will be.  And probably
some builtin-macro, if gcc supports __float128, independently
of the i386, that could probably also be helpful for writing
portable applications.



Bernd.

             reply	other threads:[~2016-09-06 18:09 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-06 18:14 Bernd Edlinger [this message]
2016-09-06 20:58 ` Joseph Myers
  -- strict thread matches above, loose matches on Subject: below --
2016-09-07 19:50 Bernd Edlinger
2016-09-07 20:06 ` Joseph Myers
2016-09-07 21:00   ` Bernd Edlinger
2016-09-07 21:48     ` Joseph Myers
2016-09-08 10:50 ` Florian Weimer
2016-09-09 17:24   ` Bernd Edlinger
2016-08-26 20:55 Make max_align_t respect _Float128 Joseph Myers
2016-09-05 17:07 ` Make max_align_t respect _Float128 [version 2] Joseph Myers
2016-09-06  9:06   ` Richard Biener
2016-09-06 11:26     ` Joseph Myers
2016-09-06  9:19   ` Florian Weimer
2016-09-06  9:24     ` Richard Biener
2016-09-07  7:45       ` Florian Weimer
2016-09-07 17:53         ` Joseph Myers
2016-09-08  9:35           ` Florian Weimer
2016-09-06 11:40     ` Joseph Myers
2016-09-06 15:06       ` Florian Weimer
2016-09-06 15:20         ` Joseph Myers
2016-09-06 15:59           ` Paul Eggert
2016-09-06 20:47             ` Joseph Myers
2016-09-06 21:41               ` Paul Eggert
2016-09-07  9:22                 ` Florian Weimer
2016-09-07 11:52                   ` Mark Wielaard
2016-09-08  1:58                     ` Paul Eggert
2016-09-08 11:58                       ` Mark Wielaard
2016-09-08 12:22                         ` Florian Weimer
2016-09-08 14:59                         ` Paul Eggert
2016-09-08 12:30                       ` Bernd Schmidt
2016-09-08 12:34                         ` Florian Weimer
2016-09-07  9:15               ` Florian Weimer
2016-09-06 21:03           ` Jason Merrill
2016-09-06 21:18             ` Joseph Myers
2016-09-06 21:53               ` Jason Merrill
2016-09-06 21:56                 ` Joseph Myers
2016-09-06 12:06     ` Bernd Schmidt
2016-09-06 14:59       ` Florian Weimer

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=AM4PR0701MB21626599D35AB842690FC1EAE4F90@AM4PR0701MB2162.eurprd07.prod.outlook.com \
    --to=bernd.edlinger@hotmail.de \
    --cc=eggert@cs.ucla.edu \
    --cc=fweimer@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    /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).