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=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=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=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=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=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=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=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=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=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=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=102484
Bug ID: 102484
Summary: Refactor duplicated cb_cpp_diagnostic_cpp_option
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
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=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
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=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=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=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=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=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=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=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=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
--- 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 #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 #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 #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
Bug ID: 109123
Summary: Bogus warning: pointer used after 'realloc'
-Wuse-after-free
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
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
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=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=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
35 matches
Mail list logo
