Re: RFC: -Wall by default

[Pedro Alves]

On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:

> Hi,
> 
> For GCC-4.8, I would like to turn on -Wall by default.
> Comments?


I'd just like to explicitly mention (the obvious fact that)
that this has the effect of breaking builds of projects that carefully
craft their warning set to be able to use -Werror, such as e.g., GDB.

Certainly not insurmountable (just add a -Wno-all), but does
require actively tweaking the build system.  I'm sure there
are many projects affected similarly.

-- 
Pedro Alves

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Wed, Apr 4, 2012 at 7:53 PM, Lawrence Crowl  wrote:
> On 4/4/12, Richard Guenther  wrote:
>> On Apr 4, 2012 Bernd Schmidt  wrote:
>> > On 04/04/2012 11:06 AM, Richard Guenther wrote:
>> > > So - I'll veto the switch unless I see 1) and 2).  1) and 2)
>> > > can be combined by transitioning vec.h to a C++ template class,
>> > > with proper GC support.  (not sure that I can veto anything
>> > > - heh)
>> >
>> > I don't think I can veto anything, but I'll go on the record
>> > again saying that I don't think this entire plan is a good
>> > idea. Write a new project in C++? Absolutely. Convert a large
>> > existing one to a different language? A huge waste of time that
>> > will distract us for years from actual user-visible changes.
>>
>> I agree for the idea of converting all of GCC to C++ (whatever
>> that means).  I disagree for the part making the internal
>> infrastructure easier to use, understand and maintain.  Which
>> means targeting mostly isolated sub-systems, like vec.h (and
>> other various containers), double-int.[ch] (and other various
>> way of representing and working with constants).  Making tree
>> or gimple a C++ class with inheritance and whatever is indeed
>> a huge waste of time and existing developer ressources (that,
>> if only because they have to adapt and maintain two completely
>> different code-bases over some time).
>
> Trees are presently a significant problem in that many static errors
> become dynamic errors, which entails more debugging.

How do you expect tree errors to become static?  By using derived
types everywhere?  Note that this would only be possible in a _very_
limited sub-set of places.

>> I expect the GCC core to maintain written in C, compiled by C++.
>
> Converting VECs to C++ vectors vector would provide significant code
> clarity benefits.  The files in which that is done would necessarily
> be C++ only.

I already had VECs as the very first and best example why C++ might
be good.

>> > I also find debugging C++ in gdb somewhat more annoying than
>> > debugging plain C, and at the moment I always go back to a
>> > stage1 compiler.
>>
>> Indeed - I'd be worried if my debugging efficiency decreases by
>> more than 5%.
>
> If the number of debugging sessions was reduced by the same amount,
> the result would be a net wash.

I have no expectation that the number of debug sessions will be reduced.

Richard.

> --
> Lawrence Crowl

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 3:58 AM, Pedro Alves  wrote:
> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>
>> Hi,
>>
>> For GCC-4.8, I would like to turn on -Wall by default.
>> Comments?
>
>
> I'd just like to explicitly mention (the obvious fact that)
> that this has the effect of breaking builds of projects that carefully
> craft their warning set to be able to use -Werror, such as e.g., GDB.
>
> Certainly not insurmountable (just add a -Wno-all), but does
> require actively tweaking the build system.  I'm sure there
> are many projects affected similarly.

Be assured that I fully appreciate that projects do use -Werror.
In fact, I do personally encourage people to use -Werror.

However, the issue is very specific: we talking about -Wall.
If something there is wrong as a default we should have a look
at it whether it should be there at all, should it be improved, etc.

-- Gaby

Re: RFC: -Wall by default

[Richard Guenther]

On Wed, Apr 4, 2012 at 5:17 PM, Ian Lance Taylor  wrote:
> Andrew Haley  writes:
>
>> On 04/04/2012 03:56 PM, Ian Lance Taylor wrote:
>>> Andrew Haley  writes:
>>>
 On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
> For GCC-4.8, I would like to turn on -Wall by default.
> Comments?

 Umm, should this really happen at exactly the same time as C++
 by default?
>>>
>>> I assume that Gaby is talking about making -Wall the default for users
>>> of GCC.
>>
>> Oh, wow.  Really?  That's a big change.  Time to be brave, I guess,
>> but I very much like the idea of a gcc that does just what it's told;
>> making -Wall the default is a big break with tradition.
>
> Yes, that would be a big change.

At the same time we should make 'gcc' optimize as every other compiler.
Thus, default to -O2.

Richard.

Re: RFC: -Wall by default

[Richard Guenther]

On Thu, Apr 5, 2012 at 6:21 AM, Gabriel Dos Reis
 wrote:
> On Wed, Apr 4, 2012 at 8:19 PM, Robert Dewar  wrote:
>> On 4/4/2012 7:03 PM, Gabriel Dos Reis wrote:
>>
>>> Again, this proposal does not come out of a whim.
>>
>>
>> But it does seem to come out of a few anecdotal requests
>> for a change,
>
> It does appear very disturbing that you would dismiss repeated
> requests on the basis that they are anecdotal without offering
> evidence.  What is more, we seem to have implemented a feature
> that makes it even more intimidating for potential users to fill
> out such requests.

Well, fact is that we of course do not get any requests reading
"Please keep -Wall not enabled by default".  I think if we would
they would outnumber the requests for the opposite.

Richard.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 4:32 AM, Richard Guenther
 wrote:
> On Wed, Apr 4, 2012 at 5:17 PM, Ian Lance Taylor  wrote:
>> Andrew Haley  writes:
>>
>>> On 04/04/2012 03:56 PM, Ian Lance Taylor wrote:
 Andrew Haley  writes:

> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>> For GCC-4.8, I would like to turn on -Wall by default.
>> Comments?
>
> Umm, should this really happen at exactly the same time as C++
> by default?

 I assume that Gaby is talking about making -Wall the default for users
 of GCC.
>>>
>>> Oh, wow.  Really?  That's a big change.  Time to be brave, I guess,
>>> but I very much like the idea of a gcc that does just what it's told;
>>> making -Wall the default is a big break with tradition.
>>
>> Yes, that would be a big change.
>
> At the same time we should make 'gcc' optimize as every other compiler.
> Thus, default to -O2.

Which goes back to what I said earlier: it is "does what it is told".

- Gaby

Re: RFC: -Wall by default

[Richard Guenther]

On Thu, Apr 5, 2012 at 11:32 AM, Gabriel Dos Reis
 wrote:
> On Thu, Apr 5, 2012 at 3:58 AM, Pedro Alves  wrote:
>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>
>>> Hi,
>>>
>>> For GCC-4.8, I would like to turn on -Wall by default.
>>> Comments?
>>
>>
>> I'd just like to explicitly mention (the obvious fact that)
>> that this has the effect of breaking builds of projects that carefully
>> craft their warning set to be able to use -Werror, such as e.g., GDB.
>>
>> Certainly not insurmountable (just add a -Wno-all), but does
>> require actively tweaking the build system.  I'm sure there
>> are many projects affected similarly.
>
> Be assured that I fully appreciate that projects do use -Werror.
> In fact, I do personally encourage people to use -Werror.
>
> However, the issue is very specific: we talking about -Wall.
> If something there is wrong as a default we should have a look
> at it whether it should be there at all, should it be improved, etc.

Btw, it would be more reasonable to enable a subset of warnings that
we enable at -Wall by default.  Notably those that if they were not
false positives, would lead to undefined behavior at runtime.  Specifically
I don't think we should warn about unused static functions or variables
by default.

Richard.

> -- Gaby

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 4:36 AM, Richard Guenther
 wrote:
> On Thu, Apr 5, 2012 at 6:21 AM, Gabriel Dos Reis
>  wrote:
>> On Wed, Apr 4, 2012 at 8:19 PM, Robert Dewar  wrote:
>>> On 4/4/2012 7:03 PM, Gabriel Dos Reis wrote:
>>>
 Again, this proposal does not come out of a whim.
>>>
>>>
>>> But it does seem to come out of a few anecdotal requests
>>> for a change,
>>
>> It does appear very disturbing that you would dismiss repeated
>> requests on the basis that they are anecdotal without offering
>> evidence.  What is more, we seem to have implemented a feature
>> that makes it even more intimidating for potential users to fill
>> out such requests.
>
> Well, fact is that we of course do not get any requests reading
> "Please keep -Wall not enabled by default".

If you try to submit a request about -Wall, you get a real time search
that shows related requests and how they had been dismissed
(in my opinion too summarily).  That has a dissuading effect to filing
another request of the same type.  So, you might come to the conclusion
you do not get enough, but because you have a system in place to dissuade
such request.  It is a system for self-fulfulling prophecy.

> I think if we would
> they would outnumber the requests for the opposite.

I don't know about that :-)

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 4:39 AM, Richard Guenther
 wrote:

> Btw, it would be more reasonable to enable a subset of warnings that
> we enable at -Wall by default.

Which ones for example?

Here is a (partial) list:
  -Wformat
  -Wchar-subscripts
  -Wmissing-braces
  -Wparentheses
  -Wreturn-type
  -Wsequence-point
  -Wstrict-aliasing
  -Wswitch
  -Waddress
  -Wstrict-overflow
  -Warray-bounds
  -Wvolatile-register
  -Wunknown-pragmas
  -Wuninitialized
  -Wmaybe-uninitialized
  -Wmain
  -Wenum-compare
  -Wsign-compare
  -Wreorder
  -Wc++0x-compat
  -Wnarrowing
  -Wtrigraphs
  -Wcomments
  -Wpointer-sign

 > Notably those that if they were not
