[Bug bootstrap/111141] Compiling gcc-13.2.0 on Ubuntu 22.04.3 LTS, problem asm-generic/errno.h

[etienne_lorrain at yahoo dot fr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41

--- Comment #3 from etienne_lorrain at yahoo dot fr ---
Just reporting that the problem do not appears when --disable-multilib is asked
at the configure stage.
Unlike for ARM64 host compiling a native compiler, you need to say such
--disable-multilib for amd64 compiling a native compiler.

[Bug bootstrap/111141] New: Compiling gcc-13.2.0 on Ubuntu 22.04.3 LTS, problem asm-generic/errno.h

[etienne_lorrain at yahoo dot fr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41

Bug ID: 41
   Summary: Compiling gcc-13.2.0 on Ubuntu 22.04.3 LTS, problem
asm-generic/errno.h
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: etienne_lorrain at yahoo dot fr
  Target Milestone: ---

On Ubuntu 22.04.3 LTS,Compiling gcc-13.2.0 by:
wget https://ftp.gnu.org/gnu/gcc/gcc-13.2.0/gcc-13.2.0.tar.xz
tar xf gcc-13.2.0.tar.xz
cd gcc-13.2.0/
./contrib/download_prerequisites
cd ..
mkdir gcc_build
cd gcc_build
../../gcc-13.2.0/configure --enable-languages=c,c++,fortran
time make -j 32

Fails with:

In file included from /usr/include/bits/errno.h:26,
 from /usr/include/errno.h:28,
 from ../../../../gcc-13.2.0/libgcc/../gcc/tsystem.h:93,
 from ../../../../gcc-13.2.0/libgcc/generic-morestack.c:32:
/usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file or
directory
1 | #include 
  |  ^
compilation terminated.
make[5]: *** [../../../../gcc-13.2.0/libgcc/shared-object.mk:14:
generic-morestack.o] Error 1
make[5]: Leaving directory
'/home/etienne/aaa/gcc_build/x86_64-pc-linux-gnu/32/libgcc'
make[4]: *** [Makefile:1214: multi-do] Error 1
make[4]: Leaving directory
'/home/etienne/aaa/gcc_build/x86_64-pc-linux-gnu/libgcc'
make[3]: *** [Makefile:127: all-multi] Error 2
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory
'/home/etienne/aaa/gcc_build/x86_64-pc-linux-gnu/libgcc'
make[2]: *** [Makefile:24671: all-stage1-target-libgcc] Error 2
make[2]: Leaving directory '/home/etienne/aaa/gcc_build'
make[1]: *** [Makefile:30190: stage1-bubble] Error 2
make[1]: Leaving directory '/home/etienne/aaa/gcc_build'
make: *** [Makefile:1088: all] Error 2

real1m7.737s
user8m1.657s
sys 1m2.220s

Host compiler being:
$ /usr/bin/gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

We do have on host a file: /usr/include/asm-generic/errno.h

At some point the "-generic" part was modified by default creating a link "asm
-> asm-target", but I am not sure now that 64 bits compiler been able to
compile 32 bits, the -generic has or not changed meaning...

In short I am not sure that is a GCC bug or a Ubuntu bug...

[Bug bootstrap/111027] [11/12/13/14 Regression] `make install` touches the build directory; Install error "tmp-header-vars: Permission denied", build on NFS, improvement possible

[etienne_lorrain at yahoo dot fr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111027

--- Comment #5 from etienne_lorrain at yahoo dot fr ---
Hello, full recompilation from source finished (your patch included), same
setup with NFS without "no_root_squash" on /home/parallella/veg, installation
goes further but stop at:

$ echo parallella | sudo -S make install

 /bin/mkdir -p '/usr/local/lib/.'
 /bin/sh ./libtool   --mode=install /usr/bin/install -c   libcc1.la
'/usr/local/lib/.'
libtool: install: warning: relinking `libcc1.la'
libtool: install: (cd /home/parallella/vega/gcc_build1/libcc1; /bin/sh
/home/parallella/vega/gcc_build1/libcc1/libtool  --tag CXX --mode=relink
/home/parallella/vega/gcc_build1/./gcc/xg++
-B/home/parallella/vega/gcc_build1/./gcc/ -nostdinc++ -nostdinc++
-I/home/parallella/vega/gcc_build1/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/armv7l-unknown-linux-gnueabihf
-I/home/parallella/vega/gcc_build1/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include
-I/home/parallella/vega/gcc-13.2.0/libstdc++-v3/libsupc++
-I/home/parallella/vega/gcc-13.2.0/libstdc++-v3/include/backward
-I/home/parallella/vega/gcc-13.2.0/libstdc++-v3/testsuite/util
-L/home/parallella/vega/gcc_build1/armv7l-unknown-linux-gnueabihf/libstdc++-v3/src
-L/home/parallella/vega/gcc_build1/armv7l-unknown-linux-gnueabihf/libstdc++-v3/src/.libs
-L/home/parallella/vega/gcc_build1/armv7l-unknown-linux-gnueabihf/libstdc++-v3/libsupc++/.libs
-B/home/parallella/vega/gcc_build1/armv7l-unknown-linux-gnueabihf/libstdc++-v3/src/.libs
-B/home/parallella/vega/gcc_build1/armv7l-unknown-linux-gnueabihf/libstdc++-v3/libsupc++/.libs
-B/usr/local/armv7l-unknown-linux-gnueabihf/bin/
-B/usr/local/armv7l-unknown-linux-gnueabihf/lib/ -isystem
/usr/local/armv7l-unknown-linux-gnueabihf/include -isystem
/usr/local/armv7l-unknown-linux-gnueabihf/sys-include -W -Wall
-fvisibility=hidden -g -O2 -D_GNU_SOURCE -module -export-symbols
../../gcc-13.2.0/libcc1/libcc1.sym -Xcompiler -static-libstdc++ -Xcompiler
-static-libgcc -o libcc1.la -rpath /usr/local/lib/. findcomp.lo libcc1.lo
libcp1.lo compiler.lo names.lo callbacks.lo connection.lo marshall.lo
-Wc,../libiberty/pic/libiberty.a )
mv: cannot move 'libcc1.so.0.0.0' to 'libcc1.so.0.0.0U': Permission denied
libtool: install: error: relink `libcc1.la' with the above command before
installing it
Makefile:497: recipe for target 'install-cc1libLTLIBRARIES' failed
make[3]: *** [install-cc1libLTLIBRARIES] Error 1
make[3]: Leaving directory '/home/parallella/vega/gcc_build1/libcc1'
Makefile:694: recipe for target 'install-am' failed
make[2]: *** [install-am] Error 2
make[2]: Leaving directory '/home/parallella/vega/gcc_build1/libcc1'
Makefile:20708: recipe for target 'install-libcc1' failed
make[1]: *** [install-libcc1] Error 2
make[1]: Leaving directory '/home/parallella/vega/gcc_build1'
Makefile:2632: recipe for target 'install' failed
make: *** [install] Error 2

I am keeping the setup ready for more patch in case it is needed, if your have
another change to try...

[Bug bootstrap/111027] [11/12/13/14 Regression] `make install` touches the build directory; Install error "tmp-header-vars: Permission denied", build on NFS, improvement possible

[etienne_lorrain at yahoo dot fr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111027

--- Comment #4 from etienne_lorrain at yahoo dot fr ---
Parallella box is free again.
Proposed patch (with a slight offset) is recompiling, result in 2065m36.178s...

[Bug other/111027] New: Install error "tmp-header-vars: Permission denied", build on NFS, improvement possible

[etienne_lorrain at yahoo dot fr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111027

Bug ID: 111027
   Summary: Install error "tmp-header-vars: Permission denied",
build on NFS, improvement possible
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: etienne_lorrain at yahoo dot fr
  Target Milestone: ---

On an ARM32 Linux system just installed, i.e. parallellla board just flashed
with an SDCard image at
https://github.com/parallella/parabuntu/releases/download/parabuntu-2019.1-beta1/parabuntu-2019.1-beta1-headless-z7010.img.gz
, full compilation works fine with:

mkdir vega
# limited SDCard storage so:
sudo mount 192.168.1.84:/home/etienne/parallella /home/parallella/vega
cd vega
wget https://ftp.gnu.org/gnu/gcc/gcc-13.2.0/gcc-13.2.0.tar.xz tar xf
gcc-13.2.0.tar.xz 
cd gcc-13.2.0/
./contrib/download_prerequisites
cd ..
mkdir gcc_build
cd gcc_build
../gcc-13.2.0/configure --enable-languages=c,c++,fortran
time make -j 3# SDCard real 2033m27.533s / NFS real: 2065m36.178s

But install fails with:
$ echo parallella | sudo -S make install
...
/usr/bin/install -c -m 644 ../../gcc-13.2.0/gcc/cp/operators.def
/usr/local/lib/gcc/armv7l-unknown-linux-gnueabihf/13.2.0/plugin/include/cp/operators.def
/usr/bin/install -c -m 644 ../../gcc-13.2.0/gcc/cp/cp-trait.def
/usr/local/lib/gcc/armv7l-unknown-linux-gnueabihf/13.2.0/plugin/include/cp/cp-trait.def
/usr/bin/install -c -m 644 ../../gcc-13.2.0/gcc/cp/contracts.h
/usr/local/lib/gcc/armv7l-unknown-linux-gnueabihf/13.2.0/plugin/include/cp/contracts.h
rm -f tmp-header-vars
echo USER_H= ... some filenames ... >> tmp-header-vars; echo
HASHTAB_H=hashtab.h >> tmp-header-vars; echo OBSTACK_H=obstack.h >>
tmp-header-vars; echo SPLAY_TREE_H=splay-tree.h >> tmp-header-vars; ...plenty
more .. ; echo GTFILES_LANG_H=gtype-ada.h gtype-c.h gtype-cp.h gtype-d.h
gtype-fortran.h gtype-go.h gtype-jit.h gtype-lto.h gtype-m2.h gtype-objc.h
gtype-objcp.h gtype-rust.h >> tmp-header-vars;
/bin/sh: tmp-header-vars: Permission denied
/bin/sh: tmp-header-vars: Permission denied
/bin/sh: tmp-header-vars: Permission denied
... lots of identical messages ...
Makefile:3736: recipe for target 's-header-vars' failed
make[2]: *** [s-header-vars] Error 1
make[2]: Leaving directory '/home/parallella/vega/gcc_build/gcc'
Makefile:5361: recipe for target 'install-gcc' failed
make[1]: *** [install-gcc] Error 2
make[1]: Leaving directory '/home/parallella/vega/gcc_build'
Makefile:2632: recipe for target 'install' failed
make: *** [install] Error 2

The problem is simple, I am just creating this bug report so that people can
google it.

That is the first time "root" (due to sudo) tries to create a simple file in
the build directory, and such build directory is mounted on a NFS filesystem.
The NFS server may not configure the export with "no_root_squash", so that a
standard user can create such a file "tmp-header-vars", but root cannot!

Maybe a simple test (and a better error message) could be created when root
cannot create a file in the build directory? Obviously root will create files
without problems on /usr/local/{bin,lib,}.

Feel free to classify as "NOTABUG", just keep it accessible in search engines!

Best Regards, Etienne.

[Bug tree-optimization/82264] [6 Regression] ICE in vn_phi_lookup at gcc/tree-ssa-sccvn.c:3125

[etienne_lorrain at yahoo dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82264

--- Comment #6 from etienne_lorrain at yahoo dot fr ---
fixed for my testcase (tested gcc version 7.2.1 20171012), can be closed.
Thanks, Etienne.

[Bug bootstrap/10740] ../../gcc/gcc/gengtype.c:430: undefined reference to "lexer_line"

[etienne_lorrain at yahoo dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10740

etienne_lorrain at yahoo dot fr changed:

   What|Removed |Added

 CC||etienne_lorrain at yahoo dot fr

--- Comment #6 from etienne_lorrain at yahoo dot fr ---
I just had this error on Fedora26 compiling gcc-7-20171012.
It looks like it is due to the fact that I did not have flex installed.
Something like "sudo yum install flex" does install flex, but obviously does
not remove file ./host-x86_64-pc-linux-gnu/gcc/gengtype-lex.c so retrying "make
bootstrap" brings exactly the same error.
I did "make realclean" and again "./configure ..." and everything works.
Maybe "./contrib/download_prerequisites" should warn that flex is needed when
that command is not present...

[Bug c/82265] packed attribute on variables but documented as so

[etienne_lorrain at yahoo dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82265

--- Comment #3 from etienne_lorrain at yahoo dot fr ---
I do not know how I finished adding such packed attribute on my variables and
not seeing any warnings, on the gcc-4.7.1 I used at the time.
That looks indeed a bug in the documentation only - I probably wanted to be
conforming to the documentation (and save data size).
So, packed attribute on variables should be removed from documentation, and
maybe document that attribute "aligned(1)" is not the "minimum alignment" of
the variable but the "required/forced alignment".
Fine for me for the bug to be closed when documentation updated.

Thanks, Etienne.

[Bug c/82265] New: packed attribute on variables in gcc-7.1.1 no more accepted

[etienne_lorrain at yahoo dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82265

Bug ID: 82265
   Summary: packed attribute on variables in gcc-7.1.1 no more
accepted
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: etienne_lorrain at yahoo dot fr
  Target Milestone: ---

Compiling the simple line on amd64:
long long a __attribute__((packed)) = 100;
with "GCC: (GNU) 7.1.1 20170622 (Red Hat 7.1.1-3)"
gives the warning:
tmp.c:1:1: warning: ‘packed’ attribute ignored [-Wattributes]
and we can verify it is really ignored, variable "a" is aligned to 8 bytes.

while it is documented in:
https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes

packed: The packed attribute specifies that a variable or structure field
should have the smallest possible alignment

The packed variable was (previous compiler versions) the only way to reduce
alignment of variables (for instance long long or strings), attribute
aligned(1) now works (reducing alignment) but is documented as "specifies a
minimum alignment", not forcing alignment.

Thanks, Etienne.

[Bug c/82264] New: internal compiler error: Segmentation fault in fct,constprop

[etienne_lorrain at yahoo dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82264

Bug ID: 82264
   Summary: internal compiler error: Segmentation fault in
fct,constprop
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: etienne_lorrain at yahoo dot fr
  Target Milestone: ---

Created attachment 42208
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42208=edit
preprocessed source

Trying to update the gujin bootloader (compiling/working no problem with older
gcc), contains a lot of inline assembler.
Got the fault by just:
/usr/libexec/gcc/x86_64-redhat-linux/7/cc1 -m32 -Os -fgnu89-inline 
/tmp/cc9y7CiU.out
Default compiler Fedora26:
gcc version 7.1.1 20170622 (Red Hat 7.1.1-3) (GCC) 
Just got this message:
util.c: In function ‘detect_processor.constprop’:
util.c:531:1: internal compiler error: Segmentation fault
 detect_processor (struct processor_str *processor)
 ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.

Thanks, Etienne.

[Bug c/79674] Missed optimisation when no sequence point present

[etienne_lorrain at yahoo dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79674

--- Comment #2 from etienne_lorrain at yahoo dot fr ---
Well, I did not really want to link to the store-merging optimisation in
particular, I wanted to point out that order of evaluation inside the function
call are not defined by the standard, so argument evaluation could be changed
to increase optimisation.

Here is an example without using volatile:
-->o--o<-
static inline void parallel (int c_compliant, ...) {}
struct { unsigned char r, g, b, t; } vol_str;
int external_fct(void);

void fct1 (void)
{
  vol_str.r = 1,
  vol_str.g = 2,
  external_fct(),
  vol_str.b = 3,
  vol_str.t = 0;
}

void fct2 (void)
{
  parallel (vol_str.r = 1, vol_str.g = 2, external_fct(), vol_str.b = 3,
vol_str.t = 0);
}

unsigned fct_use(void) { return vol_str.r; } // do not remove, anonymous
struct!
-->o--o<-

fct2() could write a 32 bit value and call external_fct() either before or
after, unlike fct1().

[Bug c/79674] New: Missed optimisation when no sequence point present

[etienne_lorrain at yahoo dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79674

Bug ID: 79674
   Summary: Missed optimisation when no sequence point present
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: etienne_lorrain at yahoo dot fr
  Target Milestone: ---

It may be controvertial use, but I would like to report it with low priority...

Having this code (tested on GCC7):
-->o--o<-
static inline void parallel (int c_compliant, ...) {}
volatile struct { unsigned char r, g, b, t; } vol_str;

void fct1 (void)
{
  vol_str.r = 1,
  vol_str.g = 2,
  vol_str.b = 3,
  vol_str.t = 0;
}

void fct2 (void)
{
  parallel (vol_str.r = 1, vol_str.g = 2, vol_str.b = 3, vol_str.t = 0);
}
-->o--o<-

fct1 has to be translated into four independant byte writes because since some
ANSI standard the comma (used like this) has become a sequence point.

but fct2 could be compiled into a single 32 bits write because there are no
sequence point when we use the comma to separate parameters in a function call
(hence the name of the function: parallel)...

[Bug middle-end/48888] Creating a copy variable simplify assembly - i686-pc-linux-gnu

[etienne_lorrain at yahoo dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4

etienne_lorrain at yahoo dot fr changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from etienne_lorrain at yahoo dot fr ---
Problem no more visible in  g++ (GCC-Explorer-Build) 7.0.0 20161113
(experimental), indirect function call not un-necessarily copied to %edx before
calling *edx, closing.

[Bug middle-end/39456] Functions/variables of a file in different named sections

[etienne_lorrain at yahoo dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39456

etienne_lorrain at yahoo dot fr changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from etienne_lorrain at yahoo dot fr ---
Fixed (string concat into __attribute__((section("pre" "fix"))) ) on  g++
(GCC-Explorer-Build) 7.0.0 20161113 (experimental), result of:

void fct2 (void) __attribute__((__section__("sect1_" "fct2")));
void fct2 (void) { return; }

is:

.sectionsect1_fct2,"ax",@progbits
.p2align 4,,15
.globl  fct2()
.type   fct2(), @function
fct2():
.LFB0:
.file 1 "/tmp/gcc-explorer-compiler1161115-73-1xzfvi6/example.cpp"
.loc 1 2 0
.cfi_startproc
.loc 1 2 0
rep ret

[Bug tree-optimization/14295] [tree-ssa] copy propagation for aggregates

[etienne_lorrain at yahoo dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14295
Bug 14295 depends on bug 24177, which changed state.

Bug 24177 Summary: function returning structure produce very long/slow assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24177

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/24177] function returning structure produce very long/slow assembly

[etienne_lorrain at yahoo dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24177

etienne_lorrain at yahoo dot fr changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from etienne_lorrain at yahoo dot fr ---
Closing, code generated by g++ (GCC-Explorer-Build) 7.0.0 20161113
(experimental) from the source is now:
fct2():
subl$40, %esp
leal12(%esp), %eax
movl$1, 12(%esp)
movl$2, 16(%esp)
movl$3, 20(%esp)
movl$4, 24(%esp)
pushl   %eax
callfct3(str*)
addl$44, %esp
ret

[Bug middle-end/22141] [5/6/7 Regression] Missing optimization when storing structures

[etienne_lorrain at yahoo dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141

--- Comment #42 from etienne_lorrain at yahoo dot fr ---
Separate Bug 78821 has been successfully created following comment 41

[Bug c/78821] New: GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[etienne_lorrain at yahoo dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821

Bug ID: 78821
   Summary: GCC7: Copying whole 32 bits structure field by field
not optimised into copying whole 32 bits at once
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: etienne_lorrain at yahoo dot fr
  Target Milestone: ---

Compiling (ia32, -O2) a function to copy whole structure is optimised on GCC7
pre-release (g++ (GCC-Explorer-Build) 7.0.0 20161113 (experimental)):

struct S
{
  char a, b, c, d;
} u, v;

void fct (void) {
  u = v;
}

leads to:
fct():
movlv, %eax
movl%eax, u
ret

But other ways to copy the structure are not optimised, both:
void fct (void) {
  u = (struct S){v.a, v.b, v.c, v.d};
}
and:
void fct (void) {
  u.a = v.a;
  u.b = v.b;
  u.c = v.c;
  u.d = v.d;
}

leads to:
movzbl  v, %eax
movb%al, u
movzbl  v+1, %eax
movb%al, u+1
movzbl  v+2, %eax
movb%al, u+2
movzbl  v+3, %eax
movb%al, u+3

[Bug middle-end/22141] [5/6/7 Regression] Missing optimization when storing structures

[etienne_lorrain at yahoo dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141

--- Comment #40 from etienne_lorrain at yahoo dot fr ---
Following my comment No 17, the optimisation could also be done for reads - we
still have (https://gcc.godbolt.org/ -O2 -m32) that:
struct S
{
  char a;
  char b;
  char c;
  char d;
} u, v;

void fct (void) {
  u.a = v.a;
  u.b = v.b;
  u.c = v.c;
  u.d = v.d;
}

compiled into:
fct():
movzbl  v, %eax
movb%al, u
movzbl  v+1, %eax
movb%al, u+1
movzbl  v+2, %eax
movb%al, u+2
movzbl  v+3, %eax
movb%al, u+3
ret

Same if fct() contains "u = (struct S) {v.a, v.b, v.c, v.d};"
Where a single read32 / write32 could be used...

Having fct() only do "u = v;" is compiled with a single read32 / write32.
I do not know if it is important enough, if it needs another bugzilla number...
Thanks.

[Bug c/57915] New: ICE in set_address_disp, at rtlanal.c:5537

[etienne_lorrain at yahoo dot fr]

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

Bug ID: 57915
   Summary: ICE in set_address_disp, at rtlanal.c:5537
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: etienne_lorrain at yahoo dot fr

On latest Fedora, with: gcc version 4.8.1 20130603 (Red Hat 4.8.1-1) (GCC)
I get:
  $ /usr/bin/gcc -m32 -Os bug.c
  bug.c: In function ‘menu’:
  bug.c:59:1: internal compiler error: in set_address_disp, at rtlanal.c:5537
   }
   ^
  Please submit a full bug report,

possibly related to  asm(... X (*str)) , I use X mostly because I had
problems using m when the pointer points to local variable on the stack.
The problem do not exists with previous compiler versions, not a new code.

The simplified source code I finished to get after few hours is:

$ cat bug.c
extern inline const char *
_strnchr (const char *str, char c, unsigned size)
{
  asm (cld ; repne scasb %%es:(%%edi),%%al
: +c (size), +D (str): a (c), X (*str):cc);
  return str - 1;
}

extern inline unsigned
strlen (const char *str)
{
  return _strnchr (str, '\0', (~0)) - str;
}

extern inline void
_strncpy (char *dst, const char *src, unsigned nb)
{

  unsigned len = strlen (src);
  if (len  nb)
len = nb;

  __builtin_memcpy (dst, src, len);
  dst[len] = '\0';

}

extern inline char *
strcpy (char *dst, const char *src)
{
  _strncpy (dst, src, (~0));
  return dst;
}

typedef struct
{
  char go_msg[8];
  char scanpath[16];
} gujin_param_t;

extern gujin_param_t copy_gujin_param;
enum { kernel_bottom_menu, setup_bottom_menu } type;

unsigned short getkey(void);
unsigned timeout;
unsigned menu (void)
{
char local_scanpath[sizeof (copy_gujin_param.scanpath)];
strcpy (local_scanpath, copy_gujin_param.scanpath);

for (;;)
  {
unsigned short key = getkey();
if ((type == kernel_bottom_menu) ? (key == (0x1312)) : key == (0x3900 | '
'))
  {
strcpy (local_scanpath, copy_gujin_param.scanpath);
  }
  }
}

Regards, Etienne.

[Bug rtl-optimization/53507] New: ia32/amd64: bsf can be used to test null memory, bsf sets zero flag

[etienne_lorrain at yahoo dot fr]

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

 Bug #: 53507
   Summary: ia32/amd64: bsf can be used to test null memory, bsf
sets zero flag
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: etienne_lorr...@yahoo.fr


Compiling:
int I;
void ifnull(void);
void testnull(void) {
  if (I == 0)
ifnull();
}

void fct (unsigned u) {
  if (u != 0)
I = __builtin_ffs(u) - 1;
}

result in for testnull():
movlI, %eax
testl%eax, %eax
je.L4
rep
ret
.L4:
jmpifnull()
It would be shorter/quicker to replace the two first lines by:
bsfl I, %eax
je   ifnull()
i.e. there is no need to load the memory variable into a register with bsf/bsr.

And result for fct():
movl4(%esp), %eax
testl%eax, %eax
je.L5
bsfl%eax, %eax
movl%eax, I
.L5:
rep
ret
It would be shorter/quicker to test if the parameter u is null by the bsf
instruction:
bsfl4(%esp), %eax
cmovne%eax, I
.L5:
rep
ret

[Bug middle-end/39456] Functions/variables of a file in different named sections

[etienne_lorrain at yahoo dot fr]

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

--- Comment #4 from etienne_lorrain at yahoo dot fr 2012-01-03 09:53:59 UTC ---
Thanks for looking at my reports and happy new year!

I think the problem I had was the quoting and string concat, you need:
void fct2 (void) __attribute__((__section__(sect1_fct2))) { return; }

The solution you give generates:
void fct1 (void) __attribute__((__section__(basesectfct1))) { return; }

You cannot give the compiler:
void fct2 (void) __attribute__((__section__(sect1_ fct2))) { return; }
because it would not concat the strings in this case (I did not re-check).

And:
#define function_def(base_section, funname, RET, ARGS) \
RET funname ARGS __attribute__((__section__(# base_section##funname)))
#define basesect sect1_
function_def(basesect, fct1, void, (void)) { return; }
will stringify #base_section before applying the ##

That was my problem...

[Bug c/51085] New: volatile const structures (in C) go in the .data section, not .rodata as expected

[etienne_lorrain at yahoo dot fr]

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

 Bug #: 51085
   Summary: volatile const structures (in C) go in the .data
section, not .rodata as expected
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: etienne_lorr...@yahoo.fr


Basically, I was hoping (maybe my fault?) that volatile const data would go
to .rodata segment.
As described in the example for array1, that is not the case.
The example show array2, but to stop an asm message changing attribute of a
section I need the dirty trick of array3.
I did not noticed that with previous compiler version.


etienne@debian-testing:~/projet$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.6/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-15'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.6.1 (Debian 4.6.1-15) 
etienne@debian-testing:~/projet$ cat text.c 
volatile const unsigned array1[3] = { 1, 2, 3 };
volatile const unsigned array2[3] __attribute__ ((section(.rodata))) = { 1,
2, 3 };
volatile const unsigned array3[3] __attribute__ ((section(.rodata #))) = { 1,
2, 3 };
etienne@debian-testing:~/projet$ gcc -S text.c -o -
.filetext.c
.globlarray1
.data
.align 4
.typearray1, @object
.sizearray1, 12
array1:
.long1
.long2
.long3
.globlarray2
.section.rodata,aw,@progbits
.align 4
.typearray2, @object
.sizearray2, 12
array2:
.long1
.long2
.long3
.globlarray3
.section.rodata #,aw,@progbits
.align 4
.typearray3, @object
.sizearray3, 12
array3:
.long1
.long2
.long3
.identGCC: (Debian 4.6.1-15) 4.6.1
.section.note.GNU-stack,,@progbits
etienne@debian-testing:~/projet$

[Bug rtl-optimization/49839] New: Use constants in registers preferably to inline constants (-Os)

[etienne_lorrain at yahoo dot fr]

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

   Summary: Use constants in registers preferably to inline
constants (-Os)
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: etienne_lorr...@yahoo.fr


When GCC needs to zero out an integer in memory, and it already has one
register at value zero, it takes less code bytes to write the register than
inline a constant, i.e.:

etienne@etienne-server:~/projet$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/i386-linux-gnu/gcc/i486-linux-gnu/4.6.1/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-4'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-multiarch
--with-multiarch-defaults=i386-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/i386-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/i386-linux-gnu
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.6.1 (Debian 4.6.1-4) 

etienne@etienne-server:~/projet$ cat tmp.c
unsigned a, b;
unsigned fct (void)
  {
  a = b = 0;
  return 0;
  }
etienne@etienne-server:~/projet$ gcc -Os -fomit-frame-pointer tmp.c -c -o tmp.o
etienne@etienne-server:~/projet$ objdump -d tmp.o

tmp.o: file format elf32-i386


Disassembly of section .text:

 fct:
   0:c7 05 00 00 00 00 00 movl   $0x0,0x0
   7:00 00 00 
   a:31 c0xor%eax,%eax
   c:c7 05 00 00 00 00 00 movl   $0x0,0x0
  13:00 00 00 
  16:c3   ret
etienne@etienne-server:~/projet$ 

It would be shorter to get this assembly:
0:31 c0xor%eax,%eax
2:a3 00 00 00 00mov%eax,a
7:a3 00 00 00 00mov%eax,b
c:c3ret

Regards,
Etienne.

[Bug c/49012] New: weak const optimisations

[etienne_lorrain at yahoo dot fr]

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

   Summary: weak const optimisations
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: etienne_lorr...@yahoo.fr


With newer GCC compilers,

const struct { int a,b; } mystruct = {15, 0};
int adder (int x) { return x + mystruct.b; };

there isn't any addition performed in adder() because GCC knows that mystruct.b
is null,
and assumes that nobody is initialising mystruct.b is assembler or declaring
mystruct as
non-const in another module.

But if we add the weak attribute to mystruct, GCC-4.4.5 does the addition in
case mystruct
has been pre-loaded by for instance LD_PRELOAD, GCC-4.6 do not do the addition.

const struct { int a,b; } mystruct __attribute__((weak))= {15, 0};
int adder (int x) { return x + mystruct.b; };

LD_PRELOAD=/home/etienne/projet/toolchain/lib/libmpc.so.2:/home/etienne/projet/toolchain/lib/libgmp.so.10
/home/etienne/projet/toolchain/bin/gcc -Os -fomit-frame-pointer -S t.c -o t.s

gives:

.filet.c
.text
.globladder
.typeadder, @function
adder:
.LFB0:
.cfi_startproc
movl4(%esp), %eax
ret
.cfi_endproc
.LFE0:
.sizeadder, .-adder
.weakmystruct
.section.rodata
.align 4
.typemystruct, @object
.sizemystruct, 8
mystruct:
.long15
.long0
.identGCC: (GNU) 4.6.0
.section.note.GNU-stack,,@progbits

[Bug c/49012] weak const optimisations

[etienne_lorrain at yahoo dot fr]

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

--- Comment #2 from etienne_lorrain at yahoo dot fr 2011-05-16 14:36:41 UTC ---
Well, with gcc-4.4.5-8 the weak attribute did the trick:

$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8) 

$ cat t.c
//const struct { int a,b; } mystruct __attribute__((weak))= {15, 0};
const struct { int a,b; } mystruct = {15, 0};
int adder (int x) { return x + mystruct.b; };

$ gcc -Os -fomit-frame-pointer t.c -S -o t.s
$ cat t.s
.filet.c
.text
.globl adder
.typeadder, @function
adder:
movl4(%esp), %eax
ret
.sizeadder, .-adder
.globl mystruct
.section.rodata
.align 4
.typemystruct, @object
.sizemystruct, 8
mystruct:
.long15
.long0
.identGCC: (Debian 4.4.5-8) 4.4.5
.section.note.GNU-stack,,@progbits

$ cat t.c
const struct { int a,b; } mystruct __attribute__((weak))= {15, 0};
//const struct { int a,b; } mystruct = {15, 0};
int adder (int x) { return x + mystruct.b; };

$ cat t.s
.filet.c
.text
.globl adder
.typeadder, @function
adder:
movl4(%esp), %eax
addlmystruct+4, %eax
ret
.sizeadder, .-adder
.weakmystruct
.section.rodata
.align 4
.typemystruct, @object
.sizemystruct, 8
mystruct:
.long15
.long0
.identGCC: (Debian 4.4.5-8) 4.4.5
.section.note.GNU-stack,,@progbits

But in fact I just discovered volatile const structures which enables me to
have a C constant
initialised at run-time by the assembly preceding main(), so personally I do
not need this
weak trick.

Thanks for the quick answer,
Etienne.

[Bug rtl-optimization/48888] New: Creating a copy variable simplify assembly - i686-pc-linux-gnu

[etienne_lorrain at yahoo dot fr]

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

   Summary: Creating a copy variable simplify assembly -
i686-pc-linux-gnu
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: etienne_lorr...@yahoo.fr


Hello,

Compiling the following C code on GCC-4.6.0 with or without BAD defined leads
to a different
assembly generated, more specifically 
$ /home/etienne/projet/toolchain/bin/gcc -Os -fomit-frame-pointer -S tmp.c -o
tmp.s -DBAD
generates near the end of tmp.s:
movlUI_function, %edx
movb%al, (%esp)
call*%edx
and compiling with:
$ /home/etienne/projet/toolchain/bin/gcc -Os -fomit-frame-pointer -S tmp.c -o
tmp.s
generates the simplest assembly:
movb%al, (%esp)
call*UI_function
$ /home/etienne/projet/toolchain/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/etienne/projet/toolchain/bin/gcc
COLLECT_LTO_WRAPPER=/home/etienne/projet/toolchain/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/etienne/projet/toolchain
--enable-languages=c --with-gmp=/home/etienne/projet/toolchain
--disable-multilib --disable-threads --enable-tls
Thread model: single
gcc version 4.6.0 (GCC)

Unfortunately for me I need to post-process those call *UI to replace them by
lcallw *UI,
and lcallw *%edx do not work - anyway I have the solution for those few
cases.
This problem is not new (seen at least in 4.5) and appears unfrequently, but it
seems that
something strange is going on, the two version should generate the same
assembly...

struct attribute_str {
unsigned char underline :1;
unsigned char reverse   :1;
unsigned char blink :1;
unsigned char other :5;
} __attribute__ ((packed)) UI_attributes_current;

struct user_interface_fct_str {
void (*setattribute) (struct attribute_str attr);
void (*putstr) (const char *str);
} UI_function;

extern unsigned UI_parameter_nbcol;

void print (const char *src, unsigned active, unsigned row, unsigned col)
  {
  char displayed[UI_parameter_nbcol], *dst = displayed;

  if (!src)
  return;
  for (;;) {
  if (!active  *src == '')
  *dst++ = '(';
else
  *dst++ = *src;
  if (*src++ == '\0')
  break;
  }

  struct attribute_str saved_attr = UI_attributes_current;

  UI_function.putstr (displayed);

  if (memcmp (saved_attr, UI_attributes_current, sizeof (struct
attribute_str))) {
#ifdef BAD 
  UI_function.setattribute (saved_attr);
#else
  /* Write it this way else GCC-4.6.0 uses movl
UI.function.setattribute,%edx ; call *%edx */
  struct attribute_str newattr = saved_attr;
  UI_function.setattribute (newattr);
#endif
  }
  }

[Bug c/48517] New: ICE in build_unary_op, at c-typeck.c:3786

[etienne_lorrain at yahoo dot fr]

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

   Summary: ICE in build_unary_op, at c-typeck.c:3786
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: etienne_lorr...@yahoo.fr


Created attachment 23929
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23929
The file which produces the ICE

If I type (locally generated libmpc and libgmp):
LD_PRELOAD=/home/etienne/projet/toolchain/lib/libmpc.so:/home/etienne/projet/toolchain/lib/libgmp.so
/home/etienne/projet/toolchain/bin/gcc  main.i
with the attached main.i, I get two warnings and:
main.c: In function ‘is_valid_chgmode_keycode’:
main.c:2575:3: internal compiler error: in build_unary_op, at c-typeck.c:3786
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

I am not sure I have generated perfectly gcc-4.6.0 - first time I generate this
version,
but I used to be able to generate gcc-4.5.* and compile that file.

$
LD_PRELOAD=/home/etienne/projet/toolchain/lib/libmpc.so:/home/etienne/projet/toolchain/lib/libgmp.so
/home/etienne/projet/toolchain/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/etienne/projet/toolchain/bin/gcc
COLLECT_LTO_WRAPPER=/home/etienne/projet/toolchain/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/etienne/projet/toolchain
--enable-languages=c --with-gmp=/home/etienne/projet/toolchain
--disable-multilib --disable-threads --enable-tls
Thread model: single
gcc version 4.6.0 (GCC)

[Bug c/42935] Warning u64 = u32 * u32; - i.e. not casting one u32 to u64

[etienne_lorrain at yahoo dot fr]

--- Comment #2 from etienne_lorrain at yahoo dot fr  2010-02-24 09:45 
---
It would be nice to have the warning in the second case too, i.e. for
(unsigned long long)(val1*val2).
Another solution, probably a lot more complex to implement, is to have
a compilation switch to expand all calculus to 64 bits even when int
is 32 bits, and let the optimiser convert back to simpler assembly code
when the result used is only 32 bits.


-- 


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

[Bug c/43162] New: option to set the promoted type of parameters of calculus

[etienne_lorrain at yahoo dot fr]

In C, variables are promoted to unsigned int or int before operations like
adding or multiplying so that we have on ia32 PC:
 unsigned char uc1 = 0x10, uc2 = 0x10;
 printf (0x%X\n, uc1*uc2); - display 0x100
 unsigned short us1 = 0x1000, us2 = 0x10;
 printf (0x%X\n, us1*us2); - display 0x1
That doesn't work for unsigned long long, by design we have:
 unsigned u1 = 0x1000, u2 = 0x10;
 printf (0x%llX\n, (unsigned long long)(u1*u2)); - display 0x0
It would be nice to be able to set the size to promote operands before
operations to either int/unsigned (as now) or long long/unsigned long long
to have the intended result on lines like:
 unsigned long long ull = u1 * u2; // with previous values of u1 and u2...
Nothing else should be changed by this option, default parameter size
of printf() should still be int/unsigned, so that a line like:
 unsigned u3 = u1 * u2;
would be optimised to the same assembly instructions whatever the value
of the switch.


-- 
   Summary: option to set the promoted type of parameters of
calculus
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: any
  GCC host triplet: any
GCC target triplet: any


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

[Bug c/42935] New: Warning u64 = u32 * u32; - i.e. not casting one u32 to u64

[etienne_lorrain at yahoo dot fr]

It is a beginer bug, but it would be nice to get a warning in:

#include stdio.h
unsigned val1 = 0x1000, val2 = 0x100;
int main(int argc, char **argv)
{
unsigned long long val3 = val1 * val2;
printf (val1 = 0x%X, val2 = 0x%X, val3 = 0x%llX, val1*val2 = 0x%llX\n,
val1, val2, val3, (unsigned long long)(val1*val2));
}

Obviously the line printed is:
val1 = 0x1000, val2 = 0x100, val3 = 0x0, val1*val2 = 0x0
(compiled with gcc -w -Wall -O2 tmp.c you get no warning)
Got bitten yesterday by gcc-4.4.3, reproduced today on gcc version 4.1.2.


-- 
   Summary: Warning u64 = u32 * u32; - i.e. not casting one u32 to
u64
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug c/40634] New: 2 small problems when building cross compiler

[etienne_lorrain at yahoo dot fr]

On Debian (and probably other), if I execute:
tar xf ../update/gcc-4.4.0.tar.bz2
cd gcc-4.4.0/
tar xf ../../update/mpfr-2.4.1.tar.bz2
tar xf ../../update/gmp-4.3.1.tar.bz2
tar xf ../../update/binutils-2.19.1.tar.bz2
mv gmp-4.3.1 gmp
mv mpfr-2.4.1 mpfr
mv binutils-2.19.1 binutils
mkdir -v ../gcc-build
cd ../gcc-build
mkdir /home/etienne/cross-tools /home/etienne/tools
../gcc-4.4.0/configure --prefix=/home/etienne/cross-tools \
--host=$(echo $MACHTYPE) --target=powerpc-unknown-linux-gnu \
--disable-multilib --with-local-prefix=/home/etienne/tools \
--disable-nls --disable-shared --disable-threads --enable-languages=c
make all-gcc

(echo $MACHTYPE gives: i486-pc-linux-gnu)
First error:
if [ x != x ]; then \
  gcc -c -DHAVE_CONFIG_H -g -O2  -I.
-I../../gcc-4.4.0/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic   ../../gcc-4.4.0/libiberty/strncmp.c -o
pic/strncmp.o; \
else true; fi
gcc -c -DHAVE_CONFIG_H -g -O2  -I. -I../../gcc-4.4.0/libiberty/../include  -W
-Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic 
../../gcc-4.4.0/libiberty/strncmp.c -o strncmp.o
rm -f ./libiberty.a pic/./libiberty.a
i486-pc-linux-gnu-ar rc ./libiberty.a \
  ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o
./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn-string.o ./fdmatch.o
./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o
./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o
./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o
./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o
./pex-one.o ./pex-unix.o ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o
./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o
./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o  ./mkstemps.o
./strncmp.o
make[1]: i486-pc-linux-gnu-ar: Command not found
make[1]: *** [libiberty.a] Error 127
make[1]: Leaving directory `/home/etienne/gcc-build/gcc-build/libiberty'
make: *** [all-libiberty] Error 2
etie...@eqng:~/gcc-build/gcc-build$ 

If I create i486-pc-linux-gnu-ar pointing to ar in /usr/bin:
# ln -vs /usr/bin/ar /usr/bin/i486-pc-linux-gnu-ar
`/usr/bin/i486-pc-linux-gnu-ar' - `/usr/bin/ar'
and rerun the same script:

gcc  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H  -o xgcc gcc.o
opts-common.o gcc-options.o gccspec.o \
  intl.o prefix.o version.o  ../libcpp/libcpp.a  
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
cp xgcc gcc-cross
gcc -c  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
-I../../gcc-4.4.0/gcc -I../../gcc-4.4.0/gcc/. -I../../gcc-4.4.0/gcc/../include
-I../../gcc-4.4.0/gcc/../libcpp/include -I/home/etienne/tmp/gcc-build/./gmp
-I/home/etienne/tmp/gcc-4.4.0/gmp -I/home/etienne/tmp/gcc-build/./mpfr
-I/home/etienne/tmp/gcc-4.4.0/mpfr  -I../../gcc-4.4.0/gcc/../libdecnumber
-I../../gcc-4.4.0/gcc/../libdecnumber/dpd -I../libdecnumber   
../../gcc-4.4.0/gcc/cppspec.c -o cppspec.o
gcc  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H  -o cpp gcc.o
opts-common.o gcc-options.o cppspec.o \
  intl.o prefix.o version.o  ../libcpp/libcpp.a  
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
powerpc-unknown-linux-gnu-gcc  -dumpspecs  tmp-specs
/bin/sh: powerpc-unknown-linux-gnu-gcc: command not found
make[1]: *** [specs] Error 127
make[1]: Leaving directory `/home/etienne/tmp/gcc-build/gcc'
make: *** [all-gcc] Error 2
etie...@eqng:~/tmp/gcc-build$ 

I just need todo:
cd /home/etienne/tmp/gcc-build/gcc
gcc-cross -dumpspecs  tmp-specs
make
cd ..
make all-gcc
make install-gcc install-binutils

and I get a working compiler.

Exactly the same 2 problems on gcc-4.3.3.

Regards,
 Etienne.


-- 
   Summary: 2 small problems when building cross compiler
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu


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

[Bug c/39892] New: -fno-function-cse not working

[etienne_lorrain at yahoo dot fr]

);
  }


-- 
   Summary: -fno-function-cse not working
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/39456] Functions of a file in different named sections

[etienne_lorrain at yahoo dot fr]

--- Comment #1 from etienne_lorrain at yahoo dot fr  2009-03-19 16:33 
---
 Also, you cannot put function in another section and then
 use -ffunction-sections, i.e.:

etie...@gujin:~$ gcc --version
gcc (Debian 4.3.3-3) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

etie...@gujin:~$ cat tmp.c
__attribute__((section(.extracode))) int fct1 (void) {
return 1;
}
__attribute__((section(.extracode))) int fct2 (void) {
return 2;
}

etie...@gujin:~$ gcc -Os -fomit-frame-pointer -ffunction-sections -S tmp.c -o
tmp.s
etie...@gujin:~$ cat tmp.s
.file   tmp.c
.section.extracode,ax,@progbits
.globl fct1
.type   fct1, @function
fct1:
movl$1, %eax
ret
.size   fct1, .-fct1
.globl fct2
.type   fct2, @function
fct2:
movl$2, %eax
ret
.size   fct2, .-fct2
.ident  GCC: (Debian 4.3.3-3) 4.3.3
.section.note.GNU-stack,,@progbits
etie...@gujin:~$

 So you cannot use garbage collection in the linker...


-- 


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

[Bug c/39456] New: Functions of a file in different named sections

[etienne_lorrain at yahoo dot fr]

Just that I need to set each functions in a C file into different sections,
with section names I can link in different segments.
 That can be done with:
__attribute__ ((section (sect1_fct1))) void fct1 (void) {}
__attribute__ ((section (sect1_fct2))) void fct2 (void) {}
 But cannot unfortunately be done in a macro like:
__attribute__ ((section (sect1_ __FUNCTION__ ))) void fct1 (void) {}

 It would be nice to have some way to do that, like:
__attribute__ ((section_prepend (sect1_))) void fct1 (void) {}
 so that a bad cutpaste somewhere do not create problems because
 a function is in the wrong section (by forgeting to change the
 concat'ed string).


-- 
   Summary: Functions of a file in different named sections
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: all-all-all
  GCC host triplet: all-all-all
GCC target triplet: all-all-all


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

[Bug inline-asm/39440] New: User Manual: describe asm (%a0,%c0::)

[etienne_lorrain at yahoo dot fr]

The user manual at:
http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Extended-Asm.html#Extended-Asm
decribes a lot of the asm syntax, but do not describe the modifier in between
the percent sign and the digit (or [name]) inside the string of the asm.

One use case is to access global structure fields inside asm():
union {
struct {
int a;
char b, c, d;
} part1;
unsigned long long part2;
} global_var;

void fct(void) {
asm volatile ( global_var_a = %c0  : : p (global_var.part1.a) );
asm volatile ( global_var_c = %c0  : : p (global_var.part1.c) );
}

asm (
movl $0,global_var_a\n
movb $0,global_var_c\n
);


-- 
   Summary: User Manual: describe asm (%a0,%c0::)
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: all-all-all
  GCC host triplet: all-all-all
GCC target triplet: all-all-all


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

[Bug inline-asm/39440] User Manual: describe asm (%a0,%c0::)

[etienne_lorrain at yahoo dot fr]

--- Comment #2 from etienne_lorrain at yahoo dot fr  2009-03-12 14:10 
---
 The thread associated:
http://gcc.gnu.org/ml/gcc/2009-03/msg00288.html


-- 


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

[Bug middle-end/22141] [4.2/4.3/4.4 Regression] Missing optimization when storing structures

[etienne_lorrain at yahoo dot fr]

--- Comment #17 from etienne_lorrain at yahoo dot fr  2009-02-03 16:38 
---
(In reply to comment #15)
 The advantage of such a RTL pass (or just adding such optimization to another
 RTL pass) would be that it would handle also say: ...

Why only limit that pass to constants, and only to writes:

etie...@cygne:~$ gcc --version
gcc (Debian 4.3.3-3) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

etie...@cygne:~$ cat tmp.c
struct S
{
  char a;
  char b;
  char c;
  char d;
} u, v;

void fct (void) {
  u.a = v.a;
  u.b = v.b;
  u.c = v.c;
  u.d = v.d;
}

etie...@cygne:~$ gcc -Os -S tmp.c -o tmp.s
etie...@cygne:~$ cat tmp.s
.file   tmp.c
.text
.globl fct
.type   fct, @function
fct:
movbv, %al
pushl   %ebp
movl%esp, %ebp
popl%ebp
movb%al, u
movbv+1, %al
movb%al, u+1
movbv+2, %al
movb%al, u+2
movbv+3, %al
movb%al, u+3
ret
.size   fct, .-fct
.comm   u,4,4
.comm   v,4,4
.ident  GCC: (Debian 4.3.3-3) 4.3.3
.section.note.GNU-stack,,@progbits
etie...@cygne:~$

 A single 32 bits read, and a single 32 bits write should be sufficient,
when none of the fields of the structure is declared volatile.


-- 


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

[Bug c++/38928] New: infinite loop on error message in C++ only

[etienne_lorrain at yahoo dot fr]

etie...@pc300:~$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1)
etie...@pc300:~$ cat tmp.c
struct id_struct
{
unsigned char is_ip_addrs[4];
};

struct addr_struct
{
unsigned shortfamily;
unsigned short   port;
struct   id_struct id;
char *name;
};

int main (int argc, char **argv)
{
struct addr_struct tmp_addr_struct = {
family: 1,
port: 666,
id: 0,
name: (char []){psig TCP}
};
return 2;
}
etie...@pc300:~$ gcc tmp.c
etie...@pc300:~$ g++ tmp.c 2 log
^C
etie...@pc300:~$ head log
tmp.c: In function 'int main(int, char**)':
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
etie...@pc300:~$


-- 
   Summary: infinite loop on error message in C++ only
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug middle-end/37135] [4.3/4.4 Regression] code size increase for bit-fields assignment

[etienne_lorrain at yahoo dot fr]

--- Comment #11 from etienne_lorrain at yahoo dot fr  2008-11-24 22:01 
---
 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142157
 Modified: trunk/gcc/dse.c

 I am using gcc-core-4.4-20081121.tar.bz2 with ia32-linux (Fedora9) and
applying your patch gives a better assembly, but still not the possible
mov $0x12345678,address - I still get 4 movb on my test.c or your testcase.
 Maybe I shall get the latest SVN, or there is more files to patch than dse.c?
$ size test.o-4.4
   textdata bss dec hex filename
 37   0   0  37  25 test.o-4.4


-- 


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

[Bug middle-end/37135] [4.3/4.4 Regression] code size increase for bit-fields assignment

[etienne_lorrain at yahoo dot fr]

--- Comment #6 from etienne_lorrain at yahoo dot fr  2008-11-21 16:10 
---
 By trying to declare:
volatile union U u;
 In your Testcase without the unnecessary enum, the u = def; is compiled as:
movl$0, u

movlu, %eax
andl$-16, %eax
orl $6, %eax
movl%eax, u

movlu, %eax
andb$15, %al
orl $64, %eax
movl%eax, u

movlu, %eax
andb$240, %ah
orb $2, %ah
movl%eax, u

movlu, %eax
andb$15, %ah
orb $176, %ah
movl%eax, u

movlu, %eax
andl$-983041, %eax
orl $196608, %eax
movl%eax, u

movlu, %eax
andl$-15728641, %eax
orl $5242880, %eax
movl%eax, u

movlu, %eax
andl$268435455, %eax
orl $1342177280, %eax
movl%eax, u

 By gcc version 4.3.2 (Debian 4.3.2-1) on i486-linux-gnu at -O2.


-- 


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

[Bug middle-end/37135] [4.3/4.4 Regression] code size increase for bit-fields assignment

[etienne_lorrain at yahoo dot fr]

--- Comment #8 from etienne_lorrain at yahoo dot fr  2008-11-21 17:45 
---
 The number of writes for that volatile structure may or may not be a problem,
I am more concerned by the number of reads of some memory which may not be
readable at all.


-- 


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

[Bug middle-end/37248] [4.4 Regression] regression 4.3.1 - 4.3.2-rc transformation bitfield to individual bytes

[etienne_lorrain at yahoo dot fr]

--- Comment #7 from etienne_lorrain at yahoo dot fr  2008-09-01 20:29 
---
Patch works for me, thanks.


-- 


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

[Bug middle-end/37248] New: regression 4.3.1 - 4.3.2-rc transformation bitfield to individual bytes

[etienne_lorrain at yahoo dot fr]

In short, when passing a bitfield as parameter, each bit is converted to bytes
before being tested instead of a simple mask and test.
 Is there a way to disable bit to bytes conversion by a compilation switch,
I have never seen that producing better code up to now?

$ cat tmp2.c
struct mouse_button_str {
unsigned char left  : 1;
unsigned char right : 1;
unsigned char middle: 1;
} button;

char fct (struct mouse_button_str newbutton)
{
return (newbutton.left  newbutton.right  newbutton.middle);
}
$ ./toolchain/bin/gcc --version
gcc (GCC) 4.3.2 20080819 (prerelease)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ ./toolchain/bin/gcc -Os tmp2.c -S -o tmp2.s
$ cat tmp2.s
.file   tmp2.c
.text
.globl fct
.type   fct, @function
fct:
pushl   %ebp
movl%esp, %ebp
movb8(%ebp), %al
movb%al, %cl
movb%al, %dl
shrb%cl
shrb$2, %dl
andl$1, %ecx
andl$1, %edx
testb   $1, %al
je  .L2
testb   %cl, %cl
je  .L2
movl%edx, %eax
andl$1, %eax
jmp .L3
.L2:
xorl%eax, %eax
.L3:
popl%ebp
ret
.size   fct, .-fct
.comm   button,1,1
.ident  GCC: (GNU) 4.3.2 20080819 (prerelease)
.section.note.GNU-stack,,@progbits
$ ./toolchain-4.3.1/bin/gcc --version
gcc (GCC) 4.3.1
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ ./toolchain-4.3.1/bin/gcc -Os tmp2.c -S -o tmp2.s
$ cat tmp2.s
.file   tmp2.c
.text
.globl fct
.type   fct, @function
fct:
pushl   %ebp
movl%esp, %ebp
movb8(%ebp), %al
popl%ebp
andl$7, %eax
cmpb$7, %al
sete%al
ret
.size   fct, .-fct
.comm   button,1,1
.ident  GCC: (GNU) 4.3.1
.section.note.GNU-stack,,@progbits


-- 
   Summary: regression 4.3.1 - 4.3.2-rc transformation bitfield to
individual bytes
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i386-linux-fedora
  GCC host triplet: i386-linux-fedora
GCC target triplet: i386-linux-fedora


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

[Bug middle-end/37135] [4.3/4.4 Regression] code size increase for bit-fields assignment

[etienne_lorrain at yahoo dot fr]

--- Comment #3 from etienne_lorrain at yahoo dot fr  2008-08-24 09:13 
---
 Moreover, if in the first test.c program, you declare variable conf
volatile,
the assembly generated contains 8 writes to conf, and that memory location
is *read* 7 times. If conf does not point to memory but to memory mapped I/O
ports (maybe not readable), that is invalid code generated for valid input.


-- 


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

[Bug middle-end/37135] [4.3/4.4 Regression] code size increase for bit-fields assignment

[etienne_lorrain at yahoo dot fr]

--- Comment #2 from etienne_lorrain at yahoo dot fr  2008-08-17 19:31 
---
 It is not related to bitfields, this also show the problem:
struct color { unsigned char red, green, blue, transparent; } cur_color;
static const struct color mycolor = { 200, 10, 30, 0 };
void fct(void)
{
cur_color = mycolor;
}
 with gcc-4.3.1 cur_color is initialised with 4 movb (so address is encoded 4
times)
 and with gcc-4.2 with a 32 bits constant and a single movl.

 It seems to be the old problem of gcc not having a write combining pass
(converting consecutive byte/word writes into single double word writes), and
the fix of defining an intermediate variable is no more working.


-- 


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

[Bug c/37135] New: code size increase from gcc-4.2.4-3 to 4.3.1-9 for simple fct

[etienne_lorrain at yahoo dot fr]

file test.c:
--
enum stdcolor_enum {
black,blue, green,  cyan,
red,  magenta,  brown,  lightgray,
darkgray, lightblue,lightgreen, lightcyan,
lightred, lightmagenta, yellow, white
};

union mouse_color_union {
struct mouse_color_str {
unsigned deflt  : 4;
unsigned leftbutton : 4;
unsigned rightbutton: 4;
unsigned middlebutton   : 4;
unsigned topbutton  : 4;
unsigned twobutton  : 4;
unsigned invalid: 4;
unsigned infield: 4;
} colors;
unsigned all;
} conf;

const union mouse_color_union MOUSE_reset_colors = { .colors = {
.deflt =brown,
.leftbutton =   red,
.rightbutton =  green,
.middlebutton = lightcyan,
.topbutton =cyan,
.twobutton =magenta,
.invalid =  black,
.infield =  magenta,
}};

void fct (void)
{
conf = MOUSE_reset_colors;
}
--
$ gcc-4.2 --version
gcc-4.2 (GCC) 4.2.4 (Debian 4.2.4-3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc-4.2 -Os -c test.c -o test.o-4.2
$ size test.o-4.2
   textdata bss dec hex filename
 19   0   0  19  13 test.o-4.2
$ gcc-4.3 --version
gcc-4.3 (Debian 4.3.1-9) 4.3.1
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc-4.3 -Os -c test.c -o test.o-4.3
$ size test.o-4.3
   textdata bss dec hex filename
 56   0   0  56  38 test.o-4.3

Basically, the assembler lines in gcc-4.2:
movlMOUSE_reset_colors, %eax
movl%eax, conf
becomes in 4.3:
movl$0, conf
movbconf+3, %al
movb$70, conf
andl$15, %eax
orl $80, %eax
movb$-78, conf+1
movb$83, conf+2
movb%al, conf+3
which looks like a regression.

Thanks, etienne.


-- 
   Summary: code size increase from gcc-4.2.4-3 to 4.3.1-9 for
simple fct
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: debian
  GCC host triplet: i386-linux-debian
GCC target triplet: i386-linux-debian


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

[Bug c/35392] New: Warning array subscript is above array bounds in inline fct

[etienne_lorrain at yahoo dot fr]

;
  if (!opaque-gujin_attr.search_subdir_kernel)
continue;
  while ((*pat = getScanPath (cpt++)) != 0)
pat++;
  *pat++ = '\\';
  opaque-curdir = inSlashBoot;
}
  else
{
  if (!opaque-gujin_attr.search_topdir_kernel)
continue;
  opaque-curdir = inRoot;
}
  if ((i  1) == (sizeof (filename_array) / sizeof (filename_array[0])))
{
  (
{
memcpy (pat, *, sizeof (*));
pat + sizeof (*) - 1;
}
  );
  (
{
memcpy (pat[1], .kgz, sizeof (.kgz));
pat[1] + sizeof (.kgz) - 1;
}
  );
}
  else
{
  strcpy (pat, filename_array[i  1]);
  strcat (pat, *.*);
}
  DosDta.name_ext[0] = 0;
  if (DOS_FindFirst (pattern, attr_allowable, error) != 0)
;
  else
{
  for (;;)
{
  unsigned filesize;
  char *filename;
  struct desc_str *elem = opaque-array[opaque-nb];
  {
filesize = DosDta.size;
filename = DosDta.name_ext;
  }
  if (opaque-nb = 100)
{
  return;
}
  elem-filesize = filesize;
  elem-curdir = (i  1) ? inRoot : inSlashBoot;
  if ((unsigned) (i  1) == 0)
elem-boottype = is_initrd;
  else if ((unsigned) (i  1) == 1)
elem-boottype = is_initramfs;
  else
elem-boottype = is_kernel_with_header;

  if ((i  1) ==
  (sizeof (filename_array) / sizeof (filename_array[0])))
{
  elem-boottype = is_kernel_without_header;

  elem-name_offset = 0;
  while (filename[elem-name_offset] != '\0'
  filename[elem-name_offset] != '-'
  filename[elem-name_offset] != '+')
elem-name_offset++;
  if (filename[elem-name_offset] != '-')
elem-name_offset = 0;
}
  else
elem-name_offset = strlen (filename_array[i  1]);
  {
char *ptr = elem-filename;

elem-disk = opaque-filesystem.common.disk;
elem-partition = opaque-filesystem.common.part;
elem-curdir = opaque-curdir;
if (opaque-curdir == inSlashBoot)
  {
unsigned cpt = 0;
*ptr++ = '/';
while ((*ptr = getScanPath (cpt++)) != 0)
  ptr++;
*ptr++ = '/';
elem-name_offset += cpt + 2;
  }
else
  {
*ptr++ = '/';
elem-name_offset++;
  }
strncpy (ptr, filename,
 sizeof (elem-filename) - 1 - (ptr -
elem-filename));
strlwr (ptr);
  }
  opaque-nb++;
  if (DOS_FindNext (error))
{
  break;
}
}
}
}
}


-- 
   Summary: Warning array subscript is above array bounds in
inline fct
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug c/32642] New: Extended Asm modification of a range of bytes

[etienne_lorrain at yahoo dot fr]

There seems to be a problem either with the doc or with GCC in this case,
 I am not sure that has ever worked neither.

[EMAIL PROTECTED] ~]$ cat tmp.c
/* info gcc - Extended Asm
If you know how large the accessed memory is, you can add it
as input or output but if this is not known, you should add `memory'.
As an example, if you access ten bytes of a string, you can use a
memory input like:
{m( ({ struct { char x[10]; } *p = (void *)ptr ; *p; }) )}.
*/
void lmemcpy (void *dst, unsigned src, unsigned short size)
  {
  unsigned dummy;
  asm volatile (
   pushl   %4  \n
   popw%%si\n
   popw%%fs\n
   cld # lmemcpy modify %3 \n
   rep movsb %%fs:(%%si),%%es:(%%di)   # no macro  \n
   nop \n
: =S (dummy), +D (dst), +c (size),
 =m ( ({ struct { char x[10]; } *p = (void *)dst ; *p; }) )
: g (src)
: cc, memory
);
  }

[EMAIL PROTECTED] ~]$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)
[EMAIL PROTECTED] ~]$ gcc -O2 tmp.c
tmp.c: In function lmemcpy:
tmp.c:22: error: invalid lvalue in asm statement
tmp.c:11: error: invalid lvalue in asm output 3
[EMAIL PROTECTED] ~]$ 

 Thanks,
 Etienne.


-- 
   Summary: Extended Asm modification of a range of bytes
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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

[Bug c/30785] New: Test to null pointer optimised away at -O2

[etienne_lorrain at yahoo dot fr]

$ cat tmp.c
typedef unsigned size_t;
char *xxcpy(  char *pDest, const char *pSrc, size_t n);
char *strncpy(  char *pDest, const char *pSrc, size_t n) {
  if (pDest == 0 || pSrc == 0) {
  if (pDest)
  *pDest = 0;
  return pDest;
  }
  return xxcpy (pDest, pSrc, n);
  }
$ powerpc-eabi-gcc -Wall -S tmp.c -o tmp.s -O2 -mcpu=440
$ cat tmp.s .file   tmp.c
.section.text
.align 2
.globl strncpy
.type   strncpy, @function strncpy: stwu 1,-8(1)
mflr 0
stw 0,12(1)
bl xxcpy
lwz 0,12(1)
addi 1,1,8
mtlr 0
blr
.size   strncpy, .-strncpy
.ident  GCC: (GNU) 4.1.1
$ powerpc-eabi-gcc -Wall -S tmp.c -o tmp.s -O1 -mcpu=440
$ cat tmp.s .file   tmp.c
.section.text
.align 2
.globl strncpy
.type   strncpy, @function strncpy: stwu 1,-8(1)
mflr 0
stw 0,12(1)
cmpwi 0,3,0
beq- 0,.L2
cmpwi 7,4,0
bne+ 7,.L4
stb 4,0(3)
b .L2 .L4: bl xxcpy .L2: lwz 0,12(1)
mtlr 0
addi 1,1,8
blr
.size   strncpy, .-strncpy
.ident  GCC: (GNU) 4.1.1
$ powerpc-eabi-gcc -v
Using built-in specs.
Target: powerpc-eabi Configured with: ../gcc-4.1.1/configure
--target=powerpc-eabi --with-cpu=440 --enable-languages=c,c++
Thread model: single
gcc version 4.1.1 

  Seems quite clear some optimisation assumes pointers cannot be null.
  Is there a flag to disable this option?
  Thanks,
  Etienne.


-- 
   Summary: Test to null pointer optimised away at -O2
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: powerpc-eabi


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

[Bug c/30785] Test to null pointer optimised away at -O2

[etienne_lorrain at yahoo dot fr]

--- Comment #2 from etienne_lorrain at yahoo dot fr  2007-02-13 13:44 
---
 Problem is fixed by -fno-tree-vrp and -O2
 I am not a specialist of -fdump-tree-all, but it seems like that:
 tmp.c.t35.copyprop1:

;; Function strncpy (strncpy)

strncpy (pDest, pSrc, n)
{
  char * D.1282;
  char * D.1281;

bb 0:
  if (pDest_2 == 0B) goto L1; else goto L0;

L0:;
  if (pSrc_5 == 0B) goto L1; else goto L4;

L1:;
  if (pDest_2 != 0B) goto L2; else goto L3;

L2:;
  *pDest_2 = 0;

L3:;
  pDest_4 = pDest_2;
  goto bb 6 (L5);

L4:;
  pDest_7 = xxcpy (pDest_2, pSrc_5, n_6);
  pDest_8 = pDest_7;

  # pDest_1 = PHI pDest_2(4), pDest_7(5);
L5:;
  return pDest_1;

}
---
  tmp.t36.vrp, the test disappear:

;; Function strncpy (strncpy)


SSA replacement table
N_i - { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

pDest_12 - { pDest_2 }
pDest_13 - { pDest_2 }
pDest_14 - { pDest_2 }
pDest_15 - { pDest_2 }
pSrc_16 - { pSrc_5 }

Number of virtual NEW - OLD mappings:   0
Number of real NEW - OLD mappings:  5
Number of total NEW - OLD mappings: 5

Number of virtual symbols: 0


Incremental SSA update started at block: 0

Number of blocks in CFG: 9
Number of blocks to update: 9 (100%)




Value ranges after VRP:

pDest_1: VARYING
pDest_2: ~[0B, 0B]  EQUIVALENCES: { } (0 elements)
retval_3: VARYING
pSrc_5: ~[0B, 0B]  EQUIVALENCES: { } (0 elements)
pDest_7: VARYING
pDest_8: [pDest_7, pDest_7]  EQUIVALENCES: { pDest_7 } (1 elements)
pDest_15: ~[0B, 0B]  EQUIVALENCES: { pDest_2 } (1 elements)
pSrc_16: ~[0B, 0B]  EQUIVALENCES: { pSrc_5 } (1 elements)


Folding predicate pDest_2 == 0B to 0
Folding predicate pSrc_5 == 0B to 0
Folding predicate pDest_2 != 0B to 1
Removing basic block 7
Removing basic block 2
Removing basic block 8
Removing basic block 3
Removing basic block 4
Removing basic block 1
Merging blocks 0 and 5
Merging blocks 0 and 6
strncpy (pDest, pSrc, n)
{
  char * D.1282;
  char * D.1281;

bb 0:
  pDest_7 = xxcpy (pDest_2, pSrc_5, n_6);
  pDest_8 = pDest_7;
  return pDest_7;

}

  Thanks,
  Etienne.


-- 


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

[Bug target/29613] static string in vararg function

[etienne_lorrain at yahoo dot fr]

--- Comment #1 from etienne_lorrain at yahoo dot fr  2006-12-06 12:47 
---
 Was another problem (Initialise the main stack at the top of the reserved
space, without keeping two words safety linked to the calling convention,
so the first call would erase the first static variable at top_stack+4)
 Sorry.


-- 

etienne_lorrain at yahoo dot fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/29613] New: static string in vararg function

[etienne_lorrain at yahoo dot fr]

When executing that on a target:

#include stdarg.h

void bug_vsprintf( char *pString, const char *format, va_list ap)
{
char c;
char *str = 0;
int str_cnt = 0;

while((c = *format++) != '\0')
{
if (c == '%')
{
if (*format++ == 's')
{
str = va_arg(ap, char *);
if (str == 0) str = (null);
for (str_cnt = 0; str[str_cnt] != '\0' 
str_cnt = 5; str_cnt++)
continue;
if (str_cnt  5) {
static char errmsg[32] = (invalid %s
ptr);
//char errmsg[32] = (invalid %s ptr);
// no bug
str = errmsg;
str_cnt = sizeof((invalid %s ptr)) -
1;
}
}


while(str_cnt)
{
*pString++ = (*str++);
str_cnt--;
}
}
else
*pString++ = c;
}

*pString = '\0';

}

void bug_sprintf( char *pString, const char *format, ...)
{
va_list argptr;

va_start( argptr, format );
bug_vsprintf( pString, format, argptr );
va_end( argptr );
}

void triggerbug(void)
{
char buffer[50];
bug_sprintf(buffer, %s, 123456789);
printf (buggy buffer: %s i.e. 0x%X 0x%X 0x%X ...\r\n, buffer,
buffer[0], buffer[1], buffer[2]);
}


 (first include stdio.h for printf)
Compilation switch:
powerpc-eabi-gcc -Wall -W -O2 -fno-strict-aliasing -ffunction-sections
-std=gnu99 -Xassembler -mregnames bug.c

  I get the line:
buggy buffer: À i.e. 0xC0 0x0 0x57 ...
  If I remove the static (in static char errmsg), I get what I want:
buggy buffer: (invalid %s ptr) i.e. 0x28 0x69 0x6E ...


-- 
   Summary: static string in vararg function
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
  GCC host triplet: cygwin-ia32
GCC target triplet: powerpc-eabi


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

[Bug middle-end/29029] temporary created for unknown reason

[etienne_lorrain at yahoo dot fr]

--- Comment #2 from etienne_lorrain at yahoo dot fr  2006-09-12 11:12 
---
 X (*str)
 We need a temporary here because *str can be modified inside the asm and we
 don't know that you want it in a memory or a register.

  *str cannot be modified inside the asm because that is an input.
  Even if it is modified, copy_in_dataseg is a dead variable, out of scope.
  Considering its size (26 bytes), it cannot be in register.

 Anyways using m(*str) instead changes that and fixes your issue.

  But that insert a seriously strange initialisation of %dl (or %edx with
 GCC-3.4.6):
cygne:/home/etienne/projet# cat aa.s
.file   aa.c
.text
.globl BOOT1_uninstall_mbr
.type   BOOT1_uninstall_mbr, @function
BOOT1_uninstall_mbr:
pushl   %edi
pushl   %esi
pushl   %ebx
subl$28, %esp
movl%esp, %eax
pushl   $28
pushl   $uninstall_mbr
pushl   %eax
callmemcpy
leal8(%esp), %esi
movb10(%esp), %dl
#APP
   movw%es,%ax
   pushl   $31744
   popw%bx
   popw%es
   pushw   %ax
   callw   read_disk
   popw%es
   setc%dl# set dest to 1 if carry, else clear dest

#NO_APP
xorl%eax, %eax
testb   %dl, %dl
setne   %al
addl$28, %esp
popl%ebx
popl%esi
popl%edi
ret
.size   BOOT1_uninstall_mbr, .-BOOT1_uninstall_mbr
.comm   uninstall_mbr,28,4
.ident  GCC: (GNU) 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)
.section.note.GNU-stack,,@progbits

 Since X means any operand, this is the correct behavior of the compiler.

  Maybe that is m which is strange, I never understood what is the added
 instruction so did not used it. I was thinking m forced a memory referenced
 with a symbol (so not in stack) - and I have seen temporary .data variables
 generated for that - and the associated copy back to stack, maybe only when
 used as asm outputs.


-- 


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

[Bug c/29029] New: temporary created for unknown reason

[etienne_lorrain at yahoo dot fr]

[EMAIL PROTECTED] gujin]$ cat tmp.c
#include string.h

typedef struct {
unsigned short data[3];
union diskcmd {
unsigned udata[5];
unsigned char cdata[20];
} cmd;
} bootloader2_t;

bootloader2_t uninstall_mbr;

extern inline unsigned char
BOOT1_diskread (union diskcmd *str, unsigned buffer)
  {
  unsigned short status, dummy;
  unsigned char  returned;

  asm volatile (
   movw%%es,%%ax   \n
   pushl   %4  \n
   popw%%bx\n
   popw%%es\n
   pushw   %%ax\n
   callw   read_disk   \n
   popw%%es\n
   setc%%dl# set dest to 1 if carry, else clear dest   \n
: =a (status), =d (returned), =S (dummy)
: S (str), g (buffer), d (str-cdata[2]), X (*str)
: ebx, edi, ecx, memory
);
  return returned;
  }

unsigned char BOOT1_uninstall_mbr (void)
  {
  bootloader2_t copy_in_dataseg;

  memcpy (copy_in_dataseg, uninstall_mbr, sizeof (bootloader2_t));
  return (BOOT1_diskread (copy_in_dataseg.cmd, 0x7c00) != 0);
  }
[EMAIL PROTECTED] gujin]$ /home/etienne/projet/toolchain-2.95.3/bin/gcc
-fomit-frame-pointer -mrtd -Os -c -o tmp.o tmp.c  size tmp.o
   textdata bss dec hex filename
 69   0   0  69  45 tmp.o
[EMAIL PROTECTED] gujin]$ /home/etienne/projet/toolchain-3.4.5/bin/gcc
-fomit-frame-pointer -mrtd -Os -c -o tmp.o tmp.c  size tmp.o
   textdata bss dec hex filename
 67   0   0  67  43 tmp.o
[EMAIL PROTECTED] gujin]$ /home/etienne/projet/toolchain-4.1.1/bin/gcc
-fomit-frame-pointer -mrtd -Os -c -o tmp.o tmp.c  size tmp.o
   textdata bss dec hex filename
 93   0   0  93  5d tmp.o
[EMAIL PROTECTED] gujin]$ /home/etienne/projet/toolchain-4.1.1/bin/gcc
-fomit-frame-pointer -mrtd -Os -S -o tmp.s tmp.c
[EMAIL PROTECTED] gujin]$ cat tmp.s
.file   tmp.c
.text
.globl BOOT1_uninstall_mbr
.type   BOOT1_uninstall_mbr, @function
BOOT1_uninstall_mbr:
pushl   %edi
pushl   %esi
pushl   %ebx
subl$56, %esp
leal8(%esp), %eax
pushl   $28
pushl   $uninstall_mbr
pushl   %eax
callmemcpy
movb18(%esp), %al
leal16(%esp), %esi
movb%al, 7(%esp)
leal36(%esp), %eax
pushl   $20
pushl   %esi
pushl   %eax
callmemcpy
movb7(%esp), %dl
#APP
   movw%es,%ax
   pushl   $31744
   popw%bx
   popw%es
   pushw   %ax
   callw   read_disk
   popw%es
   setc%dl# set dest to 1 if carry, else clear dest

#NO_APP
xorl%eax, %eax
testb   %dl, %dl
movb%dl, 3(%esp)
setne   %al
addl$56, %esp
popl%ebx
popl%esi
popl%edi
ret
.size   BOOT1_uninstall_mbr, .-BOOT1_uninstall_mbr
.comm   uninstall_mbr,28,4
.ident  GCC: (GNU) 4.1.1
.section.note.GNU-stack,,@progbits

  Note the _two_ memcpy, a temporary is created identical of copy_in_dataseg,
 even if copy_in_dataseg could be used without problem.
 If using the -O2 optimisation, the second memcpy() is inlined - but nothing
 more.


-- 
   Summary: temporary created for unknown reason
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug target/27856] With -Os, loading a constant to a register can use another register

[etienne_lorrain at yahoo dot fr]

--- Comment #3 from etienne_lorrain at yahoo dot fr  2006-09-05 11:32 
---
 Just for info, does that means we need to wait for YARA to be included,
considering 
http://gcc.gnu.org/ml/gcc/2006-08/msg00164.html
 it will probably happen after 4.2 ?

 I am seeing a lot of them, even some pattern like that to clear %eax:
xor %edx,%edx
...
mov %edx,%eax
... use %eax ...
mov 10,%edx

 Thanks.


-- 


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

[Bug c/28946] New: assembler shifts set the flag ZF, no need to re-test to zero

[etienne_lorrain at yahoo dot fr]

[EMAIL PROTECTED]:~$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
 --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --
enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060729 (prerelease) (Debian 4.1.1-10)
[EMAIL PROTECTED]:~$ cat tmp1.c
int fct1(void);
int fct2(void);

int fct (unsigned nb)
  {
  if ((nb  5) != 0)
return fct1();
  else
return fct2();
  }
[EMAIL PROTECTED]:~$ gcc -O3 -fomit-frame-pointer -S tmp1.c -o tmp1.s
[EMAIL PROTECTED]:~$ cat tmp1.s
.file   tmp1.c
.text
.p2align 4,,15
.globl fct
.type   fct, @function
fct:
movl4(%esp), %eax
shrl$5, %eax
testl   %eax, %eax
je  .L2
jmp fct1
.p2align 4,,7
.L2:
jmp fct2
.size   fct, .-fct
.ident  GCC: (GNU) 4.1.2 20060729 (prerelease) (Debian 4.1.1-10)
.section.note.GNU-stack,,@progbits
[EMAIL PROTECTED]:~$

 The assembly instruction testl %eax, %eax is not needed considering the
Intel documentation of SAL/SAR/SHL/SHR, Flags Affected:
The SF, ZF, and PF flags are set according to the result.


-- 
   Summary: assembler shifts set the flag ZF, no need to re-test to
zero
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug c/28770] New: one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[etienne_lorrain at yahoo dot fr]

 build  tar -xjf ../src/gcc-g++-$(GCC_VERSION).tar.bz2

# PATH has to contains $(HOME)/local/bin/ before anything else here
# Add in /etc/profile the lines (after cd $HOME) :
#export HOME=/cygdrive/c/cygwin-gcc
#export PATH=~/local/bin/:/usr/local/bin:/usr/bin:/bin
#export INFOPATH=~/local/info:/usr/local/info:/usr/info
#export MANPATH=~/local/man:/usr/local/man:/usr/man

native-toolchain: local
[ -d build ] || $(MAKE) toolchain-src
cd build  rm -rf native_binutils native_gcc  mkdir native_binutils
native_gcc
cd build/native_binutils  ../binutils-$(BINUTILS_VERSION)/configure
--prefix=$(HOME)/local
cd build/native_binutils  make  make install
cd build/native_gcc  ../gcc-$(GCC_VERSION)/configure
--prefix=$(HOME)/local
cd build/native_gcc  make bootstrap
# - cd build/native_gcc  make -k check  check.log 21
cd build/native_gcc  make install

# That will fail if --prefix=... is not in the $PATH.
ppc-toolchain:
[ -x local/bin/gcc ] || $(MAKE) native-toolchain
cd build  rm -rf ppc_binutils ppc_gcc  mkdir ppc_binutils ppc_gcc
cd build/ppc_binutils  ../binutils-$(BINUTILS_VERSION)/configure
--prefix=$(HOME)/local --program-prefix=x --target=powerpc-ibm-eabi
cd build/ppc_binutils  make  make install
# rm -rf build/ppc_gcc  mkdir build/ppc_gcc
cd build/ppc_gcc  ../gcc-$(GCC_VERSION)/configure
--prefix=$(HOME)/local --program-prefix=x --target=powerpc-ibm-eabi \
--with-cpu=440 --with-newlib --enable-languages=c
cd build/ppc_gcc  make  make install
---


-- 
   Summary: one reference to powerpc-ibm-eabi-ar.exe when only
xar.exe installed
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: powerpc-ibm-eabi


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

[Bug bootstrap/28770] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[etienne_lorrain at yahoo dot fr]

--- Comment #2 from etienne_lorrain at yahoo dot fr  2006-08-18 12:25 
---
  I change --target=powerpc-ibm-eabi to --target=powerpc-eabi and
 --enable-languages=c to --enable-languages=c,c++ but the configure
 should be the same, I do not know what means pre-installed...

# rm -rf build/ppc_gcc  mkdir build/ppc_gcc
cd build/ppc_gcc  ../gcc-4.1.1/configure
--prefix=/cygdrive/c/cygwin-gcc/local
 --program-prefix=x --target=powerpc-eabi \
--with-cpu=440 --with-newlib --enable-languages=c,c++
creating cache ./config.cache
checking host system type... i686-pc-cygwin
checking target system type... powerpc-unknown-eabi
checking build system type... i686-pc-cygwin
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for gnatbind... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1
$$f
2
checking for correct version of gmp.h... no
*** This configuration is not supported in the following subdirectories:
 target-libmudflap
(Any other directories should still work fine.)
checking for bison... bison -y
checking for bison... bison
checking for gm4... no
checking for gnum4... no
checking for m4... m4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
checking for expect... expect
checking for runtest... no
checking for i686-pc-cygwin-ar... no
checking for ar... ar
checking for i686-pc-cygwin-as... no
checking for as... as
checking for i686-pc-cygwin-dlltool... no
checking for dlltool... dlltool
checking for i686-pc-cygwin-ld...
/cygdrive/c/cygwin-gcc/local/lib/gcc/i686-pc-c
ygwin/4.1.1/../../../../i686-pc-cygwin/bin/ld.exe
checking for i686-pc-cygwin-lipo... no
checking for lipo... no
checking for i686-pc-cygwin-nm... no
checking for nm... nm
checking for i686-pc-cygwin-ranlib... no
checking for ranlib... ranlib
checking for i686-pc-cygwin-strip... no
checking for strip... strip
checking for i686-pc-cygwin-windres... no
checking for windres... windres
checking for i686-pc-cygwin-objcopy... no
checking for objcopy... objcopy
checking for i686-pc-cygwin-objdump... no
checking for objdump... objdump
checking for powerpc-eabi-ar... no
checking for powerpc-eabi-as... no
checking for powerpc-eabi-cc... no
checking for powerpc-eabi-gcc... no
checking for powerpc-eabi-c++... no
checking for powerpc-eabi-g++... no
checking for powerpc-eabi-cxx... no
checking for powerpc-eabi-gxx... no
checking for powerpc-eabi-dlltool... no
checking for powerpc-eabi-gcc... no
checking for powerpc-eabi-gcj... no
checking for powerpc-eabi-gfortran... no
checking for powerpc-eabi-ld... no
checking for powerpc-eabi-lipo... no
checking for powerpc-eabi-nm... no
checking for powerpc-eabi-objdump... no
checking for powerpc-eabi-ranlib... no
checking for powerpc-eabi-strip... no
checking for powerpc-eabi-windres... no
checking where to find the target ar... pre-installed
checking where to find the target as... pre-installed
checking where to find the target cc... just compiled
checking where to find the target c++... just compiled
checking where to find the target c++ for libstdc++... just compiled
checking where to find the target dlltool... pre-installed
checking where to find the target gcc... just compiled
checking where to find the target gcj... pre-installed
checking where to find the target gfortran... pre-installed
checking where to find the target ld... pre-installed
checking where to find the target lipo... pre-installed
checking where to find the target nm... pre-installed
checking where to find the target objdump... pre-installed
checking where to find the target ranlib... pre-installed
checking where to find the target strip... pre-installed
checking where to find the target windres... pre-installed
checking whether to enable maintainer-specific portions of Makefiles... no
checking if symbolic links between directories work... yes
updating cache ./config.cache
creating ./config.status
creating Makefile


-- 


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

[Bug bootstrap/28770] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[etienne_lorrain at yahoo dot fr]

--- Comment #6 from etienne_lorrain at yahoo dot fr  2006-08-18 13:55 
---
 I do have $(HOME)/local/powerpc-ibm-eabi/bin/ar.exe
 and I am using $(HOME)/local/bin/xar.exe for my stuff here, after install.
 To bootstrap, GCC may better use $(HOME)/local/powerpc-ibm-eabi/bin/ar.exe
 but that will not be in the path, so GCC needs to call it with full path.

 I was thinking combined tree was not as good, mostly because I had to
 select which common part of the trees to keep - and well, I may have
 choosen the binutils ones (difficult to report a bug to binutils when you
 did not use their source to generate).
 Thanks for the trick about using cpio with or without the -u option (better
 than rm -rf in Makefile), and to show the order you use too.

 Etienne.


-- 


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

[Bug bootstrap/28770] [4.1 Regression] one reference to powerpc-ibm-eabi-ar.exe when only xar.exe installed

[etienne_lorrain at yahoo dot fr]

--- Comment #8 from etienne_lorrain at yahoo dot fr  2006-08-18 15:04 
---
 For 4.2.0, it will find it and use it:

  Will that be in 4.1.2 (or is it in 4.1 prereleases) or only appear in 4.2 ?

   I was thinking combined tree was not as good, mostly because I had to
   select which common part of the trees to keep - and well, I may have
   choosen the binutils ones.

 gcc should always win over binutils.  That's by design.  Changes to the 
 toplevel are almost always driven by changes in gcc -- the binutils tree 
 is mostly agnostic and just follows what gcc does.

  The problem I have is that I am nearly always using the latest binutils
 because I did not get many regressions, but I sometimes regenerate with
 previous versions of compiler (GCC-3.4.5 or even try GCC-2.95.3) - maybe
 only for a quick test - and I better not get libiberty from them for
 binutils... but that is for the other project, with the other processor...

  Thanks,
  Etienne.


-- 


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

[Bug rtl-optimization/27856] New: With -Os, loading a constant to a register can use another register

[etienne_lorrain at yahoo dot fr]

$ cat tmp.c
unsigned athird (unsigned val)
  {
  return val / 3;
  }
$ /home/etienne/projet/toolchain/bin/gcc -S -Os -o tmp.s -fomit-frame-pointer
-fverbose-asm tmp.c
$ cat tmp.s
.file   tmp.c
# GNU C version 4.1.1 (i686-pc-linux-gnu)
#   compiled by GNU C version 4.1.1.
# GGC heuristics: --param ggc-min-expand=62 --param ggc-min-heapsize=60570
# options passed:  -mtune=pentiumpro -auxbase-strip -Os
# -fomit-frame-pointer -fverbose-asm
# options enabled:  -falign-loops -fargument-alias -fbranch-count-reg
# -fcaller-saves -fcommon -fcprop-registers -fcrossjumping
# -fcse-follow-jumps -fcse-skip-blocks -fdefer-pop
# -fdelete-null-pointer-checks -fearly-inlining
# -feliminate-unused-debug-types -fexpensive-optimizations -ffunction-cse
# -fgcse -fgcse-lm -fguess-branch-probability -fident -fif-conversion
# -fif-conversion2 -finline-functions -finline-functions-called-once
# -fipa-pure-const -fipa-reference -fipa-type-escape -fivopts
# -fkeep-static-consts -fleading-underscore -floop-optimize
# -floop-optimize2 -fmath-errno -fmerge-constants -fomit-frame-pointer
# -foptimize-register-move -foptimize-sibling-calls -fpcc-struct-return
# -fpeephole -fpeephole2 -fregmove -freorder-functions
# -frerun-cse-after-loop -frerun-loop-opt -fsched-interblock -fsched-spec
# -fsched-stalled-insns-dep -fschedule-insns2 -fshow-column
# -fsplit-ivs-in-unroller -fstrength-reduce -fstrict-aliasing
# -fthread-jumps -ftrapping-math -ftree-ccp -ftree-copy-prop
# -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-fre
# -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize -ftree-lrs
# -ftree-salias -ftree-sink -ftree-sra -ftree-store-ccp
# -ftree-store-copy-prop -ftree-ter -ftree-vect-loop-version -ftree-vrp
# -funit-at-a-time -fverbose-asm -fzero-initialized-in-bss -m32 -m80387
# -m96bit-long-double -malign-stringops -mfancy-math-387 -mfp-ret-in-387
# -mieee-fp -mno-red-zone -mpush-args -mtls-direct-seg-refs

# Compiler executable checksum: acc0f3237f8807740daa75cf2b5b2d98

.text
.globl athird
.type   athird, @function
athird:
movl4(%esp), %eax   # val, val
movl$3, %edx#, tmp63
movl%edx, %ecx  # tmp63,
xorl%edx, %edx  # tmp62
divl%ecx#
ret
.size   athird, .-athird
.ident  GCC: (GNU) 4.1.1
.section.note.GNU-stack,,@progbits

  Here tmp63 is not needed and the two lines:
movl$3, %edx#, tmp63
movl%edx, %ecx  # tmp63,
  Should be replaced by:
movl$3, %ecx


-- 
   Summary: With -Os, loading a constant to a register can use
another register
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug rtl-optimization/27357] 20 % increase code size in 4.1 vs 3.4.5

[etienne_lorrain at yahoo dot fr]

--- Comment #2 from etienne_lorrain at yahoo dot fr  2006-05-24 13:22 
---
[EMAIL PROTECTED]:~/projet/gujin$ /home/etienne/projet/toolchain/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/etienne/projet/toolchain
--enable-languages=c
Thread model: posix
gcc version 4.1.1 20060517 (prerelease)
[EMAIL PROTECTED]:~/projet/gujin$ /home/etienne/projet/toolchain/bin/gcc tmp1.c 
-Os
-c -o tmp.o  size tmp.o
   textdata bss dec hex filename
279   0   0 279 117 tmp.o
[EMAIL PROTECTED]:~/projet/gujin$ /home/etienne/projet/toolchain/bin/gcc tmp1.c 
-Os
-c -o tmp.o -fno-optimize-sibling-calls  size tmp.o
   textdata bss dec hex filename
251   0   0 251  fb tmp.o

  So tail return optimization disabled by -fno-optimize-sibling-calls has at
least something to do with the size increase.

 Note that this new GCC-4.1.1 prerelease also produce such code:
addl$12, %esp
leal-12(%ebp), %esp
pop allregs
ret


-- 


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

[Bug c/27357] New: 20 % increase code size in 4.1 vs 3.4.5, tail return optimisation

[etienne_lorrain at yahoo dot fr]

Here is a 20 % increase code size, because the compiler tries too much to
 jump to UI_plotHline() instead of just calling the function and then doing
 a standard return at the end of drawbutton()...


[EMAIL PROTECTED] projet]$ cat tmp.c
typedef struct {
unsigned short x, y;/* x should be the easyest to read */
} __attribute__ ((packed)) coord;

extern inline void
UI_plotHline (coord xy, unsigned short xend, unsigned color) {
extern UI_function_plotHline (coord xy, unsigned xend, unsigned color);
UI_function_plotHline (xy, xend, color);
}

extern inline void
UI_setpixel (coord xy, unsigned color) {
extern UI_function_setpixel (coord xy, unsigned color);
UI_function_setpixel (xy, color);
}

extern inline void bound_stack (void)
  {
/*
 * limit included - but add 2 to high limit for reg16, and 4 for reg32
 * if not in bound, exception #BR generated (INT5).
 * iret from INT5 will retry the bound instruction.
 */
  extern unsigned STATE_stack_limit;
  asm volatile ( bound %%esp,%0  : : m (STATE_stack_limit) );
  }

void
drawbutton (coordupperleft, coord  lowerright,
unsigned upperleftcolor, unsigned lowerrightrcolor,
unsigned fillcolor, unsigned drawbackground)
  {bound_stack();{
  /* Enlarge the button by few pixels: */
  upperleft.x -= 2;
  lowerright.x += 2;
  lowerright.y -= 1; /* do not overlap two consecutive lines */

  UI_plotHline (upperleft, lowerright.x, upperleftcolor);   /* top line */
  /* do not change VESA1 banks too often, process horizontally,
 left to right, line per line */
  for (;;) {
  upperleft.y += 1;
  if (upperleft.y = lowerright.y)
  break;
  UI_setpixel (upperleft, upperleftcolor);
  if (drawbackground)
  UI_plotHline (((coord) { .x = upperleft.x + 1, .y = upperleft.y }),
lowerright.x - 1, fillcolor);
  UI_setpixel (((coord) { .x = lowerright.x - 1, .y = upperleft.y }),
lowerrightrcolor);
  }

  UI_plotHline (upperleft, lowerright.x, lowerrightrcolor); /* bottom line
*/
  }}

[EMAIL PROTECTED] projet]$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)
[EMAIL PROTECTED] projet]$ gcc -Os -c tmp.c  size *.o
   textdata bss dec hex filename
276   0   0 276 114 tmp.o
[EMAIL PROTECTED] projet]$ toolchain-3.4.5/bin/gcc -v
Reading specs from
/home/etienne/projet/toolchain-3.4.5/bin/../lib/gcc/i686-pc-linux-gnu/3.4.5/specs
Configured with: ../configure --prefix=/home/etienne/projet/toolchain
--enable-languages=c
Thread model: posix
gcc version 3.4.5
[EMAIL PROTECTED] projet]$ toolchain-3.4.5/bin/gcc -Os -c tmp.c  size *.o
   textdata bss dec hex filename
227   0   0 227  e3 tmp.o
[EMAIL PROTECTED] projet]$


-- 
   Summary: 20 % increase code size in 4.1 vs 3.4.5, tail return
optimisation
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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

[Bug middle-end/23631] construct to memory and memcpy instead of memset

[etienne_lorrain at yahoo dot fr]

--- Comment #4 from etienne_lorrain at yahoo dot fr  2006-01-23 09:56 
---
(In reply to comment #3)
 PR 23477  was fixed in 4.1.0 and not 4.0.3.  This is still a dup of that bug.
 *** This bug has been marked as a duplicate of 23477 ***

  For me, 23477 is fixed in GCC: (GNU) 4.0.3 20051201 (prerelease) (Debian
4.0.2-5) (this bug is in C++ so compile with g++); but the current bug 23631
is still present (use pure C).

  Etienne.


-- 

etienne_lorrain at yahoo dot fr changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


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

[Bug middle-end/23631] construct to memory and memcpy instead of memset

[etienne_lorrain at yahoo dot fr]

--- Comment #2 from etienne_lorrain at yahoo dot fr  2006-01-16 10:36 
---
  Same bug still present in gcc version 4.0.3 20051201 (prerelease) (Debian
4.0.2-5).
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23477 is itself corrected, but
this current bug has never been corrected.


-- 

etienne_lorrain at yahoo dot fr changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


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

[Bug c/24177] New: function returning structure produce very long/slow assembly

[etienne_lorrain at yahoo dot fr]

Compiling this file with -O2 optimisation:

struct str {
int a, b, c, d;
};

void fct3 (struct str *);

extern inline struct str fct (void)
{
struct str returned = { 1, 2, 3, 4 };
return returned;
}

void fct2 (void)
{
struct str tmp;

tmp = fct ();
fct3 (tmp);
}

  with this compiler:
gcc version 4.0.2 20050913 (prerelease) (Debian 4.0.1-7)
  creates this assembler having three copies of the structure
 in the stack, and one as constant in .rodata:
$ gcc -O2 tmp.c -S -o tmp.s
$ cat tmp.s
.file   tmp.c
.section.rodata
.align 4
.type   C.0.1141, @object
.size   C.0.1141, 16
C.0.1141:
.long   1
.long   2
.long   3
.long   4
.text
.p2align 4,,15
.globl fct2
.type   fct2, @function
fct2:
pushl   %ebp
movl%esp, %ebp
pushl   %edi
pushl   %esi
subl$76, %esp
leal-56(%ebp), %edi
movl$C.0.1141, %esi
cld
movl$4, %ecx
rep
movsl
leal-24(%ebp), %edi
leal-56(%ebp), %esi
movb$4, %cl
rep
movsl
leal-40(%ebp), %edi
leal-24(%ebp), %esi
movb$4, %cl
rep
movsl
leal-40(%ebp), %eax
pushl   %eax
callfct3
addl$16, %esp
leal-8(%ebp), %esp
popl%esi
popl%edi
popl%ebp
ret
.size   fct2, .-fct2
.ident  GCC: (GNU) 4.0.2 20050913 (prerelease) (Debian 4.0.1-7)
.section.note.GNU-stack,,@progbits

  If compiled with -Os, the memcpy function is called three times.
$ gcc -Os tmp.c -S -o tmp.s
$ cat tmp.s
.file   tmp.c
.section.rodata
.align 4
.type   C.0.1141, @object
.size   C.0.1141, 16
C.0.1141:
.long   1
.long   2
.long   3
.long   4
.text
.globl fct2
.type   fct2, @function
fct2:
pushl   %ebp
movl%esp, %ebp
pushl   %esi
pushl   %ebx
subl$48, %esp
leal-56(%ebp), %ebx
pushl   $16
pushl   $C.0.1141
pushl   %ebx
callmemcpy
leal-24(%ebp), %esi
pushl   $16
pushl   %ebx
pushl   %esi
callmemcpy
leal-40(%ebp), %ebx
pushl   $16
pushl   %esi
pushl   %ebx
callmemcpy
addl$36, %esp
pushl   %ebx
callfct3
popl%eax
leal-8(%ebp), %esp
popl%ebx
popl%esi
popl%ebp
ret
.size   fct2, .-fct2
.ident  GCC: (GNU) 4.0.2 20050913 (prerelease) (Debian 4.0.1-7)
.section.note.GNU-stack,,@progbits

  That is not a regression, gcc-3.4* and gcc-2.95 do not produce very good
 assembler code neither for this source file.

  Etienne.


-- 
   Summary: function returning structure produce very long/slow
assembly
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug c/23782] New: -Os +22%: gcc-3.4.4 does it in 230 bytes, gcc-4.0.2-pre in 281 bytes

[etienne_lorrain at yahoo dot fr]

[EMAIL PROTECTED]:~/projet/gujin$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-
languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --
with-system-zlib --libexecdir=/usr/lib --enable-nls --without-included-
gettext --enable-threads=posix --program-suffix=-4.0 --enable-__cxa_atexit --
enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --
enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --with-java-
home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-
werror --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)
[EMAIL PROTECTED]:~/projet/gujin$ gcc -Os -c -o tmp.o tmp.c  size tmp.o
   textdata bss dec hex filename
281   0   0 281 119 tmp.o
[EMAIL PROTECTED]:~/projet/gujin$ ../toolchain-3.4.4-2.16/bin/gcc -v
Reading specs from /home/etienne/projet/toolchain-3.4.4-
2.16/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: ../configure --prefix=/home/etienne/projet/toolchain --enable-
languages=c
Thread model: posix
gcc version 3.4.4
[EMAIL PROTECTED]:~/projet/gujin$ ../toolchain-3.4.4-2.16/bin/gcc -Os -c -o 
tmp.o 
tmp.c  size tmp.o
   textdata bss dec hex filename
230   0   0 230  e6 tmp.o
[EMAIL PROTECTED]:~/projet/gujin$ cat tmp.c
typedef struct {
unsigned short x, y;/* x should be the easyest to read */
} __attribute__ ((packed)) coord;

#define FASTCALL__attribute__ (( fastcall ))

struct user_interface_fct_str {
 void (*setpixel) (coord xy, unsigned color) FASTCALL;
 void (*plotHline) (coord xy, unsigned short xend, unsigned color);
 } function;

extern inline void
UI_plotHline (coord xy, unsigned short xend, unsigned color) {
  function.plotHline (xy, xend, color);
  }
extern inline void
UI_setpixel (coord xy, unsigned color) {
  function.setpixel (xy, color);
  }

extern unsigned stack_limit;

extern inline void bound_stack (void)
  {
  asm volatile ( bound %%esp,%0  : : m (stack_limit) );
  }

void drawbutton (coordupperleft, coord  lowerright,
unsigned upperleftcolor, unsigned lowerrightrcolor,
unsigned fillcolor, unsigned drawbackground)
  {bound_stack();{
  /* Enlarge the button by few pixels: */
  upperleft.x -= 2;
  lowerright.x += 2;
  lowerright.y -= 1; /* do not overlap two consecutive lines */

  UI_plotHline (upperleft, lowerright.x, upperleftcolor);   /* top line */
  /* do not change VESA1 banks too often, process horizontally,
 left to right, line per line */
  for (;;) {
  upperleft.y += 1;
  if (upperleft.y = lowerright.y)
  break;
  UI_setpixel (upperleft, upperleftcolor);
  if (drawbackground)
  UI_plotHline (((coord) { .x = upperleft.x + 1, .y = upperleft.y }),
lowerright.x - 1, fillcolor);
  UI_setpixel (((coord) { .x = lowerright.x - 1, .y = upperleft.y }),
lowerrightrcolor);
  }

  UI_plotHline (upperleft, lowerright.x, lowerrightrcolor); /* bottom line 
*/
  }}
[EMAIL PROTECTED]:~/projet/gujin$ 

  Doing the commands:
../toolchain-3.4.4-2.16/bin/gcc -Os -S -o tmp.a tmp.c
gcc -Os -S -o tmp.b tmp.c
diff -y tmp.a tmp.b
  does not give me a clear idea of the reason...

-- 
   Summary: -Os +22%: gcc-3.4.4 does it in 230 bytes, gcc-4.0.2-pre
in 281 bytes
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug c/23631] New: construct to memory and memcpy instead of memset

