Re: diag color
Hi,
Well, I can't 'easilly' change the makefiles I am using, they are not
mine,meaning I would have to 'patch' any build env Makefile each time
we do a refresh of the app sources. Then some gcc version don't
understand the -fno-diagnostics-color meaning the makefile patch would
have to be GCC version aware, that is a bit of a mess, and as you said
the vast majority use vt100, so those could have colors if they want
to.
While a simple getenv("TERM") to setup the default of the color
predicate before going to the sequence of testing CFLAGS, et the
optargs, would cost almost nothing.
I am not convince, ethically speaking, with the 'vast majority' concept.
I am more inclined by complexity, stabililty, risk vs benefit.
Here the risk is nil, benefit very moderate ==> easy to do.
With a cancer like propagation, vast majority use gcc, that impose
vt100, then by now the vast majority got rid of term so lets remove
termcap/terminfo. Hum... I don't really like this approach.
Cheers,
Phi
Re: diag color
On 2016.07.31 at 10:46 +0200, phi gcc wrote:
> While a simple getenv("TERM") to setup the default of the color
> predicate before going to the sequence of testing CFLAGS, et the
> optargs, would cost almost nothing.
If you want a full explanation of the current behavior please read the
comments in gcc/diagnostic-color.c.
--
Markus
Re: diag color
On 31 July 2016 at 07:08, phi gcc wrote: > Hi All, > > Reposting this here from gcc-help. > > > I got the impression that I got colors in diag output depsite the fact > that I got no GCC env var setup. The manual says "Setting GCC_COLORS to the empty string disables colors." Did you try that? Setting it to an empty string in your env should disable the coloured output.
Re: diag color
Hi Jon, On Sun, Jul 31, 2016 at 1:16 PM, Jonathan Wakely > The manual says "Setting GCC_COLORS to the empty string disables colors." > > Did you try that? Setting it to an empty string in your env should > disable the coloured output. Yes it works, sounds a less intrusive one :) regarding old version compatibility, will export that. When looking quick at the src I din't spotted this getenv() that is not in the init() path as it should :) Thanx Phi
Re: diag color
Forgot to say that before posting I did try export GCC_COLORS=never after reading == -fno-diagnostics-colorUse color in diagnostics. WHEN is ‘never’, ‘always’, or ‘auto’. The default depends on how the compiler has been configured, it can be any of the above WHEN options or also ‘never’ if GCC_COLORS environment variable isn't present in the environment, and ‘auto’ otherwise. ‘auto’ means to use color only when the standard error is a terminal. The forms -fdiagnostics-color and -fno-diagnostics-color are aliases for -fdiagnostics-color=always and -fdiagnostics-color=never, respectively. == I admit I red this a bit too fast, and since the doc sez "if GCC_COLORS isn't present" I didn't infered what it does if set. I didn't saw the =never was a goof for the env var. I guess I must not be the only one trapped here. Yet I still believe it is wrongly coded, a very little logic in the init() path would allow every one to be happy :) Yet I will do the export :) Cheers, Phi
Re: diag color
On 31/07/16 13:16, phi gcc wrote: I admit I red this a bit too fast, and since the doc sez "if GCC_COLORS isn't present" I didn't infered what it does if set. I didn't saw the =never was a goof for the env var. I guess I must not be the only one trapped here. Yet I still believe it is wrongly coded, a very little logic in the init() path would allow every one to be happy :) If you think you can code it better, prove it: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps That also applies to documentation changes. Cheers, Manuel.
Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)
On 29/07/16 18:26, Warren D Smith wrote: Booleans are very useful - they turn up all over the place in programming. Nibbles, on the other hand, are almost totally useless. There are very, very few situations where you need to store a number that is within the range 0 .. 15, and are so tightly constrained for space that you can't use an 8-bit byte (or whatever size of byte your target uses). --Why does any programmer want to have a large good-quality-code-producing C compiler like gcc, as opposed to the crudest possible (but working) translator? It is for performance. If they did not care about performance, and only cared about correctness, they would not want gcc, they'd want the simpler smaller compiler, since more likely to be correct. There are many reasons why people choose gcc. Personally, I choose it because (in no specific order) : 1. Code correctness is top-class. It is very rare that gcc produces incorrect code, and correctness bugs get high priority from the developers. This has not always been my experience with commercial tools. 2. Portability - I work with dozens of different target processors, and having the same compiler for them all is a huge benefit. 3. Tool structure - I like the way the compiler and associated tools work, how well they fit together, and the kinds of files I can generate (map files, listing files, dependency files, a range of different final object files). 4. Features - gcc is the leading compiler in terms of support for C and C++ features, useful extensions, static error checking, and other features. I've used many compilers through the years - gcc's only rival is clang (and that rivalry is often cooperative, and seems to me to be a good thing for both projects). 5. Optimisation - because gcc has a lot of sophisticated optimisations, I can concentrate on writing code that is clear, correct, and maintainable, and rely on the compiler to turn it into efficient object code. 6. Freedom - it's not so much the cost (I have paid for gcc packages), but the freedom to install and use whatever versions I want for whatever targets I want on whatever host computers I want, without worrying about licenses, time limits, locking to particular hosts, etc. 7. Documentation - there is lots of documentation for gcc, and (at least in comparison to many other compilers) it is accurate and kept up-to-date. 8. Support - there is great support for the compiler from many places. Notice that the quality and the efficiency of the generated code is one of these points - but only one of them. Now why do programmers care about performance? Two reasons: memory space, and time. If programs are not going to come anywhere near memory capacity or time-capacity, then nobody needs gcc, and I have to wonder why you work on it at all. OK? So the sole rationale for the existence of large good-quality-code-producing C compilers like gcc, is for space and/or time performance. Now, suppose you are a memory-performance programmer. In that case, you are pushing memory capacity limits. Therefore, you often want to use the smallest available size for each information-packet in your program, and you want them packed. It happens that power-2 sizes (1,2,4,8,16,... bits) are more convenient, fairly small in number, and assure optimality to within a factor of 2. So as a first step, I would recommend any compiler that aims to satisfy space-performance programmers, should provide power-2 sizes, with packing. No, that is simply unnecessary. C provides enough facilities to handle this in a C-like manner. Other languages (such as Pascal or C++) may have different support. But supported packed uint4_t (or other sizes that are not multiples of CHAR_BIT) cannot be done in C in the way it works for types that /are/ a multiple of CHAR_BIT. That's life with C. If you don't like it, use a different language. (A more ambitious step would be all sizes, power-2 or not.) Now suppose you are a time-performance programmer. In that case, you also care about memory because of the cache. I have done tests on my computer indicating that random memory accesses cost a factor about 70 more time, if array is too large. That means space performance is time performance. OK? Now it is arrogant and obnoxious for somebody to tell me certain info-packet sizes (like 4) are useless while others (like 1 and 32) are useful, Yes - that's based on reality. It turns out that it is rare for types of sizes 2 to 7 bits to be useful in large enough quantity that it is worth thinking about packing them inside arrays. And it is not that hard to make your own access functions to pack them and access them as needed - while it is impossible to implement them in C in a manner that is consistent with other types. See Jonathan's post for a very clear explanation. just since they feel that way, and the main reason they feel that way is they designed gcc to make it hard for anybo
Re: diag color
Hi Manuel,
On Sun, Jul 31, 2016 at 3:16 PM, Manuel López-Ibáñez
wrote:
> On 31/07/16 13:16, phi gcc wrote:
>
> If you think you can code it better, prove it:
Why should I ? I am not a gcc designer, just humbelly reporting a
usability issue, where a gcc upgrade start to produce garbled
unreadable output on stderr.
At some point one suggested reading the source, I did it real quick,
and it appears trivial that getenv("TERM") is wrongly processed, made
a kind proposal as suggestion, that can indeed be implemented
otherwise by the code owner.
Now gcc team can simply trash this, but if gcc can't handle trivial
request like this, sounds a bit scary for the future :)
Jon sugested a valid work around that I can manage for a while that is
a gcc shell wrapper export the GCC_COLORS='' then call gcc.ori, it is
sloppy but workable.
If this is still accepted as a potential problem then lemme know the official
process to submit a bug report. If people on the list strongly think
this is not a problem, then it will save time, we close it period :)
Re: diag color
On Sun, Jul 31, 2016 at 10:54 PM, phi gcc wrote: > If this is still accepted as a potential problem then lemme know the official > process to submit a bug report. I oppsed here, I red your link and see the very last line about bugzilla will experiment this...
Re: Question about find modifiable mems
On 03-Jun-15 09:39 AM, shmeel gutl wrote: find_modifiable_mems was introduced to gcc 4.8 in september 2012. Is there any documentation as to how it is supposed to help the haifa scheduler? In my private port of gcc it make the following type of transformations from a= *(b+20) b+=30 to b+=30 a=*(b-10) Although this is functionally correct, it has changed an ANTI_DEP into a TRUE_DEP and thus introduced stalls. If it went the other way, that would be good. Any pointers? Thanks, Shmeel It seems that the problem comes from the change from ANTI_DEP to TRUE_DEP. The flow graph needs to be updated to reflect this change. Can someone look into this? Shmeel
Re: diag color
bugzilla don't likes me, can't get in Ok let's forget participation then...
Re: diag color
On 31 July 2016 at 22:06, phi gcc wrote: > bugzilla don't likes me, can't get in > Ok let's forget participation then... We were attacked by spammers last week and had to temporarily disable account creation. The notice you got from bugzilla should have given the details of an admin to contact who will create an account for you.
Re: diag color
On 31 July 2016 at 21:54, phi gcc wrote:
> Why should I ? I am not a gcc designer, just humbelly reporting a
Anybody can become a GCC developer, if they want to :)
> At some point one suggested reading the source, I did it real quick,
> and it appears trivial that getenv("TERM") is wrongly processed, made
https://gcc.gnu.org/wiki/Community point 4:
If you do not have the time/resources/people to implement your own
idea, do not expect GCC developers dropping what they are doing to
help you. Volunteers have very very limited time and paid developers
are paid to do something else. In fact, asking GCC developers to do
anything for you, no matter how trivial it seems to you, will likely
result in negative feedback. Probably it is no trivial at all.
:)
> Now gcc team can simply trash this, but if gcc can't handle trivial
> request like this, sounds a bit scary for the future :)
Nobody is trashing anything. My intention was only to helpfully point
out the most direct route to get your issue fixed.
:)
Speaking for myself, I don't understand what is "trivially wrong" with
the code that you mention and you didn't explain how you will fix it.
It doesn't matter to me, because even if you had explained, I don't
have enough free time to fix it for you, since it is never as trivial
as you think it is and you will never realize this until you try
yourself.
But if you found a workaround that makes you happy, let's save
everybody's time and stop here :)
> bugzilla don't likes me, can't get in
> Ok let's forget participation then...
Account creation may be disabled at the moment. We have been suffering
spam attacks lately. See
https://gcc.gnu.org/bugzilla/createaccount.cgi
Cheers,
Manuel.
Re: diag color
On 31 July 2016 at 22:59, Jonathan Wakely wrote: > On 31 July 2016 at 22:06, phi gcc wrote: >> bugzilla don't likes me, can't get in >> Ok let's forget participation then... > > We were attacked by spammers last week and had to temporarily disable > account creation. The notice you got from bugzilla should have given > the details of an admin to contact who will create an account for you. Actually, I haven't been able to find a way to reach the createaccount.cgi page from within bugzilla. It seems the links themselves have been removed. Cheers, Manuel.
gcc-7-20160731 is now available
Snapshot gcc-7-20160731 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20160731/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 238930 You'll find: gcc-7-20160731.tar.bz2 Complete GCC MD5=5e68659476f01c7290ee521debc577e8 SHA1=66b42ad36086359ddea0a6eb09b0f2724c9a1738 Diffs from 7-20160724 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
