Re: feature request

Re: feature request

[Sam Lauber]

That's a bit hard because you have to skip right to that line, and lseek() and friends can't precisely seek to line X. We'd have to use a lot of code to figure out how long each line is, and go to that exact line. But I think this code would maybe work for making the error:

void semicolon_error
(unsigned long line)
{
        unsigned long c_cnt, l_cnt;
        for (c_cnt = 0, l_cnt = 0; l_cnt = line; )
          {
                   while (getchar() != '\n')
                           c_cnt++;
                   l_cnt++
          }
        char c;
        while ((c = (char) getchar()) != '\n');
        printf("%lu: missing semicolon at end of line\n", line);
        printf("%lu: %c\n", line, c);
}

But wouldn't it be easier just to go back to the original idea that I had of saying "XX: no semicolon at end of line"?

Samuel Lauber

----- Original Message -----
From: "Luca Benini" <lbenini@csr.unibo.it>
To: "Ian Lance Taylor" <ian@wasabisystems.com>
Subject: Re: feature request
Date: Wed, 17 Nov 2004 08:43:09 +0100

> 
> Ian Lance Taylor wrote:
> 
> > context.  You might have to parse the messages a bit to pick out the
> > directory in which to find the file, but I doubt that would be all
> > that difficult.
> 
> Well there's another way (i think), extracting the gcc code for 
> commandline parsing and for output formatting we (I?) can create a 
> library useful for generic gcc wrapper.
> Now i have to complete the scripts for gcc mirrors check (i hate http 
> ;-)), but if you think this library can be completed in a reasonable 
> time, it will be useful can you count me for dev.
> 
> 
> Luca Benini
> 
> 

-- 
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze

Re: feature request

[Luca Benini]

Ian Lance Taylor wrote:

> context.  You might have to parse the messages a bit to pick out the
> directory in which to find the file, but I doubt that would be all
> that difficult.

Well there's another way (i think), extracting the gcc code for 
commandline parsing and for output formatting we (I?) can create a 
library useful for generic gcc wrapper.
Now i have to complete the scripts for gcc mirrors check (i hate http 
;-)), but if you think this library can be completed in a reasonable 
time, it will be useful can you count me for dev.


Luca Benini

Re: feature request

[Ian Lance Taylor]

"Sam Lauber" <sam124@operamail.com> writes:

> Wrapper program? That wouldn't exactly be a simple programming job
> because I would probably have to duplicate all the source-file
> reading (or at least parsing) code from GCC. I would also have to
> make the warnings in the exact same format that GCC uses. Which just
> the line wrap seems hard.

gcc generates error and warning messages in a very predictable format.
That is how IDEs can handle it.  You don't have to do any source-file
parsing.  You just have to look for FILENAME:LINENO pairs in the
output, and then open the file, read ahead to the line, and dump
context.  You might have to parse the messages a bit to pick out the
directory in which to find the file, but I doubt that would be all
that difficult.

It's not like it would be all that much easier for gcc to do this
itself.  gcc doesn't keep the source file in memory after it has been
parsed.

Ian

> ----- Original Message -----
> From: "Ian Lance Taylor" <ian@wasabisystems.com>
> To: "Luca Benini" <lbenini@csr.unibo.it>
> Subject: Re: feature request
> Date: 16 Nov 2004 13:27:03 -0500
> 
> > 
> > Luca Benini <lbenini@csr.unibo.it> writes:
> > 
> > > Joe Buck wrote:
> > > > That would be really ugly for those of us that use gcc from an IDE
> > > 
> > > But a little flag? something like -Wiwanteyecandyoutput ?
> > > During long compiling session in console (make) this feature can be
> > > useful or not?
> > 
> > How about first writing and contributing a little wrapper program that
> > you pipe gcc stderr through?  Then maybe we could add a gcc option
> > which automatically invoked that program on stderr.

Re: feature request

[Sam Lauber]

