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

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

[jvdelisle at gcc dot gnu.org]

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

--- Comment #2 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Please see PR36857 for some background.

gfortran uses the glibc strtod functions to convert the string to real. I think
in your C code you need to do something like this:

        setlocale(LC_ALL, "C");  
        badcall_();
        setlocale(LC_ALL, "de_DE.UTF-8");  

and then if your locale does use comma for the decimal point, do this on the
FORTRAN side.

  open(unit=1,file='bug.dat', decimal="comma")

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

[e2cd58e1 at opayq dot com]

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

--- Comment #3 from e2cd58e1 at opayq dot com ---
but what I want to do is read in values with point as decimal separator. Using

  open(unit=1,file='bug.dat', decimal="point")

doesn't seem to change anything.

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to e2cd58e1 from comment #3)
> but what I want to do is read in values with point as decimal separator.
> Using
> 
>   open(unit=1,file='bug.dat', decimal="point")
> 
> doesn't seem to change anything.

gfortran's IO for floating point numbers using the operating
systems strtof, strtod, and strtold.  Are you sure that these
functions on yuor OS actual have working locale support?

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

[e2cd58e1 at opayq dot com]

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

--- Comment #5 from e2cd58e1 at opayq dot com ---
I actually don't know - how can I test this?

But either way, shouldn't 

    open(unit=1,file='bug.dat', decimal="point")