> false positives, would lead to undefined behavior at runtime.  Specifically
> I don't think we should warn about unused static functions or variables
> by default.
>
> Richard.
>
>> -- Gaby

Re: RFC: -Wall by default

[Pedro Alves]

On 04/05/2012 10:39 AM, Richard Guenther wrote:

... [-Wall + -Werror] ...

> Btw, it would be more reasonable to enable a subset of warnings that
> we enable at -Wall by default.  Notably those that if they were not
> false positives, would lead to undefined behavior at runtime.  Specifically
> I don't think we should warn about unused static functions or variables
> by default.


Yes, I would agree more with something like that.

-- 
Pedro Alves

Re: RFC: -Wall by default

[Richard Guenther]

On Thu, Apr 5, 2012 at 11:46 AM, Gabriel Dos Reis
 wrote:
> On Thu, Apr 5, 2012 at 4:39 AM, Richard Guenther
>  wrote:
>
>> Btw, it would be more reasonable to enable a subset of warnings that
>> we enable at -Wall by default.
>
> Which ones for example?
>
> Here is a (partial) list:
>  -Wformat
>  -Wchar-subscripts
>  -Wmissing-braces
>  -Wparentheses
>  -Wreturn-type
>  -Wsequence-point
>  -Wstrict-aliasing
>  -Wswitch
>  -Waddress
>  -Wstrict-overflow
>  -Warray-bounds
>  -Wvolatile-register
>  -Wunknown-pragmas
>  -Wuninitialized
>  -Wmaybe-uninitialized
>  -Wmain
>  -Wenum-compare
>  -Wsign-compare
>  -Wreorder
>  -Wc++0x-compat
>  -Wnarrowing
>  -Wtrigraphs
>  -Wcomments
>  -Wpointer-sign

Are there more specific requests than "enable -Wall by default"?  Are
there requests to remove some options from -Wall?  Are there requests
to add some options to -Wall?

Note that some of the above depend on optimization flag settings
(and optimization happening).  Those are not good candidates - I think
good candidates are those that would still be fully operational with
-fsyntax-only.

Richard.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 4:51 AM, Richard Guenther
 wrote:
> On Thu, Apr 5, 2012 at 11:46 AM, Gabriel Dos Reis
>  wrote:
>> On Thu, Apr 5, 2012 at 4:39 AM, Richard Guenther
>>  wrote:
>>
>>> Btw, it would be more reasonable to enable a subset of warnings that
>>> we enable at -Wall by default.
>>
>> Which ones for example?
>>
>> Here is a (partial) list:
>>  -Wformat
>>  -Wchar-subscripts
>>  -Wmissing-braces
>>  -Wparentheses
>>  -Wreturn-type
>>  -Wsequence-point
>>  -Wstrict-aliasing
>>  -Wswitch
>>  -Waddress
>>  -Wstrict-overflow
>>  -Warray-bounds
>>  -Wvolatile-register
>>  -Wunknown-pragmas
>>  -Wuninitialized
>>  -Wmaybe-uninitialized
>>  -Wmain
>>  -Wenum-compare
>>  -Wsign-compare
>>  -Wreorder
>>  -Wc++0x-compat
>>  -Wnarrowing
>>  -Wtrigraphs
>>  -Wcomments
>>  -Wpointer-sign
>
> Are there more specific requests than "enable -Wall by default"?

The simpler requests are -Wall by default.  (there are some occasional
-pedantic).

The ones I've heard in person -- with the requesters quite competent and
respectable programmers -- are in less polite words what I can possibly
convey in this discussion.  Adding more options isn't on the top of the list
(to quote "I can't go through the 1 options to figure out which ones
will work for something this obvious that should be done by default.")


> Are
> there requests to remove some options from -Wall?  Are there requests
> to add some options to -Wall?
>
> Note that some of the above depend on optimization flag settings
> (and optimization happening).

I think I have long registered my opinion that diagnostics should not depend
on optimizations.  We had had that discussion in the past and I know we
have differing opinions; I am not opening that particular discussion now.
What I would like to say is that if a warning is effective only when
optimization
is turned on, it does not hurt that it enabled by default even if -On
levels would
make it more effective.  I am not going to fight on that though.

> Those are not good candidates - I think
> good candidates are those that would still be fully operational with
> -fsyntax-only.
>
> Richard.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 4:51 AM, Richard Guenther
 wrote:

>> Here is a (partial) list:
>>  -Wformat
>>  -Wchar-subscripts
>>  -Wmissing-braces
>>  -Wparentheses
>>  -Wreturn-type
>>  -Wsequence-point
>>  -Wstrict-aliasing
>>  -Wswitch
>>  -Waddress
>>  -Wstrict-overflow
>>  -Warray-bounds
>>  -Wvolatile-register
>>  -Wunknown-pragmas
>>  -Wuninitialized
>>  -Wmaybe-uninitialized
>>  -Wmain
>>  -Wenum-compare
>>  -Wsign-compare
>>  -Wreorder
>>  -Wc++0x-compat
>>  -Wnarrowing
>>  -Wtrigraphs
>>  -Wcomments
>>  -Wpointer-sign
>
> Are there more specific requests than "enable -Wall by default"?  Are
> there requests to remove some options from -Wall?  Are there requests
> to add some options to -Wall?
>
> Note that some of the above depend on optimization flag settings
> (and optimization happening).  Those are not good candidates - I think
> good candidates are those that would still be fully operational with
> -fsyntax-only.

I am not sure -fsyntax-only is a good criteria.
-fsyntax-only limits the amount of work that the compiler does in terms
of code generation, but it should be orthogonal to diagnostic issues.

-- Gaby

Re: RFC: -Wall by default

[Arnaud Charlet]

> The simpler requests are -Wall by default.  (there are some occasional
> -pedantic).
> 
> The ones I've heard in person -- with the requesters quite competent and
> respectable programmers -- are in less polite words what I can possibly
> convey in this discussion.  Adding more options isn't on the top of the list
> (to quote "I can't go through the 1 options to figure out which ones
> will work for something this obvious that should be done by default.")

Could you give some examples of which warnings these people were
expecting to be "obviously enabled by default" ?

I think that would be helpful.

BTW, I don't think -pedantic should be enabled by default, or this wouldn't
be "pedantic" anymore.

Arno

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 5:04 AM, Arnaud Charlet  wrote:
>> The simpler requests are -Wall by default.  (there are some occasional
>> -pedantic).
>>
>> The ones I've heard in person -- with the requesters quite competent and
>> respectable programmers -- are in less polite words what I can possibly
>> convey in this discussion.  Adding more options isn't on the top of the list
>> (to quote "I can't go through the 1 options to figure out which ones
>> will work for something this obvious that should be done by default.")
>
> Could you give some examples of which warnings these people were
> expecting to be "obviously enabled by default" ?

From the list I gave earlier:

  -Wformat
  -Wimplicit
  -Wreturn-type
  -Wsequence-point
  -Wswitch
  -Waddress
  -Wstrict-aliasing
  -Wenum-compare
  -Wreorder
  -Wpointer-sign


>
> I think that would be helpful.
>
> BTW, I don't think -pedantic should be enabled by default, or this wouldn't
> be "pedantic" anymore.

I am not proposing that in this discussion.  I was answering a question.

-- Gaby

Re: RFC: -Wall by default

[Arnaud Charlet]

> From the list I gave earlier:
> 
>   -Wformat
>   -Wimplicit
>   -Wreturn-type
>   -Wsequence-point
>   -Wswitch
>   -Waddress
>   -Wstrict-aliasing
>   -Wenum-compare
>   -Wreorder
>   -Wpointer-sign

OK, the above list looks reasonable to me at least as a starting point
that could be a bit refined (not sure -Wstrict-aliasing is so useful by
default for instance for legacy code), certainly much more reasonable
than 'enable -Wall by default', since as I said, switches such as
-Wuninitialized may generate lots of false positives, annoying people.

> > BTW, I don't think -pedantic should be enabled by default, or this
> > wouldn't be "pedantic" anymore.
> 
> I am not proposing that in this discussion.  I was answering a question.

Sure, but this still gives us a perspective and datapoint that what some
users ask and consider as 'obvious' are actually not reasonable requests.

Arno

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 5:16 AM, Arnaud Charlet  wrote:
>> From the list I gave earlier:
>>
>>   -Wformat
>>   -Wimplicit
>>   -Wreturn-type
>>   -Wsequence-point
>>   -Wswitch
>>   -Waddress
>>   -Wstrict-aliasing
>>   -Wenum-compare
>>   -Wreorder
>>   -Wpointer-sign
>
> OK, the above list looks reasonable to me at least as a starting point
> that could be a bit refined (not sure -Wstrict-aliasing is so useful by
> default for instance for legacy code), certainly much more reasonable
> than 'enable -Wall by default', since as I said, switches such as
> -Wuninitialized may generate lots of false positives, annoying people.

Well, if you write code so obvious that -Wuninitialized is annoying then:
either the implementation of -Wuninitialized should be improved, or as you
are so expert that you can add -Wno-uninitialized.  I think the argument
cuts both ways.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 5:16 AM, Arnaud Charlet  wrote:
>> From the list I gave earlier:
>>
>>   -Wformat
>>   -Wimplicit
>>   -Wreturn-type
>>   -Wsequence-point
>>   -Wswitch
>>   -Waddress
>>   -Wstrict-aliasing
>>   -Wenum-compare
>>   -Wreorder
>>   -Wpointer-sign
>
> OK, the above list looks reasonable to me at least as a starting point
> that could be a bit refined (not sure -Wstrict-aliasing is so useful by
> default for instance for legacy code), certainly much more reasonable
> than 'enable -Wall by default', since as I said, switches such as
> -Wuninitialized may generate lots of false positives, annoying people.

by the way, at the exception of a very tiny percentage,
what actually is in -Wall is far more reasonable that an abstract
debate about a warning by default might make it sound.

-- Gaby

Re: RFC: -Wall by default

[Robert Dewar]

On 4/5/2012 12:17 AM, Miles Bader wrote:

Robert Dewar  writes:

We have run into people running benchmarks where they were
specifically prohibited from using other than the default
options, and gcc fared badly in such comparisons.


Yeah, there was the silly "benchmark" at phoronix where they came to
the conclusion that tcc was a better compiler than gcc because it
generated faster programs when run without any options...

[*] Phoronix is well known for completely clueless benchmarking
practices, but ... unfortunately some people actually seem to pay
attention to what they say.


Well a lot of users have been burned by using optimization
options, either becausae of compiler bugs, or because of bugs
in their own code triggered by optimization. So the requirement
of not using any optimization options is not that uncommon.


-miles

Re: RFC: -Wall by default

[Arnaud Charlet]

> Well, if you write code so obvious that -Wuninitialized is annoying then:

No, the code is certainly not obvious, and improving -Wuninitialized although
a nice goal is likely to require lots of effort, likely at the expense of
removing some useful warnings.

> either the implementation of -Wuninitialized should be improved, or as you

You can't have it both ways: either -Wuninitialized is indeed improved to the
point where it generates almost no false positives, and then enabling it
by default should be considered/done; or -Wuninitialized does generate
false positives and enabling it by default is likely not a good idea.

Same for -Wmaybe-uninitialized, also part of -Wall.

> are so expert that you can add -Wno-uninitialized.  I think the argument
> cuts both ways.

Who said anything about being "so expert"? IMO that's precisely non
experts who will get the most annoyed here, because they may not understand
why the warning is generated, nor how to disable it.

And IMO, a discussion about a "default" is certainly NOT about experts,
it's precisely a discussion about what would be the best default for most
people (and most people are not experts).

Arno

Re: RFC: -Wall by default

[Robert Dewar]

On 4/5/2012 12:23 AM, Gabriel Dos Reis wrote:


-Wall is roughtly equivalent to -gnatwa in the GNAT front end,
and this is definitely NOT on by default. If you run GNAT in
default mode, there are virtually no false positives, since
the only warnings on by default are the kind of warnings that
say "if you execute this statement, your program will go wrong"


like calling a function with non-void return type whose definition
ails to return value.


Right, BTW in Ada a failure to provide a return value is detected at
run time and raises Program_Error. This is a clear case where a
warning is always desirable (basically this would be an error in
the language, except that to make it an error would require going
into the whole issue of defining possible threads of control, and
that's too much formal effort for too little gain at the level of
the language standard. So in GNAT, this is a warning that is on
by default. Like all warnings it can be suppressed, either by
suppressing all warnings (-gnatws) or by providing a Warnings
Off pragma that suppresses this particular warning.

Note that the ONE and only case where this warning is a false
positive is the ACATS test that makes sure you raise an
exception (in practice we suppress all warnings for ACATS
tests anyway, since they are deliberately full of dubious
coding practices!)

I wonder if there is a better forum for discussing whether
-Wall should be the default than this one. After all we always
emphasize that this list is for gcc developers, and this
particular issue is one better discussed by gcc users. Yes
I know there are gcc users on this list too (I am one!) but
still we don't exactly get representative user input on this
list!

Re: RFC: -Wall by default

[Robert Dewar]

On 4/5/2012 2:39 AM, Arnaud Charlet wrote:

Can someone summarize what the most useful warnings people are expecting
that -Wall would bring?

I suspect not all of -Wall would actually be welcome/a good idea by default,
and we might be looking for a better compromise where most warnings are
enabled by default, but not "all".

In particular, I'm not convinced that -Wuninitialized should be enabled
by default, precisely because this warning does generate a good bunch
of false positives.

So to me it's not black or white, and considering -Wall as a single entity
is not the right way to address these user complains IMO.


This seems a good direction for the discussion to me, the issue
in practice revolves around

a) false positives

b) warnings that are not false positives, but that are
incomprehensible to nonexpert users

A set of warnings that for the most part avoids these two
problems is precisely what can be reasonably on by default.

There is a third category

c) warnings about things that are not errors but seem like
sloppy or unnecessary code (e.g. unused variables).

Category c) is trickier.

