Re: RFC: -Wall by default

2012-04-05 Thread Arnaud Charlet
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,

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: Switching to C++ by default in 4.8

2012-04-05 Thread Richard Guenther
On Wed, Apr 4, 2012 at 7:53 PM, Lawrence Crowl cr...@google.com wrote: On 4/4/12, Richard Guenther richard.guent...@gmail.com wrote: On Apr 4, 2012 Bernd Schmidt ber...@codesourcery.com wrote: On 04/04/2012 11:06 AM, Richard Guenther wrote: So - I'll veto the switch unless I see 1) and 2).  

Re: RFC: -Wall by default

2012-04-05 Thread Gabriel Dos Reis
On Thu, Apr 5, 2012 at 3:58 AM, Pedro Alves pal...@redhat.com 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

Re: RFC: -Wall by default

2012-04-05 Thread Richard Guenther
On Wed, Apr 4, 2012 at 5:17 PM, Ian Lance Taylor i...@google.com wrote: Andrew Haley a...@redhat.com writes: On 04/04/2012 03:56 PM, Ian Lance Taylor wrote: Andrew Haley a...@redhat.com writes: On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote: For GCC-4.8, I would like to turn on -Wall by

Re: RFC: -Wall by default

2012-04-05 Thread Richard Guenther
On Thu, Apr 5, 2012 at 6:21 AM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Wed, Apr 4, 2012 at 8:19 PM, Robert Dewar de...@adacore.com 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

Re: RFC: -Wall by default

2012-04-05 Thread Gabriel Dos Reis
On Thu, Apr 5, 2012 at 4:32 AM, Richard Guenther richard.guent...@gmail.com wrote: On Wed, Apr 4, 2012 at 5:17 PM, Ian Lance Taylor i...@google.com wrote: Andrew Haley a...@redhat.com writes: On 04/04/2012 03:56 PM, Ian Lance Taylor wrote: Andrew Haley a...@redhat.com writes: On 04/04/2012

Re: RFC: -Wall by default

2012-04-05 Thread Richard Guenther
On Thu, Apr 5, 2012 at 11:32 AM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Thu, Apr 5, 2012 at 3:58 AM, Pedro Alves pal...@redhat.com 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

Re: RFC: -Wall by default

2012-04-05 Thread Gabriel Dos Reis
On Thu, Apr 5, 2012 at 4:36 AM, Richard Guenther richard.guent...@gmail.com wrote: On Thu, Apr 5, 2012 at 6:21 AM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Wed, Apr 4, 2012 at 8:19 PM, Robert Dewar de...@adacore.com wrote: On 4/4/2012 7:03 PM, Gabriel Dos Reis wrote: Again,

Re: RFC: -Wall by default

2012-04-05 Thread Gabriel Dos Reis
On Thu, Apr 5, 2012 at 4:39 AM, Richard Guenther richard.guent...@gmail.com 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread Richard Guenther
On Thu, Apr 5, 2012 at 11:46 AM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Thu, Apr 5, 2012 at 4:39 AM, Richard Guenther richard.guent...@gmail.com wrote: Btw, it would be more reasonable to enable a subset of warnings that we enable at -Wall by default. Which ones for

Re: RFC: -Wall by default

2012-04-05 Thread Gabriel Dos Reis
On Thu, Apr 5, 2012 at 4:51 AM, Richard Guenther richard.guent...@gmail.com wrote: On Thu, Apr 5, 2012 at 11:46 AM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Thu, Apr 5, 2012 at 4:39 AM, Richard Guenther richard.guent...@gmail.com wrote: Btw, it would be more reasonable to

Re: RFC: -Wall by default

2012-04-05 Thread Gabriel Dos Reis
On Thu, Apr 5, 2012 at 4:51 AM, Richard Guenther richard.guent...@gmail.com wrote: Here is a (partial) list:  -Wformat  -Wchar-subscripts  -Wmissing-braces  -Wparentheses  -Wreturn-type  -Wsequence-point  -Wstrict-aliasing  -Wswitch  -Waddress  -Wstrict-overflow  -Warray-bounds  

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread Gabriel Dos Reis
On Thu, Apr 5, 2012 at 5:04 AM, Arnaud Charlet char...@adacore.com 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread Gabriel Dos Reis
On Thu, Apr 5, 2012 at 5:16 AM, Arnaud Charlet char...@adacore.com 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

