Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense

Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense

[Enrico Scholz]

The following reply was made to PR bootstrap/3653; it has been noted by GNATS.

From: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de>
To: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense
Date: 13 Jul 2001 22:39:24 +0200

 Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr> writes:
 
 > | Besides the misinterpretation by tools, the wrapped output is more
 > | difficulty to read by humans also:
 > | 
 > | - the human brain can surveying grouped data faster than ungrouped
 > |   one. The current wrapping destroys grouping.
 > 
 > Actually, it is the unreadability of the previous formatting which
 > prompted the implementation of the functionality in discussion.
 
 What is more readable:
 
 g++3     test.cc   -o test
 test.cc: In function `int main()':
 test.cc:15: no matching function for call to `foo<std::string, 
    foo<std::basic_iostream<std::string, std::char_traits<std::string> >, 
    std::basic_iostream<std::string, std::char_traits<std::string> >, 
    std::basic_iostream<std::string, std::char_traits<std::string> > >, 
    foo<std::basic_iostream<std::string, std::char_traits<std::string> >, 
    std::basic_iostream<std::string, std::char_traits<std::string> >, 
    std::basic_iostream<std::string, std::char_traits<std::string> > > 
    >::bar(const char[3])'
 test.cc:8: candidates are: void foo<XXX, YYY, ZZZ>::bar() [with XXX = 
    std::string, YYY = foo<std::basic_iostream<std::string, 
    std::char_traits<std::string> >, std::basic_iostream<std::string, 
    std::char_traits<std::string> >, std::basic_iostream<std::string, 
    std::char_traits<std::string> > >, ZZZ = 
    foo<std::basic_iostream<std::string, std::char_traits<std::string> >, 
    std::basic_iostream<std::string, std::char_traits<std::string> >, 
    std::basic_iostream<std::string, std::char_traits<std::string> > >]
 test.cc:9:                 void foo<XXX, YYY, ZZZ>::bar(int) [with XXX = 
    std::string, YYY = foo<std::basic_iostream<std::string, 
    std::char_traits<std::string> >, std::basic_iostream<std::string, 
    std::char_traits<std::string> >, std::basic_iostream<std::string, 
    std::char_traits<std::string> > >, ZZZ = 
    foo<std::basic_iostream<std::string, std::char_traits<std::string> >, 
    std::basic_iostream<std::string, std::char_traits<std::string> >, 
    std::basic_iostream<std::string, std::char_traits<std::string> > >]
 
 
 or
 
 
 g++3 -fmessage-length=0     test.cc   -o test
 test.cc: In function `int main()':
 test.cc:15: no matching function for call to `foo<std::string, [-->
 test.cc:8: candidates are: void foo<XXX, YYY, ZZZ>::bar() [with[-->
 test.cc:9:                 void foo<XXX, YYY, ZZZ>::bar(int) [w[-->
 
 ([--> means horizontal scrolling in XEmacs; on my screen some columns
 later (at #175)).
 
 
 > | I suggest a value of `0'. ;) ... at least if it is not a tty...
 > 
 > That is the users's responsability.
 
 Why not make it a user responsability to adjust the value if he want
 line-wrapping?
 
 > | [... -fmessage-length=0 option ...]
 > | Older gcc do not know this option and will fail to compile.
 > 
 > There are bunch of options there which are recognized by older GCC.
 
 Either these options have not changed behavior or there was a technical
 reason to change it.
 
 
 
 
 Enrico

Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense

[Enrico Scholz]

The following reply was made to PR bootstrap/3653; it has been noted by GNATS.

From: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de>
To: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense
Date: 17 Jul 2001 02:01:07 +0200

 Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr> writes:
 
 > [...options not understood by former gcc versions and -fmessage-length...]
 > | Either these options have not changed behavior or there was a technical
 > | reason to change it.
 > 
 > There was a technical reason for -fmessage-length.
 
 Please tell me the technical reason which caused the swap of the default
 behavior from non-wrapping to wrap-and-break-tools mode!
 
 Made other options line-wrapping by default necessarily, is the generated
 code faster or opens -fmessage-length=72 doors to better optimizations?
 
 Don't take it amiss but I can not understand why line-wrapping is enabled
 by default.
 
 
 
 Enrico

Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense

[Gabriel Dos Reis]

The following reply was made to PR bootstrap/3653; it has been noted by GNATS.

From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
To: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de>
Cc: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>,
   gcc-gnats@gcc.gnu.org
Subject: Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense
Date: 14 Jul 2001 05:34:27 +0200

 Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de> writes:
 
 | Either these options have not changed behavior or there was a technical
 | reason to change it.
 
 There was a technical reason for -fmessage-length.
 
 -- Gaby

Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense

[Enrico Scholz]

The following reply was made to PR bootstrap/3653; it has been noted by GNATS.

From: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense
Date: 14 Jul 2001 02:33:17 +0200

 To give some impressions about mentioned incompatibility and bad
 readability I have put some screenshots under
 
                   http://www.tu-chemnitz.de/~ensc/gcc/ [1]
 
 default behavior of gcc3:
   default-0.png
   default-1.png
 
 behavior of previous gcc's or with -fmessage-length=0:
   0-one-line.png   -  horizontal scrolling mode
   0-wrapped.png    -  natural wrapping
 
 
 Please pay attention how the green area (broken in default-*.png) can
 increase readability in 0-wrapped.png!
 
 
 
 Enrico
 
 Footnotes: 
 [1]  seems to be down at time of writing; try
      http://www-usercgi.tu-chemnitz.de/~ensc/gcc instead of
 

Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense

[Enrico Scholz]

The following reply was made to PR bootstrap/3653; it has been noted by GNATS.

From: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de>
To: Phil Edwards <pedwards@disaster.jaj.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense
Date: 13 Jul 2001 22:49:22 +0200

 Phil Edwards <pedwards@disaster.jaj.com> writes:
 
 > On Fri, Jul 13, 2001 at 10:23:14PM +0200, Enrico Scholz wrote:
 > > say it should be off by *default* because it breaks compatibility
 > 
 > I really should just resist the impluse to ask, but oh well:
 > 
 > How does limiting by default to 72 characters /break/ compatibility?
 
 Previous gcc versions have not done line-wrapping by default and there
 are tools relying on an one-line-per-error format (in the maillists I
 have read the `-fmessage-length=0' was added explicitly to test-scripts
 and I gave an emacs-example already).
 
 It's not the number 72; it's every number between 1 and 1000 (I think
 error-messages having >1000 columns are exceptions and can be ignored ;))
 
 
 
 Enrico

Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense

[Phil Edwards]

The following reply was made to PR bootstrap/3653; it has been noted by GNATS.

From: Phil Edwards <pedwards@disaster.jaj.com>
To: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense
Date: Fri, 13 Jul 2001 16:33:09 -0400

 On Fri, Jul 13, 2001 at 10:23:14PM +0200, Enrico Scholz wrote:
 > say it should be off by *default* because it breaks compatibility and
 
 I really should just resist the impluse to ask, but oh well:
 
 How does limiting by default to 72 characters /break/ compatibility?
 Assuming a 100-column xterm is breaking compatibility.
 
 Phil
 
 -- 
 Would I had phrases that are not known, utterances that are strange, in
 new language that has not been used, free from repetition, not an utterance
 which has grown stale, which men of old have spoken.
                                      - anonymous Egyptian scribe, c.1700 BC

Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense

[Enrico Scholz]

The following reply was made to PR bootstrap/3653; it has been noted by GNATS.

From: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de>
To: Phil Edwards <pedwards@disaster.jaj.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense
Date: 13 Jul 2001 22:23:14 +0200

 Phil Edwards <pedwards@disaster.jaj.com> writes:
 
 > > enrico.scholz@informatik.tu-chemnitz.de writes:
 > > | 3. The value of 72 is IMHO obsoleted. Are there still existing C++
 > > | programmers which are writing code on an 80-column console? I think
 > > | most ones are using xterms or framebuffer-screens with 100 or more
 > > | columns.
 >
 > Many of us with xterms and framebuffer-screens still use 80 columns.
 
 I don't say that the -fmessage-length option shall be removed entirely. I
 say it should be off by *default* because it breaks compatibility and
 reduces readability on screens with more than 80 columns.
 
 
 > (Hint: pieces of paper cannot be stretched.)
 
 Do you really print your error-messages? In some cases it may be usefully
 (e.g. to show colleagues stupid errors and laugh together at them ;) ),
 but then you can use `-fmessage-length=72' explicitly.
 
 (Hint: using a2ps with the -l option produces nice output with more than
 80 columns)
 
 
 
 Enrico

Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense

[Phil Edwards]

The following reply was made to PR bootstrap/3653; it has been noted by GNATS.

From: Phil Edwards <pedwards@disaster.jaj.com>
To: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense
Date: Thu, 12 Jul 2001 15:54:57 -0400

 >  enrico.scholz@informatik.tu-chemnitz.de writes:
 >  | 3. The value of 72 is IMHO obsoleted. Are there still existing C++
 >  | programmers  which are writing code on an 80-column console? I think most ones are using xterms or framebuffer-screens with 100 or more columns.
 
 Many of us with xterms and framebuffer-screens still use 80 columns.
 (Hint:  pieces of paper cannot be stretched.)
 
 -- 
 Would I had phrases that are not known, utterances that are strange, in
 new language that has not been used, free from repetition, not an utterance
 which has grown stale, which men of old have spoken.
                                      - anonymous Egyptian scribe, c.1700 BC

Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense

[Gabriel Dos Reis]

The following reply was made to PR bootstrap/3653; it has been noted by GNATS.

From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
To: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de>
Cc: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>,
   gcc-gnats@gcc.gnu.org
Subject: Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense
Date: 12 Jul 2001 14:05:20 +0200

 Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de> writes:
 
 | Besides the misinterpretation by tools, the wrapped output is more
 | difficulty to read by humans also:
 | 
 | - the human brain can surveying grouped data faster than ungrouped
 |   one. The current wrapping destroys grouping.
 
 Actually, it is the unreadability of the previous formatting which
 prompted the implementation of the functionality in discussion.
 
 | I suggest a value of `0'. ;) ... at least if it is not a tty...
 
 That is the users's responsability.
 
 
 | > If you don't want the fonctionality, the documentation says you can
 | > specify -fmessage-length=0
 | 
 | Older gcc do not know this option and will fail to compile.
 
 There are bunch of options there which are recognized by older GCC.
 
 -- Gaby

Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense

[Enrico Scholz]

The following reply was made to PR bootstrap/3653; it has been noted by GNATS.

From: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de>
To: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense
Date: 12 Jul 2001 13:02:21 +0200

 Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr> writes:
 
 > | 1. It breaks existing tools. E.g. Emacs awaits a "<location>:<line>
 > | <error-msg>" format and gets confused by the current behavior
 > 
 > My personnal experience (yes, I write and compile my work under Emacs)
 > doesn't match your report.  It just works fine.
 
 Emacs detects errors only if they have the format described above. The
 wrapped lines are plain text for it and won't be recognized as a part of
 diagnostic. Try to move the mouse over wrapped and unwrapped
 error-messages! The whole unwrapped message will be marked (which helps
 to increase readability), but only the first line of the wrapped one.
 
 Besides the misinterpretation by tools, the wrapped output is more
 difficulty to read by humans also:
 
 - the human brain can surveying grouped data faster than ungrouped
   one. The current wrapping destroys grouping.
 
 - the count of lines per errormessage is increased by a factor of 3 or
   more in most cases where templates are involved. Therefore messages
   belonging together (e.g. naming of possible candidates) can not be
   read at a glance and I have to scroll the compilation-buffer manually.
 
  
 > [... value for -fmessage-length=X ...]
 > We've through that debate over and over in the past.  The default
 > value was what contented the majority which expressed their voices.
 > The exact value is configurable.
 
 I suggest a value of `0'. ;) ... at least if it is not a tty...
 
 
 > [...]
 > If you don't want the fonctionality, the documentation says you can
 > specify -fmessage-length=0
 
 Older gcc do not know this option and will fail to compile. Therefore it
 does not exist a simple way to gain unwrapped messages with gcc.
 
 I think that backward-compatibility should be preserved in this case,
 because line-wrapping offers only a few advantages but has some drawbacks,
 
 
 
 
 
 Enrico

Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense

[Gabriel Dos Reis]

The following reply was made to PR bootstrap/3653; it has been noted by GNATS.

From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
To: enrico.scholz@informatik.tu-chemnitz.de
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: bootstrap/3653: -fmessage-length=72 with g++ makes no sense
Date: 12 Jul 2001 10:40:49 +0200

 enrico.scholz@informatik.tu-chemnitz.de writes:
 
 | 1. It breaks existing tools. E.g. Emacs awaits a "<location>:<line>
 | <error-msg>" format and gets confused by the current behavior
 
 My personnal experience (yes, I write and compile my work under
 Emacs) doesn't match your report.  It just works fine.
 
 | 3. The value of 72 is IMHO obsoleted. Are there still existing C++
 | programmers  which are writing code on an 80-column console? I think most ones are using xterms or framebuffer-screens with 100 or more columns.
 
 We've through that debate over and over in the past.  The default
 value was what contented the majority which expressed their voices.
 The exact value is configurable.
 
 (And no, I'm not using an xterm)
 
 | 4. Only the g++ frontend defaults to this linebreak. This is inconsequentlally.
 
 That functionality was first implemented for g++.  If you request it
 to be available for other front-ends, I can undertsand that.
 
 If you don't want the fonctionality, the documentation says you can
 specify -fmessage-length=0
 
 -- Gaby

bootstrap/3653: -fmessage-length=72 with g++ makes no sense

[enrico.scholz]

>Number:         3653
>Category:       bootstrap
>Synopsis:       -fmessage-length=72 with g++ makes no sense
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jul 11 14:56:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de>
>Release:        gcc version 3.0.1 20010710
>Organization:
>Environment:

>Description:
By default, g++ assumes -fmessage-length=72. I think this is not a good
idea because:

0. Former g++ versions do not do it. Therefore there should be a good reason for the change.

1. It breaks existing tools. E.g. Emacs awaits a "<location>:<line>
<error-msg>" format and gets confused by the current behavior

2. It makes error-messages completely unreadable. E.g. if there are
messages saying something about templates, it is not unusual that the
template-parameter-list is splitted over several lines.

3. The value of 72 is IMHO obsoleted. Are there still existing C++
programmers  which are writing code on an 80-column console? I think most ones are using xterms or framebuffer-screens with 100 or more columns.

4. Only the g++ frontend defaults to this linebreak. This is inconsequentlally.

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: