Re: suggestion: c compiler warning for failure to test result

On Thu, 2017-04-27 at 10:42 -0600, Jeff Law wrote: > On 04/25/2017 05:02 PM, Martin Sebor wrote: > > On 04/25/2017 02:35 PM, Joe Perches wrote: > > > A possibly useful addition similar to: > > > > > > __attribute__((warn_unused_result)) > > > > > > might be > > > > > > __attribute__((warn_untest

Re: suggestion: c compiler warning for failure to test result

On 04/25/2017 05:02 PM, Martin Sebor wrote: On 04/25/2017 02:35 PM, Joe Perches wrote: A possibly useful addition similar to: __attribute__((warn_unused_result)) might be __attribute__((warn_untested_result)) for things like allocation failures that are not verified before use. I agree tha

Re: suggestion: c compiler warning for failure to test result

On 04/25/2017 02:35 PM, Joe Perches wrote: A possibly useful addition similar to: __attribute__((warn_unused_result)) might be __attribute__((warn_untested_result)) for things like allocation failures that are not verified before use. I agree that this would be a useful feature. In fact, I

Re: [Suggestion] about h8/300 architecture in gcc and binutils

On 09/13/2013 01:02 PM, Chung-Ju Wu wrote: > 2013/9/13 Chen Gang : >> > On 09/13/2013 01:09 AM, Jeff Law wrote: >>> >> On 09/11/2013 10:38 PM, Chen Gang wrote: >>> Hello all: >>> > [...] >>> currently, I only send 3 bugs: Bug58256, Bug58400, Bug58401, the other >>> bugs may dupl

Re: [Suggestion] about h8/300 architecture in gcc and binutils

2013/9/13 Chen Gang : > On 09/13/2013 01:09 AM, Jeff Law wrote: >> On 09/11/2013 10:38 PM, Chen Gang wrote: >>> Hello all: >>> [...] >>> currently, I only send 3 bugs: Bug58256, Bug58400, Bug58401, the other >>> bugs may duplicate with these bugs, so I do not send (if they are also >>> valuable, I

Re: [Suggestion] about h8/300 architecture in gcc and binutils

On 09/13/2013 01:09 AM, Jeff Law wrote: > On 09/11/2013 10:38 PM, Chen Gang wrote: >> Hello all: >> >> I have send the related issues to "http://gcc.gnu.org/bugzilla";, please >> check if you like, thanks. >> >> currently, I only send 3 bugs: Bug58256, Bug58400, Bug58401, the other >> bugs may dupl

Re: [Suggestion] about h8/300 architecture in gcc and binutils

On 09/11/2013 10:38 PM, Chen Gang wrote: > Hello all: > > I have send the related issues to "http://gcc.gnu.org/bugzilla";, please > check if you like, thanks. > > currently, I only send 3 bugs: Bug58256, Bug58400, Bug58401, the other > bugs may duplicate with these bugs, so I do not send (if the

Re: [Suggestion] about h8/300 architecture in gcc and binutils

Hello all: I have send the related issues to "http://gcc.gnu.org/bugzilla";, please check if you like, thanks. currently, I only send 3 bugs: Bug58256, Bug58400, Bug58401, the other bugs may duplicate with these bugs, so I do not send (if they are also valuable, I will send too). Next, I should

Re: [Suggestion] about h8/300 architecture in gcc and binutils

On 09/11/2013 03:55 AM, Michael Schewe wrote: > Hello Maintainers, > > if you like to drop h8/300 support in linux kernel, thats OK for me. OK, thanks. > But i like to see it still supported in gcc & binutils, at least i have > some projects and know companies using this architecture in embedded

Re: [Suggestion] about h8/300 architecture in gcc and binutils

Hello Maintainers, if you like to drop h8/300 support in linux kernel, thats OK for me. But i like to see it still supported in gcc & binutils, at least i have some projects and know companies using this architecture in embedded applications, bare metal without OS. These products have lifetime i

Re: [Suggestion] about h8/300 architecture in gcc and binutils

On 09/10/2013 10:19 AM, Jeff Law wrote: > On 09/09/2013 07:13 PM, Chen Gang wrote: >> Hello Maintainers: >> >> After google search and check the Linux kernel, H8/300 is dead, and for >> gcc-4.9.0 and binutils-2.23.2 still has h8300, do we still need it for >> another OS ? >> >> Welcome any suggesti

Re: [Suggestion] about h8/300 architecture in gcc and binutils

On 09/09/2013 07:13 PM, Chen Gang wrote: Hello Maintainers: After google search and check the Linux kernel, H8/300 is dead, and for gcc-4.9.0 and binutils-2.23.2 still has h8300, do we still need it for another OS ? Welcome any suggestions or completions, thanks. The related information in li

Re: suggestion to use lzma for snapshots, maybe more?

On Wed, 13 Jan 2010, Vincent Lefevre wrote: >> I was idly looking through a couple of snapshots of the gcc -trunk line. >> I am by no means a compiler developer, but I did notice that you aren't >> using lzma for compression. I don't know if bandwidth is at all a >> concern, but I can point to a >

Re: suggestion for ppl and cloog-ppl configure enhancement

On Wed, Jan 13, 2010 at 14:55, Rainer Emrich wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > IMHO it would be a godd idea to add the following two configure options to ppl > configure: >  --with-gmp-include=DIR  GMP include directory >  --with-gmp-lib=DIR      GMP lib directory > > On

Re: suggestion to use lzma for snapshots, maybe more?

On 2010-01-12 19:40:50 -0500, Kevin Hunter wrote: > I was idly looking through a couple of snapshots of the gcc -trunk line. > I am by no means a compiler developer, but I did notice that you aren't > using lzma for compression. I don't know if bandwidth is at all a > concern, but I can point to

Re: Suggestion for removing flex and bison as a dependancy

I suppose this is related to what I said to you on IRC, so I ought to chime in here. I agree with Daniel and David - your patch is not appropriate. As long as we actually have the .l and .y files, the associated .c/.h files should not be checked in, and flex/bison should be required when building

Re: Suggestion for removing flex/bison as a dependancy

On 2007/11/26, Karthik Kumar <[EMAIL PROTECTED]> wrote: > Hi, > > > On Nov 27, 2007 12:13 AM, J.C. Pizarro <[EMAIL PROTECTED]> wrote: > > On Mon, Nov 26, 2007, Karthik Kumar wrote: > > > I would like to propose a set of diffs to enable compilation of gcc > > > without requiring flex/bison. I feel t

Re: Suggestion for removing flex/bison as a dependancy

On Mon, Nov 26, 2007, Karthik Kumar wrote: > I would like to propose a set of diffs to enable compilation of gcc > without requiring flex/bison. I feel that this would greatly benefit > the variety of users building gcc. Dear Karthik Kumar, why not flex/bison? It's bad idea not using them. The to

Re: Suggestion for removing flex/bison as a dependancy

Daniel Jacobowitz wrote: On Mon, Nov 26, 2007 at 11:39:47PM +0530, Karthik Kumar wrote: I would like to propose a set of diffs to enable compilation of gcc without requiring flex/bison. I feel that this would greatly benefit the variety of users building gcc. Please be more concrete. I strong

Re: Suggestion for removing flex/bison as a dependancy

On Mon, Nov 26, 2007 at 11:39:47PM +0530, Karthik Kumar wrote: > I would like to propose a set of diffs to enable compilation of gcc > without requiring flex/bison. I feel that this would greatly benefit > the variety of users building gcc. Please be more concrete. I strongly disagree that there

Re: Suggestion required for appropriate implementation

"Rahul Phalak" <[EMAIL PROTECTED]> writes: > According to the first syntax, Wanalyze-Rule1, Wanalyze-Rule2 etc are > considered as seperate options in c.opt file. Look at Joined options. Consider -fbuiltin-abs -fno-builtin-memcpy. Ian

RE: Suggestion required for appropriate implementation

Hi, >>It's a little hard to know the best approach with no idea of what kinds of rules you are talking about. However, given that The rules that I am talking about are the rules that will help user to write efficient code. For e.g. "Declare variables in descending order according to base ty

Re: Suggestion required for appropriate implementation

On Jul 27, 2006, at 12:31 AM, Rahul Phalak wrote: I want to add command line options in GCC for analyzing application code for a set of rules. I agree with Ian for the most part. For research and development, you will want to give your users lots of control. They will then give you feed

Re: Suggestion required for appropriate implementation

"Rahul Phalak" <[EMAIL PROTECTED]> writes: Please don't send e-mail to both gcc@gcc.gnu.org and [EMAIL PROTECTED] This type of e-mail, related to the development of gcc, is appropriate for [EMAIL PROTECTED] > Approach 1: > Since these options are warning options, I intend to integrate them with

Re: Suggestion for logging changes on Bugzilla

Bradley Lucier <[EMAIL PROTECTED]> writes: > I just did a search on "My bugs" and found that one of them, 22118, had a > title that I didn't recognize. I then remembered that the title had been > changed from my original description; ordinarily there is not an entry in > a bugzilla record notin

Re: Suggestion for logging changes on Bugzilla

On Wed, May 31, 2006 at 02:03:41PM -0500, Bradley Lucier wrote: > I would like to suggest that all substantive changes to a bugzilla > record (change of title, change of component, change of "Reported > against", etc.) be automatically accompanied by a log entry in the PR > that states the ch

Re: Suggestion for GCC (C & C++) enhancement - static variable initialisation ordering

"Manfred von Willich" <[EMAIL PROTECTED]> writes: | | I'd encourage you to work up a solid proposal for ISO/ANSI and | | propose it there. | | Being a newbie, I'd appreciate contact/site details for submissions to the | ISO/ANSI standardisation forum (do I email [EMAIL PROTECTED]). http

Re: Suggestion for GCC (C & C++) enhancement - static variable initialisation ordering

| I'd encourage you to work up a solid proposal for ISO/ANSI and | propose it there. Being a newbie, I'd appreciate contact/site details for submissions to the ISO/ANSI standardisation forum (do I email [EMAIL PROTECTED]). I will be happy to draft and submit a proposal, including a hopefully co

Re: Suggestion for GCC (C & C++) enhancement - static variable initialisation ordering

On Apr 29, 2006, at 7:45 AM, Manfred von Willich wrote: Any interested GCC maintainers/contributors: I'd encourage you to work up a solid proposal for ISO/ANSI and propose it there. Some of the issues you bring up have already been discussed in that forum and decided, I'd doubt that they'd

RE: Suggestion

YaniMan wrote: > Hello! > > Maybe you got this type of mails, but maybe not. So i send it. :) Hey! Maybe you got this type of replies, but maybe not. So I send it too! :) > Could you put an option into the compiler, to produce other error / > warning outputs? > The "file.c:line: error messag

Re: Suggestion

[EMAIL PROTECTED] said: > Or these messages should going (by an option) to the stdout rather than > stderr, so i can write a parser (gcc a.c | myparser) to convert the > messages. Ah, but that option does exist already: gcc a.c 2>&1 | myparser :-) Christi

Re: Suggestion

"YaniMan" <[EMAIL PROTECTED]> wrote: > Or these messages should going (by an option) to the stdout rather than > stderr, so i can write a parser (gcc a.c | myparser) to convert the > messages. gcc a.c 2>&1 | myparser >&2 paul

Re: Suggestion

YaniMan wrote: Hello! Maybe you got this type of mails, but maybe not. So i send it. :) Could you put an option into the compiler, to produce other error / warning outputs? The "file.c:line: error message" format is ok, but the stupid visual studio (which i use (good editor)) knows only the "f

