[Bug c/9072] -Wconversion should be split into two distinct flags
--- Comment #14 from lopezibanez at gmail dot com 2006-07-05 11:15 --- Created an attachment (id=11826) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11826&action=view) split current functionality of Wconversion in two different options This patch divides the functionality of Wconversion into two additional warning options Wtradtional-conversion and Wcoercion as part of the Wcoercion project ( http://gcc.gnu.org/wiki/Wcoercion#Background ). These are added for the sake of clarity (in order to distinguish them from the current Wconversion) and during the development phase and they are not meant to be the final form that the options will take. Bootstrapped and tested in i686-pc-linux-gnu for trunk revision 115112. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072
[Bug c/9072] -Wconversion should be split into two distinct flags
--- Comment #15 from lopezibanez at gmail dot com 2006-07-05 11:18 --- Created an attachment (id=11827) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11827&action=view) Adds a new function which detects when a real value can be exactly represented as an integer. Patch 2of3 http://gcc.gnu.org/wiki/Wcoercion#Background Adds a new function which detects when a real value can be exactly represented as an integer. This function is needed for the next patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072
[Bug c/9072] -Wconversion should be split into two distinct flags
--- Comment #16 from lopezibanez at gmail dot com 2006-07-05 11:22 --- Created an attachment (id=11828) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11828&action=view) detect implicit conversions where a value may change patch 3of3 http://gcc.gnu.org/wiki/Wcoercion#Background Detect implicit conversions where a value may change by narrowing, loss of precision or change of sign when passing arguments and in assignments. It includes testcases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072
[Bug c/6614] [-Wconversion] incorrect conversion warning for function taking a short
--- Comment #8 from lopezibanez at gmail dot com 2006-07-05 11:34 --- I think we may close this bug report since either: * The solution is to split the functionality of Wconversion as conceived by the Wcoercion project http://gcc.gnu.org/wiki/Wcoercion#Background. In that case, this is a duplicate of bug 9072. * The message is misleading. Maybe it should say: passing arg 1 of 'func' as short instead of 'int' due to prototype. If you agree, I can generate a patch in no time. * This is not a bug. As said in comment 5, Wconversion is meant to warn about conversions that would be different in the absence of prototypes. So we may just close the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6614
[Bug c++/13932] [3.3 regression] duplicate warning message for conversion
--- Comment #8 from lopezibanez at gmail dot com 2006-07-08 13:22 ---
Would not the following testcase be better?
int i=1.;
int j=1.1; // { dg-warning "" }
I can currently handle this testcase in C front end with the code from the
Wcoercion project. I am working in a patch for g++.
What do you think? Should I reopen this or a new bug report or just send it to
gcc-patches?
--
lopezibanez at gmail dot com changed:
What|Removed |Added
CC| |lopezibanez at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13932
[Bug c++/12242] g++ should warn about out-of-range int->enum conversions
--- Comment #7 from lopezibanez at gmail dot com 2006-07-08 18:33 --- (In reply to comment #6) > Working on a patch. > Hi Gabriel, what is your patch going to do? Is it going to emit a warning? Would it be appropriate to emit the same warning for the C front end? -- lopezibanez at gmail dot com changed: What|Removed |Added CC| |lopezibanez at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12242
[Bug c++/28261] [4.0/4.1/4.2 regression] ICE with enum in constructor definition
--- Comment #1 from lopezibanez at gmail dot com 2006-08-12 20:40 --- I can confirm this in trunk rev 115951 on i686-pc-gnu-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28261
[Bug c/2707] gcc does not warn on truncate
--- Comment #6 from lopezibanez at gmail dot com 2006-09-16 00:31 --- By using the patches of the Wcoercion project [*] and compiling with -Wcoercion, gcc reports for the testcase mentioned in the description: pr2707.c: In function 'main': pr2707.c:8: warning: coercion to 'short unsigned int' from 'long unsigned int' may alter its value So I guess this bug can be closed as soon as Wcoercion is integrated into mainline. [*] http://gcc.gnu.org/wiki/Wcoercion -- lopezibanez at gmail dot com changed: What|Removed |Added CC| |lopezibanez at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2707
[Bug c++/26167] -Wconversion fails to detect signedness conversion from int to unsigned int in fuction call
--- Comment #6 from lopezibanez at gmail dot com 2006-09-16 01:08 --- In which way gcc reports the problem correctly? What gcc currently reports is that if the prototype were missing the value would be passed as a signed int. It is not warning you about the conversion, it warns you about the effect of having a prototype. If you mean that gcc (and g++) should warn that a signed variable is passed to a function that expects an unsigned variable, then when using the -Wcoercion flag (provided by the Wcoercion project [*]), both cc1 and cc1plus report: pr26167.cpp:10: warning: coercion to 'unsigned int' from 'int' may alter its value [*] http://gcc.gnu.org/wiki/Wcoercion -- lopezibanez at gmail dot com changed: What|Removed |Added CC| |lopezibanez at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167
[Bug c++/26298] -Wconversion fails to detect signedness change during widening conversion
--- Comment #2 from lopezibanez at gmail dot com 2006-09-16 01:38 ---
Richard, could you tell which bug report do you mean?
The -Wconversion warnings does not apply to this case. Wconversion warns about
the effect of adding a prototype, not about sign conversions.
Anyway, I still don't understand where is the bug. Unary minus applied to
unsigned (what typically is the type of sizeof()) gives:
" `2^n - i', where `n' is the number of bits in the
unsigned type." [1]
So actually -sizeof(int) is 4294967292 (assuming sizeof(int) is 4). This number
fits well in a signed long long. However, it doesn't fit in a signed int, and
thus, it wraps around and produces -4.
The -Wcoercion flag provided by the Wcoercion project [2] warns for the
wrap-around as:
pr26298.c:15: warning: coercion as 'int' alters 'unsigned int' constant value
[1] http://gcc.gnu.org/ml/gcc/1999-06n/msg00754.html
[2] http://gcc.gnu.org/wiki/Wcoercion
--
lopezibanez at gmail dot com changed:
What|Removed |Added
CC| |lopezibanez at gmail dot
||com, rguenth at gcc dot gnu
||dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26298
[Bug c++/26698] g++ accepts const-incorrect code due to conversion function
--- Comment #3 from lopezibanez at gmail dot com 2006-09-16 01:48 --- When using -Wconverson: pr26698.cpp:24: warning: conversion to a reference to the same type will never use a type conversion operator Maybe this warning should be reported always? -- lopezibanez at gmail dot com changed: What|Removed |Added CC||lopezibanez at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26698
[Bug c++/26298] -Wconversion fails to detect signedness change during widening conversion
--- Comment #4 from lopezibanez at gmail dot com 2006-09-16 19:45 --- Richard, and what is your opinion about the rest of my comment? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26298
[Bug c++/26698] g++ accepts const-incorrect code due to conversion function
--- Comment #4 from lopezibanez at gmail dot com 2006-09-16 21:14 --- The change was made on revision 110567 on gcc/cp/decl.c @@ -9012,7 +9011,7 @@ } if (what) - warning (0, "conversion to %s%s will never use a type " + warning (OPT_Wconversion, "conversion to %s%s will never use a type " "conversion operator", ref ? "a reference to " : "", what); } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26698
[Bug c++/26698] g++ accepts const-incorrect code due to conversion function
--- Comment #5 from lopezibanez at gmail dot com 2006-09-16 21:34 ---
Actually, it seems that the conditional on Wconversion was added before, at
revision 100541 by mmitchel (Notice the warn_conversion flag below).
@@ -8755,32 +8755,38 @@
if (operator_code == CALL_EXPR)
return;
- if (IDENTIFIER_TYPENAME_P (name) && ! DECL_TEMPLATE_INFO (decl))
+ /* Warn about conversion operators that will never be used. */
+ if (IDENTIFIER_TYPENAME_P (name)
+ && ! DECL_TEMPLATE_INFO (decl)
+ && warn_conversion
+ /* Warn only declaring the function; there is no need to
+warn again about out-of-class definitions. */
+ && class_type == current_class_type)
{
tree t = TREE_TYPE (name);
- if (! friendp)
- {
- int ref = (TREE_CODE (t) == REFERENCE_TYPE);
- const char *what = 0;
+ int ref = (TREE_CODE (t) == REFERENCE_TYPE);
+ const char *what = 0;
- if (ref)
- t = TYPE_MAIN_VARIANT (TREE_TYPE (t));
+ if (ref)
+ t = TYPE_MAIN_VARIANT (TREE_TYPE (t));
- if (TREE_CODE (t) == VOID_TYPE)
- what = "void";
- else if (t == current_class_type)
+ if (TREE_CODE (t) == VOID_TYPE)
+ what = "void";
+ else if (class_type)
+ {
+ if (t == class_type)
what = "the same type";
/* Don't force t to be complete here. */
else if (IS_AGGR_TYPE (t)
&& COMPLETE_TYPE_P (t)
- && DERIVED_FROM_P (t, current_class_type))
+ && DERIVED_FROM_P (t, class_type))
what = "a base class";
+ }
- if (what && warn_conversion)
- warning (0, "conversion to %s%s will never use a type "
- "conversion operator",
-ref ? "a reference to " : "", what);
- }
+ if (what)
+ warning (0, "conversion to %s%s will never use a type "
+"conversion operator",
+ref ? "a reference to " : "", what);
}
if (operator_code == COND_EXPR)
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26698
[Bug c++/26167] -Wconversion fails to detect signedness conversion from int to unsigned int in fuction call
--- Comment #10 from lopezibanez at gmail dot com 2006-09-18 08:16 --- Yes, I hope to get it into 4.3. Nonetheless, if you wish to test it, I can add the patch here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167
[Bug c++/26167] -Wconversion fails to detect signedness conversion from int to unsigned int in fuction call
--- Comment #12 from lopezibanez at gmail dot com 2006-09-18 12:22 --- Created an attachment (id=12291) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12291&action=view) wcoercion patch r116922 Patch for trunk revision 116922 (bootstrapped and tested on i686-pc-linux-gnu). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167
[Bug c++/26167] -Wconversion fails to detect signedness conversion from int to unsigned int in fuction call
--- Comment #13 from lopezibanez at gmail dot com 2006-09-18 12:45 --- (In reply to comment #11) > yes please. Actually I created my own patch for bringing the C++ frontend on > ear with the C frontend, but I didn't submit it because it produced bazillions > of (legal) warnings in the code I usually compile, too many to be useful. > I would like to take a look to your patch if that is possible. A few things worth commenting on the wcoercion patch: 1) One of the development goals is to separate the original behaviour of Wconversion in the C front end from the "other behaviour" of Wconversion (slightly present on the C front end and pervasive in the C++ front end). Therefore, Wconversion has been replaced by Wtraditional-conversion and Wcoercion (the interesting one). The names are tentative, pending discussion by GCC developers, and likely will change in the future. If you find all this confusing, please read http://gcc.gnu.org/wiki/Wcoercion#Background. If you work in the KDE project, it would be interesting (for me) to know your opinion on how to handle the transition. 2) Wconversion option is not completely deleted by my patch, it still exists for C++/Fortran/ObjC++ when the behaviour has not been modified and it didn't conflict with Wtraditional-conversion or Wcoercion. Properly speaking, these Wconversion warnings should be moved to Wcoercion. However, there is little point on doing this until there is a definitive decision on the names of the new options. Thus, to obtain the full set of coercion warnings in C++ you may need to specify "-Wconversion -Wcoercion" (In short, Wconversion are the ones that were already there undocumented, Wcoercion are new or modified). 3) There are a few issuess pending the review of GCC developers. For example, warning messages could be more specific/informative. 4) I don't think we should pollute this bug report further. Thus, feel free to write me directly. Much better would be to discuss things in public in the gcc mail list: we may even get the attention of some GCC developer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167
[Bug target/28405] 4.x code generation regression relative to 3.4.6
--- Comment #2 from lopezibanez at gmail dot com 2006-09-20 22:04 --- I can confirm this in a recent build of GCC: (GNU) 4.2.0 20060913 (experimental) on i686-pc-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28405
[Bug tree-optimization/29254] [4.2 Regression] verify_cgraph_node failed (inlined_to pointer is set but no predecessors found)
--- Comment #2 from lopezibanez at gmail dot com 2006-09-27 21:31 ---
Is this testcase better?
list_compare (int * list1)
{
if (list1)
value_compare ();
}
func1 (int * f){}
value_compare (int * a)
{
if (a)
list_compare (a);
}
func2 (const int * fb)
{
func1 ((int *) fb);
}
--
I was unable to reproduce the problem removing any of the 'if'. Also, I was
unable to reproduce the ICE without generating the warning about qualifiers.
Weird.
--
lopezibanez at gmail dot com changed:
What|Removed |Added
CC| |lopezibanez at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29254
[Bug tree-optimization/29254] [4.2 Regression] verify_cgraph_node failed (inlined_to pointer is set but no predecessors found)
--- Comment #4 from lopezibanez at gmail dot com 2006-09-29 00:37 --- Not so surprising if you check gcc/c-typeck.c line 3980. The warning is not conditionalised to any option. What is the criteria for a warning to be emitted always or be conditional to a given option? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29254
[Bug tree-optimization/29254] [4.2 Regression] verify_cgraph_node failed (inlined_to pointer is set but no predecessors found)
--- Comment #5 from lopezibanez at gmail dot com 2006-09-29 00:53 --- (In reply to comment #4) > Not so surprising if you check gcc/c-typeck.c line 3980. The warning is not > conditionalised to any option. What is the criteria for a warning to be > emitted > always or be conditional to a given option? > Argh! I meant line 4100 (although perhaps it is the same warning, not sure). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29254
[Bug middle-end/18071] [4.0/4.1/4.2 Regression] -Winline does not respect -fno-default-inline
--- Comment #23 from lopezibanez at gmail dot com 2006-09-30 12:36 --- I think I found out what is going on, although I cannot decide myself what is the correct action. For functions declared within class scope we do: (gcc/cp/decl.c start_method() line 11285) DECL_DECLARED_INLINE_P (fndecl) = 1; if (flag_default_inline) DECL_INLINE (fndecl) = 1; Winline tests DECL_DECLARED_INLINE (which is correct). However, as shown above, fno-default-inline does not change the DECL_DECLARED_INLINE but DECL_INLINE. Solutions: 1) Nothing, things are correct as they are. 2) When we are going to emit the warning, we check for fno-default-inline and check that the function is declared within class scope. I have no idea how to do this or whether it is appropriate. 3) fno-default-inline sets both DECL_DECLARED_INLINE and DECL_INLINE to false. It may break other things and the text of fno-default-inline says that these functions will have linkage like inline functions. 4) Something else. -- lopezibanez at gmail dot com changed: What|Removed |Added CC||lopezibanez at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug middle-end/18071] [4.0/4.1/4.2 Regression] -Winline does not respect -fno-default-inline
--- Comment #26 from lopezibanez at gmail dot com 2006-10-02 21:03 --- (In reply to comment #25) > If you look at Comment #19, you will see that I have already provided a > solution. However, I see that I failed to add the patch I wrote to the > bug report. I will do that now. My work on this patch was interrupted > by health problems, and I haven't gotten back to it yet. It is still > part of my large backlog. And if you look at comment #18, you will see that Mark Mitchell has already stated the Winline is suppossed to warn "about functions *declared* inline, but not actually inlined. [...] DECL_INLINE is an internal note to the compiler that it might make sense to inline that function." Your patch will break Winline output for any function that is declared inline ( DECL_DECLARED_INLINE_P (fndecl) = 1;) but it is marked as not making sense to be inlined by the compiler (DECL_INLINE (fndecl) = 0;). From a quick grep, there seems to be a few places where this may occur. Of course, you know more about gcc than me. I was just trying to point out this potential issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug tree-optimization/29254] [4.2 Regression] verify_cgraph_node failed (inlined_to pointer is set but no predecessors found)
--- Comment #6 from lopezibanez at gmail dot com 2006-10-04 20:21 --- Don't know whether it is relevant, but no ICE occurs if Werror is not used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29254
[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new
--- Comment #17 from lopezibanez at gmail dot com 2008-08-28 14:56 --- Subject: Re: [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new 2008/8/28 dodji at gcc dot gnu dot org <[EMAIL PROTECTED]>: > Log: > 2008-08-28 Dodji Seketeli <[EMAIL PROTECTED]> > >PR c++/36741 >* tree.c (int_fits_type_p): Don't forget unsigned integers > of type sizetype which higher end word equals -1. > > > Added: >trunk/gcc/testsuite/g++.dg/other/new-size-type.C You forgot to mention this file in the commit log. Please rectify the log. Thanks Manuel. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #36 from Manuel López-Ibáñez --- If the patch is in, it should be ok. Or ask in gcc-patches for someone to commit on your behalf. Gerald is very helpful. Just make sure the subject of the email is very clear. On Fri, 1 May 2020, 16:12 lhyatt at gmail dot com, wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 > > --- Comment #35 from Lewis Hyatt --- > (In reply to Lewis Hyatt from comment #34) > > (In reply to Eric Gallager from comment #33) > > > This is a big enough feature that it should probably get an entry in > > > gcc-10/changes.html > > > > I emailed a suggested patch to that effect here: > > https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01667.html. I can commit > if it > > looks OK. Thanks! > > With GCC 10 release imminent, would anyone be able to confirm it's OK to > push > this to changes.html please? Thanks so much. > https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544343.html > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug middle-end/4210] should not warn in dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210 --- Comment #39 from Manuel López-Ibáñez --- I think these questions are more appropriate for the mailing list, since few people are subscribed to this bug. You can easily find which pass does something by dumping (-ftree-dump-*) all of them and comparing them. On Wed, 6 May 2020, 09:11 nisse at lysator dot liu.se, < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210 > > --- Comment #38 from Niels Möller --- > Just a brief update. > > 1. Tried adding fprintf warnings to c_gimplify_expr (btw, what's the right > way > to display a pretty warning with line numbers etc in later passes?). But it > seems that's too early, I still get warnings for dead code. > > 2. The pass_remove_useless_stmts, mentioned in the docs, was deleted in > 2009 > (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41573), and I take it > it was > obsoleted earlier, since there's no mention of a replacement. So what pass > should I look at that is related to basic control flow analysis, and > discarding > unreachable statements? > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #26 from Manuel López-Ibáñez --- Hi Martin, Wouldn't it be better if the testcase tested that no warning is given for a true case? Otherwise if the bug is fixed, no warning will be given, no matter the option. Or have a testcase that the warning is given with the option and not without . On Fri, 8 Nov 2019, 12:42 jamborm at gcc dot gnu.org, < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 > > --- Comment #25 from Martin Jambor --- > I have posted an RFC patch alleviating the situation somewhat to the > mailing > list: > > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00614.html > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808 --- Comment #41 from Manuel López-Ibáñez --- All these cases can be handled perfectly by the FE and there's a patch above. Why complicate it by expecting the ME to understand C++ mem-initializer semantics?
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134 --- Comment #7 from Manuel López-Ibáñez --- What I'm suggesting is to add an option to control this warning, which is currently enabled by default. Then you can use -Wno-error or even -Wno- to make it always a warning or completely disable it. This what clang does.
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134 --- Comment #9 from Manuel López-Ibáñez --- That makes sense as well. Adding further logic to silence the warning or to make the warning not become an error is what I think is a bad idea. I like also your more explicit wording.
[Bug c++/68301] self-dependent reference member initialization not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68301 --- Comment #4 from Manuel López-Ibáñez --- This is a duplicate of bug 19808. There's a patch there that I believe needs just a little more work.
[Bug c++/43167] Warnings should not be disabled when instantiating templates defined in system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167 --- Comment #19 from Manuel López-Ibáñez --- I think the solution is to have more locations. If the diagnostic code knew where the user value came from then it will know to not suppress the diagnostic. I wonder what happens if you used something that actually has a location, like an expression, for the first test case using emplace(). On Fri, 22 Mar 2019, 15:33 redi at gcc dot gnu.org, < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167 > > --- Comment #18 from Jonathan Wakely --- > From Matthias Kretz on IRC: > > GCC needs to make a difference between warnings that apply when reading the > system headers and warnings that only manifest on a template instantiation > or > constprop > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/80472] cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472 --- Comment #5 from Manuel López-Ibáñez --- This warning will be incomprehensible to users because the warning never mentions any code that the user can modify. What should the user do according to the warning?
[Bug c++/80472] cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472 --- Comment #8 from Manuel López-Ibáñez --- There is no negative n__ in user code. On Fri, 22 Mar 2019, 21:21 redi at gcc dot gnu.org, < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472 > > --- Comment #7 from Jonathan Wakely --- > A comment added to the code would make the caret diagnostic > self-explanatory: > > --- a/libstdc++-v3/include/bits/stl_iterator_base_funcs.h > +++ b/libstdc++-v3/include/bits/stl_iterator_base_funcs.h > @@ -149,7 +149,7 @@ _GLIBCXX_END_NAMESPACE_CONTAINER >// concept requirements >__glibcxx_function_requires(_InputIteratorConcept<_InputIterator>) >__glibcxx_assert(__n >= 0); > - while (__n--) > + while (__n--) // if n is negative this has undefined behaviour > ++__i; > } > > That would make the diagnostic look like: > > /home/jwakely/gcc/9/include/c++/9.0.1/bits/stl_iterator_base_funcs.h:152:7: > warning: iteration 9223372036854775807 invokes undefined behavior > [-Waggressive-loop-optimizations] > 152 | while (__n--) // if n is negative this has undefined > behaviour > | > > > It's still a bug that there's no "In instantiation of ... required from ... > required from here" context shown though. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/80472] cannot use push/pop with #pragma GCC diagnostic warning "-Wsystem-headers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472 --- Comment #11 from Manuel López-Ibáñez --- I'm not being pedantic for the sake of being pedantic. It is trivial to fix the #pragma as I explained above. However, that won't give the user any idea about which user code is triggering the warning. For that, we need to have at the point of warning a token that comes from user code or we need to propagate a user location to the tokens that made up this particular instantation of the template, so that the diagnostic code can windup the location stack and find the user code that triggered the warning. On Fri, 22 Mar 2019, 22:18 redi at gcc dot gnu.org, < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472 > > --- Comment #10 from Jonathan Wakely --- > (In reply to Manuel López-Ibáñez from comment #8) > > There is no negative n__ in user code. > > If you want to be pedantic, there's no __n at all in user code. Because > it's a > function parameter of std::advance. But clearly if the compiler says > "undefined > behaviour detected at this line" and the line has a comment saying > "undefined > if n is negative" then the user can figure out that the function got called > with negative n. > > Is that perfect? No. Is it better than printing nothing when UB is > detected? To > me the answer is obviously yes, so it seems like you're just objecting to > making improvements. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62181 --- Comment #18 from Manuel López-Ibáñez --- A large patch will often get lost in comments and revisions unless the submitter is very insistent and committed. If you want to get this moving, my advice would be to split out the smallest piece possible (string + char literal) and just submit that for review. Once that is committed, then look for the next smallest step and repeat.
[Bug tree-optimization/70392] [openacc] inconsistent line numbers in uninitialised warnings for if clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70392 --- Comment #3 from Manuel López-Ibáñez --- Look at the dumps. Probably the C++ FE or the optimisers do not create an expression with a valid location for bool. It is not an issue with Wuninitialized. On Sat, 30 Mar 2019, 02:50 egallager at gcc dot gnu.org, < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70392 > > Eric Gallager changed: > >What|Removed |Added > > > CC||dmalcolm at gcc dot > gnu.org, >||dodji at gcc dot gnu.org, >||manu at gcc dot gnu.org > > --- Comment #2 from Eric Gallager --- > cc-ing diagnostics maintainers, and Manu since it's an issue with > -Wuninitialized > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/43064] improve location and text of diagnostics in constructor initializer lists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43064 --- Comment #6 from Manuel López-Ibáñez --- If I remember correctly, the problem here is constants and other non-expression nodes don't have a location, so diagnostics use input_location, which points to the end of the initializer. Something like X+1 should work. If so, David started fixing this problem, but this code may need fixes similar to these: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00660.html Otherwise, the problem is more insidious, and the nodes are probably built with the wrong location.
[Bug c/55976] -Werror=return-type should error on returning a value from a void function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55976 --- Comment #7 from Manuel López-Ibáñez --- My advice would be to create a new option Wreturn-pedantic. Make this option control the pedwarns that don't have any option. Then, enable it by default, but also make it be enabled by Wpedantic and Wreturn-type. An alternative would be to have the default setting of Wreturn-type depend on flag_isoc99. Then, add OPT_Wreturn_type to all those pedwarns. On Thu, 15 Mar 2018, 16:12 dave.pagan at oracle dot com, < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55976 > > --- Comment #6 from Dave Pagan --- > Helpful update, Jonathan - did you want to follow up on this bug then? Or > should I go ahead based on your new information? > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug other/44210] Extended warning control: like -Wevery -show-warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44210 --- Comment #8 from Manuel López-Ibáñez --- EnabledBy is already implemented. Also, -Wall --help=warnings shows which warnings are enabled by -Wall. The only remaining thing is to generate parts of invoke.texi directly from the .opt file.
[Bug c++/70647] Feature request: warning for self-moving in constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70647
--- Comment #3 from Manuel López-Ibáñez ---
> --- Comment #2 from Matt Godbolt ---
> Thanks Manuel. Interestingly this does elicit a warning:
>
> struct B {
> int a; int b;
> B(B &&o)
> : a(static_cast(a)),
> b(std::move(o.b)) {}
> };
Most probable, the FE removes the cast before reaching this warning, so the
warning does not see an expression. If you cast to something non trivial,
it remains an expression and the warning doesn't try to look inside it.
I wonder what happens if you do a(b), a(a). Does it still warn? My guess
would be yes. If so, it is just checking for equality on both sides, no
attempt to look within expressions nor track initialisation.
[Bug c++/71402] -Wunused-variable warnings ignore initialization side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71402 --- Comment #11 from Manuel López-Ibáñez --- 5.3 has the bug I mentioned above. It makes the pragmas believe that, for this warning, the location is at the end of the file, which is after the pop. Perhaps you can trick gcc by placing another pragma ignored at the end of the file. But that will silence all warnings that suffer from this bug.
[Bug c++/60517] warning/error for taking address of member of a temporary object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517 --- Comment #22 from Manuel López-Ibáñez --- I honestly think the uninitialized warning and fixing TREE_NOWARNING is a red-herring. My testcase should get a warning even if .x[0] is initialized. The problem is taking the address of a temporary. That should be detected way before SRA happens. No control flow needed, only scope info. On 24 Jul 2017 6:07 pm, "fredrik.hederstie...@securitas-direct.com" < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517 > > --- Comment #21 from Fredrik Hederstierna securitas-direct.com> --- > Started with fix for PR 43347 to not warn on artificial aggregates > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43347 > > -- > You are receiving this mail because: > You reported the bug.
[Bug c++/60517] warning/error for taking address of member of a temporary object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517 --- Comment #24 from Manuel López-Ibáñez --- How does typeck.c check that it is a temporary? The important thing is not that it is an ARRAY_REF but that it is a member of a temporary object. Not sure how to check that. Marc points above that the FE introduces a clobber to mark the death of the temporary, so it knows. The problem of warning for artificials is that optimization passes create and read uninitialized memory if this provides an advantage and it doesn't change the behaviour of the code. Warning about those would be very annoying, if the user code is correct.
[Bug fortran/79886] [5/6/7 Regression] ICE in pp_format, at pretty-print.c:681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79886 --- Comment #1 from Manuel López-Ibáñez --- This is probably a warning from the middle end with a printf %-code not supported by the Fortran FE's pretty printer. The solution is to either add support for it in the FE or switch to the middle end pp when entering the middle end. There are several bugs like this one. Another solution is to either not call into the middle end at arbitrary points during parsing only during gimplification (not sure if this is the case here) or move the warning to the FE (middle end warnings should be avoided if possible). On 6 Mar 2017 8:04 a.m., "marxin at gcc dot gnu.org" < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79886 > > Bug ID: 79886 >Summary: [5/6/7 Regression] ICE in pp_format, at > pretty-print.c:681 >Product: gcc >Version: 7.0 > Status: UNCONFIRMED > Keywords: ice-on-valid-code > Severity: normal > Priority: P3 > Component: fortran > Assignee: unassigned at gcc dot gnu.org > Reporter: marxin at gcc dot gnu.org > CC: manu at gcc dot gnu.org > Target Milestone: --- > > Starting from r217383 we ICE: > > $ gfortran > /home/marxin/Programming/gcc/gcc/testsuite/gfortran. > fortran-torture/compile/pr26806.f90 > -Wpadded > f951: Warning: padding struct size to alignment boundary [-Wpadded] > f951: Warning: padding struct size to alignment boundary [-Wpadded] > ‘ > in pp_format, at pretty-print.c:681 > 0x1478169 pp_format(pretty_printer*, text_info*) > ../../gcc/pretty-print.c:681 > 0x146a9f8 diagnostic_report_diagnostic(diagnostic_context*, > diagnostic_info*) > ../../gcc/diagnostic.c:961 > 0x146ad53 diagnostic_impl > ../../gcc/diagnostic.c:1084 > 0x146b0cc warning(int, char const*, ...) > ../../gcc/diagnostic.c:1172 > 0xc5a315 place_field(record_layout_info_s*, tree_node*) > ../../gcc/stor-layout.c:1215 > 0xc5bafa layout_type(tree_node*) > ../../gcc/stor-layout.c:2375 > 0x7d4a66 gfc_finish_type(tree_node*) > ../../gcc/fortran/trans-types.c:2251 > 0x7acb43 gfc_build_st_parameter > ../../gcc/fortran/trans-io.c:222 > 0x7acb43 gfc_build_io_library_fndecls() > ../../gcc/fortran/trans-io.c:318 > 0x765c17 gfc_build_builtin_function_decls() > ../../gcc/fortran/trans-decl.c:3771 > 0x73b71a gfc_create_decls > ../../gcc/fortran/f95-lang.c:189 > 0x73b71a gfc_be_parse_file > ../../gcc/fortran/f95-lang.c:203 > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/79886] [5/6/7 Regression] ICE in pp_format, at pretty-print.c:681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79886 --- Comment #3 from Manuel López-Ibáñez --- Perhaps Fortran FE formatters can call the standard formatters if an unknown directive is found? I don't know how C/C++ handles this case (does it support this %-directive or does it switch to the standard pretty printer?) but there is no reason to not do the same and share the code if possible.
[Bug fortran/79886] [5/6/7 Regression] ICE in pp_format, at pretty-print.c:681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79886 --- Comment #5 from Manuel López-Ibáñez --- The first one seems the right approach. It will also fix a number of similar bugs in one go.The second one seems more fragile and it doesn't help in decoupling ME from FE more than the first.
[Bug fortran/79859] diagnostics: argument quoted twice in "No initializer for allocatable compoonent"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79859 --- Comment #4 from Manuel López-Ibáñez --- When the original is changed, the translated strings will need to be redone. Thus, it is always better to change the original first. This change counts as obvious, you don't need approval or copyright assignment. On 20 Mar 2017 8:43 a.m., "fmarchal at perso dot be" < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79859 > > --- Comment #3 from Frederic Marchal --- > My mistake, I simply removed the superfluous single quotes in the > translated > message. Problem solved with the translation. > > The original message is still doubly quoted in English though. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/9335] repeated diagnostic when maximum template depth is exceeded
--- Comment #15 from lopezibanez at gmail dot com 2010-04-14 10:09 --- Subject: Re: repeated diagnostic when maximum template depth is exceeded When that happens? I am sorry but your answer does not help me to find how to fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9335
[Bug testsuite/30612] Testsuite cannot detect duplicated error/warning messages
--- Comment #4 from lopezibanez at gmail dot com 2010-04-19 17:42 ---
Subject: Re: Testsuite cannot detect duplicated
error/warning messages
>
> is there another way?
In this case, I think this will work:
/* { dg-bogus "foo bar" } */ /* { dg-warning "foo" } */
no?
Cheers,
Manuel.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30612
[Bug c++/44800] DECL_SAVED_TREE is always null on the first FUNCTION_DECL and is not null on the others
--- Comment #9 from lopezibanez at gmail dot com 2010-07-04 08:33 --- Subject: Re: DECL_SAVED_TREE is always null on the first FUNCTION_DECL and is not null on the others On 4 July 2010 02:39, asmprog32 at hotmail dot com wrote: > A file has 3 functions (with body), the AST generated report a body > (DECL_SAVED_TREE != null ) on function 1, 2 not on function 3 (last one) > > If i add another function , the AST generated report a body on function 1 2 3 > not on function 4 > > . and so on > > What i expect is that all functions must have the body (DECL_SAVED_TREE != > null). The code attached are examples to reproduce what i have explained. I see. Reading the documentation on DECL_SAVED_TREE, that seems a fair expectation. I don't know what is going on here. Perhaps your plugin hooks too early or there is more going on that the docs explain. Please, when you get the answer, post it here (or better, send a patch updating the documentation!). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44800
[Bug c/29739] -Wconversion produces invalid warnings.
--- Comment #2 from lopezibanez at gmail dot com 2006-11-06 16:30 --- (a bit more explanation won't hurt) The GCC documentation says: -Wconversion: Warn if a prototype causes a type conversion that is different from what would happen to the same argument in the absence of a prototype. In your program, in the absence of prototype, d would be promoted to int, thus the warning is correct. Wconversion is only useful for translating very old C code to ANSI/ISO C. Since this behaviour is not very useful in the present day, and Wconversion also warns for unsigned i = -1, we are going to move the above behaviour to Wtraditional-conversion and make Wconversion warn for implicit conversions that may change a value. This is planned for GCC 4.3 . For more info, please check http://gcc.gnu.org/wiki/Wcoercion and don't hesitate to contact me. (That wiki page is work in progress, not definitive, actually, it is a bit outdated). Testing and comments are welcome. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29739
[Bug c/29739] -Wconversion produces invalid warnings.
--- Comment #7 from lopezibanez at gmail dot com 2006-11-06 19:51 ---
I think 4.3 will be released on 2007 or early 2008. Fixing bugs on 4.2 and 4.3
will speed up things, of course.
In addition, anyone could take the patches and apply them to their preferred
stable version. I think they will apply more or less cleanly to any 4.X
version.
On the other hand, there is no issue at all in the sense that Wconversion works
as documented and it was probably very useful when it was implemented. Now, the
desire for a "different" Wconversion has been acknowledged by GCC developers
since a long long time ago and they would have welcomed any implementation the
very same day that you opened your bug. Just nobody (not only GCC devs, I mean
no person on earth, not even you) had enough free time, resources or interest
to implement it or they had higher priorities.
Finally, I understand your frustration. I have done the same when I have been
frustrated with software. (I may still do it sometimes without being fully
aware and I always regret it) But I have learnt that negative comments (such as
#6) are pointless, on the contrary, they tend to hurt and offend developers
that have put endless nights, tears and blood on it. Even if you are completely
right and correct, offending someone before asking for a favour simply doesn't
work.
--
lopezibanez at gmail dot com changed:
What|Removed |Added
CC|lopezibanez at gmail dot com|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29739
[Bug c/9072] -Wconversion should be split into two distinct flags
--- Comment #18 from lopezibanez at gmail dot com 2006-11-23 18:55 --- I have insufficient privileges to close this bug. Please, someone, close it as FIXED. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072
[Bug c/60759] improve -Wlogical-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60759 --- Comment #6 from Manuel López-Ibáñez --- I believe this is on purpose to avoid too much noise. The warning in GCC needs to be smarter about types and macros and avoid early folding.
