[Bug fortran/27715] New: Extented ASCII characters lead to wrong "CASE" selection

[Bug fortran/27715] New: Extented ASCII characters lead to wrong "CASE" selection

[P dot Schaffnit at access dot rwth-aachen dot de]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]

Hi!

I am under the impression that using "extended ASCII" wrecks "CASE
constructs"... (see example hereafter).

Cheers!

Philippe

PS: The following code lands on the default:

!
      PROGRAM Test
!
      CHARACTER ( LEN = 1 ) :: Letter
!
      Letter = "c"
      SELECT CASE ( Letter )
      CASE ( "c", "ç" )
        WRITE ( 6, "(A)" ) "Expected"
      CASE DEFAULT
        WRITE ( 6, "(A)" ) "Surprising"
      END SELECT
!
      END PROGRAM Test
!

PPPS: I' using:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /USER/philippe/Irix/Gcc_Sources/configure
--prefix=/usr1/MICRESS/Philippe/Tools/Gcc --enable-languages=c,fortran
--disable-maintainer-mode --disable-shared
--with-mpfr=/usr1/MICRESS/Philippe/Tools/Mpfr
--with-gmp=/usr1/MICRESS/Philippe/Tools/Gmp
Thread model: posix
gcc version 4.2.0 20060519 (experimental)


-- 
           Summary: Extented ASCII characters lead to wrong "CASE" selection
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: P dot Schaffnit at access dot rwth-aachen dot de
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

[fxcoudert at gcc dot gnu dot org]

------- Comment #1 from fxcoudert at gcc dot gnu dot org  2006-05-27 08:12 -------
Bug confirmed, not i686-linux specific.

The problem is that the front-end sorts the different possibilities inside a
case statement so that a binary search can be performed at runtime by the
library. But, for extended characters, front-end and library seem to have
different orders, and thus the list ordered by the front-end is not ordered for
the library, leading to a failure of the binary search.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
  GCC build triplet|i686-pc-linux-gnu           |
   GCC host triplet|i686-pc-linux-gnu           |
 GCC target triplet|i686-pc-linux-gnu           |
   Last reconfirmed|0000-00-00 00:00:00         |2006-05-27 08:12:07
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

[tkoenig at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]



------- Comment #2 from tkoenig at gcc dot gnu dot org  2006-05-28 14:53 -------
It's even worse:

$ cat cmp.f
      program main
      external isgreater
      logical isgreater
      print *,"a" > "ä"
      print *,isgreater("a", "ä")
      end

      logical function isgreater(s1, s2)
      character*1 s1, s2
      isgreater = s1 > s2
      end
$ gfortran cmp.f
$ ./a.out
 T
 F

The front end comparison is done using C's native char, whereas
the back end uses strncmp (or memcpy to fix PR 27784, hopefully soon),
which treats chars as unsigned.

Naturally, this leads to breakage when the native char type is signed.

Oh well... this doesn't look too hard to fix.  The front end should
use unsigned char.


-- 

tkoenig at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tkoenig at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

[fxcoudert at gcc dot gnu dot org]

------- Comment #3 from fxcoudert at gcc dot gnu dot org  2006-05-28 15:59 -------
Created an attachment (id=11525)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11525&action=view)
Proposed patch

I'm tempted to propose the attached patch. It makes the front-end ultimately
use unsigned chars to do the comparison, and also removes the use of the
reverse ASCII collating table for this, because I don't understand how it is
supposed to be useful :)

Opinions?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

[tkoenig at gcc dot gnu dot org]

------- Comment #4 from tkoenig at gcc dot gnu dot org  2006-05-28 16:10 -------
(In reply to comment #3)
> Created an attachment (id=11525)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11525&action=view) [edit]
> Proposed patch
> 
> I'm tempted to propose the attached patch. It makes the front-end ultimately
> use unsigned chars to do the comparison, and also removes the use of the
> reverse ASCII collating table for this, because I don't understand how it is
> supposed to be useful :)

What about using

    struct
    {
      int length;
      unsigned char *string;
    }
    character;

in gfc_expr?  There would be a few fallout issues in
other places (I assume some "char *" pointers would have
to become "unsigned char*"), but it would be much cleaner overall.

As far as the collating sequence goes... should we eventually
support locales for sorting etc.?  If so, we should leave the
code in.

in gfc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

[fxcoudert at gcc dot gnu dot org]

------- Comment #5 from fxcoudert at gcc dot gnu dot org  2006-05-28 16:32 -------
(In reply to comment #4)
>       unsigned char *string;

Humpf, I don't know. I don't think it's the best course of action... too
invasive.

> As far as the collating sequence goes... should we eventually
> support locales for sorting etc.?  If so, we should leave the
> code in.

I think we don't want locales support in sorting with the default character
kind, and if we ever want to implement that, I don't think we'll want to do it
that way :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

[kargl at gcc dot gnu dot org]

------- Comment #6 from kargl at gcc dot gnu dot org  2006-05-28 16:52 -------
Guys,

Have you read 4.3.2.1.1?  This defines the requirements on the
collating of the default character type.  It also defines the
requirements on LGT, LGE, LLE, and LLT, which is why we use the
ascii_table in simplify.c.

Thomas' idea of using unsigned char does not conflict with
4.3.2.1.1.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

[fxcoudert at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3250 bytes --]



------- Comment #7 from fxcoudert at gcc dot gnu dot org  2006-05-28 19:56 -------
(In reply to comment #6)
> Have you read 4.3.2.1.1?  This defines the requirements on the
> collating of the default character type.  It also defines the
> requirements on LGT, LGE, LLE, and LLT, which is why we use the
> ascii_table in simplify.c.

OK, I see. I think we don't have users around here using non ASCII-based
charsets, and I also think other parts of the front-end and library would fall
apart on such systems, but anyway, that's not the point.

Anyway, I know it's standard conforming, but having both LLE("é","è") and
LGE("é","è") returning true is... always surprising.

> Thomas' idea of using unsigned char does not conflict with
> 4.3.2.1.1.

Yes, but C strings are char by default and not unsigned char, so I guess we'd
best avoid changing that. But, a less invasive fix could be:

Index: simplify.c
===================================================================
--- simplify.c  (revision 113849)
+++ simplify.c  (working copy)
@@ -67,7 +67,7 @@
 /* Static table for converting non-ascii character sets to ascii.
    The xascii_table[] is the inverse table.  */

-static int ascii_table[256] = {
+static unsigned char ascii_table[256] = {
   '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0',
   '\b', '\t', '\n', '\v', '\0', '\r', '\0', '\0',
   '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0',
@@ -86,7 +86,7 @@
   'x', 'y', 'z', '{', '|', '}', '~', '\?'
 };

-static int xascii_table[256];
+static unsigned int xascii_table[256];


 /* Range checks an expression node.  If all goes well, returns the
@@ -1196,7 +1196,7 @@
       return &gfc_bad_expr;
     }

-  index = xascii_table[(int) e->value.character.string[0] & 0xFF];
+  index = xascii_table[(unsigned char) e->value.character.string[0] & 0xFF];

   result = gfc_int_expr (index);
   result->where = e->where;
@@ -4016,9 +4016,9 @@
 /* Given a collating table, create the inverse table.  */

 static void
-invert_table (const int *table, int *xtable)
+invert_table (const unsigned char *table, unsigned int *xtable)
 {
-  int i;
+  unsigned int i;

   for (i = 0; i < 256; i++)
     xtable[i] = 0;
Index: arith.c
===================================================================
--- arith.c     (revision 113849)
+++ arith.c     (working copy)
@@ -1122,9 +1122,10 @@
    collating sequence.  */

 int
-gfc_compare_string (gfc_expr * a, gfc_expr * b, const int *xcoll_table)
+gfc_compare_string (gfc_expr * a, gfc_expr * b, const unsigned int
*xcoll_table)
 {
-  int len, alen, blen, i, ac, bc;
+  int len, alen, blen, i;
+  unsigned char ac, bc;

   alen = a->value.character.length;
   blen = b->value.character.length;
Index: arith.h
===================================================================
--- arith.h     (revision 113849)
+++ arith.h     (working copy)
@@ -41,7 +41,7 @@
 arith gfc_range_check (gfc_expr *);

 int gfc_compare_expr (gfc_expr *, gfc_expr *);
-int gfc_compare_string (gfc_expr *, gfc_expr *, const int *);
+int gfc_compare_string (gfc_expr *, gfc_expr *, const unsigned int *);

 /* Constant folding for gfc_expr trees.  */
 gfc_expr *gfc_uplus (gfc_expr * op);


Comments on this one?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2006-05-28 20:03 -------
(In reply to comment #7)
> (In reply to comment #6)
> > Have you read 4.3.2.1.1?  This defines the requirements on the
> > collating of the default character type.  It also defines the
> > requirements on LGT, LGE, LLE, and LLT, which is why we use the
> > ascii_table in simplify.c.
> 
> OK, I see. I think we don't have users around here using non ASCII-based
> charsets, and I also think other parts of the front-end and library would fall
> apart on such systems, but anyway, that's not the point.

GCC does support other charatersets besides ASCII ( the IBM one is an example):

the middle-end does something like:
      target_newline = lang_hooks.to_target_charset ('\n');
      target_percent = lang_hooks.to_target_charset ('%');
      target_c = lang_hooks.to_target_charset ('c');
      target_s = lang_hooks.to_target_charset ('s');

To find %s for folding of printf, etc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2006-05-28 20:05 -------
(In reply to comment #7)
> Yes, but C strings are char by default and not unsigned char, so I guess we'd
> best avoid changing that. But, a less invasive fix could be:

And char can either default to unsigned or signed (it is the only type which is
like this in C).
For an example on most OS's on PPC, char defaults to unsigned char (and not
signed char).

-- Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
                   |dot org                     |org
                URL|                            |http://gcc.gnu.org/ml/fortra
                   |                            |n/2006-05/msg00489.html
             Status|NEW                         |ASSIGNED
           Keywords|                            |patch
      Known to fail|                            |4.2.0 4.1.2
   Last reconfirmed|2006-05-27 08:12:07         |2006-05-29 13:10:14
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

[patchapp at dberlin dot org]

------- Comment #10 from patchapp at dberlin dot org  2006-05-29 13:10 -------
Subject: Bug number PR fortran/27715

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01460.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

[tkoenig at gcc dot gnu dot org]

------- Comment #11 from tkoenig at gcc dot gnu dot org  2006-05-30 19:31 -------
Hi FX,

what about

Index: arith.c
===================================================================
--- arith.c     (revision 114111)
+++ arith.c     (working copy)
@@ -1133,8 +1133,10 @@ gfc_compare_string (gfc_expr * a, gfc_ex

   for (i = 0; i < len; i++)
     {
-      ac = (i < alen) ? a->value.character.string[i] : ' ';
-      bc = (i < blen) ? b->value.character.string[i] : ' ';
+      /* We cast to unsigned char because default char, if it is signed,
+         would lead to ac<0 for string[i] > 127.  */
+      ac = (unsigned char) ((i < alen) ? a->value.character.string[i] : ' ');
+      bc = (unsigned char) ((i < blen) ? b->value.character.string[i] : ' ');

       if (xcoll_table != NULL)
        {

?

I've regression-tested this, it does fix the test cases.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

[fxcoudert at gcc dot gnu dot org]

------- Comment #12 from fxcoudert at gcc dot gnu dot org  2006-06-01 15:44 -------
(In reply to comment #11)
> Index: arith.c
> ===================================================================
> --- arith.c     (revision 114111)
> +++ arith.c     (working copy)
> @@ -1133,8 +1133,10 @@ gfc_compare_string (gfc_expr * a, gfc_ex
> 
>    for (i = 0; i < len; i++)
>      {
> -      ac = (i < alen) ? a->value.character.string[i] : ' ';
> -      bc = (i < blen) ? b->value.character.string[i] : ' ';
> +      /* We cast to unsigned char because default char, if it is signed,
> +         would lead to ac<0 for string[i] > 127.  */
> +      ac = (unsigned char) ((i < alen) ? a->value.character.string[i] : ' ');
> +      bc = (unsigned char) ((i < blen) ? b->value.character.string[i] : ' ');
> 
>        if (xcoll_table != NULL)
>         {

OK. Although I still like better my previous patch, there's no point arguing
over this for years. Go ahead!


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|http://gcc.gnu.org/ml/fortra|
                   |n/2006-05/msg00489.html     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

[tkoenig at gcc dot gnu dot org]

------- Comment #13 from tkoenig at gcc dot gnu dot org  2006-06-01 19:24 -------
Subject: Bug 27715

Author: tkoenig
Date: Thu Jun  1 19:23:56 2006
New Revision: 114317

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114317
Log:
2006-06-01  Thomas Koenig  <Thomas.Koenig@online.de>

        PR fortran/27715
        * arith.c:  Cast the characters from the strings to unsigned
        char to avoid values less than 0 for extended ASCII.

2006-06-01  Thomas Koenig  <Thomas.Koenig@online.de>

        PR fortran/27715
        * gfortran.dg/extended_char_comparison_1.f:  New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/extended_char_comparison_1.f
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/arith.c
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] [4.1 only] Extented ASCII characters lead to wrong "CASE" selection

[fxcoudert at gcc dot gnu dot org]

------- Comment #14 from fxcoudert at gcc dot gnu dot org  2006-06-13 06:26 -------
Thomas, could you backport your patch to 4.1? (when you have some time, of
course)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] [4.1 only] Extented ASCII characters lead to wrong "CASE" selection

[tkoenig at gcc dot gnu dot org]

------- Comment #15 from tkoenig at gcc dot gnu dot org  2006-06-16 19:47 -------
(In reply to comment #14)
> Thomas, could you backport your patch to 4.1? (when you have some time, of
> course)

Hi FX,

I have a few major RL concerns next week (a few critical presentations to
give, ...) and will be on holiday for two weeks afterwards, so I suspect
I won't be able to do any backporting for about three weeks (simple
lack of time to run the regression tests).

If you want to, please go ahead and commit the fixes for PR 27980, PR 27715
and PR 27784 to 4.1.

Regards,
        Thomas


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] [4.1 only] Extented ASCII characters lead to wrong "CASE" selection

[fxcoudert at gcc dot gnu dot org]

------- Comment #16 from fxcoudert at gcc dot gnu dot org  2006-06-19 22:27 -------
(In reply to comment #15)
> If you want to, please go ahead and commit the fixes for PR 27980, PR 27715
> and PR 27784 to 4.1.

As I can't find sleep tonight, I'll be backporting those patches. I spent some
time trying to apply patch for PR27980 to mainline, only to realize it was
already in. If you include the PR number (just like in the ChangeLog) in the
commit message, the commit message will end up automagically in bugzilla, which
is very useful :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] [4.1 only] Extented ASCII characters lead to wrong "CASE" selection

[fxcoudert at gcc dot gnu dot org]

------- Comment #17 from fxcoudert at gcc dot gnu dot org  2006-06-20 06:04 -------
Subject: Bug 27715

Author: fxcoudert
Date: Tue Jun 20 06:04:14 2006
New Revision: 114803

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114803
Log:
2006-06-20  Francois-Xavier Coudert  <coudert@clipper.ens.fr>

        PR fortran/27958
        * trans-expr.c (gfc_conv_substring): If the substring start is
        greater than its end, the length of the substring is zero, and
        not negative.
        (gfc_trans_string_copy): Don't generate a call to
        _gfortran_copy_string when destination length is zero.

2006-06-20  Francois-Xavier Coudert  <coudert@clipper.ens.fr>

        PR libfortran/27895
        * resolve.c (compute_last_value_for_triplet): New function.
        (check_dimension): Correctly handle zero-sized array sections.
        Add checking on last element of array sections.

2006-06-20  Francois-Xavier Coudert  <coudert@clipper.ens.fr>

        * trans.c (gfc_msg_bounds, gfc_msg_fault, gfc_msg_wrong_return):
        Add strings for common runtime error messages.
        (gfc_trans_runtime_check): Add a locus argument, use a string
        and not a string tree for the message.
        * trans.h (gfc_trans_runtime_check): Change prototype accordingly.
        (gfc_msg_bounds, gfc_msg_fault, gfc_msg_wrong_return): Add proto.
        * trans-const.c (gfc_strconst_bounds, gfc_strconst_fault,
        gfc_strconst_wrong_return, gfc_strconst_current_filename): Remove.
        (gfc_init_constants): Likewise.
        * trans-const.h: Likewise.
        * trans-decl.c (gfc_build_builtin_function_decls): Call to
        _gfortran_runtime_error has only one argument, the message string.
        * trans-array.h (gfc_conv_array_ref): Add a symbol argument and a
        locus.
        * trans-array.c (gfc_trans_array_bound_check): Build precise
        error messages.
        (gfc_conv_array_ref): Use the new symbol argument and the locus
        to build more precise error messages.
        (gfc_conv_ss_startstride): More precise error messages.
        * trans-expr.c (gfc_conv_variable): Give symbol reference and
        locus to gfc_conv_array_ref.
        (gfc_conv_function_call): Use the new prototype for
        gfc_trans_runtime_check.
        * trans-stmt.c (gfc_trans_goto): Build more precise error message.
        * trans-io.c (set_string): Likewise.
        * trans-intrinsic.c (gfc_conv_intrinsic_bound): Use new prototype
        for gfc_trans_runtime_check.

2006-06-20  Thomas Koenig  <Thomas.Koenig@online.de>

        PR fortran/27715
        * arith.c:  Cast the characters from the strings to unsigned
        char to avoid values less than 0 for extended ASCII.

2006-06-20  Thomas Koenig  <Thomas.Koenig@online.de>

        PR libfortran/27784
        * intrinsics/string_intrinsics.c (compare_string):
        Use memcmp instead of strncmp to avoid tripping over
        CHAR(0) in a string.

2006-06-20  Francois-Xavier Coudert  <coudert@clipper.ens.fr>

        PR fortran/27958
        * gcc/testsuite/gfortran.dg/substr_2.f: New test.

2006-06-20  Francois-Xavier Coudert  <coudert@clipper.ens.fr>

        PR libfortran/27895
        * gfortran.dg/bounds_check_3.f90: New test.

2006-06-20  Thomas Koenig  <Thomas.Koenig@online.de>

        PR fortran/27715
        * gfortran.dg/extended_char_comparison_1.f:  New test.

2006-06-20  Thomas Koenig  <Thomas.Koenig@online.de>

        PR fortran/27784
        * gfortran.dg/string_null_compare_1.f:  New test case.

Added:
    branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/bounds_check_3.f90
      - copied unchanged from r114414,
trunk/gcc/testsuite/gfortran.dg/bounds_check_3.f90
   
branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/extended_char_comparison_1.f
      - copied unchanged from r114317,
trunk/gcc/testsuite/gfortran.dg/extended_char_comparison_1.f
    branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/string_null_compare_1.f
      - copied unchanged from r114175,
trunk/gcc/testsuite/gfortran.dg/string_null_compare_1.f
    branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/substr_2.f
      - copied unchanged from r114496,
trunk/gcc/testsuite/gfortran.dg/substr_2.f
Modified:
    branches/gcc-4_1-branch/gcc/fortran/ChangeLog
    branches/gcc-4_1-branch/gcc/fortran/arith.c
    branches/gcc-4_1-branch/gcc/fortran/resolve.c
    branches/gcc-4_1-branch/gcc/fortran/trans-array.c
    branches/gcc-4_1-branch/gcc/fortran/trans-array.h
    branches/gcc-4_1-branch/gcc/fortran/trans-const.c
    branches/gcc-4_1-branch/gcc/fortran/trans-const.h
    branches/gcc-4_1-branch/gcc/fortran/trans-decl.c
    branches/gcc-4_1-branch/gcc/fortran/trans-expr.c
    branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c
    branches/gcc-4_1-branch/gcc/fortran/trans-io.c
    branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c
    branches/gcc-4_1-branch/gcc/fortran/trans.c
    branches/gcc-4_1-branch/gcc/fortran/trans.h
    branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_1-branch/libgfortran/ChangeLog
    branches/gcc-4_1-branch/libgfortran/intrinsics/string_intrinsics.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

[fxcoudert at gcc dot gnu dot org]

------- Comment #18 from fxcoudert at gcc dot gnu dot org  2006-06-20 06:14 -------
Now also fixed on 4.1.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to fail|4.1.2                       |
      Known to work|                            |4.2.0 4.1.2
         Resolution|                            |FIXED
            Summary|[4.1 only] Extented ASCII   |Extented ASCII characters
                   |characters lead to wrong    |lead to wrong "CASE"
                   |"CASE" selection            |selection
   Target Milestone|---                         |4.1.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715