Generally the philosophy in GNAT is to enable by default
all warnings that avoid a) b) or c) and correspond to
definite likely errors.


Arno

Re: RFC: -Wall by default

[Andrew Haley]

On 04/04/2012 07:02 PM, Gabriel Dos Reis wrote:
>> Oh, wow.  Really?  That's a big change.  Time to be brave, I guess,
>> > but I very much like the idea of a gcc that does just what it's told;
>> > making -Wall the default is a big break with tradition.
> Sometimes, we have to be brave to challenge tradition.  The world around
> us is moving and we definitely want GCC to remain competitive.  It is
> hard to define what "it's told" means without tripping over.

I'm finding it hard to understand why "-Wall by default" makes gcc more
competitive.

Andrew.

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-04 20:01:27 +0100, Andrew Haley wrote:
> On 04/04/2012 07:11 PM, Gabriel Dos Reis wrote:
> > Really?  Such as what?
> 
> Such as "I wrote a perfectly legal C program, and gcc spewed out
> a ton of messages."

What's a "legal C program"?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Andrew Haley]

On 04/05/2012 11:50 AM, Vincent Lefevre wrote:
> On 2012-04-04 20:01:27 +0100, Andrew Haley wrote:
>> On 04/04/2012 07:11 PM, Gabriel Dos Reis wrote:
>>> Really?  Such as what?
>>
>> Such as "I wrote a perfectly legal C program, and gcc spewed out
>> a ton of messages."
> 
> What's a "legal C program"?

It's generally used to mean one that is fully defined by the
specifications in effect, often some combination of POSIX and ISO C,
with perhaps some vendor extensions.  Why do you ask?

Andrew.

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 10:48:29 +0100, Pedro Alves wrote:
> On 04/05/2012 10:39 AM, Richard Guenther wrote:
> 
> ... [-Wall + -Werror] ...
> 
> > Btw, it would be more reasonable to enable a subset of warnings that
> > we enable at -Wall by default.  Notably those that if they were not
> > false positives, would lead to undefined behavior at runtime.  Specifically
> > I don't think we should warn about unused static functions or variables
> > by default.
> 
> Yes, I would agree more with something like that.