[etienne_lorrain at yahoo dot fr]

A global .rodata constant is created in the following case
 and then memcpy() to the variable in the stack, instead
 of just calling the intended memset.

[EMAIL PROTECTED]:~/projet/gujin$ cat  tmp.c
int
sub (int i)
{
  int array[100] = { 0 };

  sub2 (array[i]);
}

[EMAIL PROTECTED]:~/projet/gujin$ ~/projet/toolchain/bin/gcc -S -Os tmp.c -o 
tmp.s
[EMAIL PROTECTED]:~/projet/gujin$ cat tmp.s
.file   tmp.c
.section.rodata
.align 32
.type   C.0.1134, @object
.size   C.0.1134, 400
C.0.1134:
.zero   400
.text
.globl sub
.type   sub, @function
sub:
pushl   %ebp
movl%esp, %ebp
pushl   %ebx
subl$400, %esp
pushl   $400
pushl   $C.0.1134
leal-404(%ebp), %ebx
pushl   %ebx
callmemcpy
movl8(%ebp), %eax
leal(%ebx,%eax,4), %eax
pushl   %eax
callsub2
addl$16, %esp
movl-4(%ebp), %ebx
leave
ret
.size   sub, .-sub
.ident  GCC: (GNU) 4.0.2 20050811 (prerelease)
.section.note.GNU-stack,,@progbits
[EMAIL PROTECTED]:~/projet/gujin$ ~/projet/toolchain/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/etienne/projet/toolchain --enable-
l
anguages=c
Thread model: posix
gcc version 4.0.2 20050811 (prerelease)

  See also the thread at:
http://gcc.gnu.org/ml/gcc/2005-08/msg00660.html
  Thanks to Jim Wilson (GNU Tools Support, http://www.specifix.com) for the
 reduced test case and the analysis of the bug in gcc@gcc.gnu.org list.

  Etienne.

-- 
   Summary: construct to memory and memcpy instead of memset
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/22439] New: ICE with unsigned char array: size_binop, at fold-const.c:1637

[etienne_lorrain at yahoo dot fr]

: etienne_lorrain at yahoo dot fr
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug c/21680] New: GCC-4.0 vs GCC-3.3.6 ia32 -Os: code size increase from 261 to 5339 bytes

[etienne_lorrain at yahoo dot fr]

;
  }

if (is_valid_chgmode_keycode (key))
  {
if (timeout == 0)
  {
toredraw.topmenu = 1;
toredraw.presskey = 1;
  }
  }
else if ((key == 0x1312) || (key == (0x3900 | ' ')))
  {
struct gujin_param_attrib params = get_gujin_param_attrib ();


if (diskconfig_changed (gujin_attr, params))
  {
probedisk (0xFF);
disk_analyse (params);
  }
else if (searchconfig_changed (gujin_attr, params))
  disk_analyse (params);

gujin_attr = params;
Menu.nbperpage = 0;

toredraw = (struct todraw_str) { 1, 1, 1, 1, 1,.presskey = 
0,.refresh =
1};
  }
