[Bug c/92684] New: bitfield behavior not matching the declared type

2019-11-26 Thread wuxb45 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92684

Bug ID: 92684
   Summary: bitfield behavior not matching the declared type
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wuxb45 at gmail dot com
  Target Milestone: ---

found wrong data when compiled by gcc 9.2.0 (x86_64, -std=gnu11). Have not
tried other gcc versions. The results are correct on clang 8.0.1.

Long story short: some bits are missing when using bitfields with uint64_t as
the declared type. Maybe I should use a (u64) cast on every dereference to
those fields. But the results are not always wrong. Maybe I should read some
C11 specs. But consider the different behaviors between gcc and clang, I decide
to report a bug here in hope to get some better help. Thanks.

This reproduces the results: gcc/clang -std=gnu11 main.c

#include 
#include 
#include 
typedef uint64_t u64;

struct st {
  union {
struct {
  u64 v1:19;
  u64 v2:45;
};
void * ptr;
  };
};

struct bits {
  u64 bit1:1;
  u64 bitx:63;
};

  int
main(void)
{
  char * val = "0xfff8";
  // x has 48 valid bits, the three low bits are 0s
  volatile u64 x = strtoull(val, NULL, 16);
  printf("%lx\n", x);
  // st stores that 45 bits
  struct st st = {.v1 = 0, .v2 = (x >> 3)};
  printf("%p\n", st.ptr);
  // y should get the original bits; but the three high bits are gone.
  u64 y = st.v2 << 3;
  printf("%lx\n", y);


  // this is another (minor) related case.
  // some are correct and some are wrong.
  struct bits b = {.bit1 = 1, .bitx = 0};
  // this is more interesting. gcc shows "8000", clang shows "1"
  printf("%lx %lx %lx\n", b.bit1, b.bit1 << 1, b.bit1 << 63);
  return 0;
}

[Bug c/49360] New: generate wrong logic code

2011-06-09 Thread wuxb45 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49360

   Summary: generate wrong logic code
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wux...@gmail.com


GCC version 4.6.0.

bug description:
gcc : *mipsel* cross compiler
in objdumped files :

