Re: DImode operations

[daniel tian]

HｉDave:
 I add the DI, SF, DFpattern. But when build the libgcc2.c, it
still cause errors.
　　The error information：

../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function '__muldi3':
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:557: internal compiler
error: in emit_move_insn, at expr.c:3379
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [_muldi3.o] Error 1
make[2]: Leaving directory
`/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc/rice-elf/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory
`/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc'
make: *** [all] Error 2

the assert:

gcc_assert (mode != BLKmode
  && (GET_MODE (y) == mode || GET_MODE (y) == VOIDmode));

in function emit_move_insn cause the error. Because the machine mode
in rtx x, y are different. X is SImode, while y is DImode.

And I hacked the CRX archtechiture, after deleting all patterns about
DI, SF, DF, it can still build successful. So I think the error is not
caused by the DI pattern.

function __muldi3:

#ifdef L_muldi3
DWtype
__muldi3 (DWtype u, DWtype v)
{
   //

Re: DImode operations

[daniel tian]

Sorry, Dove, I just gotta the solution to debug the cc1. Dove told me
the link, and I just missed. Now I checked. So sorry, I ask the stupid
question again.

But the former question, I am still puzzled.

Thanks.

GCC debug

[daniel tian]

I follow the instructions from this
website:http://gcc.gnu.org/wiki/DebuggingGCC.
but things is not going to be correct.


bacause when cc1 build libgcc2.c, some error occurred. I have debug
cc1. But If I have to build libgcc2.c,  some complex parameter have to
pass.
I don't know what's xgcc is, but it seems mandatory.  Maybe xgcc will
trigger the cc1, after xgcc processes some preprocessing.
Anyway, I don't know.
Does  anybody have some relevant materials or website, which can give
me an overview.

And this is the debug problem. And hope somebody can give me a clue.
command:
gdb --args $(./xgcc -###
-B/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc/./gcc/
-B/usr/local/cross/rice-elf/rice-elf/bin/
-B/usr/local/cross/rice-elf/rice-elf/lib/ -isystem
/usr/local/cross/rice-elf/rice-elf/include -isystem
/usr/local/cross/rice-elf/rice-elf/sys-include -O2 -g -g -O2 -O2  -O2
-g -g -O2   -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -g  -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I. -I../.././gcc
-I../../../rice-gcc-4.3.0/libgcc -I../../../rice-gcc-4.3.0/libgcc/.
-I../../../rice-gcc-4.3.0/libgcc/../gcc
-I../../../rice-gcc-4.3.0/libgcc/../include  -DHAVE_CC_TLS -o
_muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c 2>&1 | fgrep cc1)
gdb: `--args' specified but no program specified.

Any body who can help me.

Thank you very much.

 daniel.

Re: GCC debug

[daniel tian]

Thanks.
But how to debug cc1. Because now I port the gcc to my RISC target.
But when build the libgcc2.c.  Some error occurred. So i have to debug
it.
Any advice about how to debug?

gdb --args $(./xgcc -###
-B/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc/./gcc/
-B/usr/local/cross/rice-elf/rice-elf/bin/
-B/usr/local/cross/rice-elf/rice-elf/lib/ -isystem
/usr/local/cross/rice-elf/rice-elf/include -isystem
/usr/local/cross/rice-elf/rice-elf/sys-include -O2 -g -g -O2 -O2  -O2
-g -g -O2   -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -g  -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I. -I../.././gcc
-I../../../rice-gcc-4.3.0/libgcc -I../../../rice-gcc-4.3.0/libgcc/.
-I../../../rice-gcc-4.3.0/libgcc/../gcc
-I../../../rice-gcc-4.3.0/libgcc/../include  -DHAVE_CC_TLS -o
_muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c 2>&1 | fgrep cc1)
gdb: `--args' specified but no program specified.

Thanks.

Fwd: GCC debug

[daniel tian]

2009/9/28 Basile STARYNKEVITCH :
> daniel tian wrote:
>>
>> Thanks.
>> But how to debug cc1. Because now I port the gcc to my RISC target.
>> But when build the libgcc2.c.  Some error occurred. So i have to debug
>> it.
>> Any advice about how to debug?
>
>
> Start gdb from the build directory (more precisely from $BUILDIR/gcc)
>
> BTW, I am not sure your question belongs to gcc@gcc.gnu.org - it is really a
> beginner's question, and there are several documents about it.
>
> This is why I reply to you only, not to the list.
>
Thanks.
You didn't get my point.
If I just start up gdb to debug cc1, cc1 will return with message that
it did't know the parameter I pass to it.
The parameter should preprocess by xgcc first. then cc1 continue to
go. But I start up with xgcc, I can't debug cc1.
The website in my first letter, some steps mentioned about how to
debug cc1 and xgcc. I could't follow. So I ask the question here.
I am sure there are some guy also seen this problem before.

Thanks.

Re: Fwd: GCC debug

[Andrew Haley]

daniel tian wrote:
> 2009/9/28 Basile STARYNKEVITCH :
>> daniel tian wrote:
>>> Thanks.
>>> But how to debug cc1. Because now I port the gcc to my RISC target.
>>> But when build the libgcc2.c.  Some error occurred. So i have to debug
>>> it.
>>> Any advice about how to debug?
>>
>> Start gdb from the build directory (more precisely from $BUILDIR/gcc)
>>
>> BTW, I am not sure your question belongs to gcc@gcc.gnu.org - it is really a
>> beginner's question, and there are several documents about it.
>>
>> This is why I reply to you only, not to the list.
>>
> Thanks.
> You didn't get my point.
> If I just start up gdb to debug cc1, cc1 will return with message that
> it did't know the parameter I pass to it.

"gcc -v" shows you all the parameters that are passed to cc1.  You need to
use these in gdb.

Andrew.

Re: DImode operations

[Dave Korn]

daniel tian wrote:

> ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function '__muldi3':
> ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:557: internal compiler
> error: in emit_move_insn, at expr.c:3379

> make[2]: *** [_muldi3.o] Error 1

> gcc_assert (mode != BLKmode
> && (GET_MODE (y) == mode || GET_MODE (y) == VOIDmode));
> 
> in function emit_move_insn cause the error. Because the machine mode
> in rtx x, y are different. X is SImode, while y is DImode.

  Well, you need to establish why this insn is being generated.  Is it coming
from your expanders perhaps?  Now that you've figured out debugging cc1, set a
breakpoint on "internal_compiler_error" and take a look at the backtrace to
see what function has called emit_move_insn; the answer probably lies there.

cheers,
  DaveK

Re: GCC debug

[Dave Korn]

daniel tian wrote:

> And this is the debug problem. And hope somebody can give me a clue.
> command:
> gdb --args $(./xgcc -###
> -B/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc/./gcc/
> -B/usr/local/cross/rice-elf/rice-elf/bin/
> -B/usr/local/cross/rice-elf/rice-elf/lib/ -isystem
> /usr/local/cross/rice-elf/rice-elf/include -isystem
> /usr/local/cross/rice-elf/rice-elf/sys-include -O2 -g -g -O2 -O2  -O2
> -g -g -O2   -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE   -W -Wall
> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
> -Wold-style-definition  -isystem ./include   -g  -DIN_LIBGCC2
> -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I. -I../.././gcc
> -I../../../rice-gcc-4.3.0/libgcc -I../../../rice-gcc-4.3.0/libgcc/.
> -I../../../rice-gcc-4.3.0/libgcc/../gcc
> -I../../../rice-gcc-4.3.0/libgcc/../include  -DHAVE_CC_TLS -o
> _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
> ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c 2>&1 | fgrep cc1)
> gdb: `--args' specified but no program specified.
> 

  It appears that gdb is getting an empty command-line after the "--args"
option.  Are you maybe using a non-bash shell (or some old version of bash)
that doesn't support the "$(...)" syntax?  You could try using backticks
instead.  You could also try running just the part inside "$(...)" separately
to make sure that your fgrep is working.  And, as Andrew says, you can run the
xgcc command yourself with -v and copy-paste the cc1 invocation.

cheers,
  DaveK

Reload going wrong for addition.

[Mohamed Shafi]

Hello all,

I doing a port for a 32bit target for GCC 4.4.0. I am getting the
following error:

rd_er.c:19: error: insn does not satisfy its constraints:
(insn 5 35 34 2 rd_er.c:8 (set (reg:SI 16 r0)
(plus:SI (reg:SI 16 r0)
(reg:SI 2 d2))) 57 {addsi3} (expr_list:REG_EQUAL (plus:SI
(reg/f:SI 49 sp)
(const_int -65544 [0xfffefff8]))
(nil)))


My target has 16 data registers and 16 address registers. All are
32bit registers.
The target also has a dedicated stack pointer.
There is no move operation possible between SP and data regs.
There is no provision for addition between data and address registers.
R7 is used as Frame Pointer.


Pattern for addition
---

(define_insn "add3"
  [(set (match_operand:INT 0 "register_operand"
 "=d, t, k, a, a, t, k, t, d")
(plus:INT(match_operand:INT 1 "register_operand"
   "0, 0, 0, t, k, 0, 0, 0, 0")
 (match_operand:INT 2 "nonmemory_operand"
   "J, J, J, L, L, t, t, k, d")))]

The constraints used are -
;;d  -   Data registers [D0 - D15]
;;a  -   Address registers [R0 - R15]
;;t   -   Address and Index registers
;;k   -  Stack Pointer
;;J   -   Unsigned 5bit immediate
;;L   -   Signed 16bit immediate

Since there is no move operation between SP and data regs i have
specified 12 as the register_move_cost between them. I also return the
reload class as address register class in preferred_reload_class when
the rtx is SP.

b4 ira pass
---

(insn 5 2 12 2 rd_er.c:8 (set (reg/v/f:SI 60 [ bufptr ])
(reg/f:SI 23 r7)) 43 {*movsi_internal} (nil))


Input for reload pass
-

(insn 5 2 12 2 rd_er.c:8 (set (reg/v/f:SI 7 d7 [orig:60 bufptr ] [60])
(plus:SI (reg/f:SI 49 sp)
(const_int -65536 [0x]))) 57 {addsi3}
(expr_list:REG_EQUAL (plus:SI (reg/f:SI 49 sp)
(const_int -65536 [0x]))
(nil)))


After IRA
---

Reloads for insn # 5
Reload 0: reload_in (SI) = (reg/f:SI 49 sp)
reload_out (SI) = (reg/v/f:SI 7 d7 [orig:60 bufptr ] [60])
HIGH_OR_LOW, RELOAD_OTHER (opnum = 0)
reload_in_reg: (reg/f:SI 49 sp)
reload_out_reg: (reg/v/f:SI 7 d7 [orig:60 bufptr ] [60])
reload_reg_rtx: (reg:SI 16 r0)
Reload 1: reload_in (SI) = (const_int -65544 [0xfffefff8])
DALU_REGS, RELOAD_FOR_INPUT (opnum = 2)
reload_in_reg: (const_int -65544 [0xfffefff8])
reload_reg_rtx: (reg:SI 2 d2)

(insn 5 35 34 2 rd_er.c:8 (set (reg:SI 16 r0)
(plus:SI (reg:SI 16 r0)
(reg:SI 2 d2))) 57 {addsi3} (expr_list:REG_EQUAL (plus:SI
(reg/f:SI 49 sp)
(const_int -65544 [0xfffefff8]))
(nil)))

The reload pass chooses the final alternative as the goal for reloading.
Since the input instruction already has data register as the
destination the constraint combination (t, 0, t) looses to (d, 0, d),
since the last combination requires least amount copying for
constraint matching (or so the reload pass believes). There are cases
when reload fixes the add pattern and those are when either the
destination is address register or there is no stack pointer involved.
But otherwise i am getting this ICE. I am not sure how to over come
this,.

Hope someone suggests me a solution.

Regards,
Shafi

P.S Can i have commutative operation for the constraint combination
(t, 0, t) i.e (t, %0, t). If so what will be the output template?

[LTO] Request for testing: Last merge from trunk before final merge

[Diego Novillo]

In preparation for the final merge into mainline.  I need to test
the branch on various platforms.  Richi is currently testing on
i586, ppc, ppc64, ia64, s390, s390x.

If anyone has free cycles I would appreciate results from other
ELF-capable targets.

$ svn co svn://gcc.gnu.org/svn/gcc/branches/lto
$ mkdir bld && cd bld
$ ../lto/configure --enable-lto && make

You will need to have libelf 0.8.12 installed
(http://www.mr511.de/software/libelf-0.8.12.tar.gz)


I have made some cleanups in this merge:

- Spurious changes that were not needed.

- Removed LTO testing from several testsuites to prevent
  excessive build slowdowns.  We essentially only test the lto
  directories, some dg tests, executable tests and not much else.

  In particular, we no longer test libstdc++ with lto enabled (it
  had 4 failures) and fortran (it had 143 failures).  At some
  point, I would like to bring LTO testing back to fortran, but I
  understand that this needs fixes in the FE.

  My plan is to set up a tester that forces LTO builds on every
  testsuite.  I will move unique failures to one of the LTO
  directories and create tracking bugs (help appreciated in doing
  this).

- We no longer do functional testing for LTO to decide whether to
  run LTO tests.  We just test whether LTO has been enabled.
  Before, we would silently refuse to run any LTO testing if the
  little program used to detect LTO was broken.

- Removed two hacks in the C++ mangler.  In free_lang_data, we
  were creating more mangled names than necessary.  As Jason
  pointed out, there is no need to generate mangled names for
  templates.  I added a new langhook that need_assembler_name_p
  calls if set.  The only front end that needs it (so far) is
  C++.

Bootstrapped and tested on x86_64.


Diego.

Re: Succesful 4.4.1 build on win32 MinGW + msys

[Ryan Tralalaian]

Output of src/config.guess:

i686-pc-mingw32

gcc -v ouput:

Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../gcc-4.4.1/configure --prefix=/e/gcc/install
Thread model: win32
gcc version 4.4.1 (GCC)

Setup: msys 1.0.11 with autoconfig and automake and MinGW gcc 4.4.0
compiler, make, and binutils.
Also gmp 4.3.1 and mpfr 2.4.1 source were placed in gcc source tree
under gmp and mpfr directories as per the installation instructions.
The compiler has been checked through the code::Blocks IDE and is functional.

Re: [LTO] Request for testing: Last merge from trunk before final merge

[H.J. Lu]

On Mon, Sep 28, 2009 at 8:58 AM, Diego Novillo  wrote:
> In preparation for the final merge into mainline.  I need to test
> the branch on various platforms.  Richi is currently testing on
> i586, ppc, ppc64, ia64, s390, s390x.
>
> If anyone has free cycles I would appreciate results from other
> ELF-capable targets.
>
> $ svn co svn://gcc.gnu.org/svn/gcc/branches/lto
> $ mkdir bld && cd bld
> $ ../lto/configure --enable-lto && make
>
> You will need to have libelf 0.8.12 installed
> (http://www.mr511.de/software/libelf-0.8.12.tar.gz)
>

I think you should check the required libelf features in configure script:

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

FWTW, libelf in Fedora 11 works fine.


H.J.

Re: [LTO] Request for testing: Last merge from trunk before final merge

[Diego Novillo]

On Mon, Sep 28, 2009 at 12:21, H.J. Lu  wrote:

> I think you should check the required libelf features in configure script:

It's checked.  See configure.ac.


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

Thanks.  I will mark it fixed.

> FWTW, libelf in Fedora 11 works fine.

Yes, that's what prompted the new check and requirement for libelf 0.8.12.


Diego.

Re: Outdated comment in real.c (was: constant folding)

[Kaveh R. GHAZI]

On Fri, 25 Sep 2009, Vincent Lefevre wrote:

> [Cc to the gcc mailing-list]
>
> On 2009-09-25 02:18:55 +0200, Vincent Lefevre wrote:
> > Also, as EXP_BITS is the full (biased) exponent size, it seems that
> > the real.c comment is buggy (27 -> 26).
>
> Looking at the history:
>
> -#define EXP_BITS   (32 - 5)
> +#define EXP_BITS   (32 - 6)

The following change fixes the comment.  Tested with "make" on
x86_64-unknown-linux-gnu.  I'll install this as "obvious" tomorrow if
nobody comments on the patch.

--Kaveh



2009-09-28  Kaveh R. Ghazi  

* real.c: Fix comment to reflect actual exponent size.

diff -rup orig/egcc-SVN20090928/gcc/real.c egcc-SVN20090928/gcc/real.c
--- orig/egcc-SVN20090928/gcc/real.c2009-09-18 02:00:54.0 +0200
+++ egcc-SVN20090928/gcc/real.c 2009-09-28 18:06:06.0 +0200
@@ -57,7 +57,7 @@

Both of these requirements are easily satisfied.  The largest target
significand is 113 bits; we store at least 160.  The smallest
-   denormal number fits in 17 exponent bits; we store 27.
+   denormal number fits in 17 exponent bits; we store 26.

Note that the decimal string conversion routines are sensitive to
rounding errors.  Since the raw arithmetic routines do not themselves

Re: Reload going wrong for addition.

[Richard Henderson]

On 09/28/2009 07:25 AM, Mohamed Shafi wrote:

Hope someone suggests me a solution.


The solution is almost certainly something involving the 
TARGET_SECONDARY_RELOAD hook.  You need to inform reload that it's going 
to need some scratch registers in order to perform the operation.


It's been a long time since I had to fiddle with this sort of thing, so 
I forget all the details involved.  Perhaps someone else has some 
additional advice.



P.S Can i have commutative operation for the constraint combination
(t, 0, t) i.e (t, %0, t). If so what will be the output template?


You can use commutative operations for constraints.  You do not need to 
adjust the output template at all; if reload decides that a swap is 
needed, it will swap the operands in the rtl too.



r~

Re: [LTO] Request for testing: Last merge from trunk before final merge

[Toon Moene]

Diego Novillo wrote:


On Mon, Sep 28, 2009 at 12:21, H.J. Lu  wrote:



FWTW, libelf in Fedora 11 works fine.


Yes, that's what prompted the new check and requirement for libelf 0.8.12.


Unfortunately, libelf in Debian testing as of last Saturday, 19 UTC, is 
libelf 0.8.10 - so no contributions from my side ...


--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html

Solaris GCC maintainer question...

[tscheresky]

I posted the following question about GCC and Solaris locale support to
both gcc-help and libstdc++:

http://gcc.gnu.org/ml/gcc-help/2009-09/msg00212.html

It was recommended I try darwin, or ieee_1003.1-2001 for
--enable-clocale when building GCC.  None of these suggestions worked.
See here for details:

http://gcc.gnu.org/ml/gcc-help/2009-09/msg00238.html

But what I would really like to know, from the Solaris GCC maintainer,
is it a fact that the locale model for libstdc++ is 'generic', for all
versions of GCC from 3.4.x to 4.4.1, on Solaris 8 or newer, and there
will be no support for locales other than C, and POSIX?  If so, what's
the likelihood that this will change in the future?

Thanks... 

Todd

Re: [LTO] Request for testing: Last merge from trunk before final merge

[Jack Howarth]

On Mon, Sep 28, 2009 at 11:58:30AM -0400, Diego Novillo wrote:
> In preparation for the final merge into mainline.  I need to test
> the branch on various platforms.  Richi is currently testing on
> i586, ppc, ppc64, ia64, s390, s390x.
> 
> If anyone has free cycles I would appreciate results from other
> ELF-capable targets.
> 
> $ svn co svn://gcc.gnu.org/svn/gcc/branches/lto
> $ mkdir bld && cd bld
> $ ../lto/configure --enable-lto && make
> 
> You will need to have libelf 0.8.12 installed
> (http://www.mr511.de/software/libelf-0.8.12.tar.gz)
> 
> 
> I have made some cleanups in this merge:
> 
> - Spurious changes that were not needed.
> 
> - Removed LTO testing from several testsuites to prevent
>   excessive build slowdowns.  We essentially only test the lto
>   directories, some dg tests, executable tests and not much else.
> 
>   In particular, we no longer test libstdc++ with lto enabled (it
>   had 4 failures) and fortran (it had 143 failures). @some
>   point, I would like to bring LTO testing back to fortran, but I
>   understand that this needs fixes in the FE.
> 
>   My plan is to set up a tester that forces LTO builds on every
>   testsuite.  I will move unique failures to one of the LTO
>   directories and create tracking bugs (help appreciated in doing
>   this).
> 
> - We no longer do functional testing for LTO to decide whether to
>   run LTO tests.  We just test whether LTO has been enabled.
>   Before, we would silently refuse to run any LTO testing if the
>   little program used to detect LTO was broken.
> 
> - Removed two hacks in the C++ mangler.  In free_lang_data, we
>   were creating more mangled names than necessary.  As Jason
>   pointed out, there is no need to generate mangled names for
>   templates.  I added a new langhook that need_assembler_name_p
>   calls if set.  The only front end that needs it (so far) is
>   C++.
> 
> Bootstrapped and tested on x86_64.
> 
> 
> Diego.
> 

Diego,
Has this patch been tested on non-elf targets like darwin
yet to make sure they still build? If not, is the proposed
merge patch against current gcc trunk available somewhere for
testing on darwin? It would be nice to get ahead of the curve
if this merge is going to break the darwin builds.
Jack

Re: [LTO] Request for testing: Last merge from trunk before final merge

[Diego Novillo]

On Mon, Sep 28, 2009 at 14:30, Jack Howarth  wrote:

>    Has this patch been tested on non-elf targets like darwin
> yet to make sure they still build? If not, is the proposed
> merge patch against current gcc trunk available somewhere for
> testing on darwin? It would be nice to get ahead of the curve
> if this merge is going to break the darwin builds.

It should build on darwin.  configure should not enable lto (giving
you a regular non-lto build) and if you force it with --enable-lto,
configure should give you an error and refuse to proceed.

Would you be able to test this?


Thanks.  Diego.

Re: [LTO] Request for testing: Last merge from trunk before final merge

[Richard Henderson]

On 09/28/2009 11:30 AM, Jack Howarth wrote:

If not, is the proposed
merge patch against current gcc trunk available somewhere for
testing on darwin?


It's the top of the LTO branch.


r~

[LTO merge][0/15] Description of the final 15 patches

[Diego Novillo]

I will be sending the final 15 patches to bring all the
functionality from the LTO branch.  I tried to divide the patches
along maintainer lines, but there are some overlaps

- C FE
Adds processing of -flto and -fwhopr.

- C++ FE
Adds a langhook used by need_assembler_name_p to handle
templates.  This implements Jason's suggestion from
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00534.html

- Fortran FE
Adds processing of -flto and -fwhopr.  Note that the
Fortran testsuite still shows ~140 failures with LTO
enabled.  IIUC, most of these have corresponding bugs
filed and they are not LTO-related (in that LTO exposes
some bugs in the FE).  We should discuss whether we want
to include Fortran support for LTO in 4.5.

- Java FE
There is no LTO support for Java, but since LTO uses
zlib, Java does not need to include it.

- LTO FE
This is the new front end for GIMPLE.

- Configury
Detection of libelf, LTO support, etc.

- Contrib
A minor patch to add lto-plugin to the timestamps.

- Documentation
Documentation for the different LTO options.

- Driver
The somewhat ugly changes to collect2 and the main gcc
driver to support spawning lto1 when we detect a .o file
with LTO sections in it.

- Streamer
The code needed to support the on-disk representation of
GIMPLE, CFG and cgraph.

- Langhooks
New langhooks to support manipulating ELF sections and
the new langhook for asking the FE if a DECL needs to
have an assembler name set.

- libiberty
I need help with this one.  When the linker plugin is
enabled (if GCC is configured to use gold), LTO can
detect LTO objects inside archives via the callbacks it
gets from the linker.  Since the linker plugin is a
shared object, and it uses libiberty functions, it needs
to use a shared libiberty.

Currently, we just force --enable-shared on libiberty,
but I would only want to do that if gold and lto are
enabled.  We detect gold and lto support in the top
configure script, but how do I send that down to
libiberty's configure?

- Linker plugin
This is the set of callbacks that gold uses to talk with
lto1 and resolve symbols out of object files in the link.

- Middle end
All sorts of changes, mostly in the callgraph, IPA and
pass manager.

- Testsuite
New tests for LTO and new dejagnu support for writing LTO
tests.  Most of this has already been reviewed by Janis.


Major outstanding work:

- Support for debugging information.  Currently, -flto -g does
  not work (no debug information is generated).  This is because
  free_lang_data does not preserve enough information for the
  debug hooks to emit it.  I will fix this during stage 3.

- Outstanding bugzilla (http://tinyurl.com/yarz5q9).

- Some 'FIXME lto' markers.  These are cleanup markers, several
  related to WHOPR.  We could probably debate whether to include
  the WHOPR functionality in 4.5.  It certainly is not very
  different from LTO, but it does need some TLC.

Once I get all the approvals I need, I will request trunk to be
frozen for a day or so to give me time to commit the whole thing.
I already have a merged local tree and this exact same code is in
the LTO branch.


Thanks.  Diego.

Re: Lattice Mico32 port

[Richard Henderson]

+(define_predicate "no_pic_small_symbol"
+  (match_code "symbol_ref")
+{
+  return !flag_pic & SYMBOL_REF_SMALL_P (op);
+})


s/&/&&/


Index: gcc/config/lm32/sfp-machine.h
Index: gcc/config/lm32/crti.S
Index: gcc/config/lm32/lib1funcs.S
Index: gcc/config/lm32/crtn.S
Index: gcc/config/lm32/arithmetic.c
Index: gcc/config/lm32/t-fprules-softfp
Index: gcc/config/lm32/t-lm32


Can you move these to libgcc?


+#define CPP_SPEC "\
+%{mmultiply-enabled:-D__multiply_enabled__} \
+%{mdivide-enabled:-D__divide_enabled__} \
+%{mbarrel-shift-enabled:-D__barrel_shift_enabled__} \
+%{msign-extend-enabled:-D__sign_extend_enabled__} \
+%{muser-enabled:-D__user_enabled__} \


It would be nicer to merge this into TARGET_CPU_CPP_BUILTINS.

You forgot to include constraints.md in your patch.


+(define_insn "*movqi_insn"
+  [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,m,r,r")
+(match_operand:QI 1 "general_operand" "m,r,r,K,L"))]
+  ""
+  "@
+   lbu  %0, %1
+   or   %0, %1, r0
+   sb   %0, %1
+   addi %0, r0, %1
+   ori  %0, r0, %1"
+  [(set_attr "type" "load,arith,store,arith,arith")]


You don't need both addi and ori alternatives, since all legal QImode 
constants can be handled by addi.  You can use the 'n' constraint here.



+  if (GET_CODE (operands[1]) == CONST_INT)
+{
+  operands[0] = gen_rtx_SUBREG (SImode, operands[0], 0);
+  emit_insn (gen_movsi (operands[0], operands[1]));
+  DONE;
+}


These bits aren't needed in the QI and HImode expanders.

Generally ports have an extra constraint to prevent MEM-to-MEM moves 
from being generated by combine.  You prevent them from happening in 
initial rtl generation in your expanders, but you should probably have 
something like


bool l32m_move_ok (enum machine_mode mode, rtx operands[2])
{
  if (memory_operand (mode, operands[0]))
return register_or_zero_operand (mode, operands[1]);
  return true;
}

Oh, that reminds me.  I don't see a move alternative that allows R0
as the RHS of a store.


+(define_split
+  [(set (match_operand:SI 0 "register_operand" "")
+(match_operand:SI 1 "reloc_operand" ""))]
+  "!flag_pic"
+  [(set (match_dup 0) (high:SI (match_dup 1)))
+   (set (match_dup 0) (lo_sum:SI (match_dup 0) (match_dup 1)))]
+  ""
+)


Why do you need this?  Are you finding some pass putting these
symbols back together again?  If so, you've missed making these
symbols not be legitimate constants.  Yep:


+#define LEGITIMATE_CONSTANT_P(X) 1


that's exactly your problem.


+(define_insn "*movsi_lo_sum"
+  [(set (match_operand:SI 0 "register_operand" "=r")
+(lo_sum:SI (match_operand:SI 1 "register_operand" "0")
+   (match_operand:SI 2 "reloc_operand" "i")))]
+  "!flag_pic"
+  "ori  %0, %0, lo(%2)"
+  [(set_attr "type" "arith")]


Is this really an unsigned relocation?  I strongly suggest that
you make the hi/lo relocation pair use a signed low-part.  This
allows you to merge the lo_sum into a memory:

// foo++;
orhir1, r0, hi(foo)
ori r1, r1, lo(foo)
lw  r2, (r1+0)
addir2, r2, 1
sw  r2, (r1+0)
=>
orhir1, r0, hi(foo)
lw  r2, (r1+lo(foo))
addir2, r2, 1
sw  r2, (r1+lo(foo))

// x = foo[n]
orhir1, r0, hi(foo)
ori r1, r1, lo(foo)
add r1, r1, r2
lw  r3, (r1+0)
=>
orhir1, r0, hi(foo)
add r1, r1, r2
lw  r3, (r1+lo(foo))

FWIW, powerpc provides both signed and unsigned variants of
its hi relocation; "@ha" is supposed to mean "high for add"
or somesuch.

All that said, fixing this is not a requirement.


+(define_expand "indirect_jump"
+  [(set (pc) (match_operand 0 "register_operand" ""))]
+  ""
+  "
+{
+  emit_jump_insn (gen_indirect_jumpsi (operands[0]));
+  DONE;
+}")
+
+(define_insn "indirect_jumpsi"
+  [(set (pc) (match_operand:SI 0 "register_operand" "r"))]
+  ""
+  "b%0"
+  [(set_attr "type" "uibranch")]
+)


You can eliminate the expander and just use the insn.


+(define_expand "call"
+  [(parallel [(call (match_operand 0 "memory_operand" "m")
+(match_operand 1 "" ""))
+  (clobber (reg:SI RA_REGNUM))
+ ])]
+  ""
+  "
+{
+  rtx addr = XEXP (operands[0], 0);
+  if (!CONSTANT_ADDRESS_P (addr))
+{
+  emit_call_insn (gen_call_via_regsi (addr, operands[1]));
+  DONE;
+}
+}")


(define_expand "call"
  [(parallel [(call (match_operand 0 "" "")
(match_operand 1 "" ""))
  (clobber (reg:SI RA_REGNUM))])]
  ""
{
  rtx addr = XEXP (operands[0], 0);
  if (!CONSTANT_ADDRESS_P (addr))
XEXP (operands[0], 0) = force_reg (Pmode, addr);
})

(define_insn "*call"
  [(call (mem (match_operand:SI 0 "call_operand" "r,s"))
 (match_operand 1 "" ""))
   (clobber (reg:SI RA_REGNUM))]
  ""
  "@
   call %0
   calli %0"
  [(set_attr "type" "call")])

(1) Don't use "memory_operand" for the call.  T

Re: Lattice Mico32 port

[Richard Henderson]

On 09/28/2009 03:51 PM, Jon Beniston wrote:

(define_insn "*ashlsi3_const"
[(set (match_operand:SI 0 "register_operand" "=R1")
  (ashift:SI (match_operand:SI 1 "register_operand" "0")
 (match_operand:SI 2 "const_5bit_operand" "i")))
 (clobber (match_scratch:SI 3 "=RA"))]
"!TARGET_BARREL_SHIFT_ENABLED"
"calli __ashlsi3_%2"
[(set_attr "type" "call")])

As I kept on getting "unable to find a register to spill in class R1" and
wasn't sure how to fix it. As you say, this is something that can be added
later. I've also fixed a few other issues that have cropped up during
testing.


We can have a look at this again once your port is committed.

Worse come to worse, we could add more such functions which operate on 
more registers (perhaps 4?).  E.g.  __ashlsi3_R_N where R is the 
register number to operate on, and N is the number of bits to shift. 
Then you'd need to measure to see what kind of size vs speed impact this 
has for the kind of applications you are targeting.


Oh, we'd probably have to be sure to make all of these functions hidden, 
so that you don't wind up going through the dynamic linker.



r~

Re: [LTO merge][0/15] Description of the final 15 patches

[Joseph S. Myers]

On Mon, 28 Sep 2009, Diego Novillo wrote:

> - libiberty
>   I need help with this one.  When the linker plugin is
>   enabled (if GCC is configured to use gold), LTO can
>   detect LTO objects inside archives via the callbacks it
>   gets from the linker.  Since the linker plugin is a
>   shared object, and it uses libiberty functions, it needs
>   to use a shared libiberty.
> 
>   Currently, we just force --enable-shared on libiberty,
>   but I would only want to do that if gold and lto are
>   enabled.  We detect gold and lto support in the top
>   configure script, but how do I send that down to
>   libiberty's configure?

Shared libiberty seems like a bad idea as you then need to deal with 
soname allocation and changing the soname whenever an ABI-incompatible 
change is made.  What you actually need is a PIC libiberty to link into 
the plugin (and avoiding using any global data in libiberty that needs a 
single copy in any program; hopefully it doesn't have any), not a shared 
one.

(You also need to make sure this doesn't affect what is built for the 
target, only for the host.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: DImode operations

[daniel tian]

Yeah. You are right. I debuged the cc1 file with insight. It caused by
FUNCTION_VALUE macro which means the error happened in function
return. Because my target always return a SImode. I fixed it.

To debug the cc1 is always a good point to hack the bug.

But there are still other error exist. I still need to fix them.

Thanks for all your guys.
Best regards.

 daniel

Re: [LTO merge][0/15] Description of the final 15 patches

[Joseph S. Myers]

On Mon, 28 Sep 2009, Diego Novillo wrote:

> I will be sending the final 15 patches to bring all the
> functionality from the LTO branch.  I tried to divide the patches
> along maintainer lines, but there are some overlaps

I'll go through the individual patches later, but a general comment:

You say "tested on x86_64".  More detail is needed.  Have you tested both 
LTO-enabled and LTO-disabled configurations, making sure there are no 
regressions in each case?  I think such testing of both configurations is 
needed.  In addition, an LTO-enabled cross from a non-ELF host to an ELF 
target should be tested (there are five non-ELF hosts in the secondary 
platforms list for 4.5; any one of them could be used for this, or a 
non-ELF host not on that list; I realise gold's plugin support may not yet 
be portable to such hosts so that part of the patch may not be testable 
for this case).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [LTO merge][0/15] Description of the final 15 patches

[DJ Delorie]

>   gets from the linker.  Since the linker plugin is a shared
>   object, and it uses libiberty functions, it needs to use a
>   shared libiberty.

Why can't they just link a static libiberty?

Problem when computing memory dependencies for scheduling pass1

[Amker.Cheng]

Hi all:
   I have found something strange when scheduling instructions.
considering following piece of code:
-c start
int func(float x)
{
  int r = 0;
  r = (*(unsigned int*)&x) >> 23;
  return r;
}
-c end

the return value is different when compiling with or without optimization.
Have tested on 4.2.4 and 4.3.3 on mips, 4.3.2(ubuntu) on x86 and
results are the same.
Is this a bug, or something wrong with the example code?

following is output for mips target, hope it can help.

commands:
mipsel-elf-gcc -march=mips1 -EL -G0 -mabi=32 -S test/dummy.c -o
test/dummy.S -fdump-rtl-all -fsched-verbose=9 -v -O2


the as output is :
-as start
.section .mdebug.abi32
.previous
.text
.align  2
.globl  func
.entfunc
func:
.frame  $sp,0,$31   # vars= 0, regs= 0/0, args= 0, gp= 0
.mask   0x,0
.fmask  0x,0
.setnoreorder
.setnomacro

lw  $2,0($sp)
sw  $4,0($sp)
j   $31
srl $2,$2,23

.setmacro
.setreorder
.endfunc
.size   func, .-func
.ident  "GCC: (GNU) 4.2.4"
--as end
it seems the load insn is scheduled before store, which resulting in
using of uninitialized data.

following is the dumped rtls before and after sched1:

before sched1:
---

(note 8 2 6 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(insn 6 8 7 2 (set (mem/c/i:SF (reg/f:SI 77 $arg) [3 x+0 S4 A32])
(reg:SF 4 $4 [ x ])) 233 {*movsf_softfloat} (nil)
(expr_list:REG_DEAD (reg:SF 4 $4 [ x ])
(nil)))

(note 7 6 12 2 NOTE_INSN_FUNCTION_BEG)

(insn 12 7 13 2 (set (reg:SI 196)
(mem:SI (reg/f:SI 77 $arg) [4 S4 A32])) 213 {*movsi_internal} (nil)
(nil))
-

after sched1:
---
(insn 12 17 6 2 (set (reg:SI 196)
(mem:SI (reg/f:SI 77 $arg) [4 S4 A32])) 213 {*movsi_internal} (nil)
(nil))

(insn 6 12 20 2 (set (mem/c/i:SF (reg/f:SI 77 $arg) [3 x+0 S4 A32])
(reg:SF 4 $4 [ x ])) 233 {*movsf_softfloat} (nil)
(expr_list:REG_DEAD (reg:SF 4 $4 [ x ])
(nil)))
-

have checked gcc's source, It seems the two mem operands in insn12 and insn6
is computed into two different alias sets, so maybe this problem have
something to do with
the force type cast?

The result is very strange, so please help and any comments will be
highly appreciated.

-- 
Best Regards.

Re: DImode operations

[daniel tian]

Hi Dave:

when I build the libgcc2.c, an unrecognizable RTL exist. Its about subreg.
Here is the info:

../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function '__mulvsi3':
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:169: error: unrecognizable insn:
(insn 24 26 25 3 ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:165
(set (subreg:SI (reg:DI 47) 0)
(ashiftrt:SI (subreg:SI (reg/v:DI 36 [ w ]) 4)
(const_int 0 [0x0]))) -1 (expr_list:REG_NO_CONFLICT
(reg/v:DI 36 [ w ])
(nil)))
../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:169: internal compiler
error: in extract_insn, at recog.c:1990

I could understand why subreg exist, but gcc supposed to deal with it.
I mean to remove the subreg operations.

Did your guys also meet this problem?

Could you give me some advices?
Now I still debug it.

Thanks.

Re: Problem when computing memory dependencies for scheduling pass1

[Amker.Cheng]

Thanks Eric Fisher, got the answer, Please ignore this message.

-- 
Best Regards.