else if (gujin_attr.verbose)
toredraw = (struct todraw_str) { 1, 1, 1, 1, 1,.presskey = 1};
  }
}


[EMAIL PROTECTED]:~/projet/gujin$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.6/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--enable-__cxa_atexit --with-system-zlib --enable-nls
--without-included-gettext --enable-clocale=gnu --enable-debug
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.6 (Debian 1:3.3.6-5)

[EMAIL PROTECTED]:~/projet/gujin$ ../toolchain/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/etienne/projet/toolchain
--enable-languages=c
Thread model: posix
gcc version 4.0.0

-- 
   Summary: GCC-4.0 vs GCC-3.3.6 ia32 -Os: code size increase from
261 to 5339 bytes
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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

[Bug c/21626] New: Do not create very big empty structure to initialise stack

[etienne_lorrain at yahoo dot fr]

[EMAIL PROTECTED]:~/projet/gujin$ cat tmp.c
typedef struct {
enum { INIT = 0 } mode;
unsigned  very_big_array[4096];
struct short_struct { int a,b,c; } str[5];
} z_stream;

struct short_struct fct (unsigned val) {
z_stream gzlib = { .mode = INIT }; /* everything is null */
return gzlib.str[val];
}
[EMAIL PROTECTED]:~/projet/gujin$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.6/specs
Configured with: ../src/configure -v --enable-
languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --
mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-
dir=/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-
zlib --enable-nls --without-included-gettext --enable-clocale=gnu --enable-
debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.6 (Debian 1:3.3.6-5)
[EMAIL PROTECTED]:~/projet/gujin$ gcc -Os -c tmp.c -o tmp.o
[EMAIL PROTECTED]:~/projet/gujin$ size tmp.o
   textdata bss dec hex filename
 71   0   0  71  47 tmp.o
