https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114218
--- Comment #5 from Manuel López-Ibáñez ---
(In reply to Sam James from comment #4)
> Thank you! I will have a go.
If there are already tests available in the testsuite that test for this
output, just update the output. You do not need to add a
||manu at gcc dot gnu.org
--- Comment #3 from Manuel López-Ibáñez ---
(In reply to Sam James from comment #1)
> To be clear: what I'd like is if the warning included "MAGIC_NUMBER was 42
> at one instance, and 100 at another".
It should be easy to print
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66943
--- Comment #11 from Manuel López-Ibáñez ---
I think having -Wignored-pragma-omp would be useful:
1. It is useful to have a warning that warns that you need to use -fopenmp for
#pragma omp to have an effect.
2. However, it is very common to wan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118004
--- Comment #4 from Manuel López-Ibáñez ---
(In reply to Xi Ruoyao from comment #3)
> Making the entire ... access (read_only) would be incorrect, considering the
> argument corresponding to %n should be access (write_only) instead.
>
> So we s
||2024-12-12
Status|UNCONFIRMED |NEW
CC||manu at gcc dot gnu.org
--- Comment #2 from Manuel López-Ibáñez ---
__attribute__ ((access (read_only, 2)))
int printf(const char *format, const char *x);
// Type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114952
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=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 t
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 Manue
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 ma
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 to
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 p
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 middle-e
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 workarou
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
ty: normal
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__
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 with
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 und
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
gnu.o
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 that,
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 fi
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.
>
> Thus,
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;
~ ^ ~~~
/opt/compiler-explorer/gcc-snapshot/lib/gc
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 << b
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 alread
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
> reco
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
> simila
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 mi
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 diffe
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 |Add
|--- |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 Manue
||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 mark
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
--- Comme
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 Manue
||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
> above,
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 t
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 0
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()
> n
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). Pe
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 to
||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
|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 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43361
Manuel López-Ibáñez changed:
What|Removed |Added
CC||tangyixuan at mail dot
dlut.edu.cn
||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 as a
||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 possible.
This
||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
--- Comm
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 for
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 -Warray-
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
test_s
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
documentati
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 Manu
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 is
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 does
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
> introd
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 erro
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 any
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.
U
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 to
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 loo
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 o
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/wiki/G
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 -W
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
1 - 100 of 2542 matches
Mail list logo