Ditto. I sometimes get such warnings just because of the use of the
preprocessor. However taking the preprocessor into account would
mean that some useful warnings (perhaps even with currently default
ones, but I'm not sure because I always use -Wall) could not be
included. The best solution is sometimes to modify the source. For
instance, I had to do the following change (not sure whether this
is the best way) in MPFR a few days ago:

Index: src/const_euler.c
===
--- src/const_euler.c   (revision 8123)
+++ src/const_euler.c   (revision 8124)
@@ -118,7 +118,7 @@
   int inex;
   MPFR_BLOCK_DECL (flags);
 
-  MPFR_BLOCK (flags, inex = mpfr_get_z (P, n, MPFR_RNDN));
+  MPFR_BLOCK (flags, MPFR_DBGRES (inex = mpfr_get_z (P, n, MPFR_RNDN)));
   MPFR_ASSERTD (inex == 0 && ! MPFR_ERANGEFLAG (flags));
   if (a > 1)
 mpz_mul_si (P, P, 1 - (long) a);
Index: src/mpfr-impl.h
===
--- src/mpfr-impl.h (revision 8123)
+++ src/mpfr-impl.h (revision 8124)
@@ -388,12 +388,18 @@
 #define MPFR_ASSERTN(expr)  \
((void) ((MPFR_UNLIKELY(expr)) || MPFR_UNLIKELY( (ASSERT_FAIL(expr),0) )))
 
-/* MPFR_ASSERTD(expr): assertions that should be checked when testing */
+/* MPFR_ASSERTD(expr): assertions that should be checked when testing.
+   MPFR_DBGRES(assignment): to be used when the result is tested only
+ in an MPFR_ASSERTD expression (in order to avoid a warning, e.g.
+ with GCC's -Wunused-but-set-variable, in non-debug mode).
+ */
 #ifdef WANT_ASSERT
 # define MPFR_EXP_CHECK 1
 # define MPFR_ASSERTD(expr)  MPFR_ASSERTN (expr)
+# define MPFR_DBGRES(A)  (A)
 #else
 # define MPFR_ASSERTD(expr)  ((void) 0)
+# define MPFR_DBGRES(A)  ((void) (A))
 #endif
 
 /* Code to deal with impossible

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 11:55:45 +0100, Andrew Haley wrote:
> On 04/05/2012 11:50 AM, Vincent Lefevre wrote:
> > On 2012-04-04 20:01:27 +0100, Andrew Haley wrote:
> >> On 04/04/2012 07:11 PM, Gabriel Dos Reis wrote:
> >>> Really?  Such as what?
> >>
> >> Such as "I wrote a perfectly legal C program, and gcc spewed out
> >> a ton of messages."
> > 
> > What's a "legal C program"?
> 
> It's generally used to mean one that is fully defined by the
> specifications in effect, often some combination of POSIX and ISO C,
> with perhaps some vendor extensions.  Why do you ask?

Because: What if the specifications in effect say (as some vendor
extension) that some construct will generate some warning?

Note that warnings in general are not forbidden by ISO C, so that
there is nothing wrong as far as ISO C is concerned.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Eric Botcazou]

> From developer perspective, we think that -Wall is so simple to
> remember, because
> in fact, we are used to handle so many complex things that this one five
> letter is nothing.  However, users aren't as sophisticated as we would like
> them to (I am not being condescending.)  The way we have to approach this
> is how can we satisfy persistent demands and still remain competitive.

I personally don't buy the "can't remember" argument.  When you use GCC, you 
just have to remember -g, -O, -W and that's pretty much it.

-- 
Eric Botcazou

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 04/04/2012 03:17 PM, Joseph S. Myers wrote:
> On Sat, 31 Mar 2012, Stefano Lattarini wrote:
> 
>> Note there's nothing I'm planning to do, nor I should do, in this regard:
>> the two setups described above are both already supported by the current
>> automake implementation (but the last one is not encouraged, even though
>> it makes perfect sense in some *rare* situations).  I was just pointing
>> out that you have to choose one of these setups -- so, if you want to
>> distribute info files, you must accept to have them build in the srcdir.
> 
> The approach used in GCC, for example in the libquadmath directory, is a 
> --enable-generated-files-in-srcdir configure option that is used when 
> building a release tarball - so normally the files go in the build 
> directory, but a special configuration is used to put them in the source 
> directory only when building releases.  (This does not involve the 
> "cygnus" option.)  I think support for that seems more generically useful 
> (and it makes sense to me for automake to look at features used in other 
> packages' configure/build systems, that aren't inherently specific to 
> those packages, and try to provide generic versions of them).
>
I agree, but for the moment being I'm just interested in ensuring the
removal of the 'cygnus' option won't impact too negatively on its last
relevant users (GCC, GDB, Binutils, and the bfd library).  So far it
appears this is the case luckily, so I'll go ahead with the deprecation
of 'cygnus' in Automake 1.12.1 and its removal in Automake 1.13.

Regards,
  Stefano

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 06:26:43 -0400, Robert Dewar wrote:
> Well a lot of users have been burned by using optimization
> options, either becausae of compiler bugs, or because of bugs
> in their own code triggered by optimization. So the requirement
> of not using any optimization options is not that uncommon.

But no-optimizations (-O0) should not necessarily be the default
for these reasons.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 06:42:02 -0400, Robert Dewar wrote:
> c) warnings about things that are not errors but seem like
> sloppy or unnecessary code (e.g. unused variables).

This is sometimes an error, e.g. a variable name is used in the code
instead another one (but of course, such warnings won't be able to
detect all similar errors).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Robert Dewar]

On 4/5/2012 8:06 AM, Vincent Lefevre wrote:

On 2012-04-05 06:26:43 -0400, Robert Dewar wrote:

Well a lot of users have been burned by using optimization
options, either becausae of compiler bugs, or because of bugs
in their own code triggered by optimization. So the requirement
of not using any optimization options is not that uncommon.


But no-optimizations (-O0) should not necessarily be the default
for these reasons.


I think it is a problem that even at -O1 the debugger is
seriously limited, especially for an inexperienced user.

What is missing to me is a reasonable cleanup of the code that
would remove some of the junk at -O0 but not impact debugging.
In fact a reasonable criterion would be all the optimization
that is cheap to do and does not affect debugging.

Then I would make THAT the default (or simply redefine -O0
to be this level, I see no real advantage in -O0 as it is now)

Re: RFC: -Wall by default

[Michael Veksler]

On 04/05/2012 02:45 PM, Eric Botcazou wrote:
I personally don't buy the "can't remember" argument. When you use 
GCC, you just have to remember -g, -O, -W and that's pretty much it. 



It is not that they can't remember. I am a TA at a moderately basic 
programming course,
and student submit home assignments with horrible errors. These errors, 
such as
free(*str) or *str=malloc(n)  are easily be caught by -Wall. I have to 
remember to
advise them to use -Wall and to fix all the warnings, which I sometimes 
forget to do.


Many of the students don't know of -Wall because they don't read the gcc 
manual,

either because they are overwhelmed with assignments and exams, or because
they are intimidated by big manuals written in technical English. Either 
way, many

won't use -Wall unless they are told to.

My conclusion: it would be much better for beginners to have more 
warnings turned on.



As for specific warnings, I hate that the the code (a&&b || c&&d), which 
did not cause a
warning on older gcc version now gives a warning. I would not want it on 
by default since
it forces users to write too many parentheses in ((a&&b)||(c&&d)) which 
makes the expression
less readable. What next? Warn about (a*b+c*d) ? I would hate to write 
((a*b)+(c*d)).


Sure, the precedence of: << vs. +; & vs. == ; & vs. && ; is less clear 
and deserves a warning,
but: & vs. | ; && vs. || ; are at least as common as * vs. + that 
programmers ought to know

them.


Michael

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 08:17:57 -0400, Robert Dewar wrote:
> On 4/5/2012 8:06 AM, Vincent Lefevre wrote:
> >But no-optimizations (-O0) should not necessarily be the default
> >for these reasons.
> 
> I think it is a problem that even at -O1 the debugger is
> seriously limited, especially for an inexperienced user.

OK.

Now, AFAIK, compiling and running programs occurs much more often
than debugging them. So, I would say that -O1 should be the default.
The user can still recompile his program with -O0 (or future better
option) if he needs to run the debugger on it; if he doesn't know
that, there should be some feature in the debugger to tell the user
what to do.

> What is missing to me is a reasonable cleanup of the code that
> would remove some of the junk at -O0 but not impact debugging.
> In fact a reasonable criterion would be all the optimization
> that is cheap to do and does not affect debugging.

I think that for debugging, there should be a single option to
disable optimizations that are unsafe for the debugger and that
would add debugging information (such as what -g does). In short,
the user would just have to add this option, which should do all
the magic for debugging.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Robert Dewar]

On 4/5/2012 8:28 AM, Michael Veksler wrote:


It is not that they can't remember. I am a TA at a moderately basic
programming course,
and student submit home assignments with horrible errors. These errors,
such as
free(*str) or *str=malloc(n)  are easily be caught by -Wall. I have to
remember to
advise them to use -Wall and to fix all the warnings, which I sometimes
forget to do.


Wouldn't it be better in a "moderately basic programming course" to
provide standard canned scripts that set things up nicely for students
including the switches they need? Indeed for such a course wouldn't it
be better to use an appropriate IDE, so they could concentrate on the
task at hand and not fiddling with commands. Yes, I think it is very
important for students to learn what is going on, but you can't do
everything at once in a basic course.

And even in the context you give, surely it is not too much to expect
a TA to remember important advice like this?

Re: Switching to C++ by default in 4.8

[Pedro Lamarão]

On 04/04/2012 08:20 AM, Diego Novillo wrote:

On 4/4/12 5:06 AM, Richard Guenther wrote:


Btw, I think we should only start forcing C++ when 1) there is a
branch/patch out
that shows benefit from using C++. I previously mentioned that I'd
like to see
2) a patch that _properly_ wraps a C++ class for consumption by our
garbage
collector (thus, not a hack that works for a specific case but
infrastructure
that we think will work for _all_ cases, including libstdc++ container
use).


My idea was to start with something like converting VEC() which would
require dealing with GC.


Is anyone currently working or this?

I'm not experienced in the code base, but this project seems fascinating.

--
 P.

Re: RFC: -Wall by default

[Andrey Belevantsev]

On 05.04.2012 16:33, Robert Dewar wrote:

On 4/5/2012 8:28 AM, Michael Veksler wrote:


It is not that they can't remember. I am a TA at a moderately basic
programming course,
and student submit home assignments with horrible errors. These errors,
such as
free(*str) or *str=malloc(n) are easily be caught by -Wall. I have to
remember to
advise them to use -Wall and to fix all the warnings, which I sometimes
forget to do.


Wouldn't it be better in a "moderately basic programming course" to
provide standard canned scripts that set things up nicely for students
including the switches they need? Indeed for such a course wouldn't it
be better to use an appropriate IDE, so they could concentrate on the
task at hand and not fiddling with commands. Yes, I think it is very
important for students to learn what is going on, but you can't do
everything at once in a basic course.

And even in the context you give, surely it is not too much to expect
a TA to remember important advice like this?


FWIW, in our "basic programming" course students have to hand their 
homework to an automated testing system which forces the compiler options 
we think useful, including all the relevant warning switches and -Werror. 
Of course, there is a web page explaining the meaning of the switches and 
TAs help with emphasizing their importance to students.  And indeed, you 
can't do everything in an 101 course, thus not much of this (helpful) 
information remains in their heads.  But it's better than nothing.


Andrey

Re: RFC: -Wall by default

[Richard Guenther]

On Thu, Apr 5, 2012 at 2:17 PM, Robert Dewar  wrote:
> On 4/5/2012 8:06 AM, Vincent Lefevre wrote:
>>
>> On 2012-04-05 06:26:43 -0400, Robert Dewar wrote:
>>>
>>> Well a lot of users have been burned by using optimization
>>> options, either becausae of compiler bugs, or because of bugs
>>> in their own code triggered by optimization. So the requirement
>>> of not using any optimization options is not that uncommon.
>>
>>
>> But no-optimizations (-O0) should not necessarily be the default
>> for these reasons.
>
>
> I think it is a problem that even at -O1 the debugger is
> seriously limited, especially for an inexperienced user.
>
> What is missing to me is a reasonable cleanup of the code that
> would remove some of the junk at -O0 but not impact debugging.
> In fact a reasonable criterion would be all the optimization
> that is cheap to do and does not affect debugging.
>
> Then I would make THAT the default (or simply redefine -O0
> to be this level, I see no real advantage in -O0 as it is now)

Fact is that -O1 pretty much enables random stuff without any
specific priorities (apart from making compile-time not too big).
It is definitely not "optimize but keep the program debuggable":

--
@opindex O1
Optimize.  Optimizing compilation takes somewhat more time, and a lot
more memory for a large function.

With @option{-O}, the compiler tries to reduce code size and execution
time, without performing any optimizations that take a great deal of
compilation time.
--

It's on my large TODO list, somewhere at the bottom, to propose
to make -O1 stop after early optimizations and drop right to
expansion from there.  That would turn optimization expectations
upside-down of course, but early optimizations should be mostly
reducing code size (and thus increase compile speed) with
no fancy optimization that inhibit debugging (SRA, IPA-SRA,
switch conversion and function splitting are an exception,
but all but SRA are not enabled at -O1).  So we'd move to
compile-time and debuggability for -O1 (I'd expect compile time
that should be better or at least not a lot slower than -O0).

Richard.

Re: RFC: -Wall by default

[Robert Dewar]

It's on my large TODO list, somewhere at the bottom, to propose
to make -O1 stop after early optimizations and drop right to
expansion from there.  That would turn optimization expectations
upside-down of course, but early optimizations should be mostly
reducing code size (and thus increase compile speed) with
no fancy optimization that inhibit debugging (SRA, IPA-SRA,
switch conversion and function splitting are an exception,
but all but SRA are not enabled at -O1).  So we'd move to
compile-time and debuggability for -O1 (I'd expect compile time
that should be better or at least not a lot slower than -O0).


I am all in favor of such work, but I would approach it in two
steps. First make it a separate -O level, then depending on
how successful this is in practice, propose making -O1 mean
this new level.

If you do both steps at once, you get opposition on the basis
of change-is-bad, rather than to the substance of the new
level of optimization.


Richard.

Re: RFC: -Wall by default

[Michael Veksler]

On 04/05/2012 03:33 PM, Robert Dewar wrote:


Wouldn't it be better in a "moderately basic programming course" to
provide standard canned scripts that set things up nicely for students
including the switches they need? Indeed for such a course wouldn't it
be better to use an appropriate IDE, so they could concentrate on the
task at hand and not fiddling with commands. Yes, I think it is very
important for students to learn what is going on, but you can't do
everything at once in a basic course.

And even in the context you give, surely it is not too much to expect
a TA to remember important advice like this?


They use an IDE, which is either Code-Blocks or Dev-C++, which run on
Windows, but these IDEs don't turn -Wall on by default. As for the advice
 to use -Wall, there is so much to advise  and so little time, and the 
sheer

mass of information confuses students. I'd have GCC emit more warnings
by default rather than explain what -Wall is  (and have half of them forget
that by the time they get to the computer).

After seeing the disaster of their first home assignment, students would
be more attentive to the advise regarding -Wall. It is much more effective
to wait for the submission of the first assignment and explain -Wall
afterwards. On the other hand, it had been far more effective had GCC
turned it on by default!

In my code I use -Wextra and find it very helpful, but I would not recommend
it to others since it requires to have a very strict coding style. I 
find it very

effective that it warns when a symbol in an inner context overshadows a
symbol in an outer context, or warns on unused parameters,  On the other
hand, it gets annoying at times. Nevertheless, it caught enough bugs to make
it worth the trouble.

Michael

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Thu, Apr 5, 2012 at 2:41 PM, Pedro Lamarão  wrote:
> On 04/04/2012 08:20 AM, Diego Novillo wrote:
>>
>> On 4/4/12 5:06 AM, Richard Guenther wrote:
>>
>>> Btw, I think we should only start forcing C++ when 1) there is a
>>> branch/patch out
>>> that shows benefit from using C++. I previously mentioned that I'd
>>> like to see
>>> 2) a patch that _properly_ wraps a C++ class for consumption by our
>>> garbage
>>> collector (thus, not a hack that works for a specific case but
>>> infrastructure
>>> that we think will work for _all_ cases, including libstdc++ container
>>> use).
>>
>>
>> My idea was to start with something like converting VEC() which would
>> require dealing with GC.
>
>
> Is anyone currently working or this?
>
> I'm not experienced in the code base, but this project seems fascinating.

I'm not aware of anyone - so go ahead (if you happen to have a copyright
assignment on file).  Try to avoid to have to adjust vec.h users at start,
thus keep the macro wrappings (to the extent this is possible, of course).
The GC part is most interesting, the vec.h part should be quite obvious.

Richard.

> --
>  P.
>
>

Re: RFC: -Wall by default

[Basile Starynkevitch]

On Thu, Apr 05, 2012 at 03:28:54PM +0300, Michael Veksler wrote:
> On 04/05/2012 02:45 PM, Eric Botcazou wrote:
> >I personally don't buy the "can't remember" argument. When you use
> >GCC, you just have to remember -g, -O, -W and that's pretty much
> >it.

> Many of the students don't know of -Wall because they don't read the
> gcc manual,
> either because they are overwhelmed with assignments and exams, or because
> they are intimidated by big manuals written in technical English.
> Either way, many
> won't use -Wall unless they are told to.
> 
> My conclusion: it would be much better for beginners to have more
> warnings turned on.
> 

A possible solution might be to permit our spec file to turn on -Wall by 
default (it is probably possible today, or easily patchable) and more 
importantly to document how to customize the spec file to make -Wall by default.

But I do agree that newbies need -Wall even more than others, but don't know 
about it.

Cheers

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: RFC: -Wall by default

[Erik Trulsson]

On Thu, Apr 05, 2012 at 02:30:10PM +0200, Vincent Lefevre wrote:
> On 2012-04-05 08:17:57 -0400, Robert Dewar wrote:
> > On 4/5/2012 8:06 AM, Vincent Lefevre wrote:
> > >But no-optimizations (-O0) should not necessarily be the default
> > >for these reasons.
> > 
> > I think it is a problem that even at -O1 the debugger is
> > seriously limited, especially for an inexperienced user.
> 
> OK.
> 
> Now, AFAIK, compiling and running programs occurs much more often
> than debugging them. So, I would say that -O1 should be the default.
> The user can still recompile his program with -O0 (or future better
> option) if he needs to run the debugger on it; if he doesn't know
> that, there should be some feature in the debugger to tell the user
> what to do.

Better would be to improve the output from -O1 so it is usable by a
debugger, even if this might require generating slightly less optimized
code at -O1 than is done now.

> 
> > What is missing to me is a reasonable cleanup of the code that
> > would remove some of the junk at -O0 but not impact debugging.
> > In fact a reasonable criterion would be all the optimization
> > that is cheap to do and does not affect debugging.
> 
> I think that for debugging, there should be a single option to
> disable optimizations that are unsafe for the debugger and that
> would add debugging information (such as what -g does). In short,
> the user would just have to add this option, which should do all
> the magic for debugging.

No, absolutely not. Turning on debugging should not change what the
generated code looks like.  Depending on the bug it is quite possible
for changes in optimization to hide the symptoms of the bug, thereby
making it more difficult to track down the bug.


-- 

Erik Trulsson
ertr1...@student.uu.se

Re: RFC: -Wall by default

[Richard Guenther]

On Thu, Apr 5, 2012 at 2:49 PM, Robert Dewar  wrote:
>
>> It's on my large TODO list, somewhere at the bottom, to propose
>> to make -O1 stop after early optimizations and drop right to
>> expansion from there.  That would turn optimization expectations
>> upside-down of course, but early optimizations should be mostly
>> reducing code size (and thus increase compile speed) with
>> no fancy optimization that inhibit debugging (SRA, IPA-SRA,
>> switch conversion and function splitting are an exception,
>> but all but SRA are not enabled at -O1).  So we'd move to
>> compile-time and debuggability for -O1 (I'd expect compile time
>> that should be better or at least not a lot slower than -O0).
>
>
> I am all in favor of such work, but I would approach it in two
> steps. First make it a separate -O level, then depending on
> how successful this is in practice, propose making -O1 mean
> this new level.
>
> If you do both steps at once, you get opposition on the basis
> of change-is-bad, rather than to the substance of the new
> level of optimization.

Ok, that were my thoughts as well.  It was suggested to add -Og
in the past, which, at some point could become the default
for a plain 'gcc' invocation.  It happens that people care for -O0
and that -O2 is tuned quite well - -O1 did not see any adjustments
in the last 10 years I think (well, not based on any benchmarking at least).

Not sure if inflation of -O variants will be well-received though ;)  Re-using
-O looked appealing to me ...

Richard.

>>
>>
>> Richard.
>
>

Re: RFC: -Wall by default

[Michael Veksler]

On 04/05/2012 03:43 PM, Andrey Belevantsev wrote:
FWIW, in our "basic programming" course students have to hand their 
homework to an automated testing system which forces the compiler 
options we think useful, including all the relevant warning switches 
and -Werror. Of course, there is a web page explaining the meaning of 
the switches and TAs help with emphasizing their importance to 
students.  And indeed, you can't do everything in an 101 course, thus 
not much of this (helpful) information remains in their heads.  But 
it's better than nothing.


We don't have such an automated testing system at our faculty (IE). I 
had to write my own
automated testing which took me too much time to complete. Sometimes I 
excel at the NIH

syndrome, well at least I learned python on the way.

Anyway this is not quite a 101 course, since it also introduces low 
level stuff like 2's complement,
FP representation, caches, assembly, profiling, concurrency, address 
translation, and more. As
I said, too much in a short time. Remembering a specific GCC flag will 
be lost in the noise for too
many students, especially if they think that they will never work again 
with GCC after the course.
Which is probably correct for quite a few of them as this is Industrial 
Engineering & Management,

not CS or EE.

Michael

Re: RFC: -Wall by default

[Robert Dewar]

On 4/5/2012 8:59 AM, Michael Veksler wrote:


They use an IDE, which is either Code-Blocks or Dev-C++, which run on
Windows, but these IDEs don't turn -Wall on by default. As for the advice
   to use -Wall, there is so much to advise  and so little time, and the
sheer
mass of information confuses students. I'd have GCC emit more warnings
by default rather than explain what -Wall is  (and have half of them forget
that by the time they get to the computer).


I would focus on the IDE here, it is an obvious defect for an IDE not
to be able to control the default switches IMO.

Re: i370 port

[Paul Edwards]

Hi Ulrich.

I'm getting back to this after a long hiatus.

I have reviewed the 'W' code in PRINT_OPERAND:

else if (CODE == 'W')
 {
   /* hand-built sign-extension of signed 32-bit to 64-bit */
   mvs_page_lit += 8;
   if (0 <=  INTVAL (XV)) {
  fprintf (FILE, "=XL8'");
   } else {
  fprintf (FILE, "=XL8'");
   }
   fprintf (FILE, "%08X'", INTVAL (XV));
 }