Wrapper program? That wouldn't exactly be a simple programming job because I would probably have to duplicate all the source-file reading (or at least parsing) code from GCC. I would also have to make the warnings in the exact same format that GCC uses. Which just the line wrap seems hard. If your idea is for that, count me out. Whenever I try to program anything more than 10 lines of code, GCC gives me 1000 errors for everything, and if I put -Wall, it gives me 10000 warnings.

Samuel Lauber

----- Original Message -----
From: "Ian Lance Taylor" <ian@wasabisystems.com>
To: "Luca Benini" <lbenini@csr.unibo.it>
Subject: Re: feature request
Date: 16 Nov 2004 13:27:03 -0500

> 
> Luca Benini <lbenini@csr.unibo.it> writes:
> 
> > Joe Buck wrote:
> > > That would be really ugly for those of us that use gcc from an IDE
> > 
> > But a little flag? something like -Wiwanteyecandyoutput ?
> > During long compiling session in console (make) this feature can be
> > useful or not?
> 
> How about first writing and contributing a little wrapper program that
> you pipe gcc stderr through?  Then maybe we could add a gcc option
> which automatically invoked that program on stderr.
> 
> Ian
> 

-- 
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze

Re: feature request

[Ian Lance Taylor]

Luca Benini <lbenini@csr.unibo.it> writes:

> Joe Buck wrote:
> > That would be really ugly for those of us that use gcc from an IDE
> 
> But a little flag? something like -Wiwanteyecandyoutput ?
> During long compiling session in console (make) this feature can be
> useful or not?

How about first writing and contributing a little wrapper program that
you pipe gcc stderr through?  Then maybe we could add a gcc option
which automatically invoked that program on stderr.

Ian

Re: feature request

[Luca Benini]

Joe Buck wrote:
> That would be really ugly for those of us that use gcc from an IDE

But a little flag? something like -Wiwanteyecandyoutput ?
During long compiling session in console (make) this feature can be 
useful or not?


Luca

Re: feature request

[Joe Buck]

On Tue, Nov 16, 2004 at 09:35:19AM -0800, David Skinner wrote:
> I was thinking more generally than just semicolons. Any single line 
> based syntax problem could report the context in the source in which the 
> error was encountered.

That would be really ugly for those of us that use gcc from an IDE
or with Emacs; the IDE or Emacs parses the file name and line number
and allows the programmer to step from one error to the next in a
window, where the context of the error is clear.

If you want to see the context of your errors, I suggest that you use
one of these solutions.

Re: feature request

[David Skinner]

Hi Sam,

I was thinking more generally than just semicolons. Any single line 
based syntax problem could report the context in the source in which the 
error was encountered.

-David

Sam Lauber wrote:
> I agree with you. It's very frustrating when I forget the semicolon and GCC says that. But I have an idea:
> 
> code: return "something" /* no semicolon */
> 
> GCC:
> somefile.c:35: no semicolon at end of line
> 
> I think that would be a good idea. Maybe there could be an option -falternitive-semicolons that switches between your behavior, my behavior, and the default.
> 
> Samuel Lauber
> 
> ----- Original Message -----
> From: David Skinner <dskinner@nersc.gov>
> To: gcc@gnu.org
> Subject: feature request
> Date: Mon, 15 Nov 2004 14:08:09 -0800
> 
> 
>>could this sort of output :
>>
>>gcc -O2 -g -c -DLINUX_X86 -I../include -DIPM_SYSLOG_DIR="\"/doesnotexist\""
>>-DPENTIUM_M -I/usr/common/usg/papi/3.0b4//include -DHPM_PAPI
>>-DPENTIUM_M libipm.c
>>libipm.c: In function `ipm_report':
>>libipm.c:5650: syntax error before ';' token
>>make[1]: *** [libipm.a] Error 1
>>
>>be augmented with a line or two given context of the error?
>>
>>
>>gcc -O2 -g -c -DLINUX_X86 -I../include -DIPM_SYSLOG_DIR="\"/doesnotexist\""
>>-DPENTIUM_M -I/usr/common/usg/papi/3.0b4//include -DHPM_PAPI
>>-DPENTIUM_M libipm.c
>>libipm.c: In function `ipm_report':
>>libipm.c:5650: syntax error before ';' token
>>libipm.c:  /* print stuff */
>>libipm.c:  printf("I forgot the semicolon\n")
>>libipm.c:  printf("I remembered it this time :)\n");
>>make[1]: *** [libipm.a] Error 1
>>
>>
> 
> 

