[Bug c/19515] New: [4.0 Regression] Violation of C99 6.7.8 §21

[Bug c/19515] New: [4.0 Regression] Violation of C99 6.7.8 §21

[ebotcazou at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]

typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;
typedef unsigned long long upad64_t;

typedef struct _pthread_mutex {
        struct {
                uint16_t        __pthread_mutex_flag1;
                uint8_t         __pthread_mutex_flag2;
                uint8_t         __pthread_mutex_ceiling;
                uint16_t        __pthread_mutex_type;
                uint16_t        __pthread_mutex_magic;
        } __pthread_mutex_flags;
        union {
                struct {
                        uint8_t __pthread_mutex_pad[8];
                } __pthread_mutex_lock64;
                struct {
                        uint32_t __pthread_ownerpid;
                        uint32_t __pthread_lockword;
                } __pthread_mutex_lock32;
                upad64_t __pthread_mutex_owner64;
        } __pthread_mutex_lock;
        upad64_t __pthread_mutex_data;
} pthread_mutex_t; 

void foo(void)
{
   pthread_mutex_t tmp =  {{0, 0, 0, 0, 0x4d58}, {{{0}}}, 0};
}


On SPARC64 at -O0:

        sth     %g0, [%fp+2007]
        stb     %g0, [%fp+2009]
        stb     %g0, [%fp+2010]
        sth     %g0, [%fp+2011]
        sethi   %hi(19456), %g1
        or      %g1, 344, %g1
        sth     %g1, [%fp+2013]
        stb     %g0, [%fp+2015]
        stx     %g0, [%fp+2023]


On AMD64 at -O0:

        movw    $0, -32(%rbp)
        movb    $0, -30(%rbp)
        movb    $0, -29(%rbp)
        movw    $0, -28(%rbp)
        movw    $19800, -26(%rbp)
        movb    $0, -24(%rbp)
        movq    $0, -16(%rbp)


Note the 'b' on the last but one line in both cases: __pthread_mutex_pad is not
initialized according to the ISO C99 rules.  This is critical on Solaris 64-bit
as it affects POSIX thread support.

The C++ and Objective-C compilers are also affected.

-- 
           Summary: [4.0 Regression] Violation of C99 6.7.8 §21
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ebotcazou at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: *-*-*
  GCC host triplet: *-*-*
GCC target triplet: *-*-*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-18 23:06 -------
This is a midde-end problem .... (investing further)
but we end up with an empty CONSTRUTOR and the middle-end is not expanding it correctly for the 
union.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal
          Component|c                           |middle-end
           Keywords|                            |wrong-code
   Target Milestone|---                         |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-18 23:12 -------
> This is a midde-end problem .... (investing further)
> but we end up with an empty CONSTRUTOR and the middle-end is not expanding it
> correctly for the union.

Right, the 3.4.x back-end used to zero the whole aggregate if the constructor
was lacking elements.

And this is really critical according to the criterion.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-18 23:23 -------
Hmm, the gimplifier is messing up (again, there was another bug like this).
Here is the reduced testcase which shows the problem:
typedef union {
      char a2[8];
}aun;

void abort (void);

int main(void)
{
  aun a = {{0}};

  if (a.a2[2] != 0)
    abort ();
  return 0;
}


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-01-18 23:23:00
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2005-01-18 23:37 -------
I looked at the constructor gimplification stuff recently.  Lemme see if 
there's an easy fix I can figure out. 
 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
           Priority|P2                          |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-19 00:07 -------
This is basically PR 18191 but for unions this time, the struct/array part has been fixed.
Note I think the following patch caused it:
2004-01-28  Richard Henderson  <rth@redhat.com>
        
        PR opt/13798

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rth at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2005-01-20 09:04 -------
This is odd. 
 
For a struct { char a[8]; } count_type_elements returns 8. 
For a union { char a[8]; } count_type_elements returns 1. 
 
This confuses the following code in gimplify_init_constructor: 
 
        /* ??? This bit ought not be needed.  For any element not present 
           in the initializer, we should simply set them to zero.  Except 
           we'd need to *find* the elements that are not present, and that 
           requires trickery to avoid quadratic compile-time behavior in 
           large cases or excessive memory use in small cases.  */ 
        else if (num_ctor_elements < num_type_elements) 
          cleared = true; 
 
