[Patch, Fortran, committed] Add LANG=C to libgfortran/mk-kinds-h.sh

[Patch, Fortran, committed] Add LANG=C to libgfortran/mk-kinds-h.sh

[Tobias Burnus]

:ADDPATCH fortran:

After getting failures when building GCC with a non-English locale, I
found out that

    huge=`$compile -c -fdump-parse-tree tmq$$.f90 | grep TRANSFER \
                | sed 's/ *TRANSFER *// ; s/_.*//'`

only works if TRANSFER is not translated in the dump.

I committed attached patch as obvious. (As the change to mk-kinds-h.sh
is brand new, only today's GCC trunk was affected.)

Tobias

Rev. 129658.

Index: libgfortran/ChangeLog
===================================================================
--- libgfortran/ChangeLog       (Revision 129657)
+++ libgfortran/ChangeLog       (Arbeitskopie)
@@ -1,3 +1,7 @@
+2007-10-26  Tobias Burnus  <burnus@net-b.de>
+
+       * mk-kinds-h.sh: Add "LANG=C".
+
 2007-10-26  Francois-Xavier Coudert  <fxcoudert@gcc.gnu.org>

        * libgfortran.h (GFC_REAL_*_HUGE, GFC_REAL_*_DIGITS,
Index: libgfortran/mk-kinds-h.sh
===================================================================
--- libgfortran/mk-kinds-h.sh   (Revision 129657)
+++ libgfortran/mk-kinds-h.sh   (Arbeitskopie)
@@ -1,4 +1,6 @@
 #!/bin/sh
+LANG=C
+export LANG

 compile="$1"

Re: [Patch, Fortran, committed] Add LANG=C to libgfortran/mk-kinds-h.sh

[Tobias Schlüter]

Tobias Burnus wrote:
> After getting failures when building GCC with a non-English locale, I
> found out that
> 
>     huge=`$compile -c -fdump-parse-tree tmq$$.f90 | grep TRANSFER \
>                 | sed 's/ *TRANSFER *// ; s/_.*//'`
> 
> only works if TRANSFER is not translated in the dump.
> 
> I committed attached patch as obvious. (As the change to mk-kinds-h.sh
> is brand new, only today's GCC trunk was affected.)

Since I couldn't find this expression, and since I can't think of an 
occasion where one would both want to match TRANSFER and where it's a 
good idea to translate it, I'm curious: could you say where or how this 
happens?

Cheers,
- Tobi

Re: [Patch, Fortran, committed] Add LANG=C to libgfortran/mk-kinds-h.sh

[Tobias Burnus]

Tobias Schlüter wrote:
> Tobias Burnus wrote:
>> After getting failures when building GCC with a non-English locale, I
>> found out that
>>
>>     huge=`$compile -c -fdump-parse-tree tmq$$.f90 | grep TRANSFER \
>>                 | sed 's/ *TRANSFER *// ; s/_.*//'`
>
> Since I couldn't find this expression, and since I can't think of an
> occasion where one would both want to match TRANSFER and where it's a
> good idea to translate it, I'm curious: could you say where or how
> this happens?

Did you do an "svn up"? The line was checked in this morning by FX.
Thus you really should have this line or SVN has serious troubles.


The problem was that GFC_REAL_16_HUGE etc. were sometimes different in
the library than huge(0.0_16) of the compiler.

Namely, on PowerPC and MIPS  huge(0.0_16) is not LDBL_MAX.

See:
http://gcc.gnu.org/ml/fortran/2007-09/msg00466.html
and
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00515.html


Now the following is used in libgfortran/mk-kinds-h.sh:

    # Check for the value of HUGE
    echo "print *, huge(0._$k) ; end" > tmq$$.f90
    huge=`$compile -c -fdump-parse-tree tmq$$.f90 | grep TRANSFER \
                | sed 's/ *TRANSFER *// ; s/_.*//'`

And "gfortran -fdump-parse-tree c.f90" shows than:
[...]
      WRITE UNIT=6 FMT=-1
        TRANSFER 3.40282347e38
      DT_END

which is, e.g., with a German locale translated to the barely readable
      SCHREIBEN EINHEIT=6 FMT=-1
        ÜBERTRAGUNG 3.40282347e38
      DT_END
and thus the grep fails.

Tobias

Re: [Patch, Fortran, committed] Add LANG=C to libgfortran/mk-kinds-h.sh

[FX Coudert]

>     huge=`$compile -c -fdump-parse-tree tmq$$.f90 | grep TRANSFER \
>                 | sed 's/ *TRANSFER *// ; s/_.*//'`
>
> only works if TRANSFER is not translated in the dump.

If TRANSFER is translated, it's a bug a) in the gfortran POT file,  
probably by an overzealous, and b) in the front-end, which shouldn't  
mark this string for localization. Can you look into it?

> Index: libgfortran/mk-kinds-h.sh
> ===================================================================
> --- libgfortran/mk-kinds-h.sh   (Revision 129657)
> +++ libgfortran/mk-kinds-h.sh   (Arbeitskopie)
> @@ -1,4 +1,6 @@
>  #!/bin/sh
> +LANG=C
> +export LANG
>
>  compile="$1"

Is that completely portable? I'm never sure how environment variables  
work with different shells.

FX

Re: [Patch, Fortran, committed] Add LANG=C to libgfortran/mk-kinds-h.sh

[FX Coudert]

>>     huge=`$compile -c -fdump-parse-tree tmq$$.f90 | grep TRANSFER \
>>                 | sed 's/ *TRANSFER *// ; s/_.*//'`
>>
>> only works if TRANSFER is not translated in the dump.
>
> If TRANSFER is translated, it's a bug a) in the gfortran POT file,  
> probably by an overzealous, and b) in the front-end, which  
> shouldn't mark this string for localization. Can you look into it?

I should have added, though, that I'm fine with the patch to mk-kinds- 
h.sh (except the portability question). For my defence, I had checked  
that MPFR output strings with a point as decimal marker, and not a  
comma, whatever the locale is.

FX

Re: [Patch, Fortran, committed] Add LANG=C to libgfortran/mk-kinds-h.sh

[Tobias Burnus]

FX Coudert wrote:
> If TRANSFER is translated, it's a bug a) in the gfortran POT file,
> probably by an overzealous, and b) in the front-end, which shouldn't
> mark this string for localization. Can you look into it?
I think you mean in the PO and not in the POT (T = Template) file.