[EMAIL PROTECTED]:~/projet/gujin$ ../toolchain-4.0/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/etienne/projet/toolchain --enable-
languages=c
Thread model: posix
gcc version 4.0.0
[EMAIL PROTECTED]:~/projet/gujin$ ../toolchain-4.0/bin/gcc  -Os -c tmp.c -o 
tmp.o
[EMAIL PROTECTED]:~/projet/gujin$ size tmp.o
   textdata bss dec hex filename
  16509   0   0   16509407d tmp.o
[EMAIL PROTECTED]:~/projet/gujin$ ../toolchain-4.0/bin/gcc  -Os -S tmp.c -o 
tmp.s
[EMAIL PROTECTED]:~/projet/gujin$ cat tmp.s
.file   tmp.c
.section.rodata
.align 32
.type   C.0.1145, @object
.size   C.0.1145, 16448
C.0.1145:
.zero   16448
.text
.globl fct
.type   fct, @function
fct:
pushl   %ebp
movl%esp, %ebp
pushl   %ebx
subl$16448, %esp
pushl   $16448
movl8(%ebp), %ebx
pushl   $C.0.1145
leal-16452(%ebp), %eax
pushl   %eax
callmemcpy
imull   $12, 12(%ebp), %eax
pushl   $12
leal-64(%eax,%ebp), %eax
pushl   %eax
pushl   %ebx
callmemcpy
movl%ebx, %eax
movl-4(%ebp), %ebx
leave
ret $4
.size   fct, .-fct
.ident  GCC: (GNU) 4.0.0
.section.note.GNU-stack,,@progbits
[EMAIL PROTECTED]:~/projet/gujin$

