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=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=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=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=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=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=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=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=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=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=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=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 #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 #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 #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 #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=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=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=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=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=58334
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
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=102484
Bug ID: 102484
Summary: Refactor duplicated cb_cpp_diagnostic_cpp_option
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
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
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=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=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
--- Comme
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=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=114952
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comme
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=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=118004
Manuel López-Ibáñez changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114218
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||easyhack
CC|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91406
Manuel López-Ibáñez changed:
What|Removed |Added
Summary|gcc -Q -v lies about what |gcc -Q -v --help=optimizers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119823
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comme
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=120135
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92826
Manuel López-Ibáñez changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org,
45 matches
Mail list logo
