public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "joseph at codesourcery dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sources.redhat.com
Subject: [Bug libc/10110] Separate __STDC_* predefines from features.h
Date: Tue, 16 Jun 2009 16:20:00 -0000	[thread overview]
Message-ID: <20090616162015.19678.qmail@sourceware.org> (raw)
In-Reply-To: <20090428151651.10110.jsm28@gcc.gnu.org>


------- Additional Comments From joseph at codesourcery dot com  2009-06-16 16:20 -------
Subject: Re:  Separate __STDC_* predefines from features.h

On Tue, 16 Jun 2009, drepper at redhat dot com wrote:

> I don't like this super-complicated mechanism.  Just hardcode the values in gcc
> (in the spec file or where else).  They must not change anywhere.  Then glibc
> can be changed to not redefine them if they are already defined.

GCC could reasonably take responsibility for __STDC_IEC_559__ and 
__STDC_IEC_559_COMPLEX__, knowing that glibc implements the library parts 
of the requirements, and define a macro to indicate that it has taken 
responsibility for these macros.  (That would best be a separate macro, 
__IEC_559_MACROS_PREDEFINED__ or similar, since options such as 
-ffast-math mean the IEEE arithmetic requirements are not being followed 
and so these macros shouldn't actually be predefined when certain options 
are being used.)  But as I noted in the original patch submission this 
doesn't work so well for __STDC_ISO_10646__; that *should* change when 
glibc is updated for new versions of Unicode; I said:

    I strongly suspect that the value of __STDC_ISO_10646__ in glibc is
    out of date (the comment says Unicode 3.1 and the value is 200009L,
    but there have been subsequent changes updating glibc to Unicode 5).
    Updating this (in features.h before this patch or stdc-predef.h after
    it) is clearly independent of this patch.

I can implement a fixincludes-based approach, where the GCC build process 
extracts the value of __STDC_ISO_10646__ from the installed system headers 
(while determining __STDC_IEC_559__ and __STDC_IEC_559_COMPLEX__ directly 
based on the options passed to GCC); this would avoid glibc changes being 
needed, but make it more important to run the mkheaders script GCC 
installs to update the fixed headers when glibc is updated and an existing 
GCC installation is not rebuilt.  But the preinclusion mechanism in GCC is 
still needed for the use the DFP people wish to make of the GCC patch (I 
have confirmed they are interested in it), predefining __STDC_DEC_FP__ 
only when building with -I/usr/include/dfp to get DFP versions of headers 
(which include core glibc ones with #include_next); all the complexity 
goes in GCC (with some additional complexity to extract values at build 
time) and all you avoid is a small glibc patch to put some definitions in 
their own header.



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10110

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


  parent reply	other threads:[~2009-06-16 16:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-28 15:17 [Bug libc/10110] New: " jsm28 at gcc dot gnu dot org
2009-04-28 15:18 ` [Bug libc/10110] " jsm28 at gcc dot gnu dot org
2009-06-16 15:31 ` drepper at redhat dot com
2009-06-16 16:20 ` joseph at codesourcery dot com [this message]
2010-06-01  3:58 ` pasky at suse dot cz
     [not found] <bug-10110-131@http.sourceware.org/bugzilla/>
2011-01-08 17:05 ` jsm28 at gcc dot gnu.org
2011-01-09 14:10 ` drepper.fsp at gmail dot com
2012-02-22 12:59 ` jsm28 at gcc dot gnu.org
2014-06-30  9:16 ` fweimer at redhat dot com

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=20090616162015.19678.qmail@sourceware.org \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sources.redhat.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).