-- 
   Summary: Do not create very big empty structure to initialise
stack
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/21529] New: code size regression (+40%) with -Os from GCC-3.4.3 to 4.1

[etienne_lorrain at yahoo dot fr]

Compiling this code with -Os is more than 40 % bigger in size with GCC-4.1
compared to GCC-3.4.3.
See also thread: http://gcc.gnu.org/ml/gcc/2005-05/msg00532.html

struct disk_interface_str {
unsignednb_IDE_found;
struct IDE_found_str {
unsigned short  ideIOadr;
unsigned short  ideIOctrladr;
unsigned char   irq;
unsigned char   bios_order;
unsigned short  reserved;
} *IDE_found;
} DI;

void reorder_IDE_for_linux (void)
  {
  static const unsigned short idearray[] = {
0x1F0, 0x170,
0x1E8, 0x168,
0x1E0, 0x160,
};
  unsigned short cpt, order;

  for (order = 0; order  sizeof(idearray)/sizeof(idearray[0]); order++) {
  for (cpt = order + 1; cpt  DI.nb_IDE_found; cpt++)
  if (DI.IDE_found[cpt].ideIOadr == idearray[order])
  break;
  if (cpt  DI.nb_IDE_found) {
  struct IDE_found_str save = DI.IDE_found[cpt];
  unsigned short i;

  for (i = order; i  cpt; i++) {
  struct IDE_found_str tmp = DI.IDE_found[i];
  DI.IDE_found[i] = save;
  save = tmp;
  }
  DI.IDE_found[cpt] = save;
  }
  }
  }


