[Bug other/36150] New: colorize output of gcc

[Bug other/36150] New: colorize output of gcc

[pva at gentoo dot org]

It could be useful if gcc colorizes its output. Colors allow easier to
distinguish errors and warnings from makefile commands and etc... Currently
there exist a separate script like colorgcc which colorizes output of compiler
but it does not works with localized bugs.gentoo.org/168709 output so seems
that it's better to have colorizing functionality in gcc itself as only gcc
knows better what output it issues.


-- 
           Summary: colorize output of gcc
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pva at gentoo dot org


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

[Bug other/36150] colorize output of gcc

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-06 15:28 -------
I don't think we should do this.  There is already a secondary program that
does the coloring too.


-- 


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

[Bug other/36150] colorize output of gcc

[esigra at gmail dot com]

------- Comment #2 from esigra at gmail dot com  2008-05-06 17:27 -------
I would definitely like GCC to produce colourized output. It can really improve
the readability. I miss that feature. It has my vote.


-- 


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

[Bug other/36150] colorize output of gcc

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2008-05-06 17:35 -------
http://schlueters.de/colorgcc.html


-- 


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

[Bug other/36150] colorize output of gcc

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2008-05-06 17:37 -------
I rather not add too much complexity to gcc diagnostic output.  Which means no
color.  colorgcc could be extended to get the correct coloring for the
locazation.  

See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983 .


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug other/36150] colorize output of gcc

[pva at gentoo dot org]

------- Comment #5 from pva at gentoo dot org  2008-05-06 18:07 -------
Andrew, it's very pity to see this bug closed as invalid so fast. Besides being
useful, people enjoy colors and people work with compilers...

I've already stated that, but I repeat. colorgcc does not work in case you have
localized output (see our bug report). Reading source of colorgcc it seems that
it uses words like "warning" or error as a key to parse and colorize output.
Thus taking into account the number of human languages gcc is translated to and
will be in future, adding complexity of having different encodings leaves
colorgcc hardly working without "fixing it with rasp-file" after translation
updates or additions. The complexity of this makes me think that it's natural
to have this feature in place where error/warning is thrown - that is in gcc
itself...

bug 36150 although could help, as it makes possible to parse error based on
numbers, works only for languages with stable "references" where it's hardly
possible that numbers changes, as in other case wrong coloring could mislead
programmer...

Summarizing, I do not see why decision error or warning we have should be
decided based on output after gcc and not in first place - in gcc itself -
where it's known with high certainty.


-- 


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

[Bug other/36150] colorize output of gcc

[esigra at gmail dot com]

