[Bug fortran/66499] New: Letters with accents change format behavior for X and T descriptors.

[Bug fortran/66499] New: Letters with accents change format behavior for X and T descriptors.

[tbrego at gmail dot com]

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

            Bug ID: 66499
           Summary: Letters with accents change format behavior for X and
                    T descriptors.
           Product: gcc
           Version: 4.8.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tbrego at gmail dot com
  Target Milestone: ---

When use letters with accents change the position for tabbing (T) and
horizontal (X).

Example: test_char.f95
program test_character
real:: a
character(len=30):: char1, char2

a = 10
char1 = "Test without local char"
char2 = "Test with local char áç"

10 format(2X, A, T40, f10.4)

write(*,10) char1, a
write(*,10) char2, a

end program


Output:
  Test without local char                 10.0000
  Test with local char áç               10.0000
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Gap two position (one for each letter).
>From gcc-bugs-return-488682-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 02:42:37 2015
Return-Path: <gcc-bugs-return-488682-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 88142 invoked by alias); 11 Jun 2015 02:42:18 -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 88089 invoked by uid 48); 11 Jun 2015 02:42:09 -0000
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66500] New: C/C++ inconsistency in diagnostic context involving macros
Date: Thu, 11 Jun 2015 02:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: msebor at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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 target_milestone
Message-ID: <bug-66500-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: 2015-06/txt/msg01014.txt.bz2
Content-length: 5529

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

            Bug ID: 66500
           Summary: C/C++ inconsistency in diagnostic context involving
                    macros
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following test case shows that gcc and g++ emit different and sometimes
misleading context in diagnostic messages involving macros:

1) In C mode, gcc points at the offending operator, while in C++ mode it points
at an operand.  Since in this case the type of the operand the C++ diagnostic
points to is (before conversion) int, the diagnostic is misleading.

2) In C mode, gcc includes a note showing the context from which the macro was
invoked when the operand is the result of macro expansion, while in C++ mode it
does the same for the operand.

For consistency's sake it would be useful to harmonize the two.  It seems to me
that the C output makes more sense than the output produced in C++ mode since
the issue the warning points out is not specific to one or the other operand
but rather to the operator for operators of the (converted) type.

$ (set -x && cat u.c && gcc -S -Wfloat-equal -o/dev/null u.c && gcc -S
-Wfloat-equal -o/dev/null -xc++ u.c)
+ cat u.c
int f0 (double x, int y) {
    return x == y;
}

#define A(A) A
int f1 (double x, int y) {
    return A (x) == A (y);
}

#define EQL ==
int f2 (double x, int y) {
    return x EQL y;
}

#define EQUAL(A, B) A == B
int f3 (double x, int y) {
    return EQUAL (x, y);
}

+ gcc -S -Wfloat-equal -o/dev/null u.c
u.c: In function ‘f0’:
u.c:2:14: warning: comparing floating point with == or != is unsafe
[-Wfloat-equal]
     return x == y;
              ^
u.c: In function ‘f1’:
u.c:7:18: warning: comparing floating point with == or != is unsafe
[-Wfloat-equal]
     return A (x) == A (y);
                  ^
u.c: In function ‘f2’:
u.c:10:13: warning: comparing floating point with == or != is unsafe
[-Wfloat-equal]
 #define EQL ==
             ^
u.c:12:14: note: in expansion of macro ‘EQL’
     return x EQL y;
              ^
u.c: In function ‘f3’:
u.c:15:23: warning: comparing floating point with == or != is unsafe
[-Wfloat-equal]
 #define EQUAL(A, B) A == B
                       ^
u.c:17:12: note: in expansion of macro ‘EQUAL’
     return EQUAL (x, y);
            ^
+ gcc -S -Wfloat-equal -o/dev/null -xc++ u.c
u.c: In function ‘int f0(double, int)’:
u.c:2:17: warning: comparing floating point with == or != is unsafe
[-Wfloat-equal]
     return x == y;
                 ^
u.c: In function ‘int f1(double, int)’:
u.c:7:24: warning: comparing floating point with == or != is unsafe
[-Wfloat-equal]
     return A (x) == A (y);
                        ^
u.c:5:14: note: in definition of macro ‘A’
 #define A(A) A
              ^
u.c: In function ‘int f2(double, int)’:
u.c:12:18: warning: comparing floating point with == or != is unsafe
[-Wfloat-equal]
     return x EQL y;
                  ^
u.c: In function ‘int f3(double, int)’:
u.c:17:22: warning: comparing floating point with == or != is unsafe
[-Wfloat-equal]
     return EQUAL (x, y);
                      ^
u.c:15:26: note: in definition of macro ‘EQUAL’
 #define EQUAL(A, B) A == B
                          ^


In contrast, Clang output is consistent and clear in both modes without notes
that include the context of macro expansion where it isn't necessary:

+ /build/llvm-3.6.0/bin/clang -S -Wfloat-equal -o/dev/null u.c
u.c:2:14: warning: comparing floating point with == or != is unsafe
      [-Wfloat-equal]
    return x == y;
           ~ ^  ~
u.c:7:18: warning: comparing floating point with == or != is unsafe
      [-Wfloat-equal]
    return A (x) == A (y);
              ~  ^     ~
u.c:12:14: warning: comparing floating point with == or != is unsafe
      [-Wfloat-equal]
    return x EQL y;
           ~ ^   ~
u.c:10:13: note: expanded from macro 'EQL'
#define EQL ==
            ^
u.c:17:12: warning: comparing floating point with == or != is unsafe
      [-Wfloat-equal]
    return EQUAL (x, y);
           ^      ~  ~
u.c:15:23: note: expanded from macro 'EQUAL'
#define EQUAL(A, B) A == B
                      ^
4 warnings generated.
+ /build/llvm-3.6.0/bin/clang++ -S -Wfloat-equal -o/dev/null -xc++ u.c
u.c:2:14: warning: comparing floating point with == or != is unsafe
      [-Wfloat-equal]
    return x == y;
           ~ ^  ~
u.c:7:18: warning: comparing floating point with == or != is unsafe
      [-Wfloat-equal]
    return A (x) == A (y);
              ~  ^     ~
u.c:12:14: warning: comparing floating point with == or != is unsafe
      [-Wfloat-equal]
    return x EQL y;
           ~ ^   ~
u.c:10:13: note: expanded from macro 'EQL'
#define EQL ==
            ^
u.c:17:12: warning: comparing floating point with == or != is unsafe
      [-Wfloat-equal]
    return EQUAL (x, y);
           ^      ~  ~
u.c:15:23: note: expanded from macro 'EQUAL'
#define EQUAL(A, B) A == B
                      ^
4 warnings generated.
>From gcc-bugs-return-488683-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 03:01:26 2015
Return-Path: <gcc-bugs-return-488683-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 104846 invoked by alias); 11 Jun 2015 03:01:26 -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 104805 invoked by uid 48); 11 Jun 2015 03:01:22 -0000
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66484] Exception specification can declare a pointer to incomplete type, which is against C++ standard section 15.1
Date: Thu, 11 Jun 2015 03:01:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords: accepts-invalid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: msebor at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
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: cc
Message-ID: <bug-66484-4-NPQm0DOqsM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66484-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66484-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: 2015-06/txt/msg01015.txt.bz2
Content-length: 1153

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

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

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
The relevant text is in 15.4 Exception specifications, p2:

   A type denoted in an exception-specification shall not denote a pointer or
reference to an incomplete type, other than cv void* or a pointer or reference
to a class currently being defined.

The test case below contrasts the diagnostic issued for an ordinary function to
the absence of one for the implicit specialization of the function template.

$ cat u.c && gcc -c -std=c++11 -xc++ u.c
struct S;

void f () throw (S*);

template <class T> void g () throw (T);

void foo () {
    g<S*>();
}
u.c:3:19: warning: invalid use of incomplete type ‘struct S’
 void f () throw (S*);
                   ^
u.c:1:8: warning: forward declaration of ‘struct S’
 struct S;
        ^
>From gcc-bugs-return-488684-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 05:18:28 2015
Return-Path: <gcc-bugs-return-488684-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 127704 invoked by alias); 11 Jun 2015 05:18:27 -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 127551 invoked by uid 48); 11 Jun 2015 05:18:08 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66500] C/C++ inconsistency in diagnostic context involving macros
Date: Thu, 11 Jun 2015 05:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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: cc
Message-ID: <bug-66500-4-ju9NTJp0nc@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66500-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66500-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: 2015-06/txt/msg01016.txt.bz2
Content-length: 536

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

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

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Dup of PR52998 ?

You can find more bugs about the macro unwinder at
https://gcc.gnu.org/wiki/Better_Diagnostics (I).
>From gcc-bugs-return-488685-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 05:26:31 2015
Return-Path: <gcc-bugs-return-488685-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 50440 invoked by alias); 11 Jun 2015 05:26:31 -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 47798 invoked by uid 48); 11 Jun 2015 05:26:26 -0000
From: "rusty at rustcorp dot com.au" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
Date: Thu, 11 Jun 2015 05:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: rusty at rustcorp dot com.au
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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-66425-4-jydIIZ167b@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66425-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66425-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: 2015-06/txt/msg01017.txt.bz2
Content-length: 296

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

--- Comment #3 from rusty at rustcorp dot com.au ---
Indeed, cast to void has been a standard "I really want to ignore this"
notation.  It's intuitive and obvious, and ISTR seeing it in the early 90s for
lint warning suppression, for example.

[Bug fortran/66499] Letters with accents change format behavior for X and T descriptors.

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-06-11
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmed from 4.8.4 up to trunk (6.0). If I add the lines

print *, len(trim(char1))
print *, len(trim(char2))

I get

          23
          25

So each à counts as two characters, while it is printed as only one. This make
me wonder if the code is valid. However the following variant