If you look at zh_TW they also translate:

   procedure name = MAIN__

into

   程序名 = MAIN__

However, I'm not sure whether it is really a bug. For me, the English
output is clearer, but for some users it might be different.

Thus I don't see a reason for me to look into it - other things in
gfortran (and real life) are more important for me.


>>  #!/bin/sh
>> +LANG=C
>> +export LANG
>
> Is that completely portable?
I'm not 100% sure if there is an extremely odd shell which handles this
differently, but assuming that /bin/sh is more-or-less standard-adhering
POSIX shell, it should work.

Besides, the same is also used in libstdc++-v3/scripts/extract_symvers.


Tobias

Re: [Patch, Fortran, committed] Add LANG=C to libgfortran/mk-kinds-h.sh

[FX Coudert]

> However, I'm not sure whether it is really a bug. For me, the English
> output is clearer, but for some users it might be different.

I thought dumps where supposed to be machine-parsable, and thus non  
localized. I agree that it's of low priority, though.

> Thus I don't see a reason for me to look into it - other things in
> gfortran (and real life) are more important for me.

Of course. I was wondering if you could tell us which locale  
triggered the original problem, but a grep answers: de, es and tr are  
currently the only one oncerned.

> Besides, the same is also used in libstdc++-v3/scripts/ 
> extract_symvers.

That's convincing enough!

Thanks,
FX

Re: [Patch, Fortran, committed] Add LANG=C to libgfortran/mk-kinds-h.sh

[Andreas Schwab]

Tobias Burnus <burnus@net-b.de> writes:

> Index: libgfortran/mk-kinds-h.sh
> ===================================================================
> --- libgfortran/mk-kinds-h.sh   (Revision 129657)
> +++ libgfortran/mk-kinds-h.sh   (Arbeitskopie)
> @@ -1,4 +1,6 @@
>  #!/bin/sh
> +LANG=C
> +export LANG

If you want to ensure C locale you need to set LC_ALL, not LANG.  The
latter is only used as fallback, any setting of LC_foo will override it.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Patch, Fortran, committed] Add LANG=C to libgfortran/mk-kinds-h.sh