------- Comment #6 from esigra at gmail dot com  2008-05-06 18:40 -------
(In reply to comment #4)
> I rather not add too much complexity to gcc diagnostic output.  Which means no color.

We did not demand that you do it personally. We just think that it would be a
really good idea if someone would do it some time. Just how much complexity
would it take?


> colorgcc could be extended to get the correct coloring for the locazation.

Sure it *could* be done, but it would require a version of colorgcc for each
(combination of GCC version and) localization. Now we are talking about
complexity!

Localized output is inherently unsuitable for parsing. The existence of such an
ugly hack is certainly no excuse for not allowing a proper implementation in
GCC itself, where it belongs. And seriously, what is more efficcent, adding a
colour code sequence to the string constans in GCC that says "warning:",
"error:" etc or having a bunch of scripts for parsing the output of various GCC
versions/localizations, recreating it with colour codes? What would
distributions prefer to maintain?


-- 


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

[Bug other/36150] colorize output of gcc

[brian at dessent dot net]

------- Comment #7 from brian at dessent dot net  2008-05-06 21:28 -------
Subject: Re:  colorize output of gcc

esigra at gmail dot com wrote:

> And seriously, what is more efficcent, adding a
> colour code sequence to the string constans in GCC that says "warning:",
> "error:" etc or having a bunch of scripts for parsing the output of various GCC

If you added escape sequences to the string constants in the gcc source
then it would only work for the C locale messages.  And isn't your whole
complaint that colorgcc fails for non-C locales?  In other words, this
would not do anything in the very case you care about, because in non-C
locales the message strings are taken from the po file and not the
literal strings in the source code.


-- 


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

[Bug other/36150] colorize output of gcc

[esigra at gmail dot com]

------- Comment #8 from esigra at gmail dot com  2008-05-06 21:55 -------
(In reply to comment #7)
> If you added escape sequences to the string constants in the gcc source
> then it would only work for the C locale messages.

Adding escape sequences for colours would work as well with localization as any
other formatting. Simple example:

printf("%s%s%s%s", warning_format_start, _("warning: "), _("the actual
message"), warning_format_end);

Here warning_format_start may be a pointer to "<orange>" and warning_format_end
a pointer to "</orange>". If colours are disabled, they both point to "". So
the result might be "warning: the actual message" or "<orange>warning: the
actual message</orange>". Localization would work fine for both "warning: " and
"the actual message". I do not really see the problem that you were thinking
of.


-- 


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

[Bug other/36150] colorize output of gcc

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2008-05-06 21:58 -------
The other issue here is that people want different colors for each of their
warnings so why hardcode it.


-- 


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

[Bug other/36150] colorize output of gcc

[brian at dessent dot net]

------- Comment #10 from brian at dessent dot net  2008-05-06 22:06 -------
Subject: Re:  colorize output of gcc

esigra at gmail dot com wrote:

> printf("%s%s%s%s", warning_format_start, _("warning: "), _("the actual
> message"), warning_format_end);

But then that is not simply "adding a colour code sequence to the string
constans in GCC", i.e. you can't just grep for "warning:" and change it
to "\033[01;32warning:", it's much more involved.


-- 


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

[Bug other/36150] colorize output of gcc

[pva at gentoo dot org]

------- Comment #11 from pva at gentoo dot org  2008-05-07 06:54 -------
(In reply to comment #9)
> The other issue here is that people want different colors for each of their
> warnings so why hardcode it.

It should be easy to make this configurable...

Well I've googled a bit and did not found any simple library to abstract from
color codes. Thus I've looked at cmake sources which colorizes it's output and
found that they do everything by themselves. By default (if not disabled
through command line and if test for cases where colors are not support fail)
they enable colors supposing that they have vt100 terminal and colorize output.
Take a look at kwsys/Terminal.c - the code itself is small and clear... This
does not seem to be a hard task to implement something similar in gcc.

(In reply to comment #10)
> you can't just grep for "warning:" and change it to "\033[01;32warning:", it's
> much more involved.

Oh, no. Not taking into account that you'll have to rebuild gcc every time you
decide to change colors, things like output or not colors should be decided at
runtime (looking at $TERM) as on terminals which do not support colors output
became unreadable...


-- 


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

[Bug other/36150] colorize output of gcc

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

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

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-10-02 17:03:33 UTC ---
*** Bug 45850 has been marked as a duplicate of this bug. ***

[Bug other/36150] colorize output of gcc

[manu at gcc dot gnu.org]

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

--- Comment #13 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2010-10-02 17:52:39 UTC ---
Somehow I missed this bug when searching. For those here in favour of color,
clang has it and people love it [*]. Luckily, this is one of those clang things
that can be done in GCC, and it works with localized messages. I have a
prototype patch and it is not too big. Unluckily, it seems it would be rejected
anyway, so I won't bother to clean it up and do all the bureaucracy stuff.
Shame.

[*]
http://fseek.me/2010/03/how-to-convince-any-c-developer-to-dump-gcc-and-use-clang/

[Bug other/36150] colorize output of gcc

[manu at gcc dot gnu.org]

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

--- Comment #14 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2010-10-02 19:51:34 UTC ---
For future reference, more examples of color diagnostics in clang can be found
here:

http://llvm.org/devmtg/2009-10/StateOfClang.pdf

but that is quite old, recent clang versions may produce a different output.

[Bug other/36150] colorize output of gcc

[manu at gcc dot gnu.org]

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

--- Comment #15 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2011-03-16 14:41:50 UTC ---
More users trying to get this feature by parsing the output of GCC (which is
not meant to be machine-readable): http://www.mixtion.org/gccfilter/

[Bug other/36150] colorize output of gcc

[manu at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED

--- Comment #16 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-04-14 17:57:47 UTC ---
GCC 4.9 will have colorized diagnostics, although probably disabled by default: 

http://gcc.gnu.org/gcc-4.9/changes.html
>From gcc-bugs-return-420258-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Apr 14 18:57:49 2013
Return-Path: <gcc-bugs-return-420258-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22644 invoked by alias); 14 Apr 2013 18:57:49 -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 22623 invoked by uid 48); 14 Apr 2013 18:57:46 -0000
From: "sunfish at google dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/56955] New: documentation for attribute malloc contradicts itself
Date: Sun, 14 Apr 2013 18:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: sunfish at google dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56955-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01403.txt.bz2
Content-length: 1885


http://gcc.gnu.org/bugzilla/show_bug.cgi?idV955

             Bug #: 56955
           Summary: documentation for attribute malloc contradicts itself
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: sunfish@google.com


The GCC manual's definition of the malloc function attribute is:

  "The malloc attribute is used to tell the compiler that a function may be
treated as if any non-NULL pointer it returns cannot alias any other pointer
valid when the function returns and that the memory has undefined content. This
often improves optimization. Standard functions with this property include
malloc and calloc. realloc-like functions do not have this property as the
memory pointed to does not have undefined content."

It says that the attribute implies that allocated memory has undefined content,
but then it says that calloc has this property, despite the fact that memory
allocated by calloc has well-defined content.

Since calloc is already marked with this attribute in lots of places (including
GLIBC), and since the undefined-content part of this attribute seems less
important than the aliasing part for optimizers anyway, I suggest just removing
the undefined-content language from the description of the attribute.

Also, the last sentence says that realloc-like functions don't qualify since
their memory does not have undefined content. The comment on GLIBC's
declaration of realloc says that realloc doesn't qualify since the returned
pointer may alias the argument pointer (for some definition of alias). GLIBC's
comment seems more likely to be the real reason, and it doesn't rely on the
undefined-content language.

[Bug other/36150] colorize output of gcc

[bluetooth.developer at gmail dot com]

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

bluetooth.developer at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bluetooth.developer at gmail dot c
                   |                            |om

--- Comment #17 from bluetooth.developer at gmail dot com ---
Alternatively you could use GilCC which is a tool to colorize GCC output in
real time. Just in case you cannot use GGC version 4.9 you still can use GilCC.

here is the download link:
http://www.onlysolutionssoftware.com/gilcc/