On Thu, 2022-08-11 at 14:41 +0530, Immad Mir wrote:
> This patch fixes the ICE caused by valid_to_unchecked_state,
> at analyzer/sm-fd.cc by handling the m_start state in
> check_for_dup.
>
> Tested lightly on x86_64.
>
> gcc/analyzer/ChangeLog:
> PR analyzer/106551
> * sm-fd.cc (
This patch fixes the ICE caused by valid_to_unchecked_state,
at analyzer/sm-fd.cc by handling the m_start state in
check_for_dup.
Tested lightly on x86_64.
gcc/analyzer/ChangeLog:
PR analyzer/106551
* sm-fd.cc (check_for_dup): handle the m_start
state when transitioning th
With the fix for bogus warning in fd-uninit.c, the analyzer now does not
warning for the following code for which it would previously emit
-Wanalyzer-fd-use-without-check
extern int m;
test()
{
int fd = dup2(m, 1);
close(fd);
}
So I had to remove such warnings from fd-dup-1.c test_20,21,22 (in
On Wed, 2022-08-10 at 22:51 +0530, Mir Immad wrote:
> > Can you please rebase and see if your patch
> > does fix it?
>
> No, the patch that I sent did not attempt to fix this. Now that I
> have made
> the correction, XFAIL in fd-uninit-1.c has changed to XPASS.
Great - that means that, with your
> Can you please rebase and see if your patch
> does fix it?
No, the patch that I sent did not attempt to fix this. Now that I have made
the correction, XFAIL in fd-uninit-1.c has changed to XPASS.
Should i remove the dg-bogus warning from fd-uninit-1.c test_1?
Thanks.
Immad.
On Wed, Aug 10,
On Wed, 2022-08-10 at 20:34 +0530, Mir Immad wrote:
> > if you convert the "int m;" locals into an extern global, like in
> > comment #0 of bug 106551, does that still trigger the crash on the
> > unpatched sm-fd.cc?
>
> Yes, it does, since m would be in "m_start" state. I'm sending an
> updated
This patch fixes the ICE caused by valid_to_unchecked_state,
at analyzer/sm-fd.cc by handling the m_start state in
check_for_dup.
Tested lightly on x86_64.
gcc/analyzer/ChangeLog:
PR analyzer/106551
* sm-fd.cc (check_for_dup): handle the m_start
state when transitioning th
> if you convert the "int m;" locals into an extern global, like in
> comment #0 of bug 106551, does that still trigger the crash on the
> unpatched sm-fd.cc?
Yes, it does, since m would be in "m_start" state. I'm sending an updated
patch.
Thanks
Immad.
On Wed, Aug 10, 2022 at 1:32 AM David Mal
On Tue, 2022-08-09 at 21:42 +0530, Immad Mir wrote:
> This patch fixes the ICE caused by valid_to_unchecked_state,
> at analyzer/sm-fd.cc by handling the m_start state in
> check_for_dup.
>
> Tested lightly on x86_64.
>
> gcc/analyzer/ChangeLog:
> PR analyzer/106551
> * sm-fd.cc (
Thanks. I've added few testcases that use uninitialized ints in dup, dup2,
and dup3.
Immad.
On Tue, Aug 9, 2022 at 8:43 PM David Malcolm wrote:
> On Tue, 2022-08-09 at 13:16 +0530, Immad Mir wrote:
> > This patch fixes the ICE caused by valid_to_unchecked_state,
> > at analyzer/sm-fd.cc by hand
This patch fixes the ICE caused by valid_to_unchecked_state,
at analyzer/sm-fd.cc by handling the m_start state in
check_for_dup.
Tested lightly on x86_64.
gcc/analyzer/ChangeLog:
PR analyzer/106551
* sm-fd.cc (check_for_dup): handle the m_start
state when transitioning th
On Tue, 2022-08-09 at 13:16 +0530, Immad Mir wrote:
> This patch fixes the ICE caused by valid_to_unchecked_state,
> at analyzer/sm-fd.cc by handling the m_start state in
> check_for_dup.
>
> Tested lightly on x86_64.
>
> gcc/analyzer/ChangeLog:
> PR analyzer/106551
> * sm-fd.cc (
This patch fixes the ICE caused by valid_to_unchecked_state,
at analyzer/sm-fd.cc by handling the m_start state in
check_for_dup.
Tested lightly on x86_64.
gcc/analyzer/ChangeLog:
PR analyzer/106551
* sm-fd.cc (check_for_dup): handle the m_start
state when transitioning th
13 matches
Mail list logo