and it looks to me like it is already correct. If movdi is given a
const_int as a parameter, then sign-extending to 64-bit is
exactly what needs to happen, isn't it?

I'm only expecting to compile programs as 32-bit, so I'm not
expecting more than 32-bit integers. The IFOX assembler
won't do more than that. In case that's the issue.

But regardless I don't know how to make this code:

mvs_check_page (0, 6, 8);
return \"MVC^I%O0(8,%R0),%1\";

make use of that 'W' operand.

Do I change that %1 to %W1 perhaps?

I'll give that a try tomorrow.

Thanks.  Paul.





-Original Message- 
From: Ulrich Weigand 
Sent: Monday, August 22, 2011 10:22 PM 
To: Paul Edwards 
Cc: gcc@gcc.gnu.org 
Subject: Re: i370 port 


Paul Edwards wrote:


  if (operands[1] == const0_rtx)
  {
CC_STATUS_INIT;
mvs_check_page (0, 6, 8);
return \"MVC%O0(8,%R0),=XL8'00'\";
  }
  mvs_check_page (0, 6, 8);
  return \"MVC%O0(8,%R0),%1\";
}"
   [(set_attr "length" "8")]
)

forces it to use XL8'00' instead of the default F'0' and that
seems to work.  Does that seem like a proper solution to
you?