Re: feature request

[Sam Lauber]

I agree with you. It's very frustrating when I forget the semicolon and GCC says that. But I have an idea:

code: return "something" /* no semicolon */

GCC:
somefile.c:35: no semicolon at end of line

I think that would be a good idea. Maybe there could be an option -falternitive-semicolons that switches between your behavior, my behavior, and the default.

Samuel Lauber

----- Original Message -----
From: David Skinner <dskinner@nersc.gov>
To: gcc@gnu.org
Subject: feature request
Date: Mon, 15 Nov 2004 14:08:09 -0800

> 
> could this sort of output :
> 
> gcc -O2 -g -c -DLINUX_X86 -I../include -DIPM_SYSLOG_DIR="\"/doesnotexist\""
> -DPENTIUM_M -I/usr/common/usg/papi/3.0b4//include -DHPM_PAPI
> -DPENTIUM_M libipm.c
> libipm.c: In function `ipm_report':
> libipm.c:5650: syntax error before ';' token
> make[1]: *** [libipm.a] Error 1
> 
> be augmented with a line or two given context of the error?
> 
> 
> gcc -O2 -g -c -DLINUX_X86 -I../include -DIPM_SYSLOG_DIR="\"/doesnotexist\""
> -DPENTIUM_M -I/usr/common/usg/papi/3.0b4//include -DHPM_PAPI
> -DPENTIUM_M libipm.c
> libipm.c: In function `ipm_report':
> libipm.c:5650: syntax error before ';' token
> libipm.c:  /* print stuff */
> libipm.c:  printf("I forgot the semicolon\n")
> libipm.c:  printf("I remembered it this time :)\n");
> make[1]: *** [libipm.a] Error 1
> 
> 

-- 
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze

feature request

[David Skinner]

could this sort of output :

gcc -O2 -g -c -DLINUX_X86 -I../include -DIPM_SYSLOG_DIR="\"/doesnotexist\""
-DPENTIUM_M -I/usr/common/usg/papi/3.0b4//include -DHPM_PAPI
-DPENTIUM_M libipm.c
libipm.c: In function `ipm_report':
libipm.c:5650: syntax error before ';' token
make[1]: *** [libipm.a] Error 1

be augmented with a line or two given context of the error?


gcc -O2 -g -c -DLINUX_X86 -I../include -DIPM_SYSLOG_DIR="\"/doesnotexist\""
-DPENTIUM_M -I/usr/common/usg/papi/3.0b4//include -DHPM_PAPI
-DPENTIUM_M libipm.c
libipm.c: In function `ipm_report':
libipm.c:5650: syntax error before ';' token
libipm.c:  /* print stuff */
libipm.c:  printf("I forgot the semicolon\n")
libipm.c:  printf("I remembered it this time :)\n");
make[1]: *** [libipm.a] Error 1

Re: Feature Request

[Dave Hudson]

L C wrote:
> 1) I don't think the ISO code and unecessary typecasting issues would be 
> a concern since the requested compiler switch would obviously not be the 
> default. You would have to intentionally enable it and therefore realize 
> the ramifications.

One major concern I would have is that it's very easy to make mistakes 
that cause complete chaos in unexpected parts of gcc's infrastructure - 
the new switch would render most of the C torture test suite inoperable 
and thus the quality of the resultant code might be somewhat debatable 
at best - the solution I've taken allows me to continue to use the full 
testsuite and trap many otherwise subtle problems.