[Tobias Schlüter]

Tobias Burnus wrote:
> Tobias SchlÃŒter wrote:
>> Tobias Burnus wrote:
>>> After getting failures when building GCC with a non-English locale, I
>>> found out that
>>>
>>>     huge=`$compile -c -fdump-parse-tree tmq$$.f90 | grep TRANSFER \
>>>                 | sed 's/ *TRANSFER *// ; s/_.*//'`
>> Since I couldn't find this expression, and since I can't think of an
>> occasion where one would both want to match TRANSFER and where it's a
>> good idea to translate it, I'm curious: could you say where or how
>> this happens?
> 
> Did you do an "svn up"? The line was checked in this morning by FX.
> Thus you really should have this line or SVN has serious troubles.

Weird, I assume that my regexp was wrong :-(

> And "gfortran -fdump-parse-tree c.f90" shows than:
> [...]
>       WRITE UNIT=6 FMT=-1
>         TRANSFER 3.40282347e38
>       DT_END
> 
> which is, e.g., with a German locale translated to the barely readable
>       SCHREIBEN EINHEIT=6 FMT=-1
>         ÃœBERTRAGUNG 3.40282347e38
>       DT_END
> and thus the grep fails.

Wow!  I think I'll submit DÜ-ENDE as translation of DT_END and it should 
also be ÃœBERTRAGE.

Thanks for the explanation.

Cheers,
- Tobi

Re: [Patch, Fortran, committed] Add LANG=C to libgfortran/mk-kinds-h.sh

[Andrew Pinski]

On 10/26/07, Tobias Schlüter <tobias.schlueter@physik.uni-muenchen.de> wrote:
> Wow!  I think I'll submit DÜ-ENDE as translation of DT_END and it should
> also be ÜBERTRAGE.

Shouldn't the parse tree not be translated?  It seems like the better
fix is to fix the fortran front-end so it is not translated.

Thanks,
Andrew Pinski

Re: [Patch, Fortran, committed] Add LANG=C to libgfortran/mk-kinds-h.sh

[Tobias Schlüter]

Andrew Pinski wrote:
> On 10/26/07, Tobias Schlüter <tobias.schlueter@physik.uni-muenchen.de> wrote:
>> Wow!  I think I'll submit DÜ-ENDE as translation of DT_END and it should
>> also be ÃœBERTRAGE.
> 
> Shouldn't the parse tree not be translated?  It seems like the better
> fix is to fix the fortran front-end so it is not translated.

My bad, I thought it would be obvious that I was joking.

Cheers,
- Tobi

Re: [Patch, Fortran, committed] Add LANG=C to libgfortran/mk-kinds-h.sh

[Tobias Burnus]

Andreas Schwab wrote:
> Tobias Burnus <burnus@net-b.de> writes:
>   
>> Index: libgfortran/mk-kinds-h.sh
>> +LANG=C
>> +export LANG
>>     
> If you want to ensure C locale you need to set LC_ALL, not LANG.  The
> latter is only used as fallback, any setting of LC_foo will override it.
>   
Good point. I doubt that it will matter in practice, but LC_MESSAGES and
LC_ALL let indeed resurface this problem.

I therefore changed now LANG=C into LC_ALL=C.

Thanks for the comment!

Tobias

Committed as Rev. 129679.

Index: libgfortran/ChangeLog
===================================================================
--- libgfortran/ChangeLog       (Revision 129678)
+++ libgfortran/ChangeLog       (Arbeitskopie)
@@ -1,3 +1,7 @@
+2007-10-27  Tobias Burnus  <burnus@net-b.de>
+
+       * mk-kinds-h.sh: Change "LANG=C" to LC_ALL=C.
+
 2007-10-26  Tobias Burnus  <burnus@net-b.de>

        * mk-kinds-h.sh: Add "LANG=C".
Index: libgfortran/mk-kinds-h.sh
===================================================================
--- libgfortran/mk-kinds-h.sh   (Revision 129678)
+++ libgfortran/mk-kinds-h.sh   (Arbeitskopie)
@@ -1,6 +1,6 @@
 #!/bin/sh
-LANG=C
-export LANG
+LC_ALL=C
+export LC_ALL

 compile="$1"