https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70730
--- Comment #3 from Manuel López-Ibáñez ---
(In reply to Eric Gallager from comment #2)
> (In reply to Manuel López-Ibáñez from comment #1)
> > If not, this then depends on PR43486
>
> (that's now fixed, btw... so maybe that's had an impact on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28492
Manuel López-Ibáñez changed:
What|Removed |Added
Last reconfirmed|2012-04-17 00:00:00 |2024-1-9
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209
--- Comment #9 from Manuel López-Ibáñez ---
For the sake of other potential readers: Patches should be submitted to
gcc-patc...@gcc.gnu.org and reviewers do not review patches in bugzilla.
Nevertheless, it is a good idea to add the link to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654
--- Comment #4 from Manuel López-Ibáñez ---
(In reply to Julian Waters from comment #2)
> (In reply to Manuel López-Ibáñez from comment #1)
> Yeah, I did try submitting it to gcc-patches, but it simply went ignored for
> forever, so I decided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||patch
--- Comment #15 from Manuel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Richard Biener from comment #7)
> Warning for "escapes" (the store is an escape point) is also sensible I
> think.
Would it be possible to make this distinction at the point of warning?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to Manuel López-Ibáñez from comment #5)
> Is this code motion valid? Is there any point in the middle-end that checks
> the validity of the pointer beyond a free/realloc?
>
> If there is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123
--- Comment #5 from Manuel López-Ibáñez ---
> GCC has sunk part of the old_size computation (not the loads but the
> subtraction) to after the realloc but before the use of old_size.
Is this code motion valid? Is there any point in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123
--- Comment #4 from Manuel López-Ibáñez ---
This case is a bit different from other Wuse-after-free false positives:
* there is no path through which the warning is true
* the warning says "is used" not "may be used"
* there is no easy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123
--- Comment #2 from Manuel López-Ibáñez ---
This is probably the same underlying issue as PR 106119 and PR 104215, but
unlike those, this testcase is heavily reduced without any header files (and it
could be reduced further I believe).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123
Manuel López-Ibáñez changed:
What|Removed |Added
Summary|Bogus warning: pointer used |Bogus warning: pointer used
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
Target Milestone: ---
```c
typedef long unsigned int size_t;
extern void *realloc (void *__ptr, size_t __size)
__attribute__ ((__nothrow__ , __leaf__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63357
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to David Binderman from comment #8)
> This could probably be extended to other operators.
Please open a new PR mentioning this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781
--- Comment #30 from Manuel López-Ibáñez ---
(In reply to jos...@codesourcery.com from comment #29)
> As I said before, the issue is still how to define something general
> enough to be useful but that doesn't expose too much of the details of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781
--- Comment #28 from Manuel López-Ibáñez ---
(In reply to Jan Wielemaker from comment #27)
> It is really a pity this can't be resolved :( We have quite a few
> extensions in the SWI-Prolog source code, mostly for debug messages that
> deal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #24 from Manuel López-Ibáñez ---
For completeness, this is what LLD says:
ld.lld: error: undefined symbol: vtable for A
>>> referenced by example.cpp:7
>>> /tmp/example-5d8b98.o:(A::A())
>>> the vtable symbol may be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
Manuel López-Ibáñez changed:
What|Removed |Added
Assignee|jyasskin at gmail dot com |unassigned at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50486
--- Comment #3 from Manuel López-Ibáñez ---
Clang warns:
:16:18: warning: implicit conversion changes signedness: 'int' to
'enum e' [-Wsign-conversion]
return a(-1);
~ ^~
Not sure why gcc doesn't but it should.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
--- Comment #46 from Manuel López-Ibáñez ---
(In reply to Lewis Hyatt from comment #44)
> I hope this looks workable, happy to adjust the patch as needed.
If you don't get much attention to the patch, it may be worth pinging it. But
before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to Tobias Burnus from comment #8)
> f951: Warning: Include directory ‘foo/bar/’: Permission denied
> : Error: foo/bar: Permission denied
>
> (The shows up when entering a file but the
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
Target Milestone: ---
This function:
https://github.com/gcc-mirror/gcc/blob/8bafc9640f353ff11c0535a03096fb4db9a5bb95/gcc/fortran/cpp.c#L1062
is a duplicate of:
https://github.com/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62226
--- Comment #2 from Manuel López-Ibáñez ---
(In reply to Tobias Burnus from comment #1)
> I am not sure whether the original issue still exists.
>
> Fortran now uses a lot of the common machinery and also seems to handle
> CPP() well.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58334
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67499
--- Comment #11 from Manuel López-Ibáñez ---
And Clang output:
:5:13: error: invalid operands to binary expression ('std::ostream'
(aka 'basic_ostream') and 'foo')
std::cout << bar;
~ ^ ~~~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67499
--- Comment #10 from Manuel López-Ibáñez ---
This is the current GCC output:
```
: In function 'int main()':
:5:13: error: no match for 'operator<<' (operand types are
'std::ostream' {aka 'std::basic_ostream'} and 'foo')
5 | std::cout <<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471
--- Comment #18 from Manuel López-Ibáñez ---
(In reply to wavexx from comment #17)
> I wish this would be given a nudge, considering the patch. This has been
> pushed to new releases since 2016 :(
I see several patches have been committed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635
Manuel López-Ibáñez changed:
What|Removed |Added
URL||http://www.open-std.org/jtc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63943
--- Comment #4 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #3)
> As for using %K, I mostly agree. I actually have %G in my tree, but my goal
> is to get rid of both and replace them with a new warning function like so:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61112
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #8)
> I've added both the passing test case from comment #0 and the still failing
> test case from comment #5 to the test suite and xfailed the latter (thus
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #8)
> You're right, the test cases aren't equivalent, or meant to be. What I want
> to highlight is that in the test case in comment #6, in g() and other
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #6)
> In the reduced test cases (in comment #3 and comment #4) d is a global
> variable so it's value is zero. c is assigned in the first iteration of the
> loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832
--- Comment #5 from Manuel López-Ibáñez ---
Either there is no bug or the reduction is incorrect because the warning in the
testcase is correct since d is uninitialized. Maybe the bug is that it warns
about 'c' and not about 'd', but probably at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #6)
> The problem is that when the address of a variable escapes, because GCC
> doesn't track when, when the function from which it escapes calls another
> that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95848
--- Comment #3 from Manuel López-Ibáñez ---
Martin, it is not clear from the dumps what is the difference between the two
cases. Also, this warning triggers even with -O0, so it must come pretty
earlier even before we have VOPS. What is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83591
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Tony E Lewis from comment #7)
> Manuel López-Ibáñez: are you happy that all underlying issues are resolved
> and this can be closed?
Sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 94774, which changed state.
Bug 94774 Summary: Uninitialized variable retval in function
try_substitute_return_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94774
What|Removed
|--- |FIXED
CC||manu at gcc dot gnu.org
--- Comment #4 from Manuel López-Ibáñez ---
Seems fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94905
Manuel López-Ibáñez changed:
What|Removed |Added
Summary|Bogus warning |[10 Regression] Bogus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94905
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95848
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
|variable warning with |uninitialized variable
|branches at -O1 and higher |warning with difficult
||control-flow analysis
CC||manu at gcc dot gnu.org
--- Comment #2 from Manuel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96368
Manuel López-Ibáñez changed:
What|Removed |Added
Status|VERIFIED|RESOLVED
--- Comment #3 from
||manu at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-07-29
--- Comment #2 from Manuel López-Ibáñez ---
This seems some kind of weird missed optimization because this variant does
warn:
struct S { int i
|--- |DUPLICATE
CC||manu at gcc dot gnu.org
--- Comment #1 from Manuel López-Ibáñez ---
I'm pretty sure this is PR18501.
pktio_read() creates a PHI node and prevents CCP deleting the undefined value.
*** This bug has been marked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 96368, which changed state.
Bug 96368 Summary: False negative with maybe-uninitialized with goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96368
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
Manuel López-Ibáñez changed:
What|Removed |Added
CC||felix at piedallu dot me
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61579
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to David Brown from comment #7)
> Could "-Wwrite-strings" be split into two options? The warning could remain
> (and become part of -Wall for C as well as C++) if the compiler can spot and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973
Manuel López-Ibáñez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||easyhack
--- Comment #5 from
||manu at gcc dot gnu.org
Keywords||easyhack
--- Comment #6 from Manuel López-Ibáñez ---
Probably a dup of bug 19808. There is an unfinished patch there that does the
check in the FE. That would side-step issues with A being empty (you just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #35 from Manuel López-Ibáñez ---
(In reply to Niels Möller from comment #32)
> 1. There's similar code in c_fully_fold_internal, in gcc/c/c-fold.c, close
> to line 400. But that code does *not* emit any warning for the example
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #216 from Manuel López-Ibáñez ---
(In reply to Vincent Lefèvre from comment #215)
> According to https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#bug_status
> the possible status are UNCONFIRMED, CONFIRMED and IN_PROGRESS. I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #35 from Manuel López-Ibáñez ---
In any case, looking at the uninit dump with -fdump-tree-all-all-lineno it
appears that GCC knows the block where the warning is triggered is never
executed:
;; basic block 13, loop depth 0, count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #34 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #15)
> I think the following smaller test case independent of libstdc++ captures
> the same issue as the bigger test case in comment #4. Again, declaring f()
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92826
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to kim.walisch from comment #0)
> GCC should definitely not warn when using constants from . GCC
> should also provide an option to disable these warnings (e.g.
> -Wno-non-standard-suffix).
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-12-16
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #6 from Manuel López-Ibáñez ---
The fact that GCC points
||2019-12-16
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #5 from Manuel López-Ibáñez ---
This should be suspended until someone comes up with a proposal for reviving
-Wunreachable
CC||manu at gcc dot gnu.org
Summary|-Wignored-qualifiers points |-Wignored-qualifiers points
|to diff location|to wrong location and
||doesn't mention which
|UNCONFIRMED |NEW
Last reconfirmed||2019-12-16
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez ---
The key here is to add the fix-hit hint
|UNCONFIRMED |NEW
Last reconfirmed||2019-12-16
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez ---
This one would be useful to have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43361
Manuel López-Ibáñez changed:
What|Removed |Added
CC||tangyixuan at mail dot
||manu at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Manuel López-Ibáñez ---
When reporting a Wuninitialized bug please check PR24639. 99% of the cases are
duplicated of an existing report.
*** This bug has been marked
||manu at gcc dot gnu.org
Resolution|--- |WONTFIX
--- Comment #4 from Manuel López-Ibáñez ---
(In reply to tangyixuan from comment #3)
> Error handler should not stop at the first error and report the errors as
> many as po
||manu at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #6 from Manuel López-Ibáñez ---
Not a bug per comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Manuel López-Ibáñez changed:
What|Removed |Added
CC||Hi-Angel at yandex dot ru
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 89192, which changed state.
Bug 89192 Summary: -Wuninitialized doesn't warn about a vector initialization
with uninitialized field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89192
What|Removed
||manu at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #4 from Manuel López-Ibáñez ---
Duplicated
*** This bug has been marked as a duplicate of bug 19808 ***
||2019-11-02
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez ---
For the Wuninit, this is PR18501
||2019-11-02
CC||manu at gcc dot gnu.org
Depends on||49754, 79658
Summary|missing uninitialized |missing uninitialized
|warning: laundering via |warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90058
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91890
--- Comment #5 from Manuel López-Ibáñez ---
333 Warray-bounds
334 LangEnabledBy(C ObjC C++ LTO ObjC++)
335 ; in common.opt
This seems wrong, the second argument ", Wall" is missing. Moreover, this
probably should be an Alias for some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91890
--- Comment #4 from Manuel López-Ibáñez ---
I'm 100% convinced this has nothing to do with locations and all to do with how
-Warray-bounds and -Wstringop-overflow= interact.
Change the ignored for error,
char one[50];
char two[50];
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92330
--- Comment #1 from Manuel López-Ibáñez ---
Actually, it is not even deprecated. There are still a bunch of
Wstrict-overflow warnings, just some of them got removed.
Is there a way to tell which ones are still active and update the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91890
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55881
Manuel López-Ibáñez changed:
What|Removed |Added
Last reconfirmed|2013-01-07 00:00:00 |2019-11-2
--- Comment #8 from
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
CC: msebor at gcc dot gnu.org, rguenth at gcc dot gnu.org
Target Milestone: ---
According to GCC 8, Wstrict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66099
Manuel López-Ibáñez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470
--- Comment #19 from Manuel López-Ibáñez ---
(In reply to Andrew Macleod from comment #18)
> So the information would be there if one knew what to look for and how to
> use it.
The issue here is to either have VRP info in the FE (like Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973
--- Comment #15 from Manuel López-Ibáñez ---
(In reply to Lewis Hyatt from comment #13)
> I have one other question though. This quick attempt uses wchar.h, namely
> the mbrtowc() and wcwidth() functions. Firstly, it seems unfortunate to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53075
--- Comment #5 from Manuel López-Ibáñez ---
(In reply to Kamlesh Kumar from comment #4)
> This patch resolves this.
No, it doesn't.
As the documentation says: -pedantic-errors is not equivalent to
@option{-Werror=pedantic}, since there are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68901
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to Trass3r from comment #7)
> Created attachment 46435 [details]
> cleanup
>
> The previous patch should also allow removing these hacks (untested).
> Though TYPE_ARTIFICIAL wasn't set in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68901
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Trass3r from comment #5)
> Wpadded only checks for input_location != BUILTINS_LOCATION currently
> (stor-layout.c).
> Maybe something like !DECL_ARTIFICIAL(rli->t) should be added there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52981
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to krux from comment #6)
> (In reply to Manuel López-Ibáñez from comment #4)
> > This is quite easy to implement.
>
> It's not as trivial as one might think.
> There's some copy-paste code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68901
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82521
--- Comment #5 from Manuel López-Ibáñez ---
(In reply to Manuel López-Ibáñez from comment #4)
> I actually don't see anything in the patch that should change this aspect,
> so I would not be surprised if it was caused by some other change.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82521
--- Comment #4 from Manuel López-Ibáñez ---
If revision r124856 really caused this, the effect was not intentional.
I actually don't see anything in the patch that should change this aspect, so I
would not be surprised if it was caused by some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65403
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Alex Henrie from comment #8)
> Why weren't Manuel's patches accepted?
I never properly submitted them. Feel free to adopt them and get them through
the process:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87663
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
|9.0
Keywords||ice-on-valid-code
Last reconfirmed||2018-10-28
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
Summary|[6.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87656
--- Comment #2 from Manuel López-Ibáñez ---
From: https://gcc.gnu.org/wiki/DiagnosticsGuidelines
As a rough guideline, a warning option should be:
enabled by default if it has (almost) no false positives (e.g.,
-Woverflow);
added to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
Manuel López-Ibáñez changed:
What|Removed |Added
Blocks||87656
--- Comment #23 from Manuel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61534
Manuel López-Ibáñez changed:
What|Removed |Added
Blocks||87656
--- Comment #12 from Manuel
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
Target Milestone: ---
There have been quite a number of new warning flags added to GCC that are not
enabled by -Wall nor -Wextra, so they are not easily found by users. This is a
meta-bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87614
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87274
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55881
--- Comment #7 from Manuel López-Ibáñez ---
Some comments from a discussion with Martin and David:
%G and %K sometimes do not work with pragma
diagnostics. The reason is that the pragma diagnostics check is done
here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71003
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
1 - 100 of 2536 matches
Mail list logo
