[Bug c/31541] New: cannot take address of bit field

[Bug c/31541] New: cannot take address of bit field

[malitzke at metronets dot com]

i686-pc-linux-gnu-gcc: warning: -pipe ignored because -save-temps specified
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.0/configure
--mandir=/usr/share/i686-pc-linux-gnu/4.3.0/man
--infodir=/usr/share/i686-pc-linux-gnu/4.3.0/info --prefix=/usr
--host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --build=i686-pc-linux-gnu
--disable-nls --disable-checking --disable-multilib --disable-werror
--enable-shared --enable-libgcc-math --enable-tls --enable-threads=posix
--enable-bootstrap --enable-__cxa_atexit --enable-languages=c,c++,fortran
--with-cpu=pentium3 --enable-clocale=gnu
Thread model: posix
gcc version 4.3.0 20070411 (experimental)
 /usr/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -E -quiet -v -IOBJ/x86-linux-cc
-I../incs/x86-linux-cc -I../include -I../libscg -I../cdrecord
-D__attribute_const__=const -DSCHILY_BUILD -DFIFO
-DCD_DEVICE="yourSCSI_Bus,yourSCSI_ID,yourSCSI_LUN" -DFILENAME="audio"
-DUNDERSAMPLING=1
-DVERSION="2.01.01a25_linux_2.6.20.4a_i686_pentium-iii--katmai-" -DBITS_P_S=16
-DCHANNELS=2 -DAUDIOTYPE="wav" -DDURATION=0 -DDEF_INTERFACE="generic_scsi"
-DUSE_PARANOIA=1 -DDEFAULT_SPEED=0 -DCDINDEX_SUPPORT -DCDDB_SUPPORT
-DCDDBHOST="freedb.freedb.org" -DCDDBPORT=8880 -DHAVE_IOCTL_INTERFACE
-DECHO_TO_SOUNDCARD -DSOUND_DEV="/dev/dsp" -DNSECTORS=75 -DINFOFILES
-DMD5_SIGNATURES -DAUX_DEVICE="/dev/cdrom" -DSCHILY_PRINT scsi_cdr.c
-march=pentium3 -finput-charset=ISO-8859-1 -fexec-charset=UTF-8 -O -O2
-fpch-preprocess -o scsi_cdr.i
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 OBJ/x86-linux-cc
 ../incs/x86-linux-cc
 ../include
 ../libscg
 ../cdrecord
 /usr/local/include
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include-fixed
 /usr/include
End of search list.
 /usr/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -fpreprocessed scsi_cdr.i -quiet
-dumpbase scsi_cdr.c -march=pentium3 -auxbase-strip OBJ/x86-linux-cc/scsi_cdr.o
-O -O2 -version -finput-charset=ISO-8859-1 -fexec-charset=UTF-8 -o scsi_cdr.s
GNU C version 4.3.0 20070411 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 4.3.0 20070411 (experimental).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: bf863a5feb01e9874cf4d63968228528
scsi_cdr.c: In function 'select_secsize':
scsi_cdr.c:2063: error: cannot take address of bit-field 'sense_data_len'
scsi_cdr.c:2063: error: cannot take address of bit-field 'sense_data_len'
scsi_cdr.c:2063: error: cannot take address of bit-field 'sense_data_len'


This is from cdr-tools-2.01.01_alpha255. It compiled OK with the gcc-4.2.0
branch. I had a hard time getting Schily's nested makefiles to give me a
required scs_cdr.i output. My attempts at reducing were fruitless.


-- 
           Summary: cannot take address of bit field
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: malitzke at metronets dot com
 GCC build triplet: i686-pc-linux-gcc
  GCC host triplet: i686-pc-linux-gcc
GCC target triplet: i686-pc-linux-gcc


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

[Bug c/31541] cannot take address of bit field

[malitzke at metronets dot com]

------- Comment #1 from malitzke at metronets dot com  2007-04-11 21:25 -------
Created an attachment (id=13352)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13352&action=view)
required "i" file

Unreduced, as a user of gcc I am not up to the task


-- 


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2007-04-11 21:43 -------
Reduced testcase:
typedef unsigned char Uchar;
struct scsi_mode_header {
 unsigned char sense_data_len : 8;
};
int f(void)
{
 struct scsi_mode_header md;
return *(Uchar*)&md;
}


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
          Component|c                           |middle-end
     Ever Confirmed|0                           |1
  GCC build triplet|i686-pc-linux-gcc           |
   GCC host triplet|i686-pc-linux-gcc           |
 GCC target triplet|i686-pc-linux-gcc           |
           Keywords|                            |rejects-valid
   Last reconfirmed|0000-00-00 00:00:00         |2007-04-11 21:43:06
               date|                            |
            Summary|cannot take address of bit  |[4.3 Regression] cannot take
                   |field                       |address of bit field
   Target Milestone|---                         |4.3.0


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2007-04-15 01:30 -------
DECL_BIT_FIELD is false for this decl but bit_field_type is true.