Well, there isn't really anything special about const0_rtx.
*Any* CONST_INT that shows up as second operand to the movdi
pattern must be emitted into an 8 byte literal at this point.

You can do that inline; but the more usual way would be to
define an operand print format that encodes the fact that
a 64-bit operand is requested.

In fact, looking at the i370.h PRINT_OPERAND, there already
seems to be such a format: 'W'.  (Maybe not quite; since 'W'
sign-extends a 32-bit operand to 64-bit.  But since 'W'
doesn't seem to be used anyway, maybe this can be changed.)

Bye,
Ulrich

--
 Dr. Ulrich Weigand
 GNU Toolchain for Linux on System z and Cell BE
 ulrich.weig...@de.ibm.com

Re: RFC: -Wall by default

[Jonathan Wakely]

On 5 April 2012 11:03, Gabriel Dos Reis wrote:
>>
>> Note that some of the above depend on optimization flag settings
>> (and optimization happening).  Those are not good candidates - I think
>> good candidates are those that would still be fully operational with
>> -fsyntax-only.
>
> I am not sure -fsyntax-only is a good criteria.
> -fsyntax-only limits the amount of work that the compiler does in terms
> of code generation, but it should be orthogonal to diagnostic issues.

I don't think this is what you meant, but FWIW -fsyntax-only prevents
(at least some) template instantiation for C++, which means lots of
diagnostics are suppressed when using it.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 8:58 AM, Jonathan Wakely  wrote:
> On 5 April 2012 11:03, Gabriel Dos Reis wrote:
>>>
>>> Note that some of the above depend on optimization flag settings
>>> (and optimization happening).  Those are not good candidates - I think
>>> good candidates are those that would still be fully operational with
>>> -fsyntax-only.
>>
>> I am not sure -fsyntax-only is a good criteria.
>> -fsyntax-only limits the amount of work that the compiler does in terms
>> of code generation, but it should be orthogonal to diagnostic issues.
>
> I don't think this is what you meant, but FWIW -fsyntax-only prevents
> (at least some) template instantiation for C++, which means lots of
> diagnostics are suppressed when using it.

Yes, thanks!

-- Gaby

Re: RFC: -Wall by default

[Jonathan Wakely]

On 5 April 2012 11:16, Arnaud Charlet wrote:
>
> OK, the above list looks reasonable to me at least as a starting point
> that could be a bit refined (not sure -Wstrict-aliasing is so useful by
> default for instance for legacy code),

-Wstrict-aliasing is only active when -fstrict-aliasing is on, and if
that's on the warning definitely should be, since it indicates code
that may well misbehave, "legacy" or not.

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 15:09:32 +0200, Erik Trulsson wrote:
> Better would be to improve the output from -O1 so it is usable by a
> debugger, even if this might require generating slightly less optimized
> code at -O1 than is done now.

This contradicts what you say below.

> > > What is missing to me is a reasonable cleanup of the code that
> > > would remove some of the junk at -O0 but not impact debugging.
> > > In fact a reasonable criterion would be all the optimization
> > > that is cheap to do and does not affect debugging.
> > 
> > I think that for debugging, there should be a single option to
> > disable optimizations that are unsafe for the debugger and that
> > would add debugging information (such as what -g does). In short,
> > the user would just have to add this option, which should do all
> > the magic for debugging.
> 
> No, absolutely not. Turning on debugging should not change what the
> generated code looks like.

For instance, the effect of a bug appears only with -O3.
Then you have 2 possibilities:
1. The debugger can cope with such optimization levels. So, -O1
   doesn't need to be modified.
2. The debugger cannot cope with such optimization levels, and you
   are forced anyway to change what the generated code looks like
   in order to try to debug it (or improve the debugger to be in
   case 1, if possible).

> Depending on the bug it is quite possible for changes in
> optimization to hide the symptoms of the bug, thereby making it more
> difficult to track down the bug.

I agree, but this is not by removing some default optimizations
that you would solve the problems due to a bug that appears when
the user chooses to use a higher optimization level.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 5:29 AM, Arnaud Charlet  wrote:
>> Well, if you write code so obvious that -Wuninitialized is annoying then:
>
> No, the code is certainly not obvious, and improving -Wuninitialized although
> a nice goal is likely to require lots of effort, likely at the expense of
> removing some useful warnings.
>
>> either the implementation of -Wuninitialized should be improved, or as you
>
> You can't have it both ways: either -Wuninitialized is indeed improved to the
> point where it generates almost no false positives, and then enabling it
> by default should be considered/done; or -Wuninitialized does generate
> false positives and enabling it by default is likely not a good idea.

*I* do not think that the false positives of -Wuninitialized are so frequent
that it can't or should not be enabled by default; you are making that argument.
And I am saying *if* you what you say is true, then... Note the conditional.


>
> Same for -Wmaybe-uninitialized, also part of -Wall.
>
>> are so expert that you can add -Wno-uninitialized.  I think the argument
>> cuts both ways.
>
> Who said anything about being "so expert"? IMO that's precisely non
> experts who will get the most annoyed here, because they may not understand
> why the warning is generated, nor how to disable it.

If it is the non-expert that would be caught in code so non-obvious that
-Wuninitialized would trip into false positives, then it is highly likely
that the code might in fact contain an error.

> And IMO, a discussion about a "default" is certainly NOT about experts,

Full agreed.

> it's precisely a discussion about what would be the best default for most
> people (and most people are not experts).

agreed.  I don't see why we are arguing :-)

-- Gaby

Re: Switching to C++ by default in 4.8

[Diego Novillo]

On Thu, Apr 5, 2012 at 09:04, Richard Guenther
 wrote:
> On Thu, Apr 5, 2012 at 2:41 PM, Pedro Lamarão  wrote:
>>
>> Is anyone currently working or this?
>>
>> I'm not experienced in the code base, but this project seems fascinating.
>
> I'm not aware of anyone - so go ahead (if you happen to have a copyright
> assignment on file).


I will be, after the switch to C++ is done.  Pedro, if you do have a
copyright assignment, feel free to start working on this.  I suggest
creating a branch for this (I can handle that today).  If you need
forms for the copyright assignment, let me know and I'll forward them
to you.