read 1.234 in as 1.234 no matter what the locale settings are?

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

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #4)
> (In reply to e2cd58e1 from comment #3)
> > but what I want to do is read in values with point as decimal separator.
> > Using
> > 
> >   open(unit=1,file='bug.dat', decimal="point")
> > 
> > doesn't seem to change anything.
> 
> gfortran's IO for floating point numbers using the operating
> systems strtof, strtod, and strtold.  Are you sure that these
> functions on yuor OS actual have working locale support?

Yeah, replying to myself.

What happens if you give strtod "1.2345' and "1,2345" in
your locale?  I missed a section of code in io/read.c:

    case ',':
      if (dtp->u.p.current_unit->decimal_status != DECIMAL_COMMA)
        goto bad_float;
      /* Fall through.  */
    case '.':
      if (seen_dp)
        goto bad_float;
      if (!seen_int_digit)
        *(out++) = '0';
      *(out++) = '.';
      seen_dp = 1;
      break;

This implicitly changes a comma into a decimal point prior to the
call to strtod.

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

[e2cd58e1 at opayq dot com]

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

--- Comment #7 from e2cd58e1 at opayq dot com ---
For

    printf("Test 1 = %.4f\n",strtod("1.2345",NULL));
    printf("Test 2 = %.4f\n",strtod("1,2345",NULL));

I get

    Test 1 = 1,0000
    Test 2 = 1,2345

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Jul 21, 2014 at 06:18:14PM +0000, e2cd58e1 at opayq dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
> 
> --- Comment #7 from e2cd58e1 at opayq dot com ---
> For
> 
>     printf("Test 1 = %.4f\n",strtod("1.2345",NULL));
>     printf("Test 2 = %.4f\n",strtod("1,2345",NULL));
> 
> I get
> 
>     Test 1 = 1,0000
>     Test 2 = 1,2345
> 

That's what I would expect.  Here's another test;

#include <locale.h>
#include <stdio.h>
#include <stdlib.h>
int
main(void)
{
   char *s1 = "1.2345", *s2 = "5,4321";
   double d1, d2;

   setlocale(LC_ALL, "en_US.ISO8859-1");
   d1 = strtod(s1, NULL);
   d2 = strtod(s2, NULL);
   printf("%s = %.4lf and %s = %.4lf\n", s1, d1, s2, d2);

   setlocale(LC_ALL, "de_DE.UTF-8");
   d1 = strtod(s1, NULL);
   d2 = strtod(s2, NULL);
   printf("%s = %.4lf and %s = %.4lf\n", s1, d1, s2, d2);
   return 0;
}

I get

troutmask:sgk[204] ./z
1.2345 = 1.2345 and 5,4321 = 5.0000
1.2345 = 1,0000 and 5,4321 = 5,4321

So, the section of code that I posted in comment 6 is 
ensuring that the fraction separator is always a decimal
point, and your locale and strtod are expecting a comma.

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

[e2cd58e1 at opayq dot com]

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

--- Comment #9 from e2cd58e1 at opayq dot com ---
Just what I get:

    1.2345 = 1.2345 and 5,4321 = 5.0000
    1.2345 = 1,0000 and 5,4321 = 5,4321

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|bug in gfortran runtime on  |bug in gfortran runtime:
                   |OSX: digits cut off when    |digits cut off when reading
                   |reading floating point      |floating point number
                   |number                      |

--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
I can reproduce this PR on a linux box with gcc version 4.6.3 20120306 (Red Hat
4.6.3-2), so the bug is not darwin specific. 

I have noticed that the file generated by running the test is

1.2345

and does not change if I put the line

        setlocale(LC_ALL, "de_DE.UTF-8");

before the line

        f = fopen("bug.dat", "w");

Now if I change the content of bug.dat to

1,2345

suppress the file generation in bug.c and use

  open(unit=1,file='bug.dat', decimal='comma')

in bugf.f90, running the executable does not give any output (success).

So apparently strtod uses the locale to read 1.2345, giving 1.0 as a result for
"de_DE.UTF-8" (or "fr_FR.UTF-8"), using "en_US.ISO8859-1" gives 1.2345.

The only solution I see is to save the current locale, set it to "C" before
using strtod, and restore it upon completion.

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

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
After all that has been said here, I am almost afraid to add any more.

This is not a bug.  Fortran and GFortran are not locale aware. The ',' or '.'
are read from the file or device literally as is.  From this read, a numeric
string is constructed.  If the unit was opened with decimal='comma' and a comma
was seen, the comma is converted to '.'.  If decimal='point' and a comma is
read, an error occurs.

After the above described numeric string is constructed it is passed to the
glibc library strtod (sring to double).  The glibc library is locale aware and
if the locale has defined the decimal token to be a ',' (comma), it see the
decimal 'point' and interprets it as end of string conversion.

We do not want to take a performance it by checking the locale setting on every
I/O operation, so the only logical place to do that is in main.c.  However, in
the example, the original poster is only compiling a gfortran subroutine. 
There is no gfortran program, so there is no gfortran main.c

So the responsibility for addressing the locale has to fall on the C program
side or within the users subroutine using maybe system calls that are
extensions and not Fortran standard code.  This users code would query the
current runtime environment for current decimal setting and then do the I/O
with the appropriate decimal= specifier.

To avoid confusion, remember that gfortran is reading the characters in the
file literally.  So if there is a 1,2345 it sees the comma.  If there is a
1.234 it sees the point. The conversion to internal floating point
representation occurs after the character data is read.

The easiest solution is to do what I said in in Comment #2 on the C side.  The
equivalent can be done on the fortran side as well, just not as easily.

One possible enhancement we could consider is providing some set and get locale
intrinsics.  This would be helpful for some folks. But, thats a lot more work.

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

[e2cd58e1 at opayq dot com]

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

--- Comment #12 from e2cd58e1 at opayq dot com ---
Sorry but I still have a problem with this, maybe I didn't get what you are
saying or I wasn't clear enough.  

Suppose I cannot change the C-wrapper and the locale might be set to whatever.
The file bug.dat already exists and uses point decimals. So I want a fortran
routine that always reads in a file in the usual point separated format. 

If in the fortran routine I call

    open(unit=1,file='bug.dat', decimal="point")

I expect the keyword to be more important than the locale setting: I explicitly
specify to read point separated values, but in the example below, it still
returns 1.00000 instead of 1.2345. Is that really expected behavior?

----------------- bug.c --------------
#include <stdlib.h>     /* strtod */
#include <locale.h>  
#include <stdio.h>  

int badcall_();  
int main() 
{  
        setlocale(LC_ALL, "de_DE.UTF-8");  
        badcall_();  
        return 0;  
}
----------------- bug.dat --------------
1.2345
----------------- bugf.f90 --------------
subroutine badcall()  
  implicit none  
  double precision :: res
  open(unit=1,file='bug.dat',decimal="point")  
  read(1,*) res
  write(*,*) 'res =', res
end subroutine badcall

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

[jvdelisle at gcc dot gnu.org]

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

--- Comment #14 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to e2cd58e1 from comment #12)
--- snip ---
> Suppose I cannot change the C-wrapper and the locale might be set to
> whatever. The file bug.dat already exists and uses point decimals. So I want
> a fortran routine that always reads in a file in the usual point separated
> format. 
> 
> If in the fortran routine I call
> 
>     open(unit=1,file='bug.dat', decimal="point")
> 
> I expect the keyword to be more important than the locale setting: I
> explicitly specify to read point separated values, but in the example below,
> it still returns 1.00000 instead of 1.2345. Is that really expected behavior?
> 

My first bad assumption was that for some reason you wanted the current locale,
whatever it is, to remain active. My second bad assumption was that you could
easily change your C-wrapper.  :)