num_ctor_elements == 1 and num_type_elements == 1, so we don't clear. 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2005-01-20 09:10 -------
>From expr.c:count_type_elements: 
 
    case UNION_TYPE: 
    case QUAL_UNION_TYPE: 
      { 
        /* Ho hum.  How in the world do we guess here?  Clearly it isn't 
           right to count the fields.  Guess based on the number of words.  */ 
        HOST_WIDE_INT n = int_size_in_bytes (type); 
        if (n < 0) 
          return -1; 
        return n / UNITS_PER_WORD; 
      } 
 
So we cannot use count_type_elements in gimplify_init_constructor. 
 
I think we should somehow compute the size of the CONSTRUCTOR and compare 
it with int_size_in_bytes (TREE_TYPE (object))...? 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-20 09:15 -------
> From expr.c:count_type_elements: 
>  
>     case UNION_TYPE: 
>     case QUAL_UNION_TYPE: 
>       { 
>         /* Ho hum.  How in the world do we guess here?  Clearly it isn't 
>            right to count the fields.  Guess based on the number of words.  */ 
>         HOST_WIDE_INT n = int_size_in_bytes (type); 
>         if (n < 0) 
>           return -1; 
>         return n / UNITS_PER_WORD; 
>       } 
>  
> So we cannot use count_type_elements in gimplify_init_constructor. 

Can't we compute the result for unions based on the type of the first member?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions

[stevenb at suse dot de]

------- Additional Comments From stevenb at suse dot de  2005-01-20 09:26 -------
Subject: Re:  [4.0 Regression] Violation of C99 6.7.8 =?utf-8?q?=A721_for?= unions

> Can't we compute the result for unions based on the type of the first
> member?

Ehm??  "union { int i; char c[256]; }"

However, we can use int_size_in_bytes on object and on the
first field of the constructor in the gimplifier.









-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-01-20 09:31 -------
> Ehm??  "union { int i; char c[256]; }"

Doesn't look much buggier than what we currently have... maybe take the max on
all the fields then?  That said, I don't know what count_type_elements is for,
it is clearly brain-damaged for unions at the moment.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2005-01-20 11:28 -------
(In reply to comment #7)
> So we cannot use count_type_elements in gimplify_init_constructor. 

Well, not for unions anyway.

> I think we should somehow compute the size of the CONSTRUCTOR and compare 
> it with int_size_in_bytes (TREE_TYPE (object))...? 

For unions, that may be what we have to do.  With any luck, the element
being initialized will be the largest element of the union, which would
mean we wouldn't have to emit the clear.

For structures, this would mean that any structure with holes would get
cleared.  Which would clearly pessimize a very common case.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2005-01-20 11:49 -------
> For structures, this would mean that any structure with holes would get
> cleared.  Which would clearly pessimize a very common case.

I considered that too.  But, what about structures that
contain a union?

typedef struct {
  int i;
  union {
    int j[2];
    float f;
  } u;
} S;
 
void abort (void) __attribute__((noreturn));
 
int main(void)
{
  S s = { .i = 1, {.f = 1.0 } };
  if (s.u.j[1] != 0)
    abort ();
  return 0;
} 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2005-01-20 18:03 -------
(In reply to comment #12)
> But, what about structures that contain a union?

We'll need to consider the question "do we need to clear" one nesting
level at a time, and propagate it up.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-26 15:21 -------
Subject: Bug 19515

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	rth@gcc.gnu.org	2005-01-26 15:20:53

Modified files:
	gcc            : ChangeLog expr.c gimplify.c tree.h 
Added files:
	gcc/testsuite/gcc.c-torture/execute: pr19515.c 

Log message:
	PR middle-end/19515
	* expr.c (categorize_ctor_elements): New argument p_must_clear.
	(categorize_ctor_elements_1): Likewise.  Detect a union that isn't
	fully initialized.
	(mostly_zeros_p): Update for new categorize_ctor_elements argument.
	* gimplify.c (gimplify_init_constructor): Likewise.  Only shove
	objects into static storage if they have more than one non-zero value.
	* tree.h (categorize_ctor_elements): Update decl.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7285&r2=2.7286
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gcc&r1=1.772&r2=1.773
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gcc&r1=2.106&r2=2.107
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gcc&r1=1.680&r2=1.681
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr19515.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2005-01-26 15:24 -------
Fixed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515