Diego.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 5:50 AM, Andrew Haley  wrote:
> On 04/04/2012 07:02 PM, Gabriel Dos Reis wrote:
>>> Oh, wow.  Really?  That's a big change.  Time to be brave, I guess,
>>> > but I very much like the idea of a gcc that does just what it's told;
>>> > making -Wall the default is a big break with tradition.
>> Sometimes, we have to be brave to challenge tradition.  The world around
>> us is moving and we definitely want GCC to remain competitive.  It is
>> hard to define what "it's told" means without tripping over.
>
> I'm finding it hard to understand why "-Wall by default" makes gcc more
> competitive.

the competitors are enabling these kinds of warnings by default.  Furthermore,
telling users that they just have to turn these simple switches -- when we are
busy adding more at every release -- isn't convincing.

Re: Switching to C++ by default in 4.8

[Richard Guenther]

On Thu, Apr 5, 2012 at 4:21 PM, Diego Novillo  wrote:
> On Thu, Apr 5, 2012 at 09:04, Richard Guenther
>  wrote:
>> On Thu, Apr 5, 2012 at 2:41 PM, Pedro Lamarão  
>> wrote:
>>>
>>> Is anyone currently working or this?
>>>
>>> I'm not experienced in the code base, but this project seems fascinating.
>>
>> I'm not aware of anyone - so go ahead (if you happen to have a copyright
>> assignment on file).
>
>
> I will be, after the switch to C++ is done.

Which means never, because I think it's a prerequesite for switching?

;)

Richard.

> Pedro, if you do have a
> copyright assignment, feel free to start working on this.  I suggest
> creating a branch for this (I can handle that today).  If you need
> forms for the copyright assignment, let me know and I'll forward them
> to you.
>
>
> Diego.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 6:45 AM, Eric Botcazou  wrote:
>> From developer perspective, we think that -Wall is so simple to
>> remember, because
>> in fact, we are used to handle so many complex things that this one five
>> letter is nothing.  However, users aren't as sophisticated as we would like
>> them to (I am not being condescending.)  The way we have to approach this
>> is how can we satisfy persistent demands and still remain competitive.
>
> I personally don't buy the "can't remember" argument.

At least, on three occasions this week, it was made to me in person by competent
people (the last was "I forgot what actually is doing").  These people
use several tools
for programming, including several compilers.

Re: RFC: -Wall by default

[Gabriel Dos Reis]

this is drifting, but since we talking about teaching (which is part of my
daytime job)

On Thu, Apr 5, 2012 at 7:33 AM, Robert Dewar  wrote:

> Wouldn't it be better in a "moderately basic programming course" to
> provide standard canned scripts that set things up nicely for students
> including the switches they need?

you are assuming that all students have the same programming environement
or that we can force them, or that the environment they are programming in
can run "standard canned scripts that set things up".  The reality is that far
from these ideal situations.

> Indeed for such a course wouldn't it
> be better to use an appropriate IDE, so they could concentrate on the
> task at hand and not fiddling with commands. Yes, I think it is very
> important for students to learn what is going on, but you can't do
> everything at once in a basic course.

Where I teach I cannot MANDATE a particular IDE and have my course approved
by the faculty senate.


>
> And even in the context you give, surely it is not too much to expect
> a TA to remember important advice like this?

Re: Switching to C++ by default in 4.8

[Diego Novillo]

On Thu, Apr 5, 2012 at 10:24, Richard Guenther
 wrote:

> Which means never, because I think it's a prerequesite for switching?

No.  I was not clear.  By "done", I meant that GCC builds with C++ in
all the platforms we can test.

I'm sending a testing plan later today with the list of targets I
think should be tested.  I am expecting to do some adjusting patches
to get all the targets working.

Whether the vec.h conversion is committed simultaneously with the C++
switch is a minor issue.  The cleanup patches for C++ will certainly
need to be committed first.


Diego.

Re: Switching to C++ by default in 4.8

[Lawrence Crowl]

On 4/5/12, Richard Guenther  wrote:
> On Apr 4, 2012 Lawrence Crowl  wrote:
> > On 4/4/12, Richard Guenther  wrote:
> > > Making tree or gimple a C++ class with inheritance and
> > > whatever is indeed a huge waste of time and existing developer
> > > ressources (that, if only because they have to adapt and
> > > maintain two completely different code-bases over some time).
> >
> > Trees are presently a significant problem in that many static
> > errors become dynamic errors, which entails more debugging.
>
> How do you expect tree errors to become static?  By using derived
> types everywhere?  Note that this would only be possible in a
> _very_ limited sub-set of places.

Yes, a class hierarchy that directly represents the type hierarchy
already implicit in trees.  With that structure in place, functions
that require a certain kind of tree as a parameter can say so
directly in the parameter list.  Functions that return a certain
kind of tree can say so in the return type.  Calling a function
that is inappropriate to the type will result in a static error.

Certainly there are cases where the type must be made more specific,
and getting the wrong type here would necessarily be a dynamic check.
However, the number of dynamic checks can be substantially reduced.
To provide a specific example, suppose I have a common_decl *p and
need to do extra work if it is a var_decl.

do_general_work (p);
if (var_decl *q = p->to_var ())
{
  do_var_work_1 (q);
  do_var_work_2 (q);
  do_var_work_3 (q);
  do_var_work_4 (q);
}

The only dynamic work is in the pointer conversion.  All other
function calls can be statically typed.

> > > I expect the GCC core to maintain written in C, compiled
> > > by C++.
> >
> > Converting VECs to C++ vectors vector would provide significant
> > code clarity benefits.  The files in which that is done would
> > necessarily be C++ only.
>
> I already had VECs as the very first and best example why C++
> might be good.

But my point was that if we're using a C++ vector, the files are
not written in C any more.

> > > > I also find debugging C++ in gdb somewhat more annoying
> > > > than debugging plain C, and at the moment I always go back
> > > > to a stage1 compiler.
> > >
> > > Indeed - I'd be worried if my debugging efficiency decreases
> > > by more than 5%.
> >
> > If the number of debugging sessions was reduced by the same
> > amount, the result would be a net wash.
>
> I have no expectation that the number of debug sessions will
> be reduced.

On the other hand, I do.  There are many instances were I've debugged
a problem to realize that it could have been a static type error.

-- 
Lawrence Crowl

Re: Switching to C++ by default in 4.8

[David Edelsohn]

On Thu, Apr 5, 2012 at 10:36 AM, Diego Novillo  wrote:
> On Thu, Apr 5, 2012 at 10:24, Richard Guenther
>  wrote:
>
>> Which means never, because I think it's a prerequesite for switching?
>
> No.  I was not clear.  By "done", I meant that GCC builds with C++ in
> all the platforms we can test.
>
> I'm sending a testing plan later today with the list of targets I
> think should be tested.  I am expecting to do some adjusting patches
> to get all the targets working.

I tried bootstrapping on AIX using C++.

I am able to bootstrap using G++, but not with IBM xlC.  xlC is able
to compile the GCC source code (with a lot of warning messages), but
the build fails when the build passes GCC-specific no exception flags
to xlC.

NOEXCEPTION_FLAGS = -fno-exceptions -fno-rtti

xlc -c -fno-exceptions -fno-rtti conftest.c

does succeed, but

xlc -fno-exceptions -fno-rtti conftest.c

fails.  I don't think -fno-rtti -fno-exceptions does what GCC expects.

Also, I noticed that although GCC is configured with
--enable-build-with-cxx , the configure tests use $CC, which might not
be accurate.

- David

Re: RFC: -Wall by default

[Russ Allbery]

Gabriel Dos Reis  writes:

> If it is the non-expert that would be caught in code so non-obvious that
> -Wuninitialized would trip into false positives, then it is highly
> likely that the code might in fact contain an error.

I wish this were the case, but alas I continue to see fairly trivial false
positives from -Wuninitialized.  Usually cases where the initialization
and the use are both protected by equivalent conditionals at different
places in the function.

Personally, as a matter of *style*, I eliminate such cases either by
initializing the variable or restructuring the function.  But this is very
much a question of style, not of correctness.

-- 
Russ Allbery (r...@stanford.edu) 

Re: RFC: -Wall by default

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 3:24 PM, Russ Allbery  wrote:
> Gabriel Dos Reis  writes:
>
>> If it is the non-expert that would be caught in code so non-obvious that
>> -Wuninitialized would trip into false positives, then it is highly
>> likely that the code might in fact contain an error.
>
> I wish this were the case, but alas I continue to see fairly trivial false
> positives from -Wuninitialized.  Usually cases where the initialization
> and the use are both protected by equivalent conditionals at different
> places in the function.
>
> Personally, as a matter of *style*, I eliminate such cases either by
> initializing the variable or restructuring the function.  But this is very
> much a question of style, not of correctness.

-Wuninitialized wasn't on the list I sent Arnaud.

(We were just arguing with different point of view on something
we appeared to agree on.)

-- Gaby

Re: Switching to C++ by default in 4.8

[Gabriel Dos Reis]