Re: Suggestion for simple feature - "beep" on finish.

Andreas Schwab wrote: Graham Pratt <[EMAIL PROTECTED]> writes: So much compiling is done in the wee hours of the morning and it is nice to just shut your eyes for a while when the messages are scrolling past. Trouble is, you have to take a peek every now and then to see if it is finished. A

Re: Suggestion for simple feature - "beep" on finish.

Graham Pratt <[EMAIL PROTECTED]> writes: > So much compiling is done in the wee hours of the morning and it is nice to > just shut your eyes for a while when the messages are scrolling past. Trouble > is, you have to take a peek every now and then to see if it is finished. A > very simple feat

Re: Suggestion for a fix to Bug middle-end/20177

Paul Schlie wrote: Steven Bosscher wrote: IIRC these notes are for CCO, and you have to move the CC setter and user together. - unless it can be guaranteed that the particular setter's cc, will be preserved (i.e. not corrupted by successive operations) prior to it's ultimate use; ... Steven was

Re: Suggestion for a fix to Bug middle-end/20177

Mostafa Hagog wrote: Thanks for the information, what we were doing was to call update_life_info_in_dirty_blocks, but for some reason this wasn't sufficient to mark a register dead (REG_DEAD note) when the register was defined in a predecessor block and dies in the dirty block; we had to call updat