Re: RFC: -Wall by default

2012-04-05 Thread Gabriel Dos Reis
On Thu, Apr 5, 2012 at 5:16 AM, Arnaud Charlet char...@adacore.com 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

Re: RFC: -Wall by default

2012-04-05 Thread Robert Dewar
On 4/5/2012 12:17 AM, Miles Bader wrote: Robert Dewarde...@adacore.com 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread 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 vinc...@vinc17.net - Web:

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

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

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread 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.

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread 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.

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: Switching to C++ by default in 4.8

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread Richard Guenther
On Thu, Apr 5, 2012 at 2:17 PM, Robert Dewar de...@adacore.com 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: Switching to C++ by default in 4.8

2012-04-05 Thread Richard Guenther
On Thu, Apr 5, 2012 at 2:41 PM, Pedro Lamarão pedro.lama...@gmail.com 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread Richard Guenther
On Thu, Apr 5, 2012 at 2:49 PM, Robert Dewar de...@adacore.com 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: i370 port

2012-04-05 Thread 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 {

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread Gabriel Dos Reis
On Thu, Apr 5, 2012 at 8:58 AM, Jonathan Wakely jwakely@gmail.com 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread 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

Re: RFC: -Wall by default

2012-04-05 Thread Gabriel Dos Reis
On Thu, Apr 5, 2012 at 5:29 AM, Arnaud Charlet char...@adacore.com 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

Re: Switching to C++ by default in 4.8

2012-04-05 Thread Diego Novillo
On Thu, Apr 5, 2012 at 09:04, Richard Guenther richard.guent...@gmail.com wrote: On Thu, Apr 5, 2012 at 2:41 PM, Pedro Lamarão pedro.lama...@gmail.com 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

Re: RFC: -Wall by default

2012-04-05 Thread Gabriel Dos Reis
On Thu, Apr 5, 2012 at 5:50 AM, Andrew Haley a...@redhat.com 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

Re: Switching to C++ by default in 4.8

2012-04-05 Thread Richard Guenther
On Thu, Apr 5, 2012 at 4:21 PM, Diego Novillo dnovi...@google.com wrote: On Thu, Apr 5, 2012 at 09:04, Richard Guenther richard.guent...@gmail.com wrote: On Thu, Apr 5, 2012 at 2:41 PM, Pedro Lamarão pedro.lama...@gmail.com wrote: Is anyone currently working or this? I'm not experienced

Re: RFC: -Wall by default

2012-04-05 Thread Gabriel Dos Reis
On Thu, Apr 5, 2012 at 6:45 AM, Eric Botcazou ebotca...@adacore.com 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

Re: RFC: -Wall by default

2012-04-05 Thread 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 de...@adacore.com wrote: Wouldn't it be better in a moderately basic programming course to provide standard canned scripts that set things up nicely for students

Re: Switching to C++ by default in 4.8

2012-04-05 Thread Diego Novillo
On Thu, Apr 5, 2012 at 10:24, Richard Guenther richard.guent...@gmail.com 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

Re: Switching to C++ by default in 4.8

2012-04-05 Thread Lawrence Crowl
On 4/5/12, Richard Guenther richard.guent...@gmail.com wrote: On Apr 4, 2012 Lawrence Crowl cr...@google.com wrote: On 4/4/12, Richard Guenther richard.guent...@gmail.com wrote: Making tree or gimple a C++ class with inheritance and whatever is indeed a huge waste of time and existing

Re: Switching to C++ by default in 4.8

2012-04-05 Thread David Edelsohn
On Thu, Apr 5, 2012 at 10:36 AM, Diego Novillo dnovi...@google.com wrote: On Thu, Apr 5, 2012 at 10:24, Richard Guenther richard.guent...@gmail.com 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

Re: RFC: -Wall by default

2012-04-05 Thread Russ Allbery
Gabriel Dos Reis g...@integrable-solutions.net 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

Re: RFC: -Wall by default

2012-04-05 Thread Gabriel Dos Reis
On Thu, Apr 5, 2012 at 3:24 PM, Russ Allbery r...@stanford.edu wrote: Gabriel Dos Reis g...@integrable-solutions.net 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

Re: Switching to C++ by default in 4.8

2012-04-05 Thread Gabriel Dos Reis
On Thu, Apr 5, 2012 at 3:16 PM, David Edelsohn dje@gmail.com wrote: On Thu, Apr 5, 2012 at 10:36 AM, Diego Novillo dnovi...@google.com wrote: On Thu, Apr 5, 2012 at 10:24, Richard Guenther richard.guent...@gmail.com wrote: Which means never, because I think it's a prerequesite for

Re: RFC: -Wall by default

2012-04-05 Thread Robert Dewar
On 4/5/2012 4:24 PM, Russ Allbery wrote: Gabriel Dos Reisg...@integrable-solutions.net 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

gcc-4.5-20120405 is now available

2012-04-05 Thread 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

Re: Switching to C++ by default in 4.8

2012-04-05 Thread David Edelsohn
On Thu, Apr 5, 2012 at 4:35 PM, Gabriel Dos Reis g...@integrable-solutions.net 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

Re: RFC: -Wall by default

2012-04-05 Thread 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 Dewarde...@adacore.com wrote: Wouldn't it be better in a moderately basic programming course to provide standard

Re: i370 port

2012-04-05 Thread Paul Edwards
I have made this change: C:\devel\gcc\gcc\config\i370cvs 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 ***

[Bug bootstrap/52840] bootstrap fails in libstdc++, missing compatibility.lo

2012-04-05 Thread aldot at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52840 --- Comment #4 from Bernhard Reutner-Fischer aldot at gcc dot gnu.org 2012-04-05 07:00:41 UTC --- Author: aldot Date: Thu Apr 5 07:00:30 2012 New Revision: 186156 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186156 Log: PR

[Bug bootstrap/52840] bootstrap fails in libstdc++, missing compatibility.lo

2012-04-05 Thread aldot at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52840 Bernhard Reutner-Fischer aldot at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED

[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe

2012-04-05 Thread amodra at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #15 from Alan Modra amodra at gmail dot com 2012-04-05 08:06:30 UTC --- Many hours later one of my 32-bit tests failed, but I'm relieved to say it was only the pthread_once bug. #0 0x0fbd839c in raise () from /lib/power7/libc.so.6

[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe

2012-04-05 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #16 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-05 08:09:53 UTC --- I think we want a macro saying atomics are available for 'int' (which libstdc++ needs for its own uses) and a separate macro saying atomics are available for

[Bug target/52415] memcpy to local variable generates unnecessary stack frame for armv7

2012-04-05 Thread mhlavink at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415 --- Comment #6 from Michal Hlavinka mhlavink at redhat dot com 2012-04-05 08:12:54 UTC --- We can see this bug on avr target too. Following code does not work: DirEnttmp = eeFs.files[i_fileId1]; eeFs.files[i_fileId1] =

[Bug target/52876] New: [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher

2012-04-05 Thread steffen-schmidt at siemens dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 Bug #: 52876 Summary: [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher Classification: Unclassified Product: gcc Version: 4.7.0 Status:

[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher

2012-04-05 Thread steffen-schmidt at siemens dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 --- Comment #1 from Steffen Schmidt steffen-schmidt at siemens dot com 2012-04-05 08:19:24 UTC --- Created attachment 27097 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27097 Example code v2

[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher

2012-04-05 Thread steffen-schmidt at siemens dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 --- Comment #2 from Steffen Schmidt steffen-schmidt at siemens dot com 2012-04-05 08:19:49 UTC --- Created attachment 27098 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27098 Example code v3

[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher

2012-04-05 Thread steffen-schmidt at siemens dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 --- Comment #3 from Steffen Schmidt steffen-schmidt at siemens dot com 2012-04-05 08:20:23 UTC --- Created attachment 27099 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27099 Assembly -O0

[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher

2012-04-05 Thread steffen-schmidt at siemens dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 --- Comment #4 from Steffen Schmidt steffen-schmidt at siemens dot com 2012-04-05 08:21:03 UTC --- Created attachment 27100 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27100 Assembly -O1 -mx32 gcc 4.7.0

[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher

2012-04-05 Thread steffen-schmidt at siemens dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 --- Comment #5 from Steffen Schmidt steffen-schmidt at siemens dot com 2012-04-05 08:21:38 UTC --- Created attachment 27101 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27101 Assembly -O1 -mx32 gcc 4.6.3 x32 branch

[Bug fortran/52860] I/O: gfortran rejects writing after hitting END=

2012-04-05 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52860 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug c++/52874] Which directory in gcc contains error or exception message templates?

2012-04-05 Thread sch...@linux-m68k.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52874 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org 2012-04-05 09:13:36 UTC --- gcc-h...@gcc.gnu.org and libc-h...@sourceware.org are the mailings list where this kind of question is on-topic.

[Bug bootstrap/52867] Compilation of gcc-4.4.7 with gcc-4.2.4 fails on arm platform

2012-04-05 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52867 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-05 10:03:10 UTC --- Btw, as the ICE happens in the _host_ compiler which is 4.2.x this is even longer unsupported.

[Bug tree-optimization/52868] [4.7/4.8 Regression] 4.6 is faster on Atom

2012-04-05 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52868 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Depends on||52272

[Bug libgcj/52645] gnu/java/net/natPlainDatagramSocketImpl.cc:660:14: error: 'IPPROTO_IPV6' was not declared in this scope

2012-04-05 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52645 --- Comment #13 from Rainer Orth ro at gcc dot gnu.org 2012-04-05 10:04:50 UTC --- Author: ro Date: Thu Apr 5 10:04:40 2012 New Revision: 186161 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186161 Log: Restore HAVE_INET6 tests (PR

[Bug libgcj/52645] gnu/java/net/natPlainDatagramSocketImpl.cc:660:14: error: 'IPPROTO_IPV6' was not declared in this scope

2012-04-05 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52645 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher

2012-04-05 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Depends on||52854 --- Comment

[Bug target/52876] [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher

2012-04-05 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Depends on|52854 |52838 --- Comment

[Bug libstdc++/52866] [4.8 Regression] build with --enable-libstdcxx-debug fails in libstdc++

2012-04-05 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52866 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0

[Bug other/52664] [4.8 Regression]: gcc.dg/tree-ssa/pr31261.c fails

2012-04-05 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52664 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0

[Bug middle-end/52621] [4.6/4.7/4.8 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964

2012-04-05 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52621 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-*

[Bug c++/52465] [4.7/4.8 regression] g++ rejects valid code with in-class using declaration

2012-04-05 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52465 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.1

[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target

2012-04-05 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52123 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.1

[Bug c++/51214] [4.7/4.8 Regression] [C++11] name lookup issue with c++11 enums

2012-04-05 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51214 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.1

[Bug target/50946] [4.6 Regression] ICE on armhf with webkitgtk+

2012-04-05 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50946 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.4

[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files

2012-04-05 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.4

[Bug middle-end/52621] [4.6/4.7/4.8 Regression] ICE with -O3 -march=opteron in initialize_matrix_A, at tree-data-ref.c:1964

2012-04-05 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52621 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||spop at gcc

[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe

2012-04-05 Thread amodra at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #17 from Alan Modra amodra at gmail dot com 2012-04-05 12:05:01 UTC --- I spent quite a bit of time today looking at libpthread and can't spot a problem in pthread_mutex_lock and pthread_mutex_unlock. I wonder if the problem is that

[Bug testsuite/52614] [4.8 Regression] Test failures in gcc.dg/vect: vectorizing unaligned access

2012-04-05 Thread wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52614 --- Comment #10 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-04-05 12:11:58 UTC --- Author: wschmidt Date: Thu Apr 5 12:11:50 2012 New Revision: 186163 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186163 Log: gcc/testsuite:

[Bug c++/24985] caret diagnostics

2012-04-05 Thread manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #22 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-05 12:13:01 UTC --- (In reply to comment #21) Created attachment 27093 [details] Patch to prune caret diagnostics from gcc output Actually, this seems like a better

  1   2   3   >