[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number

["jb at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847

--- Comment #22 from Janne Blomqvist <jb at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #21)
> (In reply to Jerry DeLisle from comment #20)
> > Created attachment 33858 [details]
> > Proposed patch
> 
>   /* If the current locale is expecting a comma rather than a decimal
>      point, convert it now.  */
>   if (dtp->u.p.current_unit->decimal_locale == ',')
>     *strchr (buffer, '.') = ',';
> 
> In principle, there are more options than just "," and "."; for instance, in
> Britain, one often uses a centered dot (·) but that's not in the locale.
> 
> Looking at the output of all my locales, I found:
>   ps_AF.utf8:     0٫400000
> as the only locale which doesn't use either a '.' or a ','.

Interesting.. still, Jerry's patch looks like an improvement over the status
quo and should cover the vast majority of cases.

> Still, using a
> code like the following looks more robust.
> 
> /* During _gfortran_st_read/write.  */
> const char *curr_locale = setlocale(LC_ALL, NULL);
> setlocale(LC_ALL, "C");
> 
> ...
> 
> /* During _gfortran_st_read_done/write_done.  */
> setlocale(LC_ALL, curr_locale);

I really don't think we should mess with setlocale(). It changes the
process-wide locale, and if some other thread does something locale-dependent
between our setlocale() calls there will be a bug in the user program which
will be very hard to track down.

As an aside, Jerry's patch suffers from similar issues, as the locale might be
changed between checking the decimal separator (on OPEN) and using some
locale-dependent functions.

The robust solution really is to use strtod_l etc. as previously mentioned.
>From gcc-bugs-return-465709-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Nov 04 13:50:40 2014
Return-Path: <gcc-bugs-return-465709-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17774 invoked by alias); 4 Nov 2014 13:50:40 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 17716 invoked by uid 48); 4 Nov 2014 13:50:35 -0000
From: "aixtools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/63714] AIX (5.3.7, xlC v11) fails to bootstrap for gcc 4.9.2, 4.8.3 and 4.7.4
Date: Tue, 04 Nov 2014 13:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: aixtools at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63714-4-8CdVixKsh5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63714-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63714-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00181.txt.bz2
Content-length: 510

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc714

--- Comment #9 from Michael Felt <aixtools at gmail dot com> ---
While I may yet find a bug - my apologies for not better understanding the
installation document.
I see there is a better mail-list (gcc-help) and shall request assistance via
that path.

Thank you again for your assistance!

FYI: gcc-4.7.4 seems to want to finish, but I am probably still not understand
all of the instructions, e.g., where to place binutils so that they get used
properly.