RE: Supporting an instruction in the back-end - II

[Dave Korn]

Mohamed Shafi wrote on 14 May 2008 05:49:

> Hello all,
> 
> Will it be possible to write a pattern in the md file to support
> setting/clearing a bit of a particular register?
> The instructions are as follows:
> 
> clrb Rx, bitNo
> setb Rx, bitNo
> 
> Could you point me to the back-ends that has support for this kind of
> instructions?

  m68k has that kind of insn, you could take a look there.  It's probably
represented by some canonical rtl form for the full expression such as

(set (dest) 
 (andMM3 (dest) 
 (not (lshift (const_int 1) 
  (bitNo)


and likewise for setb.
  


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

gcc 4.3.0 build; I built the g++ compiler, but there are no header files and no C++ libraries

[chris kuhlman]

Hello:

I wrote to the help gcc site and got no response, so I am writing here.  
Help would be immensely appreciated.


I am trying to build GCC 4.3.0.  I built GMP 4.2.2 and MPFR 2.3.1,
and then I built GCC 4.3.0.  Everything appeared to go fine.  I
installed compilers for C, C++, and Fortran.

To configure, I did:

../src-gcc-4.3.0/gcc-4.3.0/configure
--prefix=/home/simsci1/share/gcc-4.3.0/
--with-gmp=/home/simsci1/share/to-build-gcc_4.3.0/gmp-4.2.2/install_exec/
--with-mpfr=/home/simsci1/share/to-build-gcc_4.3.0/mpfr-2.3.1/
--enable-version-specific-runtime-libs

Then I did
make

and then
make install

(The config.log file is attached.)

I then made up and ran some very simple C, C++, and Fortran codes, and
they compiled and ran.

However, I now look in the GCC 4.3.0 install directory, and under 
include there
are no header files for C++, as detailed below.  The include directory 
is empty.  Also, under the bin directory, there are files suspiciously 
missing, like libstdc++.a,  libstdc++.la,  libstdc++.so.6.0.7,  
libsupc++.a,  libsupc++.la, and  libgcc_s.so.1.


Yet, under the bin directory, the g++ and gfortran compiler executables 
exist and work (at least for small codes), as well as the gcc compiler.


So, how can the compiler be installed correctly, but not the header 
files and not the libraries for C++?


I used GCC 4.1.0 to build GCC 4.3.0.  So I looked under the install
directory for GCC 4.1.0, and under the include directory for GCC 4.1.0,
there is a c++ directory and a file called mf-runtime.h.  Under the c++
directory is a directory called 4.1.0 and that directory appears to have 
all of the C++

header files.

Do you know why I did not generate the include directory and header 
files, and the libraries under the lib directory,

when I generated the g++ compiler itself?

Thank you.

chris

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.59.  Invocation command line was

  $ ../src-gcc-4.3.0/gcc-4.3.0/configure 
--prefix=/home/simsci1/share/gcc-4.3.0/ 
--with-gmp=/home/simsci1/share/to-build-gcc_4.3.0/gmp-4.2.2/install_exec/ 
--with-mpfr=/home/simsci1/share/to-build-gcc_4.3.0/mpfr-2.3.1/ 
--enable-version-specific-runtime-libs

## - ##
## Platform. ##
## - ##

hostname = compute-4-8.local
uname -m = i686
uname -r = 2.6.9-22.0.2.ELsmp
uname -s = Linux
uname -v = #1 SMP Tue Jan 17 07:10:04 CST 2006

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = i686
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
hostinfo   = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /home/simsci1/share/gcc-4.1.0/bin
PATH: /home/simsci1/share/gcc-4.1.0/lib
PATH: /home/simsci1/share/to-build-gcc_4.3.0/gmp-4.2.2/install_exec
PATH: /home/simsci1/share/gcc-4.1.0/bin
PATH: /home/simsci1/share/gcc-4.1.0/lib
PATH: /home/simsci1/share/to-build-gcc_4.3.0/gmp-4.2.2/install_exec
PATH: /home/simsci1/share/gcc-4.1.0/bin
PATH: /home/simsci1/share/gcc-4.1.0/lib
PATH: /home/simsci3/users/ckuhlman/gcc-4.3.0/gmp/install_exec
PATH: /opt/gridengine/bin/glinux
PATH: /usr/kerberos/bin
PATH: /usr/local/bin
PATH: /bin
PATH: /usr/bin
PATH: /usr/X11R6/bin
PATH: /opt/ganglia/bin
PATH: /usr/java/jdk1.5.0/bin
PATH: /opt/rocks/bin
PATH: /opt/rocks/sbin
PATH: /home/ckuhlman/bin


## --- ##
## Core tests. ##
## --- ##

configure:1505: checking build system type
configure:1523: result: i686-pc-linux-gnu
configure:1558: checking host system type
configure:1572: result: i686-pc-linux-gnu
configure:1580: checking target system type
configure:1594: result: i686-pc-linux-gnu
configure:1637: checking for a BSD-compatible install
configure:1692: result: /usr/bin/install -c
configure:1703: checking whether ln works
configure:1725: result: yes
configure:1729: checking whether ln -s works
configure:1733: result: yes
configure:2885: checking for gcc
configure:2901: found /home/simsci1/share/gcc-4.1.0/bin/gcc
configure:2911: result: gcc
configure:3155: checking for C compiler version
configure:3158: gcc --version &5
gcc (GCC) 4.1.0
Copyright (C) 2006 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.

configure:3161: $? = 0
configure:3163: gcc -v &5
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.0-src/configure 
--prefix=/home/simsci1/share/gcc-4.1.0 --enable-languages=c,c++
Thread model: posix
gcc version 4.1.0
configure:3166: $? = 0
configure:3168: gcc -V &5
gcc: '-V' option must have argument
configure:3171: $? = 1
configure:3194: checking for C compiler default output file name
configure:3197: gccconftest.c  >&5
configure:3200: $? = 0
configure:3246: result: a.out
configure:3251: checking whet

Re: How to implement the instruction in the back end

[Ian Lance Taylor]

"Mohamed Shafi" <[EMAIL PROTECTED]> writes:

> But it would of great help if you could tell the C statment that
> actually invoked this type of pattern .. Maybe wrt some back-end?

This type of pattern is only generated by if-conversion.  Look at
cond_exec_process_insns in ifcvt.c.

Ian

GCC 4.1.2 Port - Is live analysis going wrong?

[Mohamed Shafi]

Hello all,

In the gcc 4.1.2 port i am working on, i get an ICE in insert_save, at
caller-save.c:725
And following is the assert that assert failure.

  /* A common failure mode if register status is not correct in the
 RTL is for this routine to be called with a REGNO we didn't
 expect to save.  That will cause us to write an insn with a (nil)
 SET_DEST or SET_SRC.  Instead of doing so and causing a crash
 later, check for this common case here.  This will remove one
 step in debugging such problems.  */
  gcc_assert (regno_save_mem[regno][1]);

insert_save function is called by save_call_clobbered_regs() in the
same file.The below is the relevant portion of the dump after local
register allocation.

(insn 210 213 211 1 (set (reg:HI 0 R0 [ d.104 ])
(subreg:HI (reg/v:SF 207 [ d.104 ]) 0)) 4 {movhi_regmove}
(insn_list:REG_DEP_TRUE 208 (nil))
(insn_list:REG_LIBCALL 215 (nil)))

(insn 211 210 215 1 (set (reg:HI 1 R1 [+2 ])
(subreg:HI (reg/v:SF 207 [ d.104 ]) 2)) 4 {movhi_regmove}
(insn_list:REG_DEP_TRUE 208 (nil))
(nil))

(call_insn/u 215 211 217 1 (set (reg:HI 0 R0)
(call:HI (mem:HI (reg/f:HI 234) [0 S2 A16])
(const_int 0 [0x0]))) 25 {*call_value_internal_long}
(insn_list:REG_DEP_ANTI 207 (insn_list:REG_DEP_ANTI 209
(insn_list:REG_DEP_TRUE 213 (insn_list:REG_DEP_TRUE 212
(insn_list:REG_DEP_TRUE 211 (insn_list:REG_DEP_TRUE 210
(insn_list:REG_DEP_ANTI 208 (nil
(expr_list:REG_DEAD (reg:SF 2 R2)
(insn_list:REG_RETVAL 210 (expr_list:REG_EH_REGION (const_int
-1 [0x])
(nil
(expr_list:REG_DEP_TRUE (use (reg:SF 2 R2))
(expr_list:REG_DEP_TRUE (use (reg:SF 0 R0))
(nil

(jump_insn 217 215 222 1 (set (pc)
(if_then_else (le:CC (reg:HI 0 R0)
(const_int 0 [0x0]))
(label_ref:HI 226)
(pc))) 48 {cmpbrhi_le} (insn_list:REG_DEP_TRUE 215 (nil))
(expr_list:REG_DEAD (reg:HI 0 R0)
(expr_list:REG_BR_PROB (const_int 5000 [0x1388])
(nil
;; End of basic block 1, registers live:
 1 [R1] 12 [R12] 14 [R14] 16 [AP] 206 207 208 209 215 218 234

Things go wrong in "call_insn/u 215". Target has R0 and R1 are the
parameter registers. So while building the reload chain for the call
instructions the registers that are live during the call are R0, R1
among other registers. This information is stored in live_throughout
member of the reload chain. In the function save_call_clobbered_regs()
register life information in CHAIN is used to compute which regs are
live during the call. And this is stored in hard_regs_to_save.
After doing the following operations

  /* Compute which hard regs must be saved before this call.  */
  AND_COMPL_HARD_REG_SET (hard_regs_to_save, call_fixed_reg_set);
  AND_COMPL_HARD_REG_SET (hard_regs_to_save, this_insn_sets);
  AND_COMPL_HARD_REG_SET (hard_regs_to_save, hard_regs_saved);
  AND_HARD_REG_SET (hard_regs_to_save, call_used_reg_set);

hard_regs_to_save will still contain R1 in it.(Parameter registers are
part of call used register set.) And hence insert_save is called for
saving reg R1.

>From the time of reload chain generation to save_call_clobbered_regs()
function call things are proper, even though, as the comment says the
registers status is not proper when save_call_clobbered_regs()  is
called. Looking at the dumps i think the only thing that is going
wrong is the live information of the registers.
For a call instructions all the parameter registers used by the call
instructions will be live at the time of the call. But if these
registers are used in the successor blocks only to pass the
parameters, i.e their value is not used again, shouldn't these
registers be marked as dead in the call instruction?. After some
lengthy debugging this is the only conclusion that i can come to. But
i am not sure if this is way live information is handled.

Can some one give any thoughts on this?

Regards,
Shafi

Re: gcc-get enabling-only subscription?

[Joern Rennecke]

> You can put yourself on the (global) allow list, see
> .

This didn't seem to have an effect on gcc-get.

RE: gcc-get enabling-only subscription?

[Dave Korn]

Joern Rennecke wrote on 14 May 2008 16:53:

>> You can put yourself on the (global) allow list, see
>> .
> 
> This didn't seem to have an effect on gcc-get.

  Not entirely surprising, addys on the allow list aren't verified either, so
accepting posts to lists is one thing, but accepting listmgr commands is
another.

  I think you'll probably need to take this up with [EMAIL PROTECTED]


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

gcc-4.2-20080514 is now available

[gccadmin]

Snapshot gcc-4.2-20080514 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080514/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch 
revision 135313

You'll find:

gcc-4.2-20080514.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.2-20080514.tar.bz2 C front end and core compiler

gcc-ada-4.2-20080514.tar.bz2  Ada front end and runtime

gcc-fortran-4.2-20080514.tar.bz2  Fortran front end and runtime

gcc-g++-4.2-20080514.tar.bz2  C++ front end and runtime

gcc-java-4.2-20080514.tar.bz2 Java front end and runtime

gcc-objc-4.2-20080514.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.2-20080514.tar.bz2The GCC testsuite

Diffs from 4.2-20080507 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.2
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: more m32c brokenness

[DJ Delorie]

More digging has identified this patch as the cause of the ongoing
C++-related m32c build failures:

2008-03-24  Richard Guenther  <[EMAIL PROTECTED]>

PR c/22371
* gimplify.c (gimplify_modify_expr): For frontend type-correct
pointer assignments change conversions according to middle-end rules.
(gimplify_modify_expr_rhs): Deal with NULL TARGET_EXPR_INITIAL.
* configure.ac: Include type checking in yes.
* configure: Regenerate.

In file included from ../../../../../gcc/libstdc++-v3/src/strstream.cc:50:
/greed/dj/m32c/gcc/m32c-elf/m32c-elf/m32cm/libstdc++-v3/include/backward/strstream:
 In member function 'void std::ostrstream::_ZTv0_n12_NSt10ostrstreamD0Ev()':
/greed/dj/m32c/gcc/m32c-elf/m32c-elf/m32cm/libstdc++-v3/include/backward/strstream:142:
 error: invalid types in nop conversion
unsigned int
int (*__vtbl_ptr_type) (void)
D.25530 = (unsigned int) D.25529
/greed/dj/m32c/gcc/m32c-elf/m32c-elf/m32cm/libstdc++-v3/include/backward/strstream:142:
 internal compiler error: verify_gimple failed

I have a .ii file and command line, but it's 560kb (-mcpu=m32cm build
of strstream.cc in libstdc++)

Note that --enable-checking=none lets the build pass (as of the 25th)
but I haven't yet tried testing to see if proper code is generated.
Thus, I don't know if the patch caused the bug, or exposed it.