In reading up on the locale business, setting locale to "POSIX" is suppose to
be fully portable.

So, we could easily force the locale to POSIX in the open statement.  I need to
think about whether this will mess up something else.

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

[jvdelisle at gcc dot gnu.org]

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

--- Comment #15 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Maybe something like this:

Index: open.c
===================================================================
--- open.c    (revision 212498)
+++ open.c    (working copy)
@@ -26,6 +26,7 @@ see the files COPYING3 and COPYING.RUNTIME respect
 #include "io.h"
 #include "fbuf.h"
 #include "unix.h"
+#include "locale.h"

 #ifdef HAVE_UNISTD_H
 #include <unistd.h>
@@ -725,6 +726,10 @@ st_open (st_parameter_open *opp)

   library_start (&opp->common);

+  /* For portability, set locale to "POSIX".  */
+
+  setlocale(LC_ALL, "POSIX");
+
   /* Decode options.  */

   flags.access = !(cf & IOPARM_OPEN_HAS_ACCESS) ? ACCESS_UNSPECIFIED :

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #16 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Jul 22, 2014 at 04:27:58AM +0000, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
> 
> --- Comment #15 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
> Maybe something like this:

I think that you'll need to use configure to check for locale.h.

> 
> Index: open.c
> ===================================================================
> --- open.c    (revision 212498)
> +++ open.c    (working copy)
> @@ -26,6 +26,7 @@ see the files COPYING3 and COPYING.RUNTIME respect
>  #include "io.h"
>  #include "fbuf.h"
>  #include "unix.h"
> +#include "locale.h"

#ifdef HAVE_LOCALE_H
#include <locale.h>
#endif

> 
>  #ifdef HAVE_UNISTD_H
>  #include <unistd.h>
> @@ -725,6 +726,10 @@ st_open (st_parameter_open *opp)
> 
>    library_start (&opp->common);

#ifdef HAVE_LOCALE_H

> +  /* For portability, set locale to "POSIX".  */
> +
> +  setlocale(LC_ALL, "POSIX");
> +

#endif

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

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jvdelisle at gcc dot gnu.org
           Severity|normal                      |enhancement

--- Comment #17 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I have a patch in the works.  The idea is to query the locale at the time the
Unit is connected and save the LC_NUMERIC character in the unit structure.
Then, if the decimal character matches the DECIMAL_STATUS (decimal="point" or
decimal="comma") active at the time of reading, change the decimal character
internally to the current locale character previously saved. This way, only one
call to locale is needed per unit connection, preserving efficiency. The real
string will then be converted correctly, regardless of locale.

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

[jvdelisle at gcc dot gnu.org]

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

--- Comment #18 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Created attachment 33227
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33227&action=edit
A preliminary patch

This patch is preliminary for "proof of principle". If the idea is acceptable,
then configuration magic is required to ensure the locale.h is available, and
if not, default to '.'.

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

[jb at gcc dot gnu.org]

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

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jb at gcc dot gnu.org

