public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c/5157: bad static initialization of bit-fields after :0 field
@ 2003-01-01 21:29 neroden
  0 siblings, 0 replies; 3+ messages in thread
From: neroden @ 2003-01-01 21:29 UTC (permalink / raw)
  To: gcc-bugs, gcc-prs, kenistoj, nobody

Synopsis: bad static initialization of bit-fields after :0 field

State-Changed-From-To: feedback->closed
State-Changed-By: neroden
State-Changed-When: Wed Jan  1 13:29:33 2003
State-Changed-Why:
    No feedback for 9 months.

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: c/5157: bad static initialization of bit-fields after :0 field
@ 2002-04-26  2:13 rth
  0 siblings, 0 replies; 3+ messages in thread
From: rth @ 2002-04-26  2:13 UTC (permalink / raw)
  To: gcc-bugs, gcc-prs, kenistoj, nobody

Synopsis: bad static initialization of bit-fields after :0 field

State-Changed-From-To: open->feedback
State-Changed-By: rth
State-Changed-When: Fri Apr 26 02:13:26 2002
State-Changed-Why:
    The s390 port wasn't part of gcc for 2.95.3.
    Please try again with the 3.1 prerelease.

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* c/5157: bad static initialization of bit-fields after :0 field
@ 2001-12-18 10:36 kenistoj
  0 siblings, 0 replies; 3+ messages in thread
From: kenistoj @ 2001-12-18 10:36 UTC (permalink / raw)
  To: gcc-gnats


>Number:         5157
>Category:       c
>Synopsis:       bad static initialization of bit-fields after :0 field
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 18 10:36:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Jim Keniston
>Release:        gcc version 2.95.3 20010315 (release)
>Organization:
>Environment:
Reading specs from /usr/lib/gcc-lib/s390-ibm-linux/2.95.3/specs
gcc version 2.95.3 20010315 (release)
 /usr/lib/gcc-lib/s390-ibm-linux/2.95.3/cpp0 -lang-c -v -D__GNUC__=2 -D__GNUC_MINOR__=95 -Dlinux -D__s390__ -Dunix -D__ELF__ -D__linux__ -D__s390__ -D__unix__ -D__ELF__ -D__linux -D__unix -Asystem(linux) -Acpu(s390) -Amachi
ne(s390) -Asystem(unix) -D__CHAR_UNSIGNED__ bad3.c bad3.i
GNU CPP version 2.95.3 20010315 (release) (Linux for S/390)
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc-lib/s390-ibm-linux/2.95.3/../../../../s390-ibm-linux/include
 /usr/lib/gcc-lib/s390-ibm-linux/2.95.3/include
 /usr/include
End of search list.
The following default directories have been omitted from the search path:
 /usr/lib/gcc-lib/s390-ibm-linux/2.95.3/../../../../include/g++-3
 /usr/local/include
End of omitted list.
 /usr/lib/gcc-lib/s390-ibm-linux/2.95.3/cc1 bad3.i -fno-caller-saves -quiet -dumpbase bad3.c -version -o bad3.s
GNU C version 2.95.3 20010315 (release) (s390-ibm-linux) compiled by GNU C version 2.95.3 20010315 (release).
 as -V -Qy -o bad3.o bad3.s
GNU assembler version 2.11.92.0.10 (s390-ibm-linux) using BFD version 2.11.92.0.10 20011021
 /usr/lib/gcc-lib/s390-ibm-linux/2.95.3/collect2 -m elf_s390 -dynamic-linker /lib/ld.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/s390-ibm-linux/2.95.3/crtbegin.o -L/usr/lib/gcc-lib/s390-ibm-linux/2.95.3 bad3.o -lg
cc -lc -lgcc /usr/lib/gcc-lib/s390-ibm-linux/2.95.3/crtend.o /usr/lib/crtn.o
>Description:
On an s390 system, static initialization of a struct
containing bit-fields is sometimes confused by a zero-length
bit-field.  In particular, the bit-field following the
zero-length bit-field is often initialized incorrectly.  If
I initialize the struct's fields using assignment
statements, I don't see the bug.

Hartmut Penner (GCC for S/390 Development) says: "I think
this is not a backend problem, but a problem in gcc-2.95.3.
On my Linux intel system, your testcase also generates bad
code.  The produced code looks pretty strange. You should
post it on the gcc mailing list Link found under
gcc.gnu.org."
>How-To-Repeat:
With gcc on an x86 system, I get the expected behavior:
cc bad3.c
./a.out
i1 = 1
i2 = 1
i3 = 1
On an s390 system, I get:
cc bad3.c
./a.out
i1 = 1
i2 = 0
i3 = 1
----- bad3.c -----
extern int printf(const char *format, ...);
extern void exit(int status);

struct bf1 {
        int     i1:3;
        int     :0;
        int     i2:3;
        int     i3:3;
};

struct bf1 v1 = {1, 1, 1};

main()
{
        printf("i1 = %d\n", v1.i1);
        printf("i2 = %d\n", v1.i2);
        printf("i3 = %d\n", v1.i3);
        exit(0);
}
>Fix:
Fix: unknown.  Workaround: Initialize the struct using
assignment statements.
>Release-Note:
>Audit-Trail:
>Unformatted:


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2003-01-01 21:29 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-01 21:29 c/5157: bad static initialization of bit-fields after :0 field neroden
  -- strict thread matches above, loose matches on Subject: below --
2002-04-26  2:13 rth
2001-12-18 10:36 kenistoj

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).