public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/66499] New: Letters with accents change format behavior for X and T descriptors.
@ 2015-06-11  1:56 tbrego at gmail dot com
  2015-06-11  9:20 ` [Bug fortran/66499] " dominiq at lps dot ens.fr
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: tbrego at gmail dot com @ 2015-06-11  1:56 UTC (permalink / raw)
  To: gcc-bugs

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.


^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-02-24 18:26 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-11  1:56 [Bug fortran/66499] New: Letters with accents change format behavior for X and T descriptors tbrego at gmail dot com
2015-06-11  9:20 ` [Bug fortran/66499] " dominiq at lps dot ens.fr
2015-06-11 22:52 ` jvdelisle at gcc dot gnu.org
2021-02-28 16:26 ` jvdelisle at gcc dot gnu.org
2021-04-17  3:25 ` jvdelisle at gcc dot gnu.org
2023-10-13 20:26 ` jvdelisle at gcc dot gnu.org
2024-02-24  2:21 ` jvdelisle at gcc dot gnu.org
2024-02-24 18:26 ` jvdelisle at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).