--- Comment #19 from Janne Blomqvist <jb at gcc dot gnu.org> ---
(In reply to Jerry DeLisle from comment #17)
> I have a patch in the works.  The idea is to query the locale at the time
> the Unit is connected and save the LC_NUMERIC character in the unit
> structure. Then, if the decimal character matches the DECIMAL_STATUS
> (decimal="point" or decimal="comma") active at the time of reading, change
> the decimal character internally to the current locale character previously
> saved. This way, only one call to locale is needed per unit connection,
> preserving efficiency. The real string will then be converted correctly,
> regardless of locale.

While clever, I'm not sure this approach works. A program can change the locale
between opening the file and reading from it (potentially in another thread,
since the locale is a process-wide property).

What can be done instead is to use the POSIX 2008 extended locale functionality
(newlocale) to create a "locale object" in the default C locale and then use
functions like strtod_l (for some reason not in POSIX 2008, though at least
glibc and BSD/OSX have it, IIRC) that take such a locale object as argument.
This is fairly new though and not available everywhere, but ought to be robust.

See also PR 47007.

As an aside, AFAIK the "C" and "POSIX" locales are the same, just two names for
the same thing. "C" might be more portable, as that should work everywhere
there is a C implementation.

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

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #21 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(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 ','. 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);


* * *

Side remarks:

* Per PR36857 comment 8, it has to be "C" and not "POSIX" for MinGW.
* The fix for PR 36857 also assumes that there is only "," and "."; thus, when
going the setlocale route, it should be fixed as well.
* See also PR 47007; see also the variant using __strtold_l/strtold_l and
newlocale for READ (cf. PR 47007 comment 20 to 22).
>From gcc-bugs-return-465632-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 03 11:06:17 2014
Return-Path: <gcc-bugs-return-465632-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10513 invoked by alias); 3 Nov 2014 11:06:16 -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 10494 invoked by uid 48); 3 Nov 2014 11:06:13 -0000
From: "jiwang at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/63721] New: [5 Regression] IPA ICF cause atomic-comp-swap-release-acquire.c ICE on arm
Date: Mon, 03 Nov 2014 11:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jiwang at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-63721-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00104.txt.bz2
Content-length: 3289

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

            Bug ID: 63721
           Summary: [5 Regression] IPA ICF cause
                    atomic-comp-swap-release-acquire.c ICE on arm
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jiwang at gcc dot gnu.org

Created attachment 33875
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33875&action=edit
bug.i

start from revision 216305, and still exist on latest code 217035.

commit 52200d03c231f0bddbd4bbc5cd3608c6a1dd4598
Author: marxin <marxin@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Thu Oct 16 10:47:55 2014 +0000

    IPA ICF pass, part 3/5

    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@216305
138bc75d-0d04-0410-961f-82ee72b054a4


cross configuration
===

    ../gcc/configure --target=arm-unknown-linux-gnueabihf --with-float=hard
--with-arch=armv7-a --with-tune=cortex-a15 --disable-multilib
--enable-languages=c,c++,fortran,java,lto,objc

compile command
===

  ./cc1 -O2 -fPIC bug.i -nostdinc
  (if specify -fno-ipa-icf then the ICE will go away)

backtrace
===

atomic-comp-swap-release-acquire.c: In function
‘atomic_compare_exchange_WEAK_RELEASE_ACQUIRE’:
atomic-comp-swap-release-acquire.c:7:0: error: invalid argument to gimple call

 ^
a
# .MEM_3 = VDEF <.MEM_1(D)>
retval.10_4 = atomic_compare_exchange_n_WEAK_RELEASE_ACQUIRE.localalias.0 (a,
b_2(D)); [tail call]

Breakpoint 2, internal_error (gmsgid=0x14ff2a8 "verify_gimple failed") at
../../gcc/gcc/diagnostic.c:1176
1176      va_start (ap, gmsgid);
(gdb) bt
#0  internal_error (gmsgid=0x14ff2a8 "verify_gimple failed") at
../../gcc/gcc/diagnostic.c:1176
#1  0x0000000000c8bc5d in verify_gimple_in_cfg (fn=0x7ffff6b097e0,
verify_nothrow=false) at ../../gcc/gcc/tree-cfg.c:5039
#2  0x0000000000b52b81 in execute_function_todo (fn=0x7ffff6b097e0, data=0x40)
at ../../gcc/gcc/passes.c:1758
#3  0x0000000000b51f12 in do_per_function (callback=0xb529db
<execute_function_todo(function*, void*)>, data=0x40) at
../../gcc/gcc/passes.c:1492
#4  0x0000000000b52d69 in execute_todo (flags=64) at
../../gcc/gcc/passes.c:1815
#5  0x0000000000b538cb in execute_one_pass (pass=0x1d0b0e0) at
../../gcc/gcc/passes.c:2172
#6  0x0000000000b5464e in execute_ipa_pass_list (pass=0x1d0b0e0) at
../../gcc/gcc/passes.c:2553
#7  0x00000000007db73f in ipa_passes () at ../../gcc/gcc/cgraphunit.c:2065
#8  0x00000000007db9e0 in symbol_table::compile (this=0x7ffff6c74000) at
../../gcc/gcc/cgraphunit.c:2145
#9  0x00000000007dbe52 in symbol_table::finalize_compilation_unit
(this=0x7ffff6c74000) at ../../gcc/gcc/cgraphunit.c:2298
#10 0x0000000000635abb in c_write_global_declarations () at
../../gcc/gcc/c/c-decl.c:10779
#11 0x0000000000c4ce74 in compile_file () at ../../gcc/gcc/toplev.c:582
#12 0x0000000000c4f19a in do_compile () at ../../gcc/gcc/toplev.c:1989
#13 0x0000000000c4f3a4 in toplev::main (this=0x7fffffffe49f, argc=5,
argv=0x7fffffffe598) at ../../gcc/gcc/toplev.c:2086
#14 0x00000000013a489a in main (argc=5, argv=0x7fffffffe598) at
../../gcc/gcc/main.c:38
(gdb)
>From gcc-bugs-return-465633-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 03 11:14:03 2014
Return-Path: <gcc-bugs-return-465633-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13554 invoked by alias); 3 Nov 2014 11:14:02 -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 13461 invoked by uid 48); 3 Nov 2014 11:13:59 -0000
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/63718] [5 Regression] ARM Thumb1 bootstrap fail after fuse-caller-save info in cprop-hardreg
Date: Mon, 03 Nov 2014 11:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63718-4-jxGuWhXzi2@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63718-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63718-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/msg00105.txt.bz2
Content-length: 770

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