program test_character
real:: a
character(len=30, kind=4):: char1, char2

a = 10
char1 = 4_"Test without local char"
char2 = 4_"Test with local char ÃÃ"

10 format(2X, A, T40, f10.4)

open(6, encoding="utf-8")

print *, len(trim(char1))
print *, len(trim(char2))

write(*,10) char1, a
write(*,10) char2, a

end program

gives

          23
          25
  Test without local char                 10.0000
  Test with local char ÃÃ           10.0000

???
>From gcc-bugs-return-488720-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 09:20:53 2015
Return-Path: <gcc-bugs-return-488720-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 76337 invoked by alias); 11 Jun 2015 09:20:53 -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 76292 invoked by uid 48); 11 Jun 2015 09:20:48 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/66502] SCCVN can't handle PHIs optimistically optimally
Date: Thu, 11 Jun 2015 09:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66502-4-xNvh1p3pY8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66502-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66502-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: 2015-06/txt/msg01052.txt.bz2
Content-length: 279

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Someone craft a testcase where both cases are interconnected and thus no
optimization is performed currently with either scheme (but would with
merged SCCs).

[Bug fortran/66499] Letters with accents change format behavior for X and T descriptors.

[jvdelisle at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |jvdelisle at gcc dot gnu.org

--- Comment #2 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
UTF-8 is a variable length encoding.  That explains the 6 character difference.
 The tabbing code assumes a fixed length per character.  I will have to
investigate this further.  I suspect we are counting bytes, assuming the
position from where we left off.

[Bug fortran/66499] Letters with accents change format behavior for X and T descriptors.

[jvdelisle at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |jvdelisle at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |jvdelisle at gcc dot gnu.org

--- Comment #4 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
The case in the original report is likely not valid without setting the
encoding for the output unit as Dominique has done in Comment 1. The problem
here is likely similar to 99210.

[Bug fortran/66499] Letters with accents change format behavior for X and T descriptors.

[jvdelisle at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW

[Bug fortran/66499] Letters with accents change format behavior for X and T descriptors.

[jvdelisle at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |jvdelisle at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |jvdelisle at gcc dot gnu.org

--- Comment #5 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
assigning to myself

[Bug fortran/66499] Letters with accents change format behavior for X and T descriptors.

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
This is an interesting puzzle. I took the -fdump-tree-original output of
compiling the test case and edited out all except the initialization of the two
variables char1 and char2.

I lined these up so we could see what each 4-byte character looks like.  The
last two characters should be two characters of c383.  We are generating c300
8300 for each character.

-------------------

__builtin_memmove ((void *) &char1, (void *) &"
T\x00\x00\x00
e\x00\x00\x00
s\x00\x00\x00
t\x00\x00\x00
 \x00\x00\x00
w\x00\x00\x00
i\x00\x00\x00
t\x00\x00\x00
h\x00\x00\x00
o\x00\x00\x00
u\x00\x00\x00
t\x00\x00\x00
 \x00\x00\x00
l\x00\x00\x00
o\x00\x00\x00
c\x00\x00\x00
a\x00\x00\x00
l\x00\x00\x00
 \x00\x00\x00
c\x00\x00\x00
h\x00\x00\x00
a\x00\x00\x00
r\x00\x00"[1]{lb: 1 sz: 4}, 92);

    __builtin_memmove ((void *) &char2, (void *) &"
T\x00\x00\x00
e\x00\x00\x00
s\x00\x00\x00
t\x00\x00\x00
 \x00\x00\x00
w\x00\x00\x00
i\x00\x00\x00
t\x00\x00\x00
h\x00\x00\x00
 \x00\x00\x00
l\x00\x00\x00
o\x00\x00\x00
c\x00\x00\x00
a\x00\x00\x00
l\x00\x00\x00
 \x00\x00\x00
c\x00\x00\x00
h\x00\x00\x00
a\x00\x00\x00
r\x00\x00\x00
 \x00\x00\x00
\xc3\x00\x00\x00
\x83\x00\x00\x00
\xc3\x00\x00\x00
\x83\x00\x00"[1]{lb: 1 sz: 4}, 100);

[Bug fortran/66499] Letters with accents change format behavior for X and T descriptors.

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
There two issues going on here. We do not interpret source code that is UTF-8
encoded.  This is why in our current tests for UTF-8 encoding of data files we
us hexidecimal codes.

I will have to see what the standard says about non=ASCII character sets in
source code.

If I get around this by using something like this:

char1 = 4_"Test without local char"
char2 = 4_"Test with local char "

char2(22:22) = 4_"Ã"
char2(23:23) = 4_"Ã"

$ ./a.out 
          23
          23
1234567890123456789012345678901234567890
  Test without local char              10.0000
  Test with local char ÃÃ            10.0000

The string lengths now match correctly.  One can see the tabbing is still off. 
This is because the format buffer seek functions are byte oriented and when
using UTF-8 encoding we need to seek the buffer differently. In fact we have to
allocate it differently as well to maintain the four byte characters.