[Bug middle-end/96335] [10/11 Regression] ICE in maybe_warn_rdwr_sizes since r10-4929

2020-07-28 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96335

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Jakub Jelinek  ---
Fixed for 10.3 and later.

[Bug middle-end/96335] [10/11 Regression] ICE in maybe_warn_rdwr_sizes since r10-4929

2020-07-28 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96335

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:7d88f924ad8d773cceb08e123cb2831f20d40cb4

commit r10-8541-g7d88f924ad8d773cceb08e123cb2831f20d40cb4
Author: Jakub Jelinek 
Date:   Tue Jul 28 11:08:29 2020 +0200

expander: Fix ICE in maybe_warn_rdwr_sizes [PR96335]

The following testcase ICEs in maybe_warn_rdwr_sizes.  The problem is that
the caller uses its fndecl and fntype variables to fill up rdwr_map, and
the fntype in that case is a prototype with the access attribute and all
the checks needed for that performed.  But the maybe_warn_rdwr_sizes
function tries to rediscover fndecl/fntype itself and does it differently
from how the caller did (for fndecl get_callee_fndecl and fntype from that
FUNCTION_DECL, otherwise sets fntype to CALL_EXPR_FN's type).

On the testcase, get_callee_fndecl does find a FUNCTION_DECL because
it does STRIP_NOPS in between.

Instead of trying to rediscover those, this patch just passes them down,
like is done in several other functions.

2020-07-28  Jakub Jelinek  

PR middle-end/96335
* calls.c (maybe_warn_rdwr_sizes): Add FNDECL and FNTYPE arguments,
instead of trying to rediscover them in the body.
(initialize_argument_information): Adjust caller.

* gcc.dg/pr96335.c: New test.

(cherry picked from commit f9264b9008386ac3b5c795472c222fa524b127b0)

[Bug middle-end/96335] [10/11 Regression] ICE in maybe_warn_rdwr_sizes since r10-4929

2020-07-28 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96335

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:f9264b9008386ac3b5c795472c222fa524b127b0

commit r11-2379-gf9264b9008386ac3b5c795472c222fa524b127b0
Author: Jakub Jelinek 
Date:   Tue Jul 28 11:08:29 2020 +0200

expander: Fix ICE in maybe_warn_rdwr_sizes [PR96335]

The following testcase ICEs in maybe_warn_rdwr_sizes.  The problem is that
the caller uses its fndecl and fntype variables to fill up rdwr_map, and
the fntype in that case is a prototype with the access attribute and all
the checks needed for that performed.  But the maybe_warn_rdwr_sizes
function tries to rediscover fndecl/fntype itself and does it differently
from how the caller did (for fndecl get_callee_fndecl and fntype from that
FUNCTION_DECL, otherwise sets fntype to CALL_EXPR_FN's type).

On the testcase, get_callee_fndecl does find a FUNCTION_DECL because
it does STRIP_NOPS in between.

Instead of trying to rediscover those, this patch just passes them down,
like is done in several other functions.

2020-07-28  Jakub Jelinek  

PR middle-end/96335
* calls.c (maybe_warn_rdwr_sizes): Add FNDECL and FNTYPE arguments,
instead of trying to rediscover them in the body.
(initialize_argument_information): Adjust caller.

* gcc.dg/pr96335.c: New test.

[Bug middle-end/96335] [10/11 Regression] ICE in maybe_warn_rdwr_sizes since r10-4929

2020-07-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96335

--- Comment #1 from Jakub Jelinek  ---
Created attachment 48933
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48933=edit
gcc11-pr96335.patch

Untested fix.

[Bug middle-end/96335] [10/11 Regression] ICE in maybe_warn_rdwr_sizes since r10-4929

2020-07-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96335

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |10.3
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2020-07-27
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Priority|P3  |P2
   Keywords||ice-on-valid-code