--- Comment #7 from vries at gcc dot gnu.org ---
(In reply to Joey Ye from comment #6)
> (In reply to vries from comment #5)
> > Could you try out the patch and see if it fixes things for you?
> >
> Tom, thanks for the quick action. Apparantly this patch should recover the
> bootstrap. I will test it and come back to you (bootstraping thumb1 with
> qemu takes hours!)
>

Great :)

> However, I think the fix is too conservative. There are plenty of chances
> that r0-r3 will not be clobbered by return. For example armv6-m will pretty
> much never uses r0-r3 implicitly.

Indeed, the patch is conservative, but that's not such a bad idea for a
correctness fix. We can always folllow up with a more optimal patch.

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

[jb at gcc dot 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.

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

[jb at gcc dot gnu.org]

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

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://gcc.gnu.org/ml/gcc-
                   |                            |patches/2014-11/msg00277.ht
                   |                            |ml

--- Comment #23 from Janne Blomqvist <jb at gcc dot gnu.org> ---
Patch using POSIX 2008 functionality at
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00277.html

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

[jb at gcc dot gnu.org]

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

--- Comment #24 from Janne Blomqvist <jb at gcc dot gnu.org> ---
Author: jb
Date: Mon Nov 10 00:17:16 2014
New Revision: 217273

URL: https://gcc.gnu.org/viewcvs?rev=217273&root=gcc&view=rev
Log:
PR 47007 and 61847 Locale failures in libgfortran.

2014-11-10  Janne Blomqvist  <jb@gcc.gnu.org>

    PR libfortran/47007
    PR libfortran/61847
    * config.h.in: Regenerated.
    * configure: Regenerated.
    * configure.ac (AC_CHECK_HEADERS_ONCE): Check for xlocale.h.
    (AC_CHECK_FUNCS_ONCE): Check for newlocale, freelocale, uselocale,
    strerror_l.
    * io/io.h (locale.h): Include.
    (xlocale.h): Include if present.
    (c_locale): New variable.
    (old_locale): New variable.
    (old_locale_ctr): New variable.
    (old_locale_lock): New variable.
    (st_parameter_dt): Add old_locale member.
    * io/transfer.c (data_transfer_init): Set locale to "C" if doing
    formatted transfer.
    (finalize_transfer): Reset locale to previous.
    * io/unit.c (c_locale): New variable.
    (old_locale): New variable.
    (old_locale_ctr): New variable.
    (old_locale_lock): New variable.
    (init_units): Init c_locale, init old_locale_lock.
    (close_units): Free c_locale.
    * runtime/error.c (locale.h): Include.
    (xlocale.h): Include if present.
    (gf_strerror): Use strerror_l if available. Reset locale to
    LC_GLOBAL_LOCALE for strerror_r branch.

2014-11-10  Janne Blomqvist  <jb@gcc.gnu.org>

    PR libfortran/47007
    PR libfortran/61847
    * gfortran.texi: Add note about locale issues to thread-safety
    section.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/gfortran.texi
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/config.h.in
    trunk/libgfortran/configure
    trunk/libgfortran/configure.ac
    trunk/libgfortran/io/io.h
    trunk/libgfortran/io/transfer.c
    trunk/libgfortran/io/unit.c
    trunk/libgfortran/runtime/error.c

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

[jb at gcc dot gnu.org]

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

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #25 from Janne Blomqvist <jb at gcc dot gnu.org> ---
Fixed on trunk, closing.