Bug 30913 - SRA bugs with anon bitfields
Summary: SRA bugs with anon bitfields
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.1.2
: P3 normal
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-21 14:27 UTC by Jakub Jelinek
Modified: 2010-04-09 11:03 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.3.4 4.4.3 4.5.0
Known to fail: 4.2.4
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Jelinek 2007-02-21 14:27:44 UTC
// gcc -O2 -Wall -S uninit-anon-bitfield.c

struct foo {
  unsigned int a:16;
  unsigned int b:11;
  unsigned int :5;
};

extern struct foo bar;

void foo(int a, int b)
{
  struct foo tmp;

  tmp.a = a;
  tmp.b = b;

  bar = tmp;
}

warns while it should not, the anon bitfield is just a padding, can't be
assigned to.  There is no warning with -fno-tree-sra.
The bug is in SRA IMHO, when scalarizing a struct assignment, it should certainly
ignore the anon bitfields (TREE_CODE (x->element) == FIELD_DECL && DECL_NAME (x->element) == NULL && TREE_CODE (TREE_TYPE (x->element)) == BIT_FIELD_TYPE ?).
Both in generate_element_copy, generate_copy_inout and perhaps in other places
as well.  Or not instantiate the anon bitfields at all.

There is another bug, e.g. for
struct foo {
  unsigned int a:16;
  unsigned int b:11;
  unsigned int :5;
};

extern struct foo bar;

void foo(struct foo a)
{
  struct foo tmp;

  tmp = a;

  bar = tmp;
}
SRA certainly should not have decided to use element copies at all, that makes
many times worse code.
Comment 1 Andrew Pinski 2007-02-21 15:18:43 UTC
> SRA certainly should not have decided to use element copies at all, that makes
> many times worse code.

That is really unrelated to unanonymous bitfields and is a different bug and has been filled already (I forgot the number but I filled it).
Comment 2 Andrew Pinski 2007-02-22 23:45:57 UTC
The second part of this bug is recorded as PR 22156.
Comment 3 Jie Zhang 2010-04-09 10:58:20 UTC
It's not reproducible on svn trunk now.
Comment 4 Richard Biener 2010-04-09 11:03:23 UTC
Fixed in 4.3.0.