Re: Suggestion for a fix to Bug middle-end/20177

> Steven Bosscher wrote: >> Mostafa Hagog <[EMAIL PROTECTED]> wrote: >> This is interesting, so there could be cases were want to copy CC >> register when doing SMS. what happens if we want to move the set >> of a CC to another iteration of the loop ? or the use of the CC ? but >> usually this is

Re: Suggestion for a fix to Bug middle-end/20177

James E Wilson <[EMAIL PROTECTED]> wrote on 18/03/2005 07:43:55: > > You either have to keep all REG_NOTES up to date, or call code that will > recompute them. You can recompute REG_DEAD/REG_UNUSED notes by calling > back into flow. This is presumably what happens when you mark the block >

Re: Suggestion for a fix to Bug middle-end/20177

Mostafa Hagog wrote: The question is: what is the correct fix for the longer term ? is it enough to mark the SMSed block dirty? or do we need also to keep the REG_DEAD correct in each basic-block separately? You either have to keep all REG_NOTES up to date, or call code that will recompute them.

Re: Suggestion for a fix to Bug middle-end/20177

For some reason the REG_DEAD is not the cause of the failure it is the fact that the SMSed basic-block wasn't mark dirty for update_life_info that come after it. doing so fixes the failure even with REG_DEAD is still in that insn. The REG_DEAD note is correct when we look inter-block so maybe