=
bfc0003c:afc40018 swa0,24(s8)
bfc00040:afc5001c swa1,28(s8)
/home/wuxb/workspace/gcc/test_1001/mips_1001.c:5
int a, b, temp;
if(num1n2*/
bfc00044:8fc30018 lwv1,24(s8)
bfc00048:8fc2001c lwv0,28(s8)
bfc0004c: nop
bfc00050:0062102a sltv0,v1,v0
bfc00054:104a beqzv0,bfc00080 
=
the logic int code was
if (num1 < num2) {do-sth.}
but in the generated code, it is
if (! (num1 < num2) {do-sth.}
in line , the instruction should be "bnez".


*
appendix :
*
GCC version 4.6.0. with binutils-2.21.1

System type: fedora 15 64bit, x86_64.
build a cross compile for 'mipsel'
config params:
> export PREFIX=/home/wuxb/.mipsgcc0
> export TARGET=mipsel-gnu-linux
> ../gcc-4.6.0/configure --prefix=$PREFIX --target=$TARGET


*


*
Makefile
*
.PHONY : all
SHAREFILES = ../global
CROSS = mipsel-gnu-linux-
CC = $(CROSS)gcc
LD = $(CROSS)ld
AS = $(CROSS)as
OBJCOPY = $(CROSS)objcopy
OBJDUMP = $(CROSS)objdump
INCLUDE = -I$(SHAREFILES)
CFLAGS = -v -save-temps -Wall -g -fno-builtin -fno-pic -mno-abicalls $(INCLUDE)
ASFLAGS = -gstabs -fno-pic -mno-abicalls -D__ASSEMBLY__ $(INCLUDE)
LDFLAGS = -T $(SHAREFILES)/mips.lds
COPYFLAGS = --gap-fill=0xff -O binary
BINELF = bin.elf
BINBIN = bin.bin
GLOBALSOURCES = $(SHAREFILES)/head.S
SOURCES = $(GLOBALSOURCES) mips_1001.c
ALLDEP = Makefile.dep

# .c -> .o, .s -> .o
OBJECTS = $(patsubst %.c, %.o, $(patsubst %.S, %.o, $(SOURCES)))
DEPENDS = $(patsubst %.o, %.d, $(OBJECTS)

all : $(ALLDEP) $(BINBIN)
$(BINBIN) : $(BINELF)
$(OBJCOPY) $(COPYFLAGS) $^ $@

$(BINELF) : $(OBJECTS)
$(LD) -o $@ $(LDFLAGS) $^
$(OBJDUMP) -lDS $@ > $@.txt

%.o : %.c
$(CC) $(CFLAGS) -c $< -o $@ 

%.o : %.S
$(CC) $(ASFLAGS) -c $< -o $@

$(ALLDEP) : $(SOURCES)
$(CC) $(CFLAGS) -MM $^ > $@
sinclude $(ALLDEP)

clean:
rm -vf $(OBJECTS) $(BINBIN) $(BINELF) $(ALLDEP)
*
end
*


*
file:test_1001.c
*
#include 
long lcm(long num1,long num2)
{
int a, b, temp;
if(num1n2*/
{
temp=num1; 
num1=num2;
num2=temp; /*swap*/
}
a=num1;//big
b=num2;//small
while(b!=0) /*gcd*/
{
temp=a%b;
a=b;
b=temp;
}
return num1*num2 / a;
}
long test (long a, long b)
{
return a+b;
}
int main()
{
int i, n = 0;
long a, b, g;
a = 123;
b = 321;
g = lcm(a, b);

uput(g);
return 0;
}
*
end
*



*
file:test_1001.i
*
# 1 "mips_1001.c"
# 1 "/home/wuxb/workspace/gcc/test_1001//"
# 1 ""
# 1 "<命令行>"
# 1 "mips_1001.c"
# 1 "../global/rawapi.h" 1

extern void uput(unsigned int value);
# 2 "mips_1001.c" 2
long lcm(long num1,long num2)
{
int a, b, temp;
if(num1:
../global/head.S:18
nop
.global uput
uput:
lui t0, 0xa000
sw a0, 0x700(t0)
jr ra
bfc0:3c10a000 luis0,0xa000
bfc4:2610fff0 addius0,s0,-16
bfc8:0200e821 movesp,s0
bfcc:1055 bbfc00164 
bfc00010: nop
...

bfc0001c :
bfc0001c:3c08a000 luit0,0xa000
bfc00020:ad040700 swa0,1792(t0)
bfc00024:03e8 jrra
bfc00028: nop
bfc0002c: nop

bfc00030 :
lcm():
/home/wuxb/workspace/gcc/test_1001/mips_1001.c:3
#include 
long lcm(long num1,long num2)
{
bfc00030:27bdffe8 addiusp,sp,-24
bfc00034:afbe0014 sws8,20(sp)
bfc00038:03a0f021 moves8,sp
bfc0003c:afc40018 swa0,24(s8)
bfc00040:afc5001c swa1,28(s8)
/home/wuxb/workspace/gcc/test_1001/mips_1001.c:5
int a, b, temp;
if(num1n2*/
bfc00044:8fc30018 lwv1,24(s8)
bfc00048:8fc2001c lwv0,28(s8)
bf

[Bug c/49360] generate wrong logic code

2011-06-09 Thread wuxb45 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49360

Wu Xingbo  changed:

   What|Removed |Added

 Target||mipsel-gnu-linux
   Host||Fedora 15 x86_64
  Build||Fedora 15 x86_64

--- Comment #1 from Wu Xingbo  2011-06-10 06:29:00 UTC 
---
long lcm(long num1,long num2)
{
int a, b, temp;
/***here*/
if(num1n2*/
{
temp=num1; 
num1=num2;
num2=temp; /*swap*/
}
//
/***generates the logic:*/
if(!(num1

[Bug c/49360] generate wrong logic code

2011-06-09 Thread wuxb45 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49360

Wu Xingbo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Wu Xingbo  2011-06-10 06:55:56 UTC 
---
Sorry! my mistake.