> 3) I think for a typical simple embedded systems program the savings 
> would be greater than your 2-2.5%. I changed one arithmetic calculation 
> on my AVR such that I casted every calc back to unsigned char and the 
> code to do the calculation went from about 14 bytes to 4. It would also 
> be especially valuable in interrupt service routines where small code 
> size is key.

I think a lot depends on how you're code works - there are some 
pathalogical integer promotions but I guess it depends what your ratio 
of numeric code is to other code.  I can point to examples where I've 
seen much larger reductions but overall within a pretty general OS, 
device driver, network protocol and application codebase the saving was 
under 3% - obviously some individual cases had savings of 50%+.  The 
code in question probably does have some explicit typecasts but not too 
many.

I guess you could always ask Denis Chertykov his thoughts on this since 
he wrote the AVR port and he looks after the IP2k port in the FSF tree.


Regards,
Dave

Re: Feature Request

[Fergus Henderson]

On 06-Nov-2002, L C <listcatcher@shaw.ca> wrote:
> 1) I don't think the ISO code and unecessary typecasting issues would be 
> a concern since the requested compiler switch would obviously not be the 
> default. You would have to intentionally enable it and therefore realize 
> the ramifications.

Nevertheless, adding a compiler switch like which changes the language
semantics means adding another "dialect" of C.  Having a proliferation
of different dialects leads to a number of difficulties, e.g. it makes
reusing existing code more difficult.  Hence it would be much nicer to
just get the compiler to optimize the code better, rather than creating
a new dialect.

> 2) I'm an experienced hardware/firmware developer and I'm afraid I 
> wouldn't have a clue how to write the backend code you are talking 
> about.

Well, you could have a look at the code for the IP 2022 backend.
Certainly it is true that writing or maintaining code like this
requires considerable understanding of GCC internals.  But this is
a better way of doing it.  It would IMHO be a bad idea to add a
compiler switch merely because no-one with the necessary expertise
to write a back-end optimization pass was willing to take on the task.

> A simple compiler switch would simplify matters greatly.

It would simplify some things, but at the expense of complicating other
things.  For example, adding such a compiler switch would make it more
difficult to test GCC.  The end result of that would be a compiler which
is overall less reliable and more difficult to maintain.

> 3) I think for a typical simple embedded systems program the savings 
> would be greater than your 2-2.5%. I changed one arithmetic calculation 
> on my AVR such that I casted every calc back to unsigned char and the 
> code to do the calculation went from about 14 bytes to 4. It would also 
> be especially valuable in interrupt service routines where small code 
> size is key.

For interrupt service routines it is easy enough to add the desired
casts manually, no?

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: Feature Request

[L C]

Thanks for the reply. I'd like to address some of your points, and 
hopefully this request will be considered...

1) I don't think the ISO code and unecessary typecasting issues would be 
a concern since the requested compiler switch would obviously not be the 
default. You would have to intentionally enable it and therefore realize 
the ramifications.
2) I'm an experienced hardware/firmware developer and I'm afraid I 
wouldn't have a clue how to write the backend code you are talking 
about. A simple compiler switch would simplify matters greatly.
3) I think for a typical simple embedded systems program the savings 
would be greater than your 2-2.5%. I changed one arithmetic calculation 
on my AVR such that I casted every calc back to unsigned char and the 
code to do the calculation went from about 14 bytes to 4. It would also 
be especially valuable in interrupt service routines where small code 
size is key.

I'd be interested in others' views and if I should be making this 
request elsewhere, please let me know. Thanks.


Dave Hudson wrote:

> Hi,
>
> L C wrote:
>
>> I'd like to request an option to disable the promotion of chars 
>> (signed and unsigned) to ints when doing arithmetic calculations on 
>> them. I realize this is non-ANSI standard, but it would be 
>> particularly valuable when working with 8-bit processors such as the 
>> AVR. (Ie., big speed boost and code size reduction).
>
>
> I don't believe that this is necessary for the core of gcc - it can 
> cause quite unexpected consequences for compiling ISO code and would 
> lead to a lot of otherwise unecessary typecasting required in other code.
>
> I had the same problem in the IP2022 backend and wrote some 
> backend-specific code to deal with it.  The code causes zero extends 
> and some sign extends to be split and then runs a propagation pass.  
> Where it identifies (for example) that the upper 16 bits of an 
> operation can be simplified by knowing that one operand is 0x00 (or 
> possibly 0xff in the sign-extended cases) then it simplifies the RTL 
> back to an 8-bit form instead of its promoted 16-bit form.
>
> In the 200 kBytes of object code that I regularly compile I'm only 
> aware of a small number of instances and one generic class of problem 
> where this solution doesn't fully simplify things as desired and 
> they're only not done because the propagation pass does not do 
> everything that it could.
>
> The generic class of problem is where a function result is an 8-bit 
> quantity because gcc will always promote the result to 16 bits.  I can 
> live with this because it avoids problems with older source code but 
> it's a little irritating when an already sign extended result is sign 
> extended again.
>
> Of course one advantage with the approach I took is that sometimes 
> things that started out as 16-bit operations in the source code become 
> simplified to a more efficient 8-bit form whereas a compile flag won't 
> do this.
>
> FWIW I'm not sure that the win is quite as large as you think - I've 
> estimated the win from the code I wrote to be around 2% to 2.5%, and 
> this on a codebase where every variable possible is 8 bits wide.  I've 
> seen the biggest wins in situations where switch statements are 
> converted from jump tables into if/else chains.  Of course with 
> something like the IP2022 or AVR then such small improvements can look 
> huge if it means getting an app to fit the memory space :-)
>
>
> Regards,
> Dave
>
>

Re: Feature Request

[Dave Hudson]

Hi,

L C wrote:
> I'd like to request an option to disable the promotion of chars (signed 
> and unsigned) to ints when doing arithmetic calculations on them. I 
> realize this is non-ANSI standard, but it would be particularly valuable 
> when working with 8-bit processors such as the AVR. (Ie., big speed 
> boost and code size reduction).

I don't believe that this is necessary for the core of gcc - it can 
cause quite unexpected consequences for compiling ISO code and would 
lead to a lot of otherwise unecessary typecasting required in other code.

I had the same problem in the IP2022 backend and wrote some 
backend-specific code to deal with it.  The code causes zero extends and 
some sign extends to be split and then runs a propagation pass.  Where 
it identifies (for example) that the upper 16 bits of an operation can 
be simplified by knowing that one operand is 0x00 (or possibly 0xff in 
the sign-extended cases) then it simplifies the RTL back to an 8-bit 
form instead of its promoted 16-bit form.

In the 200 kBytes of object code that I regularly compile I'm only aware 
of a small number of instances and one generic class of problem where 
this solution doesn't fully simplify things as desired and they're only 
not done because the propagation pass does not do everything that it could.

The generic class of problem is where a function result is an 8-bit 
quantity because gcc will always promote the result to 16 bits.  I can 
live with this because it avoids problems with older source code but 
it's a little irritating when an already sign extended result is sign 
extended again.

Of course one advantage with the approach I took is that sometimes 
things that started out as 16-bit operations in the source code become 
simplified to a more efficient 8-bit form whereas a compile flag won't 
do this.

FWIW I'm not sure that the win is quite as large as you think - I've 
estimated the win from the code I wrote to be around 2% to 2.5%, and 
this on a codebase where every variable possible is 8 bits wide.  I've 
seen the biggest wins in situations where switch statements are 
converted from jump tables into if/else chains.  Of course with 
something like the IP2022 or AVR then such small improvements can look 
huge if it means getting an app to fit the memory space :-)


Regards,
Dave

Feature Request

[L C]

I have a request for a compile line option for gcc. I hope this is a 
good place to put it...

I'd like to request an option to disable the promotion of chars (signed 
and unsigned) to ints when doing arithmetic calculations on them. I 
realize this is non-ANSI standard, but it would be particularly valuable 
when working with 8-bit processors such as the AVR. (Ie., big speed 
boost and code size reduction).

Thanks.