Re: middle-end/9725: Invalid dependency determination

Re: middle-end/9725: Invalid dependency determination

[Momchil Velikov]

The following reply was made to PR middle-end/9725; it has been noted by GNATS.

From: Momchil Velikov <velco@fadata.bg>
To: "Jan Beulich" <JBeulich@novell.com>
Cc: <gcc-bugs@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org>
Subject: Re: middle-end/9725: Invalid dependency determination
Date: 20 Feb 2003 10:57:02 +0200

 >>>>> "Jan" == Jan Beulich <JBeulich@novell.com> writes:
 
     Jan> Which doesn't work (and possibly doesn't have to as outlined in the
     Jan> other mail, depending on how you interpret the wording of the standard)
     Jan> when used as
 
     Jan>   (&u.s)->f1 = x;
     Jan>   (&u.s)->f2 = y;
 
 Then it's a bug. Try the same with shorts instead of bitfields.
 
 ~velco

Re: middle-end/9725: Invalid dependency determination

[Joseph S. Myers]

The following reply was made to PR middle-end/9725; it has been noted by GNATS.

From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Jan Beulich <JBeulich@novell.com>
Cc: <bangerth@ticam.utexas.edu>,  <velco@fadata.bg>,  <gcc-bugs@gcc.gnu.org>, 
     <gcc-gnats@gcc.gnu.org>
Subject: Re: middle-end/9725: Invalid dependency determination
Date: Thu, 20 Feb 2003 08:07:28 +0000 (GMT)

 On Wed, 19 Feb 2003, Jan Beulich wrote:
 
 > The structure does include two fields of type 'unsigned' (the fact that
 > they are bit fields doesn't alter their type as I view it). And, as
 
 It does alter their type; the standard is clear on this (and there are C90
 DRs confirming it).  (There are bugs in GCC relating to the types of
 bit-fields; Neil Booth had a patch for them but it was reverted because of
 problems with debug info generation.)
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk
 

Re: middle-end/9725: Invalid dependency determination

[Jan Beulich]

The following reply was made to PR middle-end/9725; it has been noted by GNATS.

From: "Jan Beulich" <JBeulich@novell.com>
To: <bangerth@ticam.utexas.edu>
Cc: <velco@fadata.bg>,<gcc-bugs@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org>
Subject: Re: middle-end/9725: Invalid dependency determination
Date: Thu, 20 Feb 2003 09:01:39 +0100

 Which is almost as bad as the memcpy approach - the thing to be created
 that way (i.e. through a macro) can't possibly be an lvalue when
 supposed to access more than something contained within a single
 byte...
 I realized a supposedly legal (and working) approach anyway (though I
 continue to believe that the original bitfield approach is legal, too -
 just that it doesn't work with gcc...): Instead of having a union of
 aliased type and aliasing structure, add a flexible array of the aliased
 type to the end of the aliasing structure.
 
 >>> Wolfgang Bangerth <bangerth@ticam.utexas.edu> 19.02.03 18:14:43
 >>>
 
 > of not using this logic - how do I access sub-fields of a built-in
 type
 
 Go through a char* which can alias everything. This special case exists
 
 for this particular purpose: accessing single bytes in other types.
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:           
 bangerth@ticam.utexas.edu 
                               www:
 http://www.ticam.utexas.edu/~bangerth/ 
 
 

Re: middle-end/9725: Invalid dependency determination

[Jan Beulich]

The following reply was made to PR middle-end/9725; it has been noted by GNATS.

From: "Jan Beulich" <JBeulich@novell.com>
To: <velco@fadata.bg>
Cc: <gcc-bugs@gcc.gnu.org>,<gcc-gnats@gcc.gnu.org>
Subject: Re: middle-end/9725: Invalid dependency determination
Date: Thu, 20 Feb 2003 08:39:50 +0100

 Which doesn't work (and possibly doesn't have to as outlined in the
 other mail, depending on how you interpret the wording of the standard)
 when used as
 
   (&u.s)->f1 = x;
   (&u.s)->f2 = y;
 
 which is (supposedly) equivalent to the use of the . operator...
 
 Jan
 
 >>> Momchil Velikov <velco@fadata.bg> 19.02.03 22:10:36 >>>
 >>>>> "Jan" == Jan Beulich <JBeulich@novell.com> writes:
 
     Jan> But why is the structure incompatible?
     Jan> "... an aggregate or union type that includes one of the
 aforementioned
     Jan> types among its
     Jan> members (including, recursively, a member of a subaggregate
 or
     Jan> contained union), ..."
 
 which means that you example should be coded as
 
 struct s
 {
   unsigned f1:16;
   unsigned f2:16;
 };
 
 void
 test (unsigned *pf, unsigned x, unsigned y)
 {
   union
   {
     unsigned f;
     struct s s;
   } u;
 
   u.s.f1 = x;
   u.s.f2 = y;
   
   *pf = u.f;
 }
 
 
 ~velco

Re: middle-end/9725: Invalid dependency determination

[Momchil Velikov]

The following reply was made to PR middle-end/9725; it has been noted by GNATS.

From: Momchil Velikov <velco@fadata.bg>
To: "Jan Beulich" <JBeulich@novell.com>
Cc: <bangerth@ticam.utexas.edu>, <gcc-bugs@gcc.gnu.org>,
	<gcc-gnats@gcc.gnu.org>
Subject: Re: middle-end/9725: Invalid dependency determination
Date: 19 Feb 2003 23:10:36 +0200

 >>>>> "Jan" == Jan Beulich <JBeulich@novell.com> writes:
 
     Jan> But why is the structure incompatible?
     Jan> "... an aggregate or union type that includes one of the aforementioned
     Jan> types among its
     Jan> members (including, recursively, a member of a subaggregate or
     Jan> contained union), ..."
 
 which means that you example should be coded as
 
 struct s
 {
   unsigned f1:16;
   unsigned f2:16;
 };
 
 void
 test (unsigned *pf, unsigned x, unsigned y)
 {
   union
   {
     unsigned f;
     struct s s;
   } u;
 
   u.s.f1 = x;
   u.s.f2 = y;
   
   *pf = u.f;
 }
 
 
 ~velco

Re: middle-end/9725: Invalid dependency determination

[Jan Beulich]

The following reply was made to PR middle-end/9725; it has been noted by GNATS.

From: "Jan Beulich" <JBeulich@novell.com>
To: <bangerth@ticam.utexas.edu>
Cc: <velco@fadata.bg>,<gcc-bugs@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org>
Subject: Re: middle-end/9725: Invalid dependency determination
Date: Wed, 19 Feb 2003 18:08:42 +0100

 But why is the structure incompatible?
 
 "... an aggregate or union type that includes one of the aforementioned
 types among its
 members (including, recursively, a member of a subaggregate or
 contained union), ..."
 
 The structure does include two fields of type 'unsigned' (the fact that
 they are bit fields doesn't alter their type as I view it). And, as
 already asked, when the second store is deemed non-conflicting, then why
 isn't the first store, too? And, with respect to the other mail - short
 of not using this logic - how do I access sub-fields of a built-in type
 (while the code I have to fix for others to overcome the optimizer
 problem uses ints, I'm really more interested in accessing sub-fields of
 floating point types (other than through memcpy-ing the float into and
 afterwards out of a structure)?
 
 Thanks, Jan
 
 >>> Wolfgang Bangerth <bangerth@ticam.utexas.edu> 19.02.03 17:59:46
 >>>
 
 > struct s {
 > 	unsigned f1:16;
 > 	unsigned f2:16;
 > };
 > 
 > void test(unsigned *pf, unsigned x, unsigned y) {
 > 	unsigned f;
 > 
 > 	((struct s*)&f)->f1 = x;
 > 	((struct s*)&f)->f2 = y;
 > 	*pf = f;
 > }
 
 You still try to access the bits of the unsigned int variable f through
 
 the bits of the incompatible structure s. Short answer: don't do that.
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:           
 bangerth@ticam.utexas.edu 
                               www:
 http://www.ticam.utexas.edu/~bangerth/ 
 
 

Re: middle-end/9725: Invalid dependency determination

[Wolfgang Bangerth]

The following reply was made to PR middle-end/9725; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Jan Beulich <JBeulich@novell.com>
Cc: velco@fadata.bg, <gcc-bugs@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org>
Subject: Re: middle-end/9725: Invalid dependency determination
Date: Wed, 19 Feb 2003 11:14:43 -0600 (CST)

 > of not using this logic - how do I access sub-fields of a built-in type
 
 Go through a char* which can alias everything. This special case exists 
 for this particular purpose: accessing single bytes in other types.
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 

Re: middle-end/9725: Invalid dependency determination

[Wolfgang Bangerth]

The following reply was made to PR middle-end/9725; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Jan Beulich <JBeulich@novell.com>
Cc: velco@fadata.bg, <gcc-bugs@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org>
Subject: Re: middle-end/9725: Invalid dependency determination
Date: Wed, 19 Feb 2003 10:59:46 -0600 (CST)

 > struct s {
 > 	unsigned f1:16;
 > 	unsigned f2:16;
 > };
 > 
 > void test(unsigned *pf, unsigned x, unsigned y) {
 > 	unsigned f;
 > 
 > 	((struct s*)&f)->f1 = x;
 > 	((struct s*)&f)->f2 = y;
 > 	*pf = f;
 > }
 
 You still try to access the bits of the unsigned int variable f through 
 the bits of the incompatible structure s. Short answer: don't do that.
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 

Re: middle-end/9725: Invalid dependency determination

[Wolfgang Bangerth]

The following reply was made to PR middle-end/9725; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Jan Beulich <JBeulich@novell.com>
Cc: gcc-bugs@gcc.gnu.org, <gcc-gnats@gcc.gnu.org>
Subject: Re: middle-end/9725: Invalid dependency determination
Date: Mon, 17 Feb 2003 10:49:29 -0600 (CST)

 > I was fearing you would say this. But I can in no way agree - the code
 > presented is valid C, and hence should work at any optimization level.
 
 What makes you think so? gcc's info pages show
 
 `-fstrict-aliasing'
      Allows the compiler to assume the strictest aliasing rules
      applicable to the language being compiled.  For C (and C++), this
      activates optimizations based on the type of expressions.  In
      particular, an object of one type is assumed never to reside at
      the same address as an object of a different type, unless the
      types are almost the same.  For example, an `unsigned int' can
      alias an `int', but not a `void*' or a `double'.  A character type
      may alias any other type.
 
 In your code you try to pretend that a variable of type "struct S" resides 
 at the place of a long long. That's exactly the case that's covered above, 
 which in turn exactly parallels what the standard says.
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 

Re: middle-end/9725: Invalid dependency determination

[bangerth]

Synopsis: Invalid dependency determination

State-Changed-From-To: open->closed
State-Changed-By: bangerth
State-Changed-When: Mon Feb 17 15:48:54 2003
State-Changed-Why:
    This is how aliasing is supposed to work. If you have a
    variable of type long long, don't access it as something
    else, or hell will break loose.
    
    If you need to play type games, use the "union" trick
    which should be described in the documentation.
    
    W.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9725

middle-end/9725: Invalid dependency determination

[jbeulich]

>Number:         9725
>Category:       middle-end
>Synopsis:       Invalid dependency determination
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 17 15:36:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Jan Beulich
>Release:        gcc-3.2.2
>Organization:
>Environment:
Cygwin host, various targets.
>Description:
The code below, compiled with -O2 (or -O1 -fstrict-aliasing)
causes the compiler to omit (or, in a non-contrived
environment) incorrectly schedule the second store. This
appears to be related to the incorrect assumption in
alias.c (three places) that different alias sets provide for
non-conflicting memory accesses; this isn't true if I
understand the concept of alias sets (as explained close to
the top of that file) correctly; instead, only the inverse
conclusion would guarantee correct code - if two accesses
are in the same alias set, then there potentially is a
conflict. However, the simple change to invert the tests
(and return values) in the three affected functions yields
various cases where scheduling non-conflicting stores ahead
of other operations is suppressed, so appearantly a better
than this trivial fix is needed.
An interesting (and worrying, at least to me) additional
note is that when the type of the second structure field
is 'unsigned char' the problem is not present.
>How-To-Repeat:
struct s {
	unsigned int h;
	unsigned short q;
};

void test(unsigned long long*pf, unsigned int h, unsigned short q) {
	unsigned long long f;

	((struct s*)&f)->h = h;
	((struct s*)&f)->q = q;
	*pf = f;
}
>Fix:
The simple (to at least guarantee correct code) but
inefficient fix is to invert (and move down as far as
possible the three instances of 
  if (DIFFERENT_ALIAS_SETS_P (x, mem))
    return 0;
to
  if (!DIFFERENT_ALIAS_SETS_P (x, mem))
    return 1;
in alias.c.
>Release-Note:
>Audit-Trail:
>Unformatted: