[Bug c/35649] Incorrect printf warning: expect double has float
--- Comment #9 from manu at gcc dot gnu dot org 2010-09-23 07:54 --- Why is this waiting? It only requires a fix. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2010-09-22 20:13:19 |2010-09-23 07:54:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35649
[Bug c/43772] Errant -Wlogical-op warning when testing limits
--- Comment #5 from manu at gcc dot gnu dot org 2010-09-23 08:13 --- (In reply to comment #4) Me too. This is real code, from xdgmime library (errno doesn't matter) long retval = -1; ... if ((retval INT_MIN) || (retval INT_MAX) || (errno != 0)) return -1; What is the above testing for when int == long? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
[Bug c/43772] Errant -Wlogical-op warning when testing limits
--- Comment #6 from manu at gcc dot gnu dot org 2010-09-23 08:24 --- I don't get a warning in trunk r159764. I think I fixed a similar bug during 4.6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
[Bug middle-end/45325] [4.6 Regression] target attribute doesn't work with -march=i586
--- Comment #9 from manu at gcc dot gnu dot org 2010-09-23 15:53 --- (In reply to comment #1) Well - obviously global typedefs keep their BLKmode. The target attribute can't work this way - it's broken by design. If it is broken by design, why not remove it before people start depending on it and GCC has to add layer after layer of workarounds? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325
[Bug preprocessor/45696] Continuation character gets lost or not taken into account
--- Comment #5 from manu at gcc dot gnu dot org 2010-09-17 08:54 --- I have seen this question/bug reported a couple of times in bugzilla and a few more in gcc-help, so I added a FAQ: http://gcc.gnu.org/wiki/FAQ#cpp_continuation_discarded I suggest that it is rather more useful to answer such questions in the wiki and then always provide a link. Moreover, the answers in the wiki tend to be more satisfactory and clear (if not, they can be gradually improved). Otherwise, the same questions are answered again and again but the answers tend to not be uniform in terms of clarity and quality. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45696
[Bug preprocessor/45362] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #7 from manu at gcc dot gnu dot org 2010-09-16 17:04 --- (In reply to comment #4) (In reply to comment #2) http://gcc.gnu.org/bugs/#need Since this is a bug in the preprocessor it is hard to get a preprocessed source that causes a bug. I think this is covered by: blockquoteThe only excuses to not send us the preprocessed sources are (i) if you've found a bug in the preprocessor,/blockquote A testcase is always nice, even if not preprocessed. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-16 17:04:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug preprocessor/45362] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #2 from manu at gcc dot gnu dot org 2010-09-14 09:32 --- http://gcc.gnu.org/bugs/#need -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug c++/45609] [Regression 4.3/4.4/4.5/4.6] 'is used uninitialized' becomes 'may be used uninitialized' on unrelated code changes (namespace addition)
--- Comment #2 from manu at gcc dot gnu dot org 2010-09-09 08:00 --- In any case, this is a clear regression of the pretty printer. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-09 08:00:56 date|| Summary|'is used uninitialized' |[Regression 4.3/4.4/4.5/4.6] |becomes 'may be used|'is used uninitialized' |uninitialized' on unrelated |becomes 'may be used |code changes (namespace |uninitialized' on unrelated |addition) |code changes (namespace ||addition) Target Milestone|--- |4.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45609
[Bug c/45610] misleading warning when operator paired with a constant - is it operator precedence?
--- Comment #2 from manu at gcc dot gnu dot org 2010-09-09 13:15 --- We need a testcase http://gcc.gnu.org/bugs/minimize.html but I am pretty sure this is not warned anymore in GCC 4.6 (and probably GCC 4.4 and 4.5) -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45610
[Bug c/25880] improve message of warning for discarding qualifiers
--- Comment #6 from manu at gcc dot gnu dot org 2010-09-08 23:33 --- (In reply to comment #5) The changes done in pp_c_cv_qualifiers print �__attribute__((const))� or '__attribute__((noreturn))' for function pointer even if they are defined with 'const' or 'volatile' in the users code and this may be confusing for some. This is on purpose. There is no way to internally differentiate between these two cases[*], so one has to decide to print one or the other. We decided the current approach for function pointers was clearer, because (1) one should really use the attributes and not volatile/const (2) one can lookup the attributes and find out what they mean and that they are equivalent to volatile/const. I hope this answers your question. [*] GCC is very far from retaining such detailed source-level information and no one is working on improving this for the foreseeable future. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||rmansfield at qnx dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25880
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #20 from manu at gcc dot gnu dot org 2010-09-07 06:38 --- (In reply to comment #19) Manu, did you mean to change Severity back to 'critical' ? No, that was a mistake. In any case, this is INVALID for the reasons discussed above. -- manu at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #22 from manu at gcc dot gnu dot org 2010-09-03 14:06 --- (In reply to comment #21) (In reply to comment #8) Is 'coverity' a compiler? I don't think so. Coverity is not a tool that generates code, but it does perform all the syntactic semantic analysis that a code-generating compiler will. Then, it goes beyond that with further static analysis. GCC is not designed to be used as a static analysis tool. This doesn't mean it wouldn't be interesting to be able to reuse GCC analysis modules for doing that. Other compilers have shown that it is possible and a desirable feature [*]. However, GCC is not designed to be reusable, there is none working on a similar thing for GCC, and no sign that any existing GCC developer will start working on it in the near future. Unless someone new starts working on this, don't expect anything similar from GCC. [*] http://clang-analyzer.llvm.org/ Do you have actual examples of *compilers* which, everything taken into account, decided to make sure this case is worth warning? That's the worst argument I've read in a long time. Do we need proof that another compiler does something before the gcc team will take it up now? There is more work to do in GCC than people willing (or being paid) to do it, so if there is some indication that some feature may be impossible or too expensive to implement, existing GCC developers will probably focus their efforts on something else more feasible. If you can show that another compiler is able to do it in an efficient way, that shows that it is feasible. As far as I know, GCC has always been a very conservative compiler in terms of features, not a source of innovation. So yes, showing a working implementation seems to be a necessary condition (but not a sufficient one). In fact, it is common practice to check what other compilers do in order to verify a bug, and it is useful information in bug reports. I am sorry for this flamewar. I hope I clarified all the issues and the wiki [**] contains a more detailed discussion about the technical issues related to uninitialized warnings in case anyone is willing to help to solve them. [**] http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/45493] -Wuninitialized does not warn
--- Comment #4 from manu at gcc dot gnu dot org 2010-09-02 22:50 --- CCP is responsible for this. *** This bug has been marked as a duplicate of 18501 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45493
[Bug tree-optimization/18501] [4.3/4.4/4.5/4.6 Regression] Missing 'used uninitialized' warning (CCP)
--- Comment #40 from manu at gcc dot gnu dot org 2010-09-02 22:50 --- *** Bug 45493 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||tadhunt at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
[Bug tree-optimization/45085] [4.6 Regression] incorrect -Wuninitialized warning
--- Comment #7 from manu at gcc dot gnu dot org 2010-09-02 22:59 --- WAITING is for waiting for submitters information. -- manu at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||24639 nThis|| Status|WAITING |ASSIGNED Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45085
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #20 from manu at gcc dot gnu dot org 2010-09-02 23:10 --- The first testcase and the second are different issues. Both of them are old, known and reported in bugzilla. None of them are trivial to fix. GCC developers would wish to make our compiler as powerful as to solve the halting problem in less than a blink. Unfortunately, time, money, and contributors willing to work on this particular problem are scarce. If you can help in some way, please do so. Otherwise, thanks for the report anyway. *** This bug has been marked as a duplicate of 18501 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug tree-optimization/18501] [4.3/4.4/4.5/4.6 Regression] Missing 'used uninitialized' warning (CCP)
--- Comment #41 from manu at gcc dot gnu dot org 2010-09-02 23:10 --- *** Bug 42884 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||tstdenis at elliptictech dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
[Bug c/45467] gcc won't warn about an uninitialized value
--- Comment #8 from manu at gcc dot gnu dot org 2010-08-31 20:37 --- (In reply to comment #7) Updated code snippet, GCC doesn't warn here either if we leave `#if 0' as-is, even though the function foo() may have side-effects. No, the function below does not have any side-effects. The result of the program is the same whether the function runs or not because the return value is ignored. To have a side-effect you need to write/print, change global memory, or affect the return value of the program. Until then, this is invalid. Please, reopen when you have a valid testcase (there are bugs in Wuninitialized, so I wouldn't be surprised if you find one). -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #11 from manu at gcc dot gnu dot org 2010-08-31 20:53 --- (In reply to comment #8) (In reply to comment #7) I am pointing out a case where it does not warn (and it seems to me that it should); what is your point? My point is that you should open a different bug that says we should warn about that case with -O0 rather than warning that -Wuninitialized needs -O. The manual says: Because these warnings depend on optimization, the exact variables or elements for which there are warnings will depend on the precise optimization options and version of GCC used. It is infeasible to perform expensive analysis at -O0, so there is little point to open such a bug report. It might be possible to have some fast dataflow analysis at -O0 to detect this case but I am pretty sure that no existing GCC developer is going to work on this. So unless you are planning to work on this yourself (or pay someone to do it), don't expect any fix soon. But opening bug reports is free, so go for it if you wish. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #13 from manu at gcc dot gnu dot org 2010-08-31 21:07 --- (In reply to comment #12) Sorry Andrew, misinterpreted some things you said. I understand now that you meant that normally everything should work as expected. @Manuel, So, perhaps then this bug report is at least sort of valid? It seems that to get `-Wuninitialized' to *fully* work, one would need at least `-O1'? No, higher levels of optimization may provide even better warnings (or disable some false positives) It seems to me, that if that is the case, and the user has not specified *any* `-O'-like option on the command-line, GCC should warn, since it's probably the user's intent to get a *fully* working `-Wuninitialized' option? If however, There is no such thing as a *fully* working Wuninitialized. The results totally depend on which optimization passes are run (and their order). See http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings for more background on the issues involved and existing bugs. the user did specify `-O0', perhaps GCC should assume the user has knowledge about GCC not being able to warn about every case? Old gcc versions warned because Wuninitialized did nothing without optimization. The user should know that GCC is not able to warn about every case at any optimization level, but higher optimization levels should provide better results (this is what the manual says!). No amount of analysis will warn about every case (the usual halting problem). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #15 from manu at gcc dot gnu dot org 2010-08-31 21:34 --- (In reply to comment #14) depend on which optimization passes are run (and their order). See http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings for more background on the issues involved and existing bugs. :( It is an unfortunate truth that GCC's warnings are sometimes far from optimal, but maybe it's also good in some ways. For one thing, it forces us programmers to be more conscientious while coding. I don't think the situation is good at all. It is one of the favourite themes of criticism towards GCC. One reason why Clang warnings are better than GCC's is that Clang has some degree of dataflow analysis in the front-end. Unfortunately, GCC lacks any dataflow analysis in front-ends, where most warnings occur. Even in middle-end warnings, one cannot enable the analysis without enabling code transformations. It would be fantastic to have (1) fast data-flow analysis that can work on the front-end (similar to those of Clang static analyzer), (2) a way to enable some middle-end analysis without enabling any code transformations. However, as far as I know, no one in GCC is even thinking about either. Sorry. (Item 1 is particularly difficult because GCC C/C++ front-ends are very slow already, so adding more stuff on top is highly unwelcome.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #18 from manu at gcc dot gnu dot org 2010-08-31 22:44 --- (In reply to comment #17) Manuel, can you back up your claims about the C FE being slow with some numbers? I don't remember the C FE ever being a time issue recently, of course C++ is a different story. I mean slow relative to Clang (despite Clang performs dataflow analysis in the FE): http://clang.llvm.org/features.html#performance http://clang.llvm.org/performance.html In any case, the main argument I got against adding dataflow to the FE was that it would slow it down. If this is not an issue anymore, it would be good to say so more publicly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c++/44641] Generated constructors and destructors get wrong debug location when a typedef uses a forward declaration of the type before the definition
--- Comment #11 from manu at gcc dot gnu dot org 2010-07-21 19:40 --- (In reply to comment #8) Despite your remarkably rude response, I've mailed a fix: http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01665.html Don't take it personally. Some of us are not native English-speakers, so we miss some nuances of English languages. On the other hand, others often use a matter-of-fact tone that is unintentionally rude. Finally, there is for sure rude people around. Since it is hard to differentiate between these three cases without starting an argument, just ignore it altogether. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44641
[Bug c++/40146] Unexplained 'anonymous' is used uninitialized in this function warning
--- Comment #15 from manu at gcc dot gnu dot org 2010-07-13 15:22 --- Before closing this, please check all testcases provided and add at least one of them to the testsuite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40146
[Bug c/44842] gcc should not issue warnings for code that will never be executed
--- Comment #2 from manu at gcc dot gnu dot org 2010-07-06 17:24 --- *** This bug has been marked as a duplicate of 4210 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44842
[Bug middle-end/4210] should not warning with dead code
--- Comment #21 from manu at gcc dot gnu dot org 2010-07-06 17:24 --- *** Bug 44842 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||vincent at vinc17 dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
[Bug middle-end/4210] should not warning with dead code
--- Comment #22 from manu at gcc dot gnu dot org 2010-07-06 17:28 --- The way Clang gets this right is to perform some very-fast bitmap common constant propagation in the FE. I personally think this would be helpful if implemented correctly, even if it slows down the FE a little. But do not wait for a fix soon because this is not trivial to fix and no one has both the desire and the free time to work on fixing this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
[Bug c++/33801] Missing warning
--- Comment #3 from manu at gcc dot gnu dot org 2010-07-06 17:34 --- 3 years in waiting... I am closing this, we have too many real bugs open to worry about. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33801
[Bug c++/34039] [MInGW] -Werror does not trigger non zero exit code
--- Comment #5 from manu at gcc dot gnu dot org 2010-07-06 17:35 --- No feedback, unconfirmed, unreproducible, thus closing. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34039
[Bug other/32185] unused result warnings and -werror
--- Comment #6 from manu at gcc dot gnu dot org 2010-07-06 17:39 --- No duplicates in 3 years, no new feedback, closing this. Please reopen if necessary. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32185
[Bug middle-end/33654] Strange message + bad code generated for -fPIC -O3
--- Comment #4 from manu at gcc dot gnu dot org 2010-07-06 17:41 --- Too large testcase, no feedback in 3 years, no clear report. Closing... -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33654
[Bug c/44774] -Werror=edantic
--- Comment #12 from manu at gcc dot gnu dot org 2010-07-04 08:27 --- (In reply to comment #11) I do not object to -Wpedantic. Ah, ok! Then, I will start with this and worry about the other warnings when their time comes. Thanks! -- manu at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2010-07-01 21:42:35 |2010-07-04 08:27:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44774
[Bug c++/44800] DECL_SAVED_TREE is always null on the first FUNCTION_DECL and is not null on the others
--- Comment #10 from manu at gcc dot gnu dot org 2010-07-04 08:34 --- (In reply to comment #8) After the bug has been closed. i has posted the question to gcc-help, thanks ( i has reported as bug because , i has thinked it was a bug ) I personally think that if this is not clear (but it is the correct behaviour) it is a documentation bug. Whatever you find, please post it here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44800
[Bug c++/16630] missing type name in __PRETTY_FUNCTION__
--- Comment #11 from manu at gcc dot gnu dot org 2010-07-04 18:17 --- Subject: Bug 16630 Author: manu Date: Sun Jul 4 18:16:59 2010 New Revision: 161805 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161805 Log: 2010-07-04 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/16630 * g++.dg/ext/pretty3.C: New. Added: trunk/gcc/testsuite/g++.dg/ext/pretty3.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16630
[Bug c++/16630] missing type name in __PRETTY_FUNCTION__
--- Comment #12 from manu at gcc dot gnu dot org 2010-07-04 18:19 --- Testcase added. Closing as FIXED. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16630
[Bug c++/44800] DECL_SAVED_TREE is always null on the first FUNCTION_DECL and is not null on the others
--- Comment #6 from manu at gcc dot gnu dot org 2010-07-03 18:58 --- Pietro, Please explain what is happening and what do you expect to happen, and why do you expect that. If you are having troubles about using gcc, please ask in gcc-help first. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44800
[Bug c++/44796] segfault with variable named 'xor' (Apple-gcc-4.2.1)
--- Comment #2 from manu at gcc dot gnu dot org 2010-07-03 19:01 --- Shouldn't Apple have their own bugurl? Perhaps we should add some short sentence in bugs.html about NOT reporting Apple bugs to us (anyway their compiler version is too old to be interesting for us). -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44796
[Bug c++/99] Bug in template type in error message.
--- Comment #18 from manu at gcc dot gnu dot org 2010-07-03 19:59 --- I think this bug is not actually assigned to anybody. Anyone feel free to take it. -- manu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|gdr at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=99
[Bug c/21759] Implement warning for codes at the intersection of C and C++
--- Comment #11 from manu at gcc dot gnu dot org 2010-07-03 20:08 --- Isn't this a duplicate of PR37041? That PR is more complete than this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21759
[Bug c/37041] -Wc++-compat refinements
--- Comment #4 from manu at gcc dot gnu dot org 2010-07-03 20:10 --- We should collect individual Wc++-compat issues here. -- manu at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||40564 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37041
[Bug c/44774] -Werror=edantic
--- Comment #4 from manu at gcc dot gnu dot org 2010-07-02 06:58 --- I knew this couldn't be easy ;-) Let's restrict to -pedantic first. It is the only warning flag that doesn't start with -W. This breaks some code that expects that every warning flag starts with -W. I want to introduce -Wpedantic as an alias. You do not like the name. What is your suggestion? Manuel. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44774
[Bug c/44774] -Werror=edantic
--- Comment #5 from manu at gcc dot gnu dot org 2010-07-02 08:07 --- Related PR 37187 -- manu at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||37187 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44774
[Bug c++/44499] No default constructor available
--- Comment #7 from manu at gcc dot gnu dot org 2010-07-02 08:09 --- Could someone test what clang says here? Their diagnostics are generally better than g++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c++/44499] No default constructor available
--- Comment #9 from manu at gcc dot gnu dot org 2010-07-02 09:15 --- Thanks Pawel, which diagnostic do you prefer? I would favor clang's but I would still keep the note that points to the class definition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c/44774] -Werror=edantic
--- Comment #7 from manu at gcc dot gnu dot org 2010-07-02 10:56 --- Why? All of them do, except -pedantic. I don't see any reason for -pedantic being exceptional. Or can I start proposing warnings options that do not start with -W? Should we introduce a special case for pedantic (code and documentation) for -Werror= and for -Wno-error= and for -Wno-? I can start opening PRs for the missing special cases. We would also need to introduce (and handle specially) -no-pedantic and -no-pedantic-errors. All the above is free if we just make -Wpedantic an alias for -pedantic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44774
[Bug c/44782] New: implement -ferror-limit=
clang: -ferror-limit=123: Stop emitting diagnostics after 123 errors have been produced. The default is 20, and the error limit can be disabled with -ferror-limit=0 (-ferror-limit=1 is equivalent to -Wfatal-errors) -- Summary: implement -ferror-limit= Product: gcc Version: unknown Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44782
[Bug c++/44783] New: implement -ftemplate-backtrace-limit=
clang: -ftemplate-backtrace-limit=123: Only emit up to 123 template instantiation notes within the template instantiation backtrace for a single warning or error. The default is 10, and the limit can be disabled with -ftemplate-backtrace-limit=0. I recently implemented this but hardcoded the value to 10. We should add this switch to allow configuration of this value (specially to disable the limit). -- Summary: implement -ftemplate-backtrace-limit= Product: gcc Version: unknown Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44783
[Bug c/44774] -Werror=edantic
--- Comment #9 from manu at gcc dot gnu dot org 2010-07-02 14:24 --- (In reply to comment #8) By the way, the subject should read -Werror=pedantic, right? Well, it depends. We actually print -Werror=edantic. ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44774
[Bug c++/44786] New: -fcatch-undefined-behavior: Turn on runtime code generation to check for undefined behavior
Clang provides a number of ways to control code generation. The options are listed below. -fcatch-undefined-behavior: Turn on runtime code generation to check for undefined behavior. This option, which defaults to off, controls whether or not Clang adds runtime checks for undefined runtime behavior. If the check fails, __builtin_trap() is used to indicate failure. The checks are: # Subscripting where the static type of one operand is variable which is decayed from an array type and the other operand is greater than the size of the array or less than zero. # Shift operators where the amount shifted is greater or equal to the promoted bit-width of the left-hand-side or less than zero. # If control flow reaches __builtin_unreachable. -- Summary: -fcatch-undefined-behavior: Turn on runtime code generation to check for undefined behavior Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786
[Bug c++/40793] Error: no matching function for call to XYZ doesn't display function-template-arguments
--- Comment #7 from manu at gcc dot gnu dot org 2010-07-01 21:31 ---
With the patch below, we print this:
pr40793.C:5:31: error: no matching function for call to staticPrintdouble,
text()
pr40793.C:2:18: note: candidate is: templateclass T, T t void staticPrint()
but I am not sure if it is possible to print the type of text. Any ideas?
Index: call.c
===
--- call.c (revision 161658)
+++ call.c (working copy)
@@ -3247,12 +3247,19 @@ build_new_function_call (tree fn, VEC(tr
{
if (!any_viable_p candidates ! candidates-next
(TREE_CODE (candidates-fn) == FUNCTION_DECL))
return cp_build_function_call_vec (candidates-fn, args, complain);
if (TREE_CODE (fn) == TEMPLATE_ID_EXPR)
- fn = TREE_OPERAND (fn, 0);
- if (!any_viable_p)
+ {
+ if (!any_viable_p)
+ error (no matching function for call to %%E(%A)%,
+ fn, build_tree_list_vec (*args));
+ else
+ error (call of overloaded %%E(%A)% is ambiguous,
+ fn, build_tree_list_vec (*args));
+ }
+ else if (!any_viable_p)
error (no matching function for call to %%D(%A)%,
DECL_NAME (OVL_CURRENT (fn)), build_tree_list_vec (*args));
else
error (call of overloaded %%D(%A)% is ambiguous,
DECL_NAME (OVL_CURRENT (fn)), build_tree_list_vec (*args));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793
[Bug rtl-optimization/44752] insn-automata.c: empty translation unit
--- Comment #2 from manu at gcc dot gnu dot org 2010-07-01 21:36 --- Is that really printing -Werror=edantic or a problem copy+pasting? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44752
[Bug c/44774] New: -Werror=edantic
cc1 empty.c -pedantic -Werror empty.c:1:0: error: ISO C forbids an empty translation unit [-Werror=edantic] -- Summary: -Werror=edantic Product: gcc Version: unknown Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44774
[Bug c/44774] -Werror=edantic
--- Comment #1 from manu at gcc dot gnu dot org 2010-07-01 21:42 --- I will propose to introduce -Wpedantic as the canonical name of pedantic. This will also make -Werror=pedantic work. I don't see any reason why -pedantic has to be special except historical. We can keep the old forms as aliases indefinitely. Joseph, Gabriel, what is your opinion? Should I prepare a patch to add -Wpedantic? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org, ||gdr at gcc dot gnu dot org, ||jsm28 at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-01 21:42:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44774
[Bug c/44774] -Werror=edantic
--- Comment #2 from manu at gcc dot gnu dot org 2010-07-01 21:53 --- man...@gcc11:~$ ~/test2/161617M/build/gcc/cc1 empty2.c -pedantic-errors empty2.c:1:1: error: struct has no members [-pedantic] empty2.c:2:1: error: unnamed struct/union that defines no instances man...@gcc11:~$ ~/test2/161617M/build/gcc/cc1 empty2.c -pedantic -Werror empty2.c:1:1: error: struct has no members [-Werror=edantic] empty2.c:2:1: error: unnamed struct/union that defines no instances [-Werror] We also should add a -Wpedantic-default (or -Wpedantic-required) for pedwarns enabled by default (not by -pedantic). OK? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44774
[Bug rtl-optimization/44752] insn-automata.c: empty translation unit
--- Comment #4 from manu at gcc dot gnu dot org 2010-07-01 22:52 --- I know, I wrote that code but missed the -pedantic case. I opened PR 44774 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44752
[Bug c/40564] Invalid -Wc++-compat warning about stringized C++ operator name
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-29 23:46 ---
I have another troublesome testcase:
/* { dg-do compile } */
/* { dg-options -Wall -Wextra -Wc++compat } */
#error \
In order for the format checking to accept the C front end diagnostic \
framework extensions, you must include this file before diagnostic-core.h \
not after.
I want to add the above in c-family/c-common.h
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC||manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40564
[Bug c++/44673] static const variable works in if/else, fails at linking in ternary
--- Comment #12 from manu at gcc dot gnu dot org 2010-06-26 10:35 --- (In reply to comment #11) [class.static.data]/3 If a static data member is of const literal type, its declaration in the class de#64257;nition can specify a brace-or-equal-initializer ... The member shall still be de#64257;ned in a namespace scope if it is used in the program and the namespace scope de#64257;nition shall not contain an initializer. [basic.def.odr] explains what used means. The code is invalid, I don't think it does users a service to accept it. So is g++ accepting invalid code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44673
[Bug c++/44673] static const variable works in if/else, fails at linking in ternary
--- Comment #14 from manu at gcc dot gnu dot org 2010-06-26 10:53 --- (In reply to comment #12) So is g++ accepting invalid code? Yes, but it's a violation of the ODR, no diagnostic is required (it's not possible to tell until link time that there's no definition.) There are DOZENS of duplicates of this bug, they are all invalid. However, it links in the if-else case. I understand that ?: may be used as a lvalue, but in this case, it is not and the value may be inlined in the same way as in if-else (I guess that is what Andrew's patch did). If the standard is clear that this should not work, then so be it. Let's close this as INVALID, because I don't know how we could improve the diagnostics here to help users. I wish we could but I cannot see how it can be done. I guess that would require an integrated super-smart linker, I wonder if the LLVM project is going to suggest that next? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44673
[Bug middle-end/44665] typo in comment, incorrect/out-of-date comment
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-25 13:09 --- Subject: Bug 44665 Author: manu Date: Fri Jun 25 13:09:28 2010 New Revision: 161380 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161380 Log: 2010-06-25 Manuel López-Ibáñez m...@gcc.gnu.org PR 44665 * tree-inline.c (gimple_expand_calls_inline): Fix typo in comment. * gimplify.c (is_gimple_reg_rhs_or_call): Likewise. (gimplify_expr): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44665
[Bug middle-end/44665] typo in comment, incorrect/out-of-date comment
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-25 13:14 --- FIXED in trunk. Such fixes are considered obvious, so feel free to commit patches to fix them. Fixing changelogs and svn logs for typos falls also into the obvious category. If you do not have write access, just send a patch to gcc-patches and ask for someone to commit it. I am not going to fix it in GCC 4.5, but anyone should feel free to backport my patch. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-25 13:14:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44665
[Bug c++/44673] static const variable works in if/else, fails at linking in ternary
--- Comment #7 from manu at gcc dot gnu dot org 2010-06-26 00:18 --- (In reply to comment #4) In the case of if, the value was inlined and in the case of ?:, it is not. I had a patch which changed the behavior but lost it when I moved companies. And what did your patch do exactly? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44673
[Bug c++/44673] static const variable works in if/else, fails at linking in ternary
--- Comment #9 from manu at gcc dot gnu dot org 2010-06-26 00:30 --- Then, I reopen this as an enhancement request. If you ever find/redo the patch or someone else decides to fix this in the same way, it would a nice improvement for usability. -- manu at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44673
[Bug c++/44673] static const variable works in if/else, fails at linking in ternary
-- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i486-linux-gnu | GCC host triplet|i486-linux-gnu | GCC target triplet|i486-linux-gnu | Last reconfirmed|-00-00 00:00:00 |2010-06-26 00:31:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44673
[Bug preprocessor/44652] Column numbers in error messages are wrong
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-24 12:03 --- (In reply to comment #3) I think column 0 is correct for the start of all preprocessor directives. But the #include does not start at column 0, so there is something wrong there. We know that libcpp column information sucks in many places. Tom and I have several patches but we never got around to finish them. To not get column info just use -fno-show-column -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-24 12:03:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44652
[Bug c/44657] GCCSense: merge code-assist branch, or plugin
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-24 17:56 --- Nice! But to get anything merged to GCC you need first a copyright assignment. Otherwise, we cannot even look at your code. http://gcc.gnu.org/contribute.html#legal For implementing this as a plugin, you do not need anything from the GCC project (do you?). So there is no need to open a PR. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44657
[Bug c++/44625] ICE after error: anonymous struct not inside named type
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-22 09:21 --- Confirmed in trunk. A reduce testcase would be helpful: http://gcc.gnu.org/bugs/minimize.html -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-22 09:21:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44625
[Bug c++/44623] [4.6 Regression] ICE on invalid code
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-22 09:25 --- Confirmed in trunk. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.4.3 Last reconfirmed|-00-00 00:00:00 |2010-06-22 09:25:03 date|| Summary|ICE on invalid code |[4.6 Regression] ICE on ||invalid code Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44623
[Bug c++/44623] [4.6 Regression] ICE on invalid code
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-22 09:27 --- It would be more correct to say that it doesn't ICE on g++ 4.4.3, but still error-recovery is awful: pr44623.ii:3:137: warning: missing terminating character pr44623.ii:3: error: missing terminating character pr44623.ii:3: error: two or more data types in declaration of 'parameter' pr44623.ii:3: error: expected primary-expression at end of input pr44623.ii:3: error: type 'basic_stringbufint, int, _Alloc' is not derived from type 'basic_stringbuf template-parameter-1-1, template-parameter-1-2, template-parameter-1-3 ' pr44623.ii:3: error: expected '}' at end of input pr44623.ii:3: error: expected unqualified-id at end of input -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44623
[Bug c++/44607] basic template struct has no direct access to members of a basic parent template struct
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-21 14:00 --- (In reply to comment #2) You can also use the online Comeau compiler at http://www.comeaucomputing.com/tryitout/ to test your assumptions. If Comeau and GCC both give an error then you can be 99.9% sure the problem is in your code not the compiler. Perhaps it would be more useful if the bug reporting instructions would mention this advice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44607
[Bug c++/44609] Invalid template code causes infinite loop of error messages
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-21 14:03 --- And what is the difference between an ICE and an infinite loop? Both seem to be internal errors of the compiler. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2010-06-21 14:03:26 date|| Summary|Invalid code causes ICE |Invalid template code causes ||infinite loop of error ||messages http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
[Bug c++/44613] Declaring an array with non-constant length inside a switch corrupts stack pointer.
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-21 16:45 --- (In reply to comment #1) (In reply to comment #0) The following program compiles with g++ -O3 without errors or warnings Not with warnings enabled it doesn't! ??? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44613
[Bug c++/44613] Declaring an array with non-constant length inside a switch corrupts stack pointer.
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-21 16:51 --- (In reply to comment #3) (In reply to comment #1) (In reply to comment #0) The following program compiles with g++ -O3 without errors or warnings Not with warnings enabled it doesn't! Sorry, g++ -O3 -Wall -Wextra switch-crash.cpp gives: switch-crash.cpp: In function int f(int): switch-crash.cpp:6: warning: unused variable x switch-crash.cpp:10: warning: no return statement in function returning non-void If you add return 0 after the printf, this warning is silenced and it still crashes (it crashes for me even at -O0). switch-crash.cpp:7: warning: saved_stack.1 is used uninitialized in this function The saved_stack.1 is somewhat suspicious. It is a bug anyway, because internal variables should never be warned. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-21 16:51:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44613
[Bug other/32998] -frecord-gcc-switches issues
--- Comment #8 from manu at gcc dot gnu dot org 2010-06-20 21:20 --- I think this is pretty much confirmed. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-20 21:20:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998
[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.
--- Comment #7 from manu at gcc dot gnu dot org 2010-06-20 21:25 --- Patches should be sent to gcc-patches. You may CC the libgomp maintainer ja...@redhat.com. See also http://gcc.gnu.org/contribute.html -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616
[Bug c/44598] -Wunused-variable miss 'static const char x[] = ;'
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-20 21:30 --- I think we do not warn on purpose because unused global static const strings are used often for storing version, metadata and stuff that may only be conditionally compiled after preprocessing. I would argue we should not warn for either case then. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org, ||jakub at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-20 21:30:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44598
[Bug middle-end/44600] warnings about possibly uninitialized locals
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-20 21:35 --- I appreciate your effort reporting this but, why should we care about wrong warnings from very very old compilers? And initializing the variables has a cost, because optimizations cannot just assume any value. Otherwise, we could have fixed PR18501 a while ago. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44600
[Bug c/44586] gcc does not warn about casting non-variadic types to variadic types
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-20 21:41 --- Joseph, what do you think? Any suggestions where this may be catched? wording? option? I have wished for some time to create a -Wundefined option anyway. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org, ||jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44586
[Bug c/44586] gcc does not warn about casting non-variadic types to variadic types
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-20 22:25 --- OK. So I would say confirmed, but still I am not sure how I would implement this. So patches welcome. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-20 22:25:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44586
[Bug tree-optimization/44547] -Wuninitialized reports false warning in nested switch statements (missed switch optimization)
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-17 07:18 --- You are right. The issue occurs in VRP but not because of the disjoint ranges. Pass vrp1 is able to optimize your first example (nested if) but not the second (nested switch). I think this is a missed optimization. Not easy to fix, though. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-17 07:18:58 date|| Summary|-Wuninitialized reports |-Wuninitialized reports |false warning in nested |false warning in nested |switch statements |switch statements (missed ||switch optimization) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44547
[Bug c++/44486] [4.3/4.4/4.5/4.6 regression] missing space in __PRETTY_FUNCTION__ expansion in anonymous namespace
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-17 07:28 --- Subject: Bug 44486 Author: manu Date: Thu Jun 17 07:28:21 2010 New Revision: 160877 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160877 Log: 2010-06-17 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/44486 cp/ * error.c (dump_decl): Better wording for anonymous namespace. testsuite/ * g++.dg/pr44486.C: New. Added: trunk/gcc/testsuite/g++.dg/pr44486.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44486
[Bug c++/44486] [4.3/4.4/4.5/4.6 regression] missing space in __PRETTY_FUNCTION__ expansion in anonymous namespace
--- Comment #5 from manu at gcc dot gnu dot org 2010-06-17 07:29 --- FIXED in GCC 4.6. Thanks for the report. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44486
[Bug tree-optimization/44547] -Wuninitialized reports false warning in nested switch statements (missed switch optimization)
--- Comment #5 from manu at gcc dot gnu dot org 2010-06-17 08:37 --- (In reply to comment #4) It seems that optimizing is what's causing the problem: the example compiles fine with -O0, but not -On=1. It also compiles fine when the case values are consecutive, which seems telling. My first guess would be to take a look at what optimizations are being done to switch statements that have non-consecutive-valued cases as opposed to those that have consecutive values. Wuninitialized does not detect as many cases with -O0 than with higher optimizations. When the cases are consecutive, VRP kicks in and simplifies the switch. You can check what is going on using -fdump-tree-all-lineno and inspecting the dumps. n(D) means the uninitialized value of n. When that is removed, then Wuninitialized will not warn. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44547
[Bug tree-optimization/44547] -Wuninitialized reports false warning in nested switch statements
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-16 11:54 --- Value range-propagation (VRP) does not work on disjoint ranges, so the compiler does not actually know that argc can only be 1, 2 or 4. I think there is already a PR about this but I cannot find it right now. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org OtherBugsDependingO||24639 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44547
[Bug c++/44548] Link error when defining templated static const variable
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-16 11:58 --- (In reply to comment #3) but it is an explicit specialization of the *definition* of the variable No it is a specialization of the declaration. There are only specialization of declarations; never definitions. Re-read the link you gave and you will see the following: Explicit specialization declaration syntax . So what the above code actually means? Is it valid? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44548
[Bug c/44513] New: improve column number and text of format warnings
Testcase:
/* { dg-do compile } */
/* { dg-options -std=iso9899:1990 -pedantic -Wformat } */
#include format.h
void
foo (int i)
{
printf (%d%d, i);
}
gcc-4.6:
/home/manuel/test/src/gcc/testsuite/gcc.dg/format/clang-1.c: In function 'foo':
/home/manuel/test/src/gcc/testsuite/gcc.dg/format/clang-1.c:9:3: warning: too
few arguments for format [-Wformat]
clang prints:
warning: '.*' specified field precision is missing a matching 'int' argument
and the column number points to the extra %d.
--
Summary: improve column number and text of format warnings
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44513
[Bug c/44514] New: bad error recovery with forgotten ; after class definition
Testcase:
templateclass T
class a {}
class temp {};
atemp b;
struct b {
}
gcc-4.6:
clang-2.C:3:15: error: multiple types in one declaration
clang-2.C:4:7: error: non-template type a used as a template
clang-2.C:4:10: error: invalid type in declaration before ; token
clang-2.C:6:1: error: expected unqualified-id at end of input
clang:
t.cc:2:11: error: expected ';' after class
class a {}
^
;
t.cc:6:2: error: expected ';' after struct
}
^
;
--
Summary: bad error recovery with forgotten ; after class
definition
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44514
[Bug c/44515] New: improve message for missing ;
Testcase:
void bar(void);
void foo(void)
{
bar()
}
gcc-4.6:
clang-3.c:7:1: error: expected ; before } token
clang:
t.c:4:8: error: expected ';' after expression
bar()
^
;
--
Summary: improve message for missing ;
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44515
[Bug c++/16630] missing type name in __PRETTY_FUNCTION__
--- Comment #10 from manu at gcc dot gnu dot org 2010-06-13 12:46 --- I don't care as long as there is a testcase that tests for this bug. Bugs shouldn't be closed if a testcase has not been committed that prevents regressing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16630
[Bug c++/44516] New: unclear error message for invalid operands to binary operator
Testcase:
namespace services {
struct WebService { };
}
namespace myapp {
namespace servers {
struct Server { };
}
}
using namespace myapp;
void addHTTPService(servers::Server const server, ::services::WebService const
*http) {
server += http;
}
gcc-4.6:
clang-4.C:12:13: error: no match for operator+= in server += http
Note that the column number points to http.
clang:
t.cpp:9:10: error: invalid operands to binary expression ('servers::Server
const' and '::services::WebService const *')
server += http;
~~ ^
--
Summary: unclear error message for invalid operands to binary
operator
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44516
[Bug c/44517] New: improve diagnostic for mispelled typename in function declaration
Testcase:
int foo(int x, pid_t y) {
return x+y;
}
gcc-4.6:
clang-5.c:1:16: error: expected declaration specifiers or ... before pid_t
foo
clang-5.c: In function foo:
clang-5.c:2:12: error: y undeclared (first use in this function)
clang-5.c:2:12: note: each undeclared identifier is reported only once for each
function it appears in
clang:
t.c:1:16: error: unknown type name 'pid_t'
int foo(int x, pid_t y) {
^
--
Summary: improve diagnostic for mispelled typename in function
declaration
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44517
[Bug c/44519] New: improve message for missing ; after struct
Testcase:
struct foo { int x; }
typedef int bar;
gcc-4.6:
clang-6.c:3:9: error: two or more data types in declaration specifiers
Notice the line and the column are far away from the problem.
clang:
t.c:1:22: error: expected ';' after struct
struct foo { int x; }
^
;
--
Summary: improve message for missing ; after struct
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44519
[Bug c++/44520] New: improve diagnostic for ambiguous lookup
Testcase:
struct B1 { void f(); };
struct B2 { void f(double); };
struct I1 : B1 { };
struct I2 : B1 { };
struct D: I1, I2, B2 {
using B1::f; using B2::f;
void g() {
f();
}
};
gcc-4.6:
clang-7.C:10:7: error: B1 is an ambiguous base of D
clang:
t.cc:10:5: error: ambiguous conversion from derived class 'D' to base class
'B1':
struct D - struct I1 - struct B1
struct D - struct I2 - struct B1
f();
^
Clang prints the hierarchy, which is something that g++ doesn't support (I
think).
--
Summary: improve diagnostic for ambiguous lookup
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44520
[Bug c++/44521] New: unhelpful candidates for ambiguous lookup
Testcase:
struct B1 { void f(); };
struct B2 { void f(double); };
struct I1 : B1 { };
struct I2 : B1 { };
struct D: I1, I2, B2 {
void g() {
f();
}
};
gcc-4.6:
clang-8.C:9:5: error: reference to f is ambiguous
clang-8.C:2:18: error: candidates are: void B2::f(double)
clang-8.C:1:18: error: void B1::f()
clang-8.C:1:18: error: void B1::f()
B1 is printed twice and there is no clear info about the hierarchy.
clang:
t.cc:10:5: error: non-static member 'f' found in multiple base-class subobjects
of type 'B1':
struct D - struct I1 - struct B1
struct D - struct I2 - struct B1
f();
^
t.cc:1:18: note: member found by ambiguous name lookup
struct B1 { void f(); };
^
--
Summary: unhelpful candidates for ambiguous lookup
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44521
[Bug c/44511] Misdetects missing return with non-void return type, but only if the function is static
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-13 13:49 --- (In reply to comment #1) instead. So the warning you see is really warning about no return statement, not about control reaching the end of a non-void function. And it does so by design just for functions with static linkage. So I'd say the warning is not false, it is just not useful for the case where the function does not return at all. Leaving the bug as enhancement request instead of closing as wontfix/invalid. I don't see how one can detect that the function does not return from the FE, so I don't think this is possible to implement without moving the warning to the middle-end. Perhaps we should not care about unused static functions and remove this warning altogether. What happens if the static function actually returns and is used? Do you get 2 warnings? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44511
[Bug c++/44522] New: improve diagnostic for :: vs : typo
Testcase:
namespace x {
struct a { };
}
x:a a2;
x::a a3 = a2;
gcc-4.6:
clang-9.C:5:1: error: x does not name a type
clang-9.C:6:11: error: a2 was not declared in this scope
clang:
t.cc:5:2: error: unexpected ':' in nested name specifier
x:a a2;
^
::
In addition to getting the error message right (and suggesting a fixit
replacement to ::), Clang knows what you mean so it handles the subsequent
uses of a2 correctly. GCC, in contrast, gets confused about what the error is
which leads it to emit bogus errors on every use of a2.
--
Summary: improve diagnostic for :: vs : typo
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44522
[Bug c++/44523] New: improve diagnostic for :: vs : typo (complex case)
Testcase:
namespace x {
struct a { };
}
template typename t
class foo {
};
foox::a a1;
foox:a a2;
x::a a3 = a2;
gcc-4.6:
clang-10.C:10:8: error: template argument 1 is invalid
clang-10.C:10:12: error: invalid type in declaration before ; token
clang-10.C:12:11: error: conversion from int to non-scalar type x::a
requested
clang:
t2.cc:10:6: error: unexpected ':' in nested name specifier
foox:a a2;
^
::
t2.cc:12:6: error: no viable conversion from 'foox::a' to 'x::a'
x::a a3 = a2;
^~~
t2.cc:2:10: note: candidate constructor (the implicit copy constructor) not
viable: no known conversion from 'foox::a' to 'x::a const' for 1st argument
struct a { };
^
--
Summary: improve diagnostic for :: vs : typo (complex case)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44523
[Bug c++/44524] New: improve diagnostic for . vs - typo
Testcase:
#include map
int bar(std::mapint, float *X) {
return X.empty();
}
gcc-4.6:
/home/manuel/test/src/gcc/testsuite/g++.dg/warn/clang-11.C: In function 'int
bar(std::mapint, float*)':^M
/home/manuel/test/src/gcc/testsuite/g++.dg/warn/clang-11.C:4:12: error: request
for member 'empty' in 'X', which is of non-class type 'std::mapint, float*'
clang:
t.cc:4:11: error: member reference type 'std::mapint, float *' is a pointer;
maybe you meant to use '-'?
return X.empty();
~^
-
In GCC, we would need to mention X and empty somewhere in addition to the type.
I would suggest:
error: request for member 'empty' in 'X', which has pointer type 'std::mapint,
float *' ; maybe you meant to use '-'
--
Summary: improve diagnostic for . vs - typo
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44524
[Bug c/44527] New: improve diagnostics in inline assembly
Testcase:
int foo(int X) {
__asm__ (frob%0 : +r (X));
return X;
}
gcc-4.6:
/var/folders/51/51Qw875vFdGa9KojoIi7Zk+++TM/-Tmp-//ccyXfgfZ.s:11:no such
instruction: `frob %eax'
clang:
inline asm:1:2: error: unrecognized instruction
frob%eax
^
t.c:2:11: note: generated from here
__asm__ (frob%0 : +r (X));
^
1 error generated.
--
Summary: improve diagnostics in inline assembly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44527
[Bug inline-asm/44527] improve diagnostics in inline assembly
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-13 16:59 --- The column information is wrong. The diagnostic markers are inconsistent (Error versus error). This depends on the gnu assembler, which is not the default in many places. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44527
[Bug inline-asm/44527] improve diagnostics in inline assembly
--- Comment #6 from manu at gcc dot gnu dot org 2010-06-13 17:30 --- This column information: t.c:2:11: note: generated from here __asm__ (frob%0 : +r (X)); ^ I am not going to get into a reopen war with you anyway. I am just trying to make a list of the diagnostic issues where LLVM claims superiority to GCC. There are a lot, so I guess one more or less doesn't make much difference. http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44527