On Thu, Apr 5, 2012 at 3:16 PM, David Edelsohn  wrote:
> On Thu, Apr 5, 2012 at 10:36 AM, Diego Novillo  wrote:
>> On Thu, Apr 5, 2012 at 10:24, Richard Guenther
>>  wrote:
>>
>>> Which means never, because I think it's a prerequesite for switching?
>>
>> No.  I was not clear.  By "done", I meant that GCC builds with C++ in
>> all the platforms we can test.
>>
>> I'm sending a testing plan later today with the list of targets I
>> think should be tested.  I am expecting to do some adjusting patches
>> to get all the targets working.
>
> I tried bootstrapping on AIX using C++.
>
> I am able to bootstrap using G++, but not with IBM xlC.  xlC is able
> to compile the GCC source code (with a lot of warning messages), but
> the build fails when the build passes GCC-specific no exception flags
> to xlC.
>
> NOEXCEPTION_FLAGS = -fno-exceptions -fno-rtti
>
> xlc -c -fno-exceptions -fno-rtti conftest.c
>
> does succeed, but
>
> xlc -fno-exceptions -fno-rtti conftest.c
>
> fails.  I don't think -fno-rtti -fno-exceptions does what GCC expects.

Thanks for these data.  I think -fno-rtti and -fno-exceptions don't make
much sense at the linker level so we should leave them out, and use
them only when "compiling", e.g. with "-c".

>
> Also, I noticed that although GCC is configured with
> --enable-build-with-cxx , the configure tests use $CC, which might not
> be accurate.

that is correct.  I suspect a patch for the switch will switch to $CXX.

-- Gaby

Re: RFC: -Wall by default

[Robert Dewar]

On 4/5/2012 4:24 PM, Russ Allbery wrote:

Gabriel Dos Reis  writes:


If it is the non-expert that would be caught in code so non-obvious that
-Wuninitialized would trip into false positives, then it is highly
likely that the code might in fact contain an error.


I wish this were the case, but alas I continue to see fairly trivial false
positives from -Wuninitialized.  Usually cases where the initialization
and the use are both protected by equivalent conditionals at different
places in the function.


Yes, and often it is not so easy for the compiler to see that the
conditionals are always the same


Personally, as a matter of *style*, I eliminate such cases either by
initializing the variable or restructuring the function.  But this is very
much a question of style, not of correctness.


Indeed, and for me, when you are forced to do an initialization like
this, it is mandatory to comment why you are initializing it, otherwise
it obscures the code ("why is this being initialized, where is that
value used?") and that ends up junky IMO. The Ada front end 
unfortunately has quite a few such commented junk initializations.

gcc-4.5-20120405 is now available

[gccadmin]

Snapshot gcc-4.5-20120405 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120405/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch 
revision 186170

You'll find:

 gcc-4.5-20120405.tar.bz2 Complete GCC

  MD5=1d5609099f0b94e0820360ba8d8b85c4
  SHA1=f85c9aa128fbb68e5c092e36f5e3331146307080

Diffs from 4.5-20120329 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
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.

Re: Switching to C++ by default in 4.8

[David Edelsohn]

On Thu, Apr 5, 2012 at 4:35 PM, Gabriel Dos Reis
 wrote:

>> xlc -fno-exceptions -fno-rtti conftest.c
>>
>> fails.  I don't think -fno-rtti -fno-exceptions does what GCC expects.
>
> Thanks for these data.  I think -fno-rtti and -fno-exceptions don't make
> much sense at the linker level so we should leave them out, and use
> them only when "compiling", e.g. with "-c".

It is used when compiling, e.g. gcov.c, but when compiling and linking
directly from source without an intermediate object file.

- David

Re: RFC: -Wall by default

[Pedro Lamarão]

On 04/05/2012 11:29 AM, Gabriel Dos Reis wrote:

this is drifting, but since we talking about teaching (which is part of my
daytime job)

On Thu, Apr 5, 2012 at 7:33 AM, Robert Dewar  wrote:


Wouldn't it be better in a "moderately basic programming course" to
provide standard canned scripts that set things up nicely for students
including the switches they need?


you are assuming that all students have the same programming environement
or that we can force them, or that the environment they are programming in
can run "standard canned scripts that set things up".  The reality is that far
from these ideal situations.


If people should be wrapped inside scripts which enable -Wall for them, 
just enable -Wall for them, right?


Eclipse CDT and Visual Studio turn warnings on by default for new 
projects. You could ask them if anyone is requesting this default to be 
turned off.


--
 P.

Re: i370 port

[Paul Edwards]

I have made this change:

C:\devel\gcc\gcc\config\i370>cvs diff -c -r 1.23 i370.md
Index: i370.md
===
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.md,v
retrieving revision 1.23
retrieving revision 1.24
diff -c -r1.23 -r1.24
*** i370.md 6 Apr 2012 03:57:08 -   1.23
--- i370.md 6 Apr 2012 04:03:21 -   1.24
***
*** 843,848 
--- 843,853 
   /*return \"STM  %1,%N1,%0\"; */
   return \"ST %1,%0\;ST   %N1,4+%0\";
 }
+   if (GET_CODE (operands[1]) == CONST_INT)
+ {
+   mvs_check_page (0, 6, 8);
+   return \"MVC%O0(8,%R0),%W1\";
+ }
   mvs_check_page (0, 6, 8);
   return \"MVC%O0(8,%R0),%1\";
 }"

C:\devel\gcc\gcc\config\i370>


And it has had a good effect:

diff old/cpplib.s new/cpplib.s
1670c1670
<  MVC   120(8,13),=F'0'
---

 MVC   120(8,13),=XL8''

1796c1796
<  MVC   120(8,13),=F'0'
---

 MVC   120(8,13),=XL8''





However, I'm still stuck.  Because when I make this change:

C:\devel\gcc\gcc\config\i370>cvs diff -r 1.17 i370.h
Index: i370.h
===
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.h,v
retrieving revision 1.17
retrieving revision 1.18
diff -r1.17 -r1.18
599a600,602

#define EXTRA_MEMORY_CONSTRAINT(C, STR) \
  ((C) == 'S')



It triggers off a problem with plus:SI

C:\devel\gcc\gcc>stdcompm global.c

C:\devel\gcc\gcc>gccmvs -DUSE_MEMMGR -Os -S -DHAVE_CONFIG_H -DIN_GCC -DPUREISO 
-

I ../../pdos/pdpclib -I . -I config/i370 -I ../include global.c
global.c: In function `find_reg':
global.c:1325: error: unrecognizable insn:
(insn 2432 130 131 12 (set (reg:SI 15 15)
   (plus:SI (plus:SI (reg:SI 4 4 [orig:82 allocno ] [82])
   (reg:SI 3 3 [87]))
   (const_int 44 [0x2c]))) -1 (nil)
   (nil))
global.c:1325: internal compiler error: in ZZZ_680, at recog.c:2083
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gccmvs.sourceforge.net> for instructions.

C:\devel\gcc\gcc>


Seems to be a problem when adding very small const_ints (in
the above case, 44) that can fit into a LA.  I tried to isolate
which plus:SI rule was causing the problem by commenting out these:

;
; addsi3 instruction pattern(s).
;
; The following insn is used when it is known that operand one is an 
address,

; frame, stack or argument pointer, and operand two is a constant that is
; small enough to fit in the displacement field.
; Notice that we can't allow the frame pointer to used as a normal register
; because of this insn.
;

;(define_insn ""
;  [(set (match_operand:SI 0 "register_operand" "=d")
;^I(plus:SI (match_operand:SI 1 "general_operand" "%a")
;^I^I (match_operand:SI 2 "immediate_operand" "J")))]
;  "((REGNO (operands[1]) == FRAME_POINTER_REGNUM || REGNO (operands[1]) == 
ARG$

;  "*
;{
;  check_label_emit ();
;  CC_STATUS_INIT;  /* add assumes CC but LA doesn't set CC */
;  mvs_check_page (0, 4, 0);
;  return \"LA^I%0,%c2(,%1)\";
;}"
;   [(set_attr "length" "4")]
;)

;; The CC status bits for the arithmetic instructions are handled
;; in the NOTICE_UPDATE_CC macro (yeah???) and so they do not need
;; to be set below.  They only need to be invalidated if *not* set
;; (e.g. by BCTR) ... yeah I think that's right ...
;;

;(define_insn "addsi3"
;  [(set (match_operand:SI 0 "nonimmediate_operand" "=d")
;^I(plus:SI (match_operand:SI 1 "general_operand" "%0")
;^I^I (match_operand:SI 2 "general_operand" "g")))]
;  ""
;  "*
;{
;  check_label_emit ();
;  if (REG_P (operands[2]))
;{
;  mvs_check_page (0, 2, 0);
;  return \"AR^I%0,%2\";
;}
;  if (GET_CODE (operands[2]) == CONST_INT)
;{
;  if (INTVAL (operands[2]) == -1)
;^I{
;  CC_STATUS_INIT;  /* add assumes CC but BCTR doesn't set CC */
;^I  mvs_check_page (0, 2, 0);
;^I  return \"BCTR^I%0,0\";
;^I}
;}
;  mvs_check_page (0, 4, 0);
;  return \"A^I%0,%2\";
;}"
;   [(set_attr "length" "4")]
;)


But that seemed to invoke some sort of bug in the main compiler:

C:\devel\gcc\gcc>stdcompm alias.c

C:\devel\gcc\gcc>gdb --args 
gccmvs -DUSE_MEMMGR -Os -S -DHAVE_CONFIG_H -DIN_GCC
-DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I ../include 
alias.

c
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) run
Starting program: 
/cygdrive/c/devel/gcc/gcc/gccmvs.exe -DUSE_MEMMGR -Os -S -DHAV
E_CONFIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I 
../in

clude alias.c
Error: dll starting at 0x76901000 not found.
Error: dll starting at 0x