-- 
   Summary: code size regression (+40%) with -Os from GCC-3.4.3 to
4.1
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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

[Bug c/18057] New: strange warning

[etienne_lorrain at yahoo dot fr]

With the latest version bootstrapped on PC debian:
$ /home/etienne/projet/toolchain/bin/gcc -v
Reading specs from /home/etienne/projet/toolchain/lib/gcc/i686-pc-linux-
gnu/4.0.0/specs
Configured with: ../configure --prefix=/home/etienne/projet/toolchain --enable-
languages=c
Thread model: posix
gcc version 4.0.0 20041017 (experimental)

   compiling this code:
typedef struct {
unsignedlimit : 16;
unsignedbase : 24;
unsignedaccessed : 1;   /* if 1 */
unsignedwritable : 1;   /* if 1 */
unsignedexpansion_direction : 1;/* down if 1 */
unsignedcste_10 : 2;
unsigneddpl : 2;
unsignedpresent : 1;
unsignedlimit_msb : 4;
unsignedavailable : 1;
unsignedcste_0 : 1;
unsignedbig : 1;
unsignedgranularity : 1;
unsignedbase_msb : 8;
} __attribute__ ((packed)) dataseg_t;

dataseg_t dataseg = {
  .limit= 0x,
  .base = 0,
  .accessed = 1,
  .writable = 1,
  .cste_10  = 2,
  .present  = 1,
  .limit_msb= 0xFF,
  .big  = 0,
  .granularity  = 1
};

  leads to this warning (line of .limit_msb):
$ /home/etienne/projet/toolchain/bin/gcc -Os -c tmp.c
tmp.c:25: warning: large integer implicitly truncated to unsigned type

  Etienne.

-- 
   Summary: strange warning
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/18057] strange warning

[etienne_lorrain at yahoo dot fr]

--- Additional Comments From etienne_lorrain at yahoo dot fr  2004-10-19 12:47 
---
  Well, sometimes you are sure the field is 8 bits wide,
 limit_msb is only 4 bits unlike base_msb.
 A value does not fit the size would be better, but ...

  Sorry,
  Etienne.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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