[Bug middle-end/88968] [8/9 Regression] Stack overflow in gimplify_expr

2019-01-22 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 22 22:28:42 2019
New Revision: 268165

URL: https://gcc.gnu.org/viewcvs?rev=268165&root=gcc&view=rev
Log:
PR middle-end/88968
* gimplify.c (gimplify_omp_atomic): Handle bitfield atomics with
non-integral DECL_BIT_FIELD_REPRESENTATIVEs.

* c-omp.c (c_finish_omp_atomic): For bitfield atomics, update type
variable after using BIT_FIELD_REF.

* c-c++-common/gomp/atomic-23.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/gomp/atomic-23.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-omp.c
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/88968] [8/9 Regression] Stack overflow in gimplify_expr

2019-01-22 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 45495
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45495&action=edit
gcc9-pr88968.patch

Untested fix.

[Bug middle-end/88968] [8/9 Regression] Stack overflow in gimplify_expr

2019-01-22 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968

--- Comment #3 from Jakub Jelinek  ---
The problem is that for these packed structs the DECL_BIT_FIELD_REPRESENTATIVE
is not integral FIELD_DECL that the c-omp.c code assumes.  BIT_FIELD_REF seems
to work with non-integral base types from which the field is extracted:
/* Reference to a group of bits within an object.  Similar to COMPONENT_REF
   except the position is given explicitly rather than via a FIELD_DECL.
   Operand 0 is the structure or union expression;
   operand 1 is a tree giving the constant number of bits being referenced;
   operand 2 is a tree giving the constant position of the first referenced
bit.
   The result type width has to match the number of bits referenced.
   If the result type is integral, its signedness specifies how it is extended
   to its mode width.  */
DEFTREECODE (BIT_FIELD_REF, "bit_field_ref", tcc_reference, 3)
but we need to insert the field back and for that the BIT_INSERT_EXPR we are
using requires that it stores into an integral or vector type expression:
/* Given a container value, a replacement value and a bit position within
   the container, produce the value that results from replacing the part of
   the container starting at the bit position with the replacement value.
   Operand 0 is a tree for the container value of integral or vector type;
   Operand 1 is a tree for the replacement value of another integral or
   the vector element type;
   Operand 2 is a tree giving the constant bit position;
   The number of bits replaced is given by the precision of the type of the
   replacement value if it is integral or by its size if it is non-integral.
   ???  The reason to make the size of the replacement implicit is to avoid
   introducing a quaternary operation.
   The replaced bits shall be fully inside the container.  If the container
   is of vector type, then these bits shall be aligned with its elements.  */
DEFTREECODE (BIT_INSERT_EXPR, "bit_insert_expr", tcc_expression, 3)

[Bug middle-end/88968] [8/9 Regression] Stack overflow in gimplify_expr

2019-01-22 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968

Arseny Solokha  changed:

   What|Removed |Added

  Component|c   |middle-end

--- Comment #2 from Arseny Solokha  ---
struct {
  unsigned int hq : 16;
  unsigned int dv : 1;
} __attribute__ ((__packed__)) e2;

int
yp (void)
{
  int sr;

#pragma omp atomic capture
  {
sr = e2.hq;
e2.hq = 0;
  }

  return sr;
}

% gcc-9.0.0-alpha20190120 -fopenmp -c zto53g7w.c
zto53g7w.c: In function 'yp':
zto53g7w.c:15:3: internal compiler error: in fold_convert_loc, at
fold-const.c:2552
   15 |   }
  |   ^
0x615112 fold_convert_loc(unsigned int, tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/fold-const.c:2552
0xa741b8 omit_one_operand_loc(unsigned int, tree_node*, tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/fold-const.c:3769
0x8918ad c_finish_omp_atomic(unsigned int, tree_code, tree_code, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node*, bool, omp_memory_order, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/c-family/c-omp.c:412
0x834307 c_parser_omp_atomic
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/c/c-parser.c:16470
0x843aea c_parser_omp_construct
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/c/c-parser.c:19490
0x821667 c_parser_pragma
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/c/c-parser.c:11562
0x83b2b4 c_parser_compound_statement_nostart
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/c/c-parser.c:5114
0x83b8b8 c_parser_compound_statement
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/c/c-parser.c:4980
0x83d1b5 c_parser_declaration_or_fndef
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/c/c-parser.c:2352
0x84456f c_parser_external_declaration
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/c/c-parser.c:1653
0x844fb1 c_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/c/c-parser.c:1534
0x844fb1 c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/c/c-parser.c:19840
0x898bcb c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/c-family/c-opts.c:1155