-- 


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2007-04-15 01:36 -------
And the reason is:
          /* See if we can use an ordinary integer mode for a bit-field.
             Conditions are: a fixed size that is correct for another mode
             and occupying a complete byte or bytes on proper boundary.  */


So we have to check DECL_BIT_FIELD_TYPE also.
I have a patch.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2007-04-21 23:33 -------
I am finally getting around to testing the patch (been busy with a release of
our own toolchain last week).


-- 


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2007-04-22 09:10 -------
*** Bug 31654 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcb314 at hotmail dot com


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[dcb314 at hotmail dot com]

------- Comment #7 from dcb314 at hotmail dot com  2007-06-12 16:05 -------
(In reply to comment #5)
> I am finally getting around to testing the patch (been busy with a release of
> our own toolchain last week).

I can confirm that this bug still exists in gcc snapshot
20070608.

Is it significant that the last couple of months 
of gcc 4.3 haven't been able to compile recent
Linux kernels ?


-- 


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2007-06-21 11:19 -------
Ping?


-- 

rguenth at gcc dot gnu dot org changed:

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


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[hubicka at ucw dot cz]

------- Comment #9 from hubicka at ucw dot cz  2007-06-21 14:39 -------
Subject: Re:  [4.3 Regression] cannot take address of bit field

> 
> 
> ------- Comment #8 from rguenth at gcc dot gnu dot org  2007-06-21 11:19 -------
> Ping?

I tought the bug is long fixed by moving the folding from fold into
Gimple fold_stmt.  We probably should not emit frontend warnings/errors
that late, I will check if I can get it done earlier at gimplification
time.  Otherwise Andrew's patch to avoid the folding for bit_field_type
is probably way to go.

Honza


-- 


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[rguenther at suse dot de]

------- Comment #10 from rguenther at suse dot de  2007-06-21 14:52 -------
Subject: Re:  [4.3 Regression] cannot take address of
 bit field

On Thu, 21 Jun 2007, hubicka at ucw dot cz wrote:

> 
> 
> ------- Comment #9 from hubicka at ucw dot cz  2007-06-21 14:39 -------
> Subject: Re:  [4.3 Regression] cannot take address of bit field
> 
> > 
> > 
> > ------- Comment #8 from rguenth at gcc dot gnu dot org  2007-06-21 11:19 -------
> > Ping?
> 
> I tought the bug is long fixed by moving the folding from fold into
> Gimple fold_stmt.  We probably should not emit frontend warnings/errors
> that late, I will check if I can get it done earlier at gimplification
> time.  Otherwise Andrew's patch to avoid the folding for bit_field_type
> is probably way to go.

The bug is still there and we fail to build the kernel because of it 
still.

Richard.


-- 


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[malitzke at metronets dot com]

------- Comment #11 from malitzke at metronets dot com  2007-06-21 21:13 -------
After you solve that there is that little matter of udivdi3.


-- 


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[hubicka at ucw dot cz]

------- Comment #12 from hubicka at ucw dot cz  2007-06-22 09:35 -------
Subject: Re:  [4.3 Regression] cannot take address of bit field

Hi,
I've experimented with this a bit - the problem is that the error is
produced during gimplification: gimplifier translates the expression
into the addr_expr form and later gimplifying the addr_expr it calls the
mark_addressable langhook that porudces the error.

It seems to me that this langhook call is unnecesary.  Removing it
breaks since C++ is sometimes producing references to objects not having
addr_expr during gimplification, but it seems to me that adding just
generic code that takes gimple addr_expr and marks bit addressable (just
as aliasing does) instead the full blown langhook should just work?

THe typechecking in frontend should be enough to catch this sort of
syntax errors (when address is taken form something language prohibits).
Does this seem sane?

Honza


-- 


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[hubicka at ucw dot cz]

------- Comment #13 from hubicka at ucw dot cz  2007-06-22 09:36 -------
Subject: Re:  [4.3 Regression] cannot take address of bit field

> After you solve that there is that little matter of udivdi3.
udivdi3?


-- 


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[rguenther at suse dot de]

------- Comment #14 from rguenther at suse dot de  2007-06-22 09:45 -------
Subject: Re:  [4.3 Regression] cannot take address of
 bit field

On Fri, 22 Jun 2007, hubicka at ucw dot cz wrote:

> ------- Comment #12 from hubicka at ucw dot cz  2007-06-22 09:35 -------
> Subject: Re:  [4.3 Regression] cannot take address of bit field
> 
> Hi,
> I've experimented with this a bit - the problem is that the error is
> produced during gimplification: gimplifier translates the expression
> into the addr_expr form and later gimplifying the addr_expr it calls the
> mark_addressable langhook that porudces the error.
> 
> It seems to me that this langhook call is unnecesary.  Removing it
> breaks since C++ is sometimes producing references to objects not having
> addr_expr during gimplification, but it seems to me that adding just
> generic code that takes gimple addr_expr and marks bit addressable (just
> as aliasing does) instead the full blown langhook should just work?
> 
> THe typechecking in frontend should be enough to catch this sort of
> syntax errors (when address is taken form something language prohibits).
> Does this seem sane?

Yes.  It looks like a frontend bug if the tree was not marked addressable
before gimplification but would need to after.

Richard.


-- 


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[malitzke at metronets dot com]

------- Comment #15 from malitzke at metronets dot com  2007-06-22 12:51 -------
> > After you solve that there is that little matter of udivdi3.
> udivdi3?

In comment 7 somebody (dcb) remarked about PR31654 (marked duplicate to this
bug) was impeding kernel compilation. In comment 10 it was reiterated that the
importance of the present bug related to kernel compilation. At least for the
x86 kernels I never got to the present bug because with gcc-4.3 there is the
ugly fact that a recognized __stupid__ and unwarranted optimization per PR31990
downgraded to less than trivial status as an enhancement in PR32044 is impeding
kernel compilation. Great fun (not function).


-- 


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[hubicka at ucw dot cz]

------- Comment #16 from hubicka at ucw dot cz  2007-06-22 23:59 -------
Subject: Re:  [4.3 Regression] cannot take address of bit field

> 
> Yes.  It looks like a frontend bug if the tree was not marked addressable
> before gimplification but would need to after.

This does not seem to be so easy, sadly.  The occurences of missing
addressables are in a cases gimplifier expanding stuff into address
expression (so the address is not strictly taken in the language sense)

The attached patch bootstraps/regtests. I am simply using the gimple
code a-la ssa-alias.c to set the addressable flag instead of hooking
into frontend.

In some sense I like it because I don't think frontends needs to be in
busyness in computing TREE_ADDRESSABLE bit for middle end. On the other
hand I guess I should spend some time tomorrow to produce simple C++
testcases where the FE fails to set the bit.


Index: gimplify.c
===================================================================
--- gimplify.c  (revision 125921)
+++ gimplify.c  (working copy)
@@ -117,6 +117,17 @@ static enum gimplify_status gimplify_com
 static bool cpt_same_type (tree a, tree b);
 #endif

+/* Mark X addressable.  Unlike the langhook we expect X to be in gimple
+   form and we don't do any syntax checking.  */
+static void
+mark_addressable (tree x)
+{
+  while (handled_component_p (x))
+    x = TREE_OPERAND (x, 0);
+  if (TREE_CODE (x) != VAR_DECL && TREE_CODE (x) != PARM_DECL)
+    return ;
+  TREE_ADDRESSABLE (x) = 1;
+}

 /* Return a hash value for a formal temporary table entry.  */

@@ -3434,7 +3445,7 @@ gimplify_modify_expr_rhs (tree *expr_p, 
            if (use_target)
              {
                CALL_EXPR_RETURN_SLOT_OPT (*from_p) = 1;
-               lang_hooks.mark_addressable (*to_p);
+               mark_addressable (*to_p);
              }
          }

@@ -3957,6 +3968,8 @@ gimplify_addr_expr (tree *expr_p, tree *
         the address of a call that returns a struct; see
         gcc.dg/c99-array-lval-1.c.  The gimplifier will correctly make
         the implied temporary explicit.  */
+
+      /* Mark the RHS addressable.  */
       ret = gimplify_expr (&TREE_OPERAND (expr, 0), pre_p, post_p,
                           is_gimple_addressable, fb_either);
       if (ret != GS_ERROR)
@@ -3972,8 +3985,7 @@ gimplify_addr_expr (tree *expr_p, tree *
             is set properly.  */
          recompute_tree_invariant_for_addr_expr (expr);

-         /* Mark the RHS addressable.  */
-         lang_hooks.mark_addressable (TREE_OPERAND (expr, 0));
+         mark_addressable (TREE_OPERAND (expr, 0));
        }
       break;
     }
@@ -4011,7 +4023,7 @@ gimplify_asm_expr (tree *expr_p, tree *p
                               &allows_mem, &allows_reg, &is_inout);

       if (!allows_reg && allows_mem)
-       lang_hooks.mark_addressable (TREE_VALUE (link));
+       mark_addressable (TREE_VALUE (link));

       tret = gimplify_expr (&TREE_VALUE (link), pre_p, post_p,
                            is_inout ? is_gimple_min_lval : is_gimple_lvalue,
@@ -4140,7 +4152,7 @@ gimplify_asm_expr (tree *expr_p, tree *p
        {
          tret = gimplify_expr (&TREE_VALUE (link), pre_p, post_p,
                                is_gimple_lvalue, fb_lvalue | fb_mayfail);
-         lang_hooks.mark_addressable (TREE_VALUE (link));
+         mark_addressable (TREE_VALUE (link));
          if (tret == GS_ERROR)
            {
              error ("memory input %d is not directly addressable", i);
@@ -5562,7 +5574,7 @@ gimplify_expr (tree *expr_p, tree *pre_p
          if (fallback == fb_lvalue)
            {
              *expr_p = get_initialized_tmp_var (*expr_p, pre_p, post_p);
-             lang_hooks.mark_addressable (*expr_p);
+             mark_addressable (*expr_p);
            }
          break;

@@ -5575,7 +5587,7 @@ gimplify_expr (tree *expr_p, tree *pre_p
          if (fallback == fb_lvalue)
            {
              *expr_p = get_initialized_tmp_var (*expr_p, pre_p, post_p);
-             lang_hooks.mark_addressable (*expr_p);
+             mark_addressable (*expr_p);
            }
          break;

@@ -5763,7 +5775,7 @@ gimplify_expr (tree *expr_p, tree *pre_p
          else if (fallback == fb_lvalue)
            {
              *expr_p = get_initialized_tmp_var (*expr_p, pre_p, post_p);
-             lang_hooks.mark_addressable (*expr_p);
+             mark_addressable (*expr_p);
            }
          else
            ret = GS_ALL_DONE;


-- 


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[rguenth at gcc dot gnu dot org]

------- Comment #17 from rguenth at gcc dot gnu dot org  2007-06-23 08:56 -------
The patch looks reasonable and is ok if you add the testcase from comment #2
and
it bootstraps&regtests.  Thanks.


-- 


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[hubicka at gcc dot gnu dot org]

------- Comment #18 from hubicka at gcc dot gnu dot org  2007-06-23 11:58 -------
Subject: Bug 31541

Author: hubicka
Date: Sat Jun 23 11:58:18 2007
New Revision: 125971

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125971
Log:

        PR middle-end/31541
        * gimplify.c (mark_addressable): New function.
        (gimplify_modify_expr_rhs, gimplify_addr_expr, gimplify_expr): Use it.

        * gcc.c-torture/compile/pr31541.c: New.

Added:
    trunk/gcc/testsuite/gcc.c-torture/compile/pr31541.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gimplify.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[malitzke at metronets dot com]

------- Comment #19 from malitzke at metronets dot com  2007-06-23 15:39 -------
Thank you Mr Hubicka for solving this. I had earlier used your patch from
comment 16 but i had to apply it by hand as my patch-2.5.9 (Larry Wall) would
take that published patch even after html2text; changing --- gimplify.c to
gimplify.c.old; deleting all text after the second @@. Maybe what is published
on bugzilla is no intended for outsiders like myself and works only with CVS,
subversion. However, doing it by hand enabled me to compile cdrutils
(Schilling) and erase an CD-RW.

Could you or somebody else clarify what patch program to use or state that
original reporters of PR's should refrain from using the posted patches.

Now to comments 7, 10, 11, 13, 15 the vital difference is that _dcb_ and
apparently Mr Guenther used a 64-bit machine while I am using a 32-bit. 

Question is it the policy of the gcc community to render all 32-bit machines
obsolete for later versions of gcc-4.{3-9}.x? just like certain C constructs
are first marked as disparaged and subsequently rendered unacceptable.

I believe that the requested clarification should be made available to users at
large. Thanks again.


-- 


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[rguenther at suse dot de]

------- Comment #20 from rguenther at suse dot de  2007-06-23 15:42 -------
Subject: Re:  [4.3 Regression] cannot take address of
 bit field

On Sat, 23 Jun 2007, malitzke at metronets dot com wrote:

> Question is it the policy of the gcc community to render all 32-bit machines
> obsolete for later versions of gcc-4.{3-9}.x? just like certain C constructs
> are first marked as disparaged and subsequently rendered unacceptable.

No, what get's you to this thought?

Richard.


-- 


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

[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field

[rguenth at gcc dot gnu dot org]

------- Comment #21 from rguenth at gcc dot gnu dot org  2007-06-23 15:59 -------
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

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


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