Re: Suggestion for a fix to Bug middle-end/20177

Richard Kenner wrote: That's one of the reasons why very few (any?) machines use CC0 anymore. IIUC, according to there are 12 targets that use cc0, out of a list of 32 targets. Eric

Re: Suggestion for a fix to Bug middle-end/20177

This is interesting, so there could be cases were want to copy CC register when doing SMS. what happens if we want to move the set of a CC to another iteration of the loop ? or the use of the CC ? but usually this is couldn't happen in a simple loop, right? the use of CC is ev

Re: Suggestion for a fix to Bug middle-end/20177

On Mar 16, 2005 05:11 PM, Mostafa Hagog <[EMAIL PROTECTED]> wrote: > > > > > [EMAIL PROTECTED] (Richard Kenner) wrote on 16/03/2005 17:27:59: > > > REG_NOTE (NONNEG) > > REG_NOTE (NO_CONFLICT) > > REG_NOTE (UNUSED) > >mustn't be copied > >describe a fact about othe

Re: Suggestion for a fix to Bug middle-end/20177

[EMAIL PROTECTED] (Richard Kenner) wrote on 16/03/2005 17:27:59: > REG_NOTE (NONNEG) > REG_NOTE (NO_CONFLICT) > REG_NOTE (UNUSED) >mustn't be copied >describe a fact about other instructions so this >may change if copied. > > Tricky. Often UNUSED means that

Re: Suggestion for a fix to Bug middle-end/20177

REG_NOTE (NONNEG) REG_NOTE (NO_CONFLICT) REG_NOTE (UNUSED) mustn't be copied describe a fact about other instructions so this may change if copied. Tricky. Often UNUSED means that we're allocating a psuedo for some temporary which we know isn't used. REG_NOT

Re: Suggestion: Different exit code for ICE

Janis Johnson wrote: On Thu, Feb 24, 2005 at 11:46:20AM +0100, Volker Reichelt wrote: Regressions that cause ICE's on invalid code often go unnoticed in the testsuite, since regular errors and ICE's both match { dg-error "" }. See for example g++.dg/parse/error16.C which ICE's since yesterday, but

Re: Suggestion: Different exit code for ICE

On Thu, Feb 24, 2005 at 11:46:20AM +0100, Volker Reichelt wrote: > Regressions that cause ICE's on invalid code often go unnoticed in the > testsuite, since regular errors and ICE's both match { dg-error "" }. > See for example g++.dg/parse/error16.C which ICE's since yesterday, > but the testsuite

Re: Suggestion: Different exit code for ICE

> Regressions that cause ICE's on invalid code often go unnoticed in the > testsuite, since regular errors and ICE's both match { dg-error "" }. > See for example g++.dg/parse/error16.C which ICE's since yesterday, > but the testsuite still reports "PASS": > >Executing on host: > /Work/reich