Issue in combine pass.
Hello, I experienced an ICE for no-scevccp-outer-16.c in our port. It seems not in other ports so I couldn't file a bug report. Baiscally, the problem appears after the following transformations in expand_compound_operation (combine.c). Enter expand_compound_operation x: (zero_extend:SI (subreg:HI (plus:V4HI (reg:V4HI 143 [ vect_var_.65 ]) (reg:V4HI 142 [ vect_var_.65 ])) 0)) tem = gen_lowpart (mode, XEXP (x, 0)); tem = (subreg:SI (plus:V4HI (reg:V4HI 143 [ vect_var_.65 ]) (reg:V4HI 142 [ vect_var_.65 ])) 0) tem = simplify_shift_const (NULL_RTX, ASHIFT, mode, tem, modewidth - pos - len); tem = (subreg:SI (ashift:V4HI (plus:V4HI (reg:V4HI 143 [ vect_var_.65 ]) (reg:V4HI 142 [ vect_var_.65 ])) (const_int 16 [0x10])) 0) tem = simplify_shift_const (NULL_RTX, unsignedp ? LSHIFTRT : ASHIFTRT, mode, tem, modewidth - len); /projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-16.c: In function 'main': /projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-16.c:59:1: internal compiler error: in trunc_int_for_mode, at explow.c:56 Please submit a full bug report, #0 internal_error (gmsgid=0xe9aa77 "in %s, at %s:%d") at ../../src/gcc/diagnostic.c:707 #1 0x005acf23 in fancy_abort (file=0xea8453 "../../src/gcc/explow.c", line=56, function=0xea8440 "trunc_int_for_mode") at ../../src/gcc/diagnostic.c:763 #2 0x0060528b in trunc_int_for_mode (c=65535, mode=V4HImode) at ../../src/gcc/explow.c:56 #3 0x005edf24 in gen_int_mode (c=65535, mode=V4HImode) at ../../src/gcc/emit-rtl.c:459 #4 0x00cf22d9 in simplify_and_const_int (x=0x0, mode=V4HImode, varop=0x2a957a8420, constop=65535) at ../../src/gcc/combine.c:9038 #5 0x00cf462f in simplify_shift_const_1 (code=LSHIFTRT, result_mode=SImode, varop=0x2a957a0600, orig_count=16) at ../../src/gcc/combine.c:10073 #6 0x00cf47cf in simplify_shift_const (x=0x0, code=LSHIFTRT, result_mode=SImode, varop=0x2a957a8408, count=16) at ../../src/gcc/combine.c:10122 #7 0x00cebbf9 in expand_compound_operation (x=0x2a95789c20) at ../../src/gcc/combine.c:6517 #8 0x00ce8afe in combine_simplify_rtx (x=0x2a95789c20, op0_mode=HImode, in_dest=0) at ../../src/gcc/combine.c:5535 #9 0x00ce6da5 in subst (x=0x2a95789c20, from=0x2a95781ba0, to=0x2a957a83a8, in_dest=0, unique_copy=0) at ../../src/gcc/combine.c:4884 #10 0x00ce6b53 in subst (x=0x2a957a0660, from=0x2a95781ba0, to=0x2a957a83a8, in_dest=0, unique_copy=0) at ../../src/gcc/combine.c:4812 #11 0x00ce13ed in try_combine (i3=0x2a957a1678, i2=0x2a957a1630, i1=0x0, new_direct_jump_p=0x7fbfffeafc) at ../../src/gcc/combine.c:2963 ... It seems to me that both the gen_lowpart and simplify_shift_const do the wrong things in handling vector type. (zero_extend:SI (subreg:HI (V4HI)) is not equal to (subreg:SI (V4HI)), is it? simplify_shift_const produces (ashift:V4HI (V4HI..) (16), which is not right either. Does shifting of a vector with a const value mean shifting every element of vector or treat the vector as an entity? Internal manual is not very clear about that. Thanks, Bingfeng Mei
mirror proposition
Dear Sir/Madam, We would like to raise an HTTP GCC mirror on our dedicated server in Canada and I would be very grateful if you provided me with instructions. Thank you. Best wishes, James Miller
Re: Issue in combine pass.
> It seems to me that both the gen_lowpart and simplify_shift_const do the > wrong things in handling vector type. (zero_extend:SI (subreg:HI (V4HI)) is > not equal to (subreg:SI (V4HI)), is it? simplify_shift_const produces > (ashift:V4HI (V4HI..) (16), which is not right either. The combine pass had been written at least a decade before vector modes were introduced so it essentially doesn't expect them, i.e. some transformations simply don't make sense for vector modes. You need to analyze the one you're seeing (e.g. where does the subreg come from?) and determine whether it makes sense; it it doesn't, then it should be disabled for vector modes. -- Eric Botcazou
CXXFLAGS_FOR_TARGET and config/mt-gnu
The file config/mt-gnu currently defines CXXFLAGS_FOR_TARGET = $(CXXFLAGS) -D_GNU_SOURCE. To me, it seems that it should be += -D_GNU_SOURCE (like most of the other frags). Otherwise, I cannot override the CXXFLAGS without overriding CXXFLAGS_FOR_TARGET. Or am I missing something?
Re: Issue in combine pass.
On 03/25/2010 12:31 PM, Eric Botcazou wrote: The combine pass had been written at least a decade before vector modes were introduced so it essentially doesn't expect them, i.e. some transformations simply don't make sense for vector modes. You need to analyze the one you're seeing (e.g. where does the subreg come from?) and determine whether it makes sense; it it doesn't, then it should be disabled for vector modes. The whole of simplify_shift_const probably doesn't make sense. Other likely candidates are simplify_and_const_int and force_to_mode, though there may be something to salvage there. Paolo
Re: About behavior of -save-temps=obj option on GCC 4.5
Hi Richard
(* I am weak in English, so pleas forgive my English mistake.)
Thank you for your reply, and I'm sorry to be late a reply.
> On Sat, Mar 20, 2010 at 5:40 PM, Tadashi Koike wrote:
>> [ summary ]
>> compiling is failed when more than two source file are
>>specified with both -save-temps=obj and -o options.
:
>> [[ operations being error ]]
>> % gcc -save-temps=obj -o hellow main.c func.c
>> % gcc -save-temps=obj -o obj_dir/hellow main.c func.c
2010/3/21 Richard Guenther :
>
> It should be an error to use -save-temps=obj with multiple
> input files. Mike, can you look at this?
>
> Thanks,
> Richard.
>
After I received your reply, I confirm an information about "-save-temps=obj".
In this URL(http://gcc.gnu.org/gcc-4.5/changes.html), "-save-temps=obj"
option are introduced as follow:
| The -save-temps=obj switch will write files into the directory specified
| with the -o option, and the intermediate filenames are based on the
| output file.
If above is a specification of "-save-temps=obj" option, found behaviors
in my report about "-save-temps=obj" are true behaviors (but cannot
deal in case of multiple input files).
I considered. And I read a purpose of this option in above URL :
| This will allow the user to get the compiler intermediate files when
| doing parallel builds without two builds of the same filename located in
| different directories from interfering with each other.
My recognition is below:
- True purpose is a failure of compiling under parallel builds. In detail,
problem is a compiling failure under parallel builds caused by interfering
intermediate file each other. To solve this problem, developer thought
that the intermediate files have to be created in different directory.
So a directory specified with the -o option are choose as these purpose.
(I named this problem as "Compiling failure by interfering" for following
discussion.)
- If two builds of the same file name located in different directories are
done as serial, each build is successful fine, but intermediate file is
overwritten by a latest compiling.
(I named this problem as "Overwritten by interfering" for following
discussion.)
- A purpose of "-save-temps=obj" option is to solve the "Compiling
failure by interfering", not to solve the "Overwritten by interfering".
>From my consideration, I reached some understanding as follow:
- True solution for "Compiling failure by interferng" is using a
true independent file name which is assured by System (such as
filename returned by tmpnam() function in stdio.h) for each
intermediate file. After compiling are successful, filename of
intermediate files need to change as true filenames based on
source/object files.
- "-save-temps=obj" option is useful to solve some "Overwritten
by interfering" problems. Trouble will decrease caused this
problem. (so I hope/want this option very much)
- I hope that the filename of intermediate file by "-save-temps=obj"
is also based on source files.
I hope to hear someone's opinion else.
Best regards,
Tadashi Koike
2010/3/21 Richard Guenther :
> On Sat, Mar 20, 2010 at 5:40 PM, Tadashi Koike wrote:
>> Hi all,
>> (* I am weak in English, so pleas forgive my English mistake.)
>>
>>Please teach me about a behavior of -save-temps=obj option
>> on gcc 4.5. A behavior I found is whether bug or specification ?
>>
>> [ summary ]
>> compiling is failed when more than two source file are
>> specified with both -save-temps=obj and -o options.
>>
>> 1) Environment
>>---
>>[System]: Fedora release 12 (Constantine)
>>[gcc version]:
>> % /usr/local/bin/gcc -v
>> Using built-in specs.
>> COLLECT_GCC=/usr/local/bin/gcc
>>
>> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
>> Target: x86_64-unknown-linux-gnu
>> Configured with: ../gcc-4.5-20100304-src/configure
>> --prefix=/usr/local --mandir=/usr/local/share/man
>> --infodir=/usr/local/share/info --enable-languages=c,c++ --disable-nls
>> Thread model: posix
>> gcc version 4.5.0 20100304 (experimental) (GCC)
>>---
>>
>> 2) Source files I used are bellow:
>>[main.c]
>>+--
>>|extern int func(const char *);
>>|int main () {
>>| func("hello world!\n");
>>|}
>>+--
>>[func.c]
>>+--
>>|#include
>>|int func (const char *str) {
>>| return(fprintf(stdout, str));
>>|}
>>+--
>>
>> 3) Files/Directory structure is bellow:
>> /tmp/test/hellow.c
>> /func.c
>> /obj_dir/
>>
>> 4) Test
Question about RTL code hoisting
I just found that the current RTL code hoisting cannot optimize
REG = ...
if (cond)
{
r0 = REG;
}
else
{
r0 = REG;
...
}
to
REG = ...
r0 = REG;
if (cond)
{
}
else
{
...
}
where REG is a pseudo register and r0 is a physical register. I have
looked at the code of RTL hoisting pass. But I cannot find a simple way
to extend it to deal with this case. And the hoisting pass is only
enabled when -Os. So I'm going to implement another hoisting pass to do
this optimization. Is it a good idea? Does anyone know if there is an
existing pass which should have handled or be able to be easily adapted
to handle this case? Thanks!
--
Jie Zhang
CodeSourcery
(650) 331-3385 x735
Re: Question about RTL code hoisting
On 03/25/2010 04:03 PM, Jie Zhang wrote:
> I just found that the current RTL code hoisting cannot optimize
>
> REG = ...
> if (cond)
> {
> r0 = REG;
>
> }
> else
> {
> r0 = REG;
> ...
> }
>
> to
>
>
> REG = ...
> r0 = REG;
> if (cond)
> {
>
> }
> else
> {
> ...
> }
>
> where REG is a pseudo register and r0 is a physical register. I have
> looked at the code of RTL hoisting pass. But I cannot find a simple way
> to extend it to deal with this case. And the hoisting pass is only
> enabled when -Os. So I'm going to implement another hoisting pass to do
> this optimization. Is it a good idea? Does anyone know if there is an
> existing pass which should have handled or be able to be easily adapted
> to handle this case? Thanks!
Isn't this similar to crossjumping, except done in the other direction?
Bernd
Re: Question about RTL code hoisting
On Thu, Mar 25, 2010 at 4:14 PM, Bernd Schmidt wrote:
> On 03/25/2010 04:03 PM, Jie Zhang wrote:
>> I just found that the current RTL code hoisting cannot optimize
>>
>> REG = ...
>> if (cond)
>> {
>> r0 = REG;
>>
>> }
>> else
>> {
>> r0 = REG;
>> ...
>> }
>>
>> to
>>
>>
>> REG = ...
>> r0 = REG;
>> if (cond)
>> {
>>
>> }
>> else
>> {
>> ...
>> }
>>
>> where REG is a pseudo register and r0 is a physical register. I have
>> looked at the code of RTL hoisting pass. But I cannot find a simple way
>> to extend it to deal with this case. And the hoisting pass is only
>> enabled when -Os. So I'm going to implement another hoisting pass to do
>> this optimization. Is it a good idea? Does anyone know if there is an
>> existing pass which should have handled or be able to be easily adapted
>> to handle this case? Thanks!
>
> Isn't this similar to crossjumping, except done in the other direction?
Yes. "head merging" if you will. I have a patch for this, and intend
to submit it for GCC 4.6.
Ciao!
Steven
Re: Question about RTL code hoisting
On 03/25/10 09:14, Bernd Schmidt wrote:
On 03/25/2010 04:03 PM, Jie Zhang wrote:
I just found that the current RTL code hoisting cannot optimize
REG = ...
if (cond)
{
r0 = REG;
}
else
{
r0 = REG;
...
}
to
REG = ...
r0 = REG;
if (cond)
{
}
else
{
...
}
where REG is a pseudo register and r0 is a physical register. I have
looked at the code of RTL hoisting pass. But I cannot find a simple way
to extend it to deal with this case. And the hoisting pass is only
enabled when -Os. So I'm going to implement another hoisting pass to do
this optimization. Is it a good idea? Does anyone know if there is an
existing pass which should have handled or be able to be easily adapted
to handle this case? Thanks!
Isn't this similar to crossjumping, except done in the other direction?
Yes, though the implementation is completely different. Hoisting
computes which blocks compute specific expressions, then determines if
all paths from a point compute the same expression and if so, moves the
multiple computations to a single location.
cross jumping works by matching RTL bits at the end of blocks.
I never bothered to implement hoisting which touched hard regs -- I
never thought the cost/benefit analysis made much sense. It's quite a
bit more work to implement and code motion of hard regs is much more
restricted than code motion involving just pseudos.
jeff
Bernd
Re: Question about RTL code hoisting
On Thu, Mar 25, 2010 at 4:03 PM, Jie Zhang wrote:
> I just found that the current RTL code hoisting cannot optimize
>
> REG = ...
> if (cond)
> {
> r0 = REG;
>
> }
> else
> {
> r0 = REG;
> ...
> }
>
> to
>
>
> REG = ...
> r0 = REG;
> if (cond)
> {
>
> }
> else
> {
> ...
> }
>
> where REG is a pseudo register and r0 is a physical register. I have looked
> at the code of RTL hoisting pass. But I cannot find a simple way to extend
> it to deal with this case.
Right, there are two issues:
* HOIST doesn't handle hard registers
* HOIST doesn't hoist reg-reg moves
There is no easy way to add cost metrics to hoist reg-reg moves, and
handling hard regs is an even bigger problem.
What is the original code? I (well, by now: we) have patches in the
works for GCC 4.6 that add code hoisting to GIMPLE (see PR23286),
perhaps that solves this case for you.
> And the hoisting pass is only enabled when -Os.
> So I'm going to implement another hoisting pass to do this optimization. Is
> it a good idea?
To add duplicate functionality? No.
> Does anyone know if there is an existing pass which should
> have handled or be able to be easily adapted to handle this case?
Hoisting should handle it, bui
Can you open a new PR and make it block PR33828, please?
Ciao!
Steven
Re: About behavior of -save-temps=obj option on GCC 4.5
On Thu, Mar 25, 2010 at 11:33:17PM +0900, Tadashi Koike wrote:
> Hi Richard
> (* I am weak in English, so pleas forgive my English mistake.)
>
> Thank you for your reply, and I'm sorry to be late a reply.
>
> > On Sat, Mar 20, 2010 at 5:40 PM, Tadashi Koike wrote:
> >> [ summary ]
> >> compiling is failed when more than two source file are
> >>specified with both -save-temps=obj and -o options.
> :
> >> [[ operations being error ]]
> >> % gcc -save-temps=obj -o hellow main.c func.c
> >> % gcc -save-temps=obj -o obj_dir/hellow main.c func.c
>
> 2010/3/21 Richard Guenther :
> >
> > It should be an error to use -save-temps=obj with multiple
> > input files. Mike, can you look at this?
> >
> > Thanks,
> > Richard.
> >
>
> After I received your reply, I confirm an information about "-save-temps=obj".
I tend to agree with Richard, that if there are multiple source inputs, it
should be an error to use -save-temps=obj without the -c/-S option.
Though it might be friendlier to allow:
gcc -o dir/exe a.c b.c c.c
and put the temp files in:
dir/a.{s,i}
dir/b.{s,i}
dir/c.{s,i}
But it would fail for doing:
gcc -o exe dir1/a.c dir2/a.c
where the names overlap. Let me look at it.
> In this URL(http://gcc.gnu.org/gcc-4.5/changes.html), "-save-temps=obj"
> option are introduced as follow:
>
> | The -save-temps=obj switch will write files into the directory specified
> | with the -o option, and the intermediate filenames are based on the
> | output file.
>
> If above is a specification of "-save-temps=obj" option, found behaviors
> in my report about "-save-temps=obj" are true behaviors (but cannot
> deal in case of multiple input files).
>
> I considered. And I read a purpose of this option in above URL :
>
> | This will allow the user to get the compiler intermediate files when
> | doing parallel builds without two builds of the same filename located in
> | different directories from interfering with each other.
>
> My recognition is below:
> - True purpose is a failure of compiling under parallel builds. In detail,
> problem is a compiling failure under parallel builds caused by
> interfering
> intermediate file each other. To solve this problem, developer thought
> that the intermediate files have to be created in different directory.
> So a directory specified with the -o option are choose as these purpose.
>
> (I named this problem as "Compiling failure by interfering" for following
> discussion.)
Yes, the motivation was for doing large builds (notably spec 2006) where
several of the files have the same base name but are in different
subdirectories. In particular, I could not build 436.cactusADM with -j8
without getting conflicts (bugzilla 39293). Even if I built it with -j1 so
they wouldn't interfere, I would lose the asm files for some of the builds,
which would mean my static analysis programs would miss some objects.
I have also seen conflicts with -save-temps if you use have -j numbers when
doing a compiler bootstrap.
> - If two builds of the same file name located in different directories are
> done as serial, each build is successful fine, but intermediate file is
> overwritten by a latest compiling.
> (I named this problem as "Overwritten by interfering" for following
> discussion.)
Yes.
> - A purpose of "-save-temps=obj" option is to solve the "Compiling
> failure by interfering", not to solve the "Overwritten by interfering".
Well the real purpose is to allow me to better debug stuff when doing large
builds, so that I can go back without having to do the build by hand. Just
like when I added the original -save-temps option around 1988 or so.
> From my consideration, I reached some understanding as follow:
> - True solution for "Compiling failure by interferng" is using a
> true independent file name which is assured by System (such as
> filename returned by tmpnam() function in stdio.h) for each
> intermediate file. After compiling are successful, filename of
> intermediate files need to change as true filenames based on
> source/object files.
Well if this is a big problem for you, when 4.6 opens up, feel free to add a
new varient of -save-temps=. The current implementation of
-save-temps=obj meets the needs that I had in doing large builds.
> - "-save-temps=obj" option is useful to solve some "Overwritten
> by interfering" problems. Trouble will decrease caused this
> problem. (so I hope/want this option very much)
>
> - I hope that the filename of intermediate file by "-save-temps=obj"
> is also based on source files.
>
> I hope to hear someone's opinion else.
--
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meiss...@linux.vnet.ibm.com
Re: Question about RTL code hoisting
On 03/25/2010 11:22 PM, Jeff Law wrote:
On 03/25/10 09:14, Bernd Schmidt wrote:
On 03/25/2010 04:03 PM, Jie Zhang wrote:
I just found that the current RTL code hoisting cannot optimize
REG = ...
if (cond)
{
r0 = REG;
}
else
{
r0 = REG;
...
}
to
REG = ...
r0 = REG;
if (cond)
{
}
else
{
...
}
where REG is a pseudo register and r0 is a physical register. I have
looked at the code of RTL hoisting pass. But I cannot find a simple way
to extend it to deal with this case. And the hoisting pass is only
enabled when -Os. So I'm going to implement another hoisting pass to do
this optimization. Is it a good idea? Does anyone know if there is an
existing pass which should have handled or be able to be easily adapted
to handle this case? Thanks!
Isn't this similar to crossjumping, except done in the other direction?
Yes, though the implementation is completely different. Hoisting
computes which blocks compute specific expressions, then determines if
all paths from a point compute the same expression and if so, moves the
multiple computations to a single location.
cross jumping works by matching RTL bits at the end of blocks.
I never bothered to implement hoisting which touched hard regs -- I
never thought the cost/benefit analysis made much sense. It's quite a
bit more work to implement and code motion of hard regs is much more
restricted than code motion involving just pseudos.
Thanks Bernd and Jeff.
This case is not common. I'm wondering how likely this kind of
optimization pass will be accepted into GCC.
Another way to fix it is teaching register allocator to allocate r0 to
REG. But I guess it's more difficult.
Jie
Re: Question about RTL code hoisting
On 03/25/2010 11:24 PM, Steven Bosscher wrote:
On Thu, Mar 25, 2010 at 4:03 PM, Jie Zhang wrote:
I just found that the current RTL code hoisting cannot optimize
REG = ...
if (cond)
{
r0 = REG;
}
else
{
r0 = REG;
...
}
to
REG = ...
r0 = REG;
if (cond)
{
}
else
{
...
}
where REG is a pseudo register and r0 is a physical register. I have looked
at the code of RTL hoisting pass. But I cannot find a simple way to extend
it to deal with this case.
Right, there are two issues:
* HOIST doesn't handle hard registers
* HOIST doesn't hoist reg-reg moves
There is no easy way to add cost metrics to hoist reg-reg moves, and
handling hard regs is an even bigger problem.
What is the original code? I (well, by now: we) have patches in the
works for GCC 4.6 that add code hoisting to GIMPLE (see PR23286),
perhaps that solves this case for you.
I'm not sure if I can make the test case public. I need to ask. I'm
afraid gimple cannot help this. r0 is here because it's used for passing
argument to callees. This issue is only exposed when expanded to RTL.
And the hoisting pass is only enabled when -Os.
So I'm going to implement another hoisting pass to do this optimization. Is
it a good idea?
To add duplicate functionality? No.
I'm not going to add duplicate functionality. What I'm going to do is
only handle "hard-reg = pseudo-reg" case.
Does anyone know if there is an existing pass which should
have handled or be able to be easily adapted to handle this case?
Hoisting should handle it, bui
Can you open a new PR and make it block PR33828, please?
If I can publish the test case, yes. Or I have to rewrite a test case.
--
Jie Zhang
CodeSourcery
(650) 331-3385 x735
Re: Question about RTL code hoisting
On 03/25/10 10:19, Jie Zhang wrote: On 03/25/2010 11:22 PM, Jeff Law wrote: I never bothered to implement hoisting which touched hard regs -- I never thought the cost/benefit analysis made much sense. It's quite a bit more work to implement and code motion of hard regs is much more restricted than code motion involving just pseudos. Thanks Bernd and Jeff. This case is not common. I'm wondering how likely this kind of optimization pass will be accepted into GCC. If the code is clean and doesn't add significant compile-time overhead, it'd probably be accepted. Another way to fix it is teaching register allocator to allocate r0 to REG. But I guess it's more difficult. Well, the register allocator will already attempt to allocate REG to r0 -- when it sees a copy between a pseudo and a hard reg it will adjust its cost model appropriately to encourage the pseudo to be allocated to the hard reg (thus eliminating the copy). It's probably at least worth looking into why the pseudos in question aren't being assigned to the appropriate hard register to eliminate the copy. Another alternative would be to look at something like copy motion (see Morgan's text). I've always wondered if it was generally useful and what it's compile-time impact might be. Jeff
Re: CXXFLAGS_FOR_TARGET and config/mt-gnu
Doug Semler writes: > The file config/mt-gnu currently defines CXXFLAGS_FOR_TARGET = > $(CXXFLAGS) -D_GNU_SOURCE. To me, it seems that it should be += > -D_GNU_SOURCE (like most of the other frags). Otherwise, I cannot > override the CXXFLAGS without overriding CXXFLAGS_FOR_TARGET. Or am I > missing something? I think you are right. Ian
Re: Test Failures on sparc-rtems not repeatable by hand
Hi, I wanted to let you know that I found the issue. The arguments to the script that drove the simulator had changed. Once I saw the command line that invoked the simulator, it was trivial to fix. Thanks for the pointer. Easy problem that was hard to find. --joel On 03/23/2010 04:10 PM, Janis Johnson wrote: On Tue, Mar 23, 2010 at 1:20 PM, Joel Sherrill wrote: On 03/23/2010 03:01 PM, Janis Johnson wrote: On Tue, Mar 23, 2010 at 10:56 AM, Joel Sherrill wrote: Hi, There are a number of failures in my latest run of sparc-rtems4.10 but the ones I have gone back and run the executable by hand actually pass. I have no idea why this is happening and wondered if someone had some insight as to what I should look at next. From gcc.log Executing on host: /users/joel/test-gcc/b-gcc1-sparc/gcc/xgcc -B/users/joel/test-gcc/b-gcc1-sparc/gcc/ /users/joel/test-gcc/gcc-svn/gcc/testsuite/gcc.c-torture/execute/builtins/snprintf-chk.c /users/joel/test-gcc/gcc-svn/gcc/testsuite/gcc.c-torture/execute/builtins/snprintf-chk-lib.c /users/joel/test-gcc/gcc-svn/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c gcc_tg.o -w -O0 -DSTACK_SIZE=2048 -isystem /users/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/./newlib/targ-include -isystem /users/joel/test-gcc/gcc-svn/newlib/libc/include -B/users/joel/test-gcc/install-svn/sparc-rtems4.10/sis/lib/ -specs bsp_specs -qrtems -mcpu=cypress -B/users/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/./newlib/ -L/users/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/./newlib /users/joel/test-gcc/b-gcc1-sparc/rtems_gcc_main.o -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o /users/joel/test-gcc/b-gcc1-sparc/gcc/testsuite/gcc/snprintf-chk.x0 (timeout = 300) PASS: gcc.c-torture/execute/builtins/snprintf-chk.c compilation, -O0 sparc-rtems4.10-run is /users/joel/test-gcc/install-svn/bin/sparc-rtems4.10-run Running /users/joel/test-gcc/b-gcc1-sparc/gcc/testsuite/gcc/snprintf-chk.x0 for maximum 60 seconds FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution, -O0 So it compiles but apparently fails to run. OK so I run it by hand: $ /users/joel/test-gcc/install-svn/bin/sparc-rtems4.10-run snprintf-chk.x0 *** EXIT code 0 [j...@rtbf64b gcc]$ echo $? 0 Any suggestions on how to track down what is going wrong? What are /users/joel/test-gcc/b-gcc1-sparc/rtems_gcc_main.o and -Wl,-wrap,main? Is main being replaced by something that doesn't return 0? rtems_gcc_main.c is a file with the RTEMS OS configuration in it. It specifies to start running the user program at main, the stack size, etc. It does not contain main() -- just a pointer to main(). We don't return a value. We set this for the simulator. set_board_info needs_status_wrapper 1 Which turns on the linker option to wrap main() and enables some standard support code to for the main wrapper to take the exit code and print it stdout. Or at least that's what it used to do. Is there anyway to get some visibility as to why the scripting thinks it is failing? You'll need to add some messages to DejaGnu's procedures in the .exp files in share/dejagnu, under where DejaGnu is installed on your system. I don't know much about the ones used for running on simulators or remote systems, it's all pretty awful. Janis -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Problem with ADDR_EXPR array offset
Thank you very much!!! :D
--- Mer 24/3/10, Ian Lance Taylor ha scritto:
> Da: Ian Lance Taylor
> Oggetto: Re: Problem with ADDR_EXPR array offset
> A: "Massimo Nazaria"
> Cc: gcc@gcc.gnu.org
> Data: Mercoledì 24 marzo 2010, 23:59
> Massimo Nazaria
> writes:
>
> > I'm working on a pass and I need to handle some
> pointer expressions.
> > For example, I have this C-code:
> > int v[1000];
> > int *p;
> > p = &v[10];
> >
> > The problem is that, when I'm trying to parse "p =
> &v[10];", I'm not able to get the array offset (10 in
> this case).
> >
> > Namely, for a given statement like "p = &v[10]", I
> need to get:
> > array: v (I can do that)
> > offset: 10
> >
> > Here is the code I am working on:
> > op0 = gimple_op (stmt, 0);
> > op1 = gimple_op (stmt, 1);
> >
> > if (gimple_assign_rhs_code (stmt) ==
> ADDR_EXPR)
> > {
> > base = get_base_address
> (TREE_OPERAND (op1, 0)); // the array v, OK
> > offset = // ???
> >
> > How can I do?
>
> There is nothing wrong with calling get_base_address, but
> by doing
> that you have thrown away the offset information. I
> would expected
> TREE_OPERAND (op1, 0) to be an ARRAY_REF. Operand 0
> of that will be
> an array, operand 1 will be an index.
>
> I would recommend taking a look at get_inner_reference
> rather than
> get_base_address.
>
> Ian
>
gcc-4.5-20100325 is now available
Snapshot gcc-4.5-20100325 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100325/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 157731 You'll find: gcc-4.5-20100325.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20100325.tar.bz2 C front end and core compiler gcc-ada-4.5-20100325.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20100325.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20100325.tar.bz2 C++ front end and runtime gcc-java-4.5-20100325.tar.bz2 Java front end and runtime gcc-objc-4.5-20100325.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20100325.tar.bz2The GCC testsuite Diffs from 4.5-20100318 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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.
expected behavior for --with-cloog?
While testing a patch to update the minimum version
of cloog-ppl in gcc trunk...
Index: configure.ac
===
--- configure.ac(revision 157732)
+++ configure.ac(working copy)
@@ -1612,9 +1612,9 @@
if test "x$with_cloog" != "xno" -a "${ENABLE_CLOOG_CHECK}" = "yes"; then
saved_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS $clooginc $gmpinc $pplinc"
- AC_MSG_CHECKING([for version 0.15.5 (or later revision) of CLooG])
+ AC_MSG_CHECKING([for version 0.15.9 (or later revision) of CLooG])
AC_TRY_COMPILE([#include "cloog/cloog.h"],[
- #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 ||
CLOOG_VERSION_REVISION < 5
+ #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 ||
CLOOG_VERSION_REVISION < 9
choke me
#endif
], [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([no]); clooglibs= ; clooginc= ])
I noticed that this test only returns...
checking for version 0.15.9 (or later revision) of CLooG... no
for...
../gcc-4.5-20100325/configure --prefix=/sw --prefix=/sw/lib/gcc4.5
--mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,obj-c++,java \
--with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw
--with-mpc=/sw --with-system-zlib \
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--disable-libjava-multilib --enable-checking=release
...when a cloog-ppl earlier than 0.15.9 is installed. Shouldn't configure fail
outright in this case since the user obviously intended cloog to be used?
Currently
configure proceeds to set up a build without graphite support.
Jack
[G++ 4.4.2] ABI changing?
Howdy, I find a problem when upgraded g++ from 4.4.1 to 4.4.2. Original g++ generates code with "System V ABI", but new g++ generates code with "Linux ABI". I don't know what difference between them, but the output .so file from g++ 4.4.2 cannot be used in g++ 4.4.1. To describe my problem clear, I have two x86-64 PCs with RedHat Linux. g++ 4.4.1 is installed in PC1, while 4.4.2 is installed in PC2. If I copy the executable file compiled by PC1 to PC2, and run "ldd a.out", it prints the related modules. But if I copy the executable file compiled by PC2 to PC1, and run "ldd a.out", it prints error message for "not a dynamic executable". Therefore, it seem the gcc tool-chain have backward compatibility for "System V" and "Linux" ABI. Could you tell me why g++ changes ABI? and why cannot I find any thing about it from the changelog of gcc 4.4.2? Is there a way to specify ABI in gcc command line on x86/64 platform? Thank you in advance. -- ShenLei
Re: [G++ 4.4.2] ABI changing?
甜瓜 writes: > I find a problem when upgraded g++ from 4.4.1 to 4.4.2. Original g++ > generates code with "System V ABI", but new g++ generates code with > "Linux ABI". I don't know what difference between them, but the output > .so file from g++ 4.4.2 cannot be used in g++ 4.4.1. > > To describe my problem clear, I have two x86-64 PCs with RedHat Linux. > g++ 4.4.1 is installed in PC1, while 4.4.2 is installed in PC2. > If I copy the executable file compiled by PC1 to PC2, and run "ldd > a.out", it prints the related modules. > But if I copy the executable file compiled by PC2 to PC1, and run "ldd > a.out", it prints error message for "not a dynamic executable". > Therefore, it seem the gcc tool-chain have backward compatibility for > "System V" and "Linux" ABI. > > Could you tell me why g++ changes ABI? and why cannot I find any thing > about it from the changelog of gcc 4.4.2? > Is there a way to specify ABI in gcc command line on x86/64 platform? This question is not appropriate for the mailing list g...@gcc.gnu.org. It would be appropriate for the mailing list gcc-h...@gcc.gnu.org. Please take any followups to gcc-help or to some non-gcc mailing list. Thanks. This is actually being caused by the linker, which is not a part of gcc. The linker marks the ABI in an executable or shared library by setting the EI_OSABI field in the ELF header, which you can display using readelf -h. The default value, 0, is known as the "System V ABI." The GNU linker will set the EI_OSABI field to ELFOSABI_LINUX if there are any STT_GNU_IFUNC symbols, which are a new feature of glibc. There is no way to change the linker's behaviour from the gcc command line. Ian
