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.
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
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,
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
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.
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
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
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
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
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?
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
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.
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.
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.
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?
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
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
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
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.
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
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.
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
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
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
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 &)
> : a(static_cast(a)),
> b(std::move(o.b)) {}
>
--- 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
gcc-bugzi...@gcc.gnu.org wrote:
A file has 3
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=12291action=view)
wcoercion patch r116922
Patch for trunk revision 116922 (bootstrapped and tested on i686-pc-linux-gnu
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=11826action=view)
split current functionality of Wconversion in two different options
This patch divides the functionality
--- 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=11827action=view)
Adds a new function which detects when a real value can be exactly represented
as an integer.
Patch 2of3 http
--- 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=11828action=view)
detect implicit conversions where a value may change
patch 3of3 http://gcc.gnu.org/wiki/Wcoercion#Background
--- 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
56 matches
Mail list logo
