Re: Question about dead_or_predicable

[Steven Bosscher]

On Wed, Jun 24, 2009 at 5:35 PM, Richard Henderson wrote:

> Have a quick look at the implementation of invert_jump, and both
> questions are quickly answered.

Heh, well, all those functions in jump.c also really confuse me --
probably because I've never really understood how all the functions to
change RTL work.  But OK, I understand what is going on now, thanks.


> All that said, I think your plan to rearrange things to allow both
> CE and NCE paths to be followed is fine.  You'll just need to dup
> that jump change into both paths so that the CE path change group
> gets its own shot at rejecting the jump change.

Right.  I think I'll do it with a verify_changes() check at the end of
the CE path, that should result in a smaller patch.

Thanks for your help,

Ciao!
Steven

Re: (known?) Issue with bitmap iterators

[Daniel Berlin]

On Mon, Jun 22, 2009 at 3:19 PM, Dave
Korn wrote:
> Joe Buck wrote:
>
>> As a general rule there is a performance cost for making iterators
>> on a data structure safe with respect to modifications of that data
>> structure.  I'm not in a position to say what the right solution is
>> in this case, but passes that iterate over bitmaps without modifying
>> those bitmaps shouldn't be penalized.  One solution sometimes used is
>> two sets of iterators, with a slower version that's safe under
>> modification.
>
>  But then we'll run into the same bug again when someone uses the wrong kind,
> or changes the usage of a bitmap without changing which type it is.

We have this situation with, for example, the immediate use iterators,
and at least as far as anyone knows, it hasn't been broken yet ;)
So i don't think we should be too worried about it happening if we
were to create two types of iterators.

Re: Should -Wjump-misses-init be in -Wall?

[Manuel López-Ibáñez]

2009/6/23 Ian Lance Taylor :
> Paolo Bonzini  writes:
>
>> I don't think this warning can report anything that -Wuninitialized
>> cannot report, so it should go in -Wc++-compat only.
>
> For the record, it can, as in when compiling this case without
> optimization.  This is not a strong example by any means.

This is a part of SSA that I don't understand completely. We create a
var_decl for i in the following assignment:

D.1606_1 = i;

because i is loaded from memory. But then, because there is no alias
info, there are no vuse/vdef operators for this statement. So we
actually do not know if this vuse is the default definition of i. Is
there no way to know this without alias info? In the dump, it looks
like this could be known:

f1 ()
{
  intD.0 iD.1605;
  intD.0 D.1606;

  # BLOCK 2
  # PRED: ENTRY (fallthru)
  # SUCC: 3 (fallthru)

  # BLOCK 3, starting at line 10
  # PRED: 2 (fallthru)
lab1L.0:
  [test.c : 10:4] D.1606_1 = iD.1605;
  return D.1606_1;
  # SUCC: EXIT

}

BTW, why the dump and the output of debug_gimple_stmt are so different?

Cheers,

Manuel.

Re: Any ideas how to get the IRA to choose one subclass of registers over another in the same cover class?

[Jeff Law]

Dave Hudson wrote:



I would have hoped that having done the analysis early on that the 
register allocator would try to allocate from the preferred register 
class rather than the cover class but it seems that doesn't happen?
So you're saying that the register preferences look reasonable, but in 
low pressure situations the allocator appears to largely ignore the 
preferred register class?


It might help if you could provide some debugging dumps.  The .ira dump 
in particular contains a wealth of information about the decisions the 
allocator is making.




Anyone have any ideas other than writing a pass that runs before 
reload and tries to fix this up?
The first thing is to understand why IRA is doing what it's doing.  
We're generally better off generating a good allocation rather than 
trying to clean it up post-allocation.


jeff

Re: (known?) Issue with bitmap iterators

[Jeff Law]

Joe Buck wrote:

As a general rule there is a performance cost for making iterators
on a data structure safe with respect to modifications of that data
structure.  
Absolutely true. 


I'm not in a position to say what the right solution is
in this case, but passes that iterate over bitmaps without modifying
those bitmaps shouldn't be penalized.  One solution sometimes used is
two sets of iterators, with a slower version that's safe under
modification.
  
I wasn't suggesting we make them "safe" in the sense that one could 
modify the bitmap and everything would just work.  Instead I was 
suggesting we make the bitmap readonly for the duration of the iterator 
and catch attempts to modify the bitmap -- under the control of 
ENABLE_CHECKING of course.  If that turns out to still be too expensive, 
it could be conditional on ENABLE_BITMAP_ITERATOR_CHECKING or whatever, 
which would normally be off.


My biggest concern would be catching all the exit paths from the 
gazillion iterators we use and making sure they all reset the readonly 
flag.  Ick...



jeff

Re: How to deal with unrecognizable RTL code

[Jeff Law]

田晓南 wrote:
> Hello, guys:
>   The porting is really a difficult and huge job. So many things I
> don't know or miss result in countless bugs. 
>   
Definitely true. Though it gets easier the 2nd, 3rd, 4th, time around :-)

>   
>  Here I encounter some unrecognizable RTL (R0 to R15 are registers. I
> hate the unrecognizable RTL insns always coming about, and I wanna end it.):
> (insn 264 191 193 15 (set (reg:HI 5 R5)
> (subreg:HI (mem:SI (plus:SI (reg/f:SI 14 R14)
> (const_int 12 [0xc])) [0 crc+0 S4 A32]) 0)) -1 (nil)
> (nil))
>
> (insn 261 197 200 14 (set (reg:HI 5 R5)
> (subreg:HI (mem:SI (reg/f:SI 14 R14) [7 crc.16+0 S4 A32]) 0)) -1
> (nil)
> (nil))
>   
OK. Subregs of MEMs are a little special. In general, you don't want to
see these at all. I wouldn't necessarily expect this to be a
PROMOTE_MODE problem.

As others have suggested, find the first pass where you see a (subreg
(mem)) expression. That will be a big help. Extra credit if you can
correlate the insns in that dump with insns in the previous dump file
which would show how the pass in question modified the RTL incorrectly.
Given that it should be relatively easy to start digging into the problem.


>  
> (insn:HI 17 13 14 0 (set (mem/s:SI (plus:SI (mem/f:SI (reg/f:SI 14 R14) [15
> header+0 S4 A32])
>
> (const_int 32 [0x20])) [10 .private_bits+0 S4
> A32])
>
> (reg:SI 4 R4 [56])) 8 {store_si} (insn_list:REG_DEP_TRUE 13
> (insn_list:REG_DEP_TRUE 6 (nil)))
>
> (expr_list:REG_EQUAL (const_int 0 [0x0])
>
> (nil)))
>   
This looks like a different problem. What pass generates insn 17? What
does insn 17 look like in the prior pass? If r14 is your stack/frame
pointer, this might point to a problem in how your port interacts with
register allocation/reload as reload can replace a pseudo with an
equivalent memory location.

Jeff

Re: How to deal with unrecognizable RTL code

[Jeff Law]

daniel tian wrote:
>
> it will be called in GO_IF_LEGITIMATE_ADDRESS, and
> LEGITIMIZE_RELOAD_ADDRESS. So like the following unrecognizable RTL
> has gone.
>   
I would _strongly_ recommend you initially develop your port without
defining LEGITIMIZE_RELOAD_ADDRESS. Let reload work in the way it was
intended, particularly since I haven't seen anything to-date which would
indicate your chip has characteristics which reload can't handle.

Once your port is working well, you can go back and define
LEGITIMIZE_RELOAD_ADDRESS to optimize handling of reloads -- and because
your port was working prior to defining LEGITIMIZE_RELOAD_ADDRESS any
new failures are most likely due to an improper definition of
LEGITIMIZE_RELOAD_ADDRESS (which is easy to do given you have to know
how reload works to properly implement LEGITIMIZE_RELOAD_ADDRESS).


[ ... ]
>
> The RTL is at the beginning of the function, and R5 is used to pass
> parameter. So I think maybe should also trace the parameter passing
> function.
>   
Again, the best thing you can do is find the first dump file where these
problematical insns exist. That would be a huge step forward.

jeff

Re: Should -Wjump-misses-init be in -Wall?

[Richard Guenther]

On Thu, Jun 25, 2009 at 8:11 PM, Manuel
López-Ibáñez wrote:
> 2009/6/23 Ian Lance Taylor :
>> Paolo Bonzini  writes:
>>
>>> I don't think this warning can report anything that -Wuninitialized
>>> cannot report, so it should go in -Wc++-compat only.
>>
>> For the record, it can, as in when compiling this case without
>> optimization.  This is not a strong example by any means.
>
> This is a part of SSA that I don't understand completely. We create a
> var_decl for i in the following assignment:
>
> D.1606_1 = i;
>
> because i is loaded from memory. But then, because there is no alias
> info, there are no vuse/vdef operators for this statement. So we

The only reason there is no VUSE/VDEF at -O0 is that we never need
it, so we omit it for efficiency reasons.  We have enough information
at -O0 to add them should we need them.

Richard.

> actually do not know if this vuse is the default definition of i. Is
> there no way to know this without alias info? In the dump, it looks
> like this could be known:
>
> f1 ()
> {
>  intD.0 iD.1605;
>  intD.0 D.1606;
>
>  # BLOCK 2
>  # PRED: ENTRY (fallthru)
>  # SUCC: 3 (fallthru)
>
>  # BLOCK 3, starting at line 10
>  # PRED: 2 (fallthru)
> lab1L.0:
>  [test.c : 10:4] D.1606_1 = iD.1605;
>  return D.1606_1;
>  # SUCC: EXIT
>
> }
>
> BTW, why the dump and the output of debug_gimple_stmt are so different?
>
> Cheers,
>
> Manuel.
>

Re: Should -Wjump-misses-init be in -Wall?

[Manuel López-Ibáñez]

2009/6/25 Richard Guenther :
> On Thu, Jun 25, 2009 at 8:11 PM, Manuel
> López-Ibáñez wrote:
>> 2009/6/23 Ian Lance Taylor :
>>> Paolo Bonzini  writes:
>>>
 I don't think this warning can report anything that -Wuninitialized
 cannot report, so it should go in -Wc++-compat only.
>>>
>>> For the record, it can, as in when compiling this case without
>>> optimization.  This is not a strong example by any means.
>>
>> This is a part of SSA that I don't understand completely. We create a
>> var_decl for i in the following assignment:
>>
>> D.1606_1 = i;
>>
>> because i is loaded from memory. But then, because there is no alias
>> info, there are no vuse/vdef operators for this statement. So we
>
> The only reason there is no VUSE/VDEF at -O0 is that we never need
> it, so we omit it for efficiency reasons.  We have enough information
> at -O0 to add them should we need them.

My question was more like: Can we actually tell other way that this
var_decl is an use of uninitialized variable?
I think this is related to PR19430.

Cheers,

Manuel.

Re: Address mode offset spill

[Jeff Law]

Ian Lance Taylor wrote:

daniel tian  writes:

  

Yeah. Now I solve the unrecognize RTL problem. cc1 does not crash. And
before I add the second_reload macro. There are two problems happened.
1. there is a RTL code which move the memory data to another memory
location. RTL extracted  from file *.23.greg :

(insn 128 127 130 7 (set (mem/i:SI (plus:SI (reg/f:SI 14 R14)
(const_int 28 [0x1c])) [0 nChannels+0 S4 A32])
(mem:SI (plus:SI (reg/f:SI 14 R14)
(const_int 11372 [0x2c6c])) [0 iftmp.0+0 S4 A32])) 8
{store_si} (nil)
(nil))

this is not allowed in my RISC chip. And This doesn't go through the
reload  macro. Is this need to solve in secondary reload?



This kind of thing will be generated during reload, but should be
cleaned up during reload.  If it is not, it suggests that perhaps you
are not checking REG_OK_STRICT as required, or that your predicates or
constraints are wrong.  Or there may be some other explanation.
  
Also note that the secondary reload code needs to handle the case where 
it's passed a pseudo that hasn't been allocated a hard register.  I 
think he can get that code of code if he's not handling those cases 
properly.


However, the most likely cause is reload replacing a pseudo with its 
equivalent memory location and the port incorrectly accepting that form 
as valid, either because of a problem with REG_OK_STRICT, operand 
predicate or constraints, LEGITIMIZE_RELOAD_ADDRESS, etc.





  

2. Here is the RTL code in file *.23.greg:
(insn:HI 112 218 105 4 (set (reg:SI 5 R5 [78])
(plus:SI (reg:SI 7 R7)
(const_int 2064 [0x810]))) 45 {rice_addsi3}
(insn_list:REG_DEP_TRUE 161 (insn_list:REG_DEP_TRUE 73
(insn_list:REG_DEP_ANTI 79 (nil
(expr_list:REG_EQUIV (plus:SI (reg/f:SI 14 R14)
(const_int 2076 [0x81c]))
(nil)))

which is not legal in my risc chip. In MD file, I 've already defined
the addsi instruction pattern which only allows the 2nd operand with
less than 512. I don't know how did this happen. I mean I do know this
RTL comes from gcc optimization combination, but how it , which should
be an unrecognizable RTL, becomes recognizable  RTL. Does it also need
the secondary reload macro to handle?



The insn was recognized as rice_addsi3, so take a good look at that insn
and make sure the predicates and constraints reject the 2064.
  
Agreed.   There may be cases where reload generates this as well when 
there's pseudos that don't get hard registers and the pseudos have 
equivalent forms.   These may indicate more cases that will need 
secondary reloads.



Jeff

Phase 1 of gcc-in-cxx now complete

[Ian Lance Taylor]

I am pleased to report that if you configure gcc with
--enable-build-with-cxx, which causes the core compiler to be built
using a C++ compiler, a bootstrap on x86_64-unknown-linux-gnu now
completes.

I would like to encourage people to try using --enable-build-with-cxx in
other configuration--other bootstraps, cross-compilers--to see how well
it works.  Please let me know if you run into problems that you don't
know how, or don't have time, to fix.

This completes the first phase of the gcc-in-cxx project, which I
started about one year ago at the 2008 GCC Summit.

At this point I personally will probably not work on this project for
some weeks, other than bug fixing.  Further steps on the overall project
of converting gcc to C++ are:

* Write a coding standards document for gcc in C++.

* Convert more code to be compiled as C++ when using
  --enable-build-with-cxx.  Currently the generator programs
  (genattrtab, etc.) and libcpp are still compiled as C.

* Develop some trial patches which require C++, e.g., convert VEC to
  std::vector.

* Test starting the bootstrap with earlier versions of the compiler to
  see which C++ compiler version is required, and document that.

* Petition the steering committee for formal approval to switch to C++.

I do not expect to convert the compiler to require C++ in the 4.5
timeframe.

I encourage anybody who is interested to experiment with these further
steps.

Ian

Re: Address mode offset spill

[Jeff Law]

daniel tian wrote:

PS: there are 16 general registers in my RISC chip, from R0 to R15.
R14, and R15 are used for FP,SP. R0 register is special.
Every large immediate, larger than 512, must be moved into R0
register, which means that R0 is the only register to load large
immediate.
This is a thorny problem.
  

But not terribly uncommon.

Do you need to synthesize large constants?  ie, what code would you 
generate to load the value 0x12345 into a register?


If you need to synthesize large constants, do you need any additional 
scratch registers, or can you do so using just r0?



jeff

Re: Phase 1 of gcc-in-cxx now complete

[Richard Guenther]

On Thu, Jun 25, 2009 at 10:32 PM, Ian Lance Taylor wrote:
> I am pleased to report that if you configure gcc with
> --enable-build-with-cxx, which causes the core compiler to be built
> using a C++ compiler, a bootstrap on x86_64-unknown-linux-gnu now
> completes.
>
> I would like to encourage people to try using --enable-build-with-cxx in
> other configuration--other bootstraps, cross-compilers--to see how well
> it works.  Please let me know if you run into problems that you don't
> know how, or don't have time, to fix.
>
> This completes the first phase of the gcc-in-cxx project, which I
> started about one year ago at the 2008 GCC Summit.
>
> At this point I personally will probably not work on this project for
> some weeks, other than bug fixing.  Further steps on the overall project
> of converting gcc to C++ are:
>
> * Write a coding standards document for gcc in C++.
>
> * Convert more code to be compiled as C++ when using
>  --enable-build-with-cxx.  Currently the generator programs
>  (genattrtab, etc.) and libcpp are still compiled as C.
>
> * Develop some trial patches which require C++, e.g., convert VEC to
>  std::vector.
>
> * Test starting the bootstrap with earlier versions of the compiler to
>  see which C++ compiler version is required, and document that.
>
> * Petition the steering committee for formal approval to switch to C++.
>
> I do not expect to convert the compiler to require C++ in the 4.5
> timeframe.

I think it would be a good thing to try forcing the C++ host compiler
requirement for GCC 4.5 with just building stage1 with C++ and stage2/3
with the stage1 C compiler.  --disable-build-with-cxx would be a
workaround for a missing C++ host compiler.

That should give us an idea on what problems we are going to face
when switching to actual C++ code.

Richard.

> I encourage anybody who is interested to experiment with these further
> steps.
>
> Ian
>

Re: Address mode offset spill

[Jeff Law]

daniel tian wrote:


You mean before LEGITIMIZE_RELOAD_ADDRESS, cc1 must generate the
correct RTL code, regardless of whether efficient or not.
  
The compiler should work with or without defining 
LEGITIMIZE_RELOAD_ADDRESS.   It's often difficult to write a correct 
LEGITIMIZE_RELOAD_ADDRESS without knowing the internals of how reload 
works.  Therefore, I strongly recommend first writing the port without 
LEGITIMIZE_RELOAD_ADDRESS -- after the port is working correctly you can 
go back and add LEGITIMIZE_RELOAD_ADDRESS to generate more efficient code.



Take the immediate load for instance, should  I generate the the right
code in "movm" expander? I mean ,first the larger immediate data will
move into a pseduo register, then I insert a RTL code, first move to
R0, then R0 move to the pseduo register. Right?
  

I'm not familiar with your port.  So I would have to start with a question.

Does your target require the constant to be loaded into r0, or is r0 a 
scratch register necessary to synthesize the constant into some other 
register?  The difference is subtle, but important for reload.  For the 
former, you will have a secondary reload that is a intermediate 
register, for the latter, the secondary reload will be a scratch register.




Now I just force the larger immedate into a register, and let the
reload to move the immediate into R0 register.
  
It is generally better to force the large constant into a pseudo rather 
than expose R0 early in RTL generation, so you're doing the right thing 
in this regard.  I think the problem is you haven't defined your 
secondary reloads yet.


jeff

Re: Phase 1 of gcc-in-cxx now complete (Ada)

[Laurent GUERBY]

On Thu, 2009-06-25 at 13:32 -0700, Ian Lance Taylor wrote:
> I am pleased to report that if you configure gcc with
> --enable-build-with-cxx, which causes the core compiler to be built
> using a C++ compiler, a bootstrap on x86_64-unknown-linux-gnu now
> completes.
> 
> I would like to encourage people to try using --enable-build-with-cxx in
> other configuration--other bootstraps, cross-compilers--to see how well
> it works.  Please let me know if you run into problems that you don't
> know how, or don't have time, to fix.

Hi,

Wanting to test Ada on the branch, after checkout I did on x86_64-linux:

../gcc/configure --enable-languages=c,c++,ada --enable-__cxa_atexit
--disable-nls --enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.4.1/
--with-gmp=/opt/cfarm/gmp-4.2.4/  --prefix=/n/16/guerby/cxx/install
--enable-build-with-cxx

make bootstrap
...
g++ -c  -g -g -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wmissing-format-attribute -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-4.2.4//include
-I/opt/cfarm/mpfr-2.4.1//include -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/bid
-I../libdecnumber../../gcc/gcc/c-decl.c -o c-decl.o
/usr/include/libintl.h:40: error: expected unqualified-id before ‘const’
/usr/include/libintl.h:40: error: expected `)' before ‘const’
/usr/include/libintl.h:40: error: expected initializer before ‘const’
/usr/include/libintl.h:81: error: expected unqualified-id before ‘const’
/usr/include/libintl.h:81: error: expected `)' before ‘const’
/usr/include/libintl.h:81: error: expected initializer before ‘const’
/usr/include/libintl.h:85: error: expected unqualified-id before ‘const’
/usr/include/libintl.h:85: error: expected `)' before ‘const’
/usr/include/libintl.h:85: error: expected initializer before ‘const’
../../gcc/gcc/c-decl.c: In function ‘tree_node* finish_enum(tree_node*,
tree_node*, tree_node*)’:
../../gcc/gcc/c-decl.c:7011: warning: comparison between signed and
unsigned integer expressions
../../gcc/gcc/c-decl.c:7032: warning: comparison between signed and
unsigned integer expressions
make[3]: *** [c-decl.o] Error 1
make[3]: Leaving directory `/home/guerby/cxx/build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/guerby/cxx/build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/guerby/cxx/build'
make: *** [bootstrap] Error 2

Given the error is in non Ada-related code I guess this has to do
with the base C++ compiler and system headers in C++ mode, gcc16 is
running Debian 4.0 and GCC 4.1.2 (which works for trunk bootstrap of c,c
++,ada):

gue...@gcc16:~/cxx/build$ g++ --version
g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

gcc16 has a collection of GCC versions:
gue...@gcc16:~/cxx/build$ ls /opt/cfarm/release/
4.2.0  4.2.1  4.2.2  4.2.3  4.2.4  4.3.0  4.3.1  4.3.2  4.3.3  4.4.0

Using 4.2.3 as base compiler failed with the same error as system 4.1.2.

Using 4.3.3 and 4.4.0 as base compiler bootstrap failed on Ada-related
stuff, here gcc/ada/gcc-interface/decl.c:

g++ -c  -g -g -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual   -fno-common  
-DHAVE_CONFIG_H -I.. -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada 
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -\
I/opt/cfarm/gmp-4.2.4//include -I/opt/cfarm/mpfr-2.4.1//include 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid 
-I../libdecnumber../../gcc/gcc/ada/gcc-interface/decl.c -o ada/decl.o
../../gcc/gcc/ada/gcc-interface/decl.c: In function 'tree_node* 
substitute_in_type(tree_node*, tree_node*, tree_node*)':
../../gcc/gcc/ada/gcc-interface/decl.c:7791: error: expected unqualified-id 
before 'new'
../../gcc/gcc/ada/gcc-interface/decl.c:7812: error: expected type-specifier 
before '=' token
../../gcc/gcc/ada/gcc-interface/decl.c:7812: error: lvalue required as left 
operand of assignment
../../gcc/gcc/ada/gcc-interface/decl.c:7813: error: expected type-specifier 
before ')' token
../../gcc/gcc/ada/gcc-interface/decl.c:7813: error: request for member 'base' 
in '*(int*)__t', which is of non-class type 'int'
../../gcc/gcc/ada/gcc-interface/decl.c:7813: error: request for member 'base' 
in '*(int*)__t', which is of non-class type 'int'
../../gcc/gcc/ada/gcc-interface/decl.c:7813: error: request for member 'base' 
in '*(int*)__t', which is of non-class type 'int'
../../gcc/gcc/ada/gcc-interface/decl.c:7813: error: request for member 'base' 
in '*(int*)__t', which is of non-class type 'int'
../../gcc/gcc/ada/gcc-interface/decl.c:7813: error: request for member 'base' 
in '*(int*)__t', which is of non-class type 'int'
../../gcc/gcc/ada/gcc-interface/decl.c:7813: error: cannot convert 'int* const' 
to 'const tree_node*' for argument '1' to 'void tree_check_failed(const 
tree_node*, const char*, int, const char*, ...)'
../../gcc/gcc/ada/gcc-interface/decl.c:7813: error: request for member 'type' 
in '*({...})', wh

Re: ICE building svn trunk on Ubuntu 9.x amd64

[Matt]

(now sending to gcc@ instead of gcc-help@, as suggested)

I have narrowed it down to this reduced commandline (the time is there 
just to show that it may take a while, but this particular issue doesn't 
cause a hang):


 m...@hargett-755:~/src/gcc-obj/prev-gcc$ time 
/home/matt/src/gcc-obj/./prev-gcc/xgcc 
-B/home/matt/src/gcc-obj/./prev-gcc/ 
-B/home/matt/x86_64-unknown-linux-gnu/bin/ 
-B/home/matt/x86_64-unknown-linux-gnu/bin/ 
-B/home/matt/x86_64-unknown-linux-gnu/lib/ -isystem 
/home/matt/x86_64-unknown-linux-gnu/include -isystem 
/home/matt/x86_64-unknown-linux-gnu/sys-include-c  -O2 
-ftree-loop-distribution -DIN_GCC -DHAVE_CONFIG_H -I. -I. 
-I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/. 
-I../../gcc-trunk/gcc/../include -I../../gcc-trunk/gcc/../libcpp/include 
-I../../gcc-trunk/gcc/../libdecnumber 
-I../../gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber -Iyes/include 
-Iyes/include -DCLOOG_PPL_BACKEND   ../../gcc-trunk/gcc/reload1.c -o 
reaload1.o../../gcc-trunk/gcc/reload1.c: In function delete_output_reload:
../../gcc-trunk/gcc/reload1.c:8391:1: error: type mismatch in binary 
expression

long unsigned int



long unsigned int

D.65146_650 = D.65145_651 - D.65141_624;

../../gcc-trunk/gcc/reload1.c:8391:1: error: type mismatch in binary 
expression

long unsigned int



long unsigned int

D.65154_658 = D.65153_659 - D.65149_647;

../../gcc-trunk/gcc/reload1.c:8391:1: internal compiler error: 
verify_stmts failed

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

real9m25.630s
user9m23.823s
sys 0m0.972s


-O0 -ftree-loop-distribution doesn't exhibit the problem, and neither does 
-O1 -ftree-loop-distribution. There's something about the combination of 
-O2 (or -O3) and -ftree-loop-distribution that causes the ICE on this 
particular file.


I'll try bootstrapping without -ftree-loop-distribution and see if that 
works for me. If more information is needed, or I should file a bug 
report, let me know.


On Wed, 24 Jun 2009, Matt wrote:


Hi,

I left my profiled bootstrap to of svn r148885 to run overnight, and saw this 
in the morning:


/home/matt/src/gcc-obj/./prev-gcc/xgcc -B/home/matt/src/gcc-obj/./prev-gcc/ 
-B/home/matt/x86_64-unknown-linux-gnu/bin/ 
-B/home/matt/x86_64-unknown-linux-gnu/bin/ 
-B/home/matt/x86_64-unknown-linux-gnu/lib/ -isystem 
/home/matt/x86_64-unknown-linux-gnu/include -isystem 
/home/matt/x86_64-unknown-linux-gnu/sys-include-c  -O3 -floop-interchange 
-floop-strip-mine -floop-block -findirect-inlining -ftree-switch-conversion 
-fvect-cost-model -fgcse-sm -fgcse-las -fgcse-after-reload -fsee 
-ftree-loop-linear -ftree-loop-distribution -ftree-loop-im 
-ftree-loop-ivcanon -fivopts -fvpt -funroll-loops -funswitch-loops 
-fprofile-generate -DIN_GCC   -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 -Werror -fno-common  -DHAVE_CONFIG_H -I. -I. 
-I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/. 
-I../../gcc-trunk/gcc/../include -I../../gcc-trunk/gcc/../libcpp/include 
-I../../gcc-trunk/gcc/../libdecnumber 
-I../../gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber -Iyes/include 
-Iyes/include -DCLOOG_PPL_BACKEND   ../../gcc-trunk/gcc/rtl.c -o rtl.o

../../gcc-trunk/gcc/reload1.c: In function delete_output_reload:
../../gcc-trunk/gcc/reload1.c:8391:1: error: type mismatch in binary 
expression

long unsigned int



long unsigned int

D.58046_964 = D.58045_963 - D.58041_946;

../../gcc-trunk/gcc/reload1.c:8391:1: error: type mismatch in binary 
expression

long unsigned int



long unsigned int

D.58054_972 = D.58053_971 - D.58049_967;

../../gcc-trunk/gcc/reload1.c:8391:1: internal compiler error: verify_stmts 
failed

Please submit a full bug report,
with preprocessed source if appropriate.

This is using the 4:4.4.0-3ubuntu1 version of Ubuntu's gcc package on amd64.

Here's my configure cmdline:
CFLAGS="-O3 -floop-interchange -floop-strip-mine -floop-block 
-findirect-inlining -ftree-switch-conversion -fvect-cost-model -fgcse-sm 
-fgcse-las -fgcse-after-reload -fsee -ftree-loop-linear 
-ftree-loop-distribution -ftree-loop-im -ftree-loop-ivcanon -fivopts -fvpt 
-funroll-loops -funswitch-loops" CPPFLAGS="-O3 -floop-interchange 
-floop-strip-mine -floop-block -findirect-inlining -ftree-switch-conversion 
-fvect-cost-model -fgcse-sm -fgcse-las -fgcse-after-reload -fsee 
-ftree-loop-linear -ftree-loop-distribution -ftree-loop-im 
-ftree-loop-ivcanon -fivopts -fvpt -funroll-loops -funswitch-loops" 
../gcc-trunk/configure --prefix=/home/matt --enable-stage1-checking=all 
--enable-bootstrap --enable-lto --enable-languages=c,c++ --with-ppl 
--with-cloog


and here's my make cmdline:
make BOOT_CFLAGS="-O3 -floop-interchange -floop-strip-mine -floop-block 
-findirect-inlining -ftree-switch-conversion -fvect-cost-model -fgcse-sm 

Re: Phase 1 of gcc-in-cxx now complete (Ada)

[Richard Guenther]

On Thu, Jun 25, 2009 at 11:50 PM, Laurent GUERBY wrote:
> On Thu, 2009-06-25 at 13:32 -0700, Ian Lance Taylor wrote:
>> I am pleased to report that if you configure gcc with
>> --enable-build-with-cxx, which causes the core compiler to be built
>> using a C++ compiler, a bootstrap on x86_64-unknown-linux-gnu now
>> completes.
>>
>> I would like to encourage people to try using --enable-build-with-cxx in
>> other configuration--other bootstraps, cross-compilers--to see how well
>> it works.  Please let me know if you run into problems that you don't
>> know how, or don't have time, to fix.
>
> Hi,
>
> Wanting to test Ada on the branch, after checkout I did on x86_64-linux:
>
> ../gcc/configure --enable-languages=c,c++,ada --enable-__cxa_atexit
> --disable-nls --enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.4.1/
> --with-gmp=/opt/cfarm/gmp-4.2.4/  --prefix=/n/16/guerby/cxx/install
> --enable-build-with-cxx
>
> make bootstrap
> ...
> g++ -c  -g -g -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
> -Wmissing-format-attribute -fno-common  -DHAVE_CONFIG_H -I. -I.
> -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
> -I../../gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-4.2.4//include
> -I/opt/cfarm/mpfr-2.4.1//include -I../../gcc/gcc/../libdecnumber
> -I../../gcc/gcc/../libdecnumber/bid
> -I../libdecnumber    ../../gcc/gcc/c-decl.c -o c-decl.o
> /usr/include/libintl.h:40: error: expected unqualified-id before ‘const’
> /usr/include/libintl.h:40: error: expected `)' before ‘const’
> /usr/include/libintl.h:40: error: expected initializer before ‘const’
> /usr/include/libintl.h:81: error: expected unqualified-id before ‘const’
> /usr/include/libintl.h:81: error: expected `)' before ‘const’
> /usr/include/libintl.h:81: error: expected initializer before ‘const’
> /usr/include/libintl.h:85: error: expected unqualified-id before ‘const’
> /usr/include/libintl.h:85: error: expected `)' before ‘const’
> /usr/include/libintl.h:85: error: expected initializer before ‘const’
> ../../gcc/gcc/c-decl.c: In function ‘tree_node* finish_enum(tree_node*,
> tree_node*, tree_node*)’:
> ../../gcc/gcc/c-decl.c:7011: warning: comparison between signed and
> unsigned integer expressions
> ../../gcc/gcc/c-decl.c:7032: warning: comparison between signed and
> unsigned integer expressions
> make[3]: *** [c-decl.o] Error 1
> make[3]: Leaving directory `/home/guerby/cxx/build/gcc'
> make[2]: *** [all-stage1-gcc] Error 2
> make[2]: Leaving directory `/home/guerby/cxx/build'
> make[1]: *** [stage1-bubble] Error 2
> make[1]: Leaving directory `/home/guerby/cxx/build'
> make: *** [bootstrap] Error 2
>
> Given the error is in non Ada-related code I guess this has to do
> with the base C++ compiler and system headers in C++ mode, gcc16 is
> running Debian 4.0 and GCC 4.1.2 (which works for trunk bootstrap of c,c
> ++,ada):
>
> gue...@gcc16:~/cxx/build$ g++ --version
> g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
>
> gcc16 has a collection of GCC versions:
> gue...@gcc16:~/cxx/build$ ls /opt/cfarm/release/
> 4.2.0  4.2.1  4.2.2  4.2.3  4.2.4  4.3.0  4.3.1  4.3.2  4.3.3  4.4.0
>
> Using 4.2.3 as base compiler failed with the same error as system 4.1.2.
>
> Using 4.3.3 and 4.4.0 as base compiler bootstrap failed on Ada-related
> stuff, here gcc/ada/gcc-interface/decl.c:
>
> g++ -c  -g -g -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual   -fno-common  
> -DHAVE_CONFIG_H -I.. -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada 
> -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -\
> I/opt/cfarm/gmp-4.2.4//include -I/opt/cfarm/mpfr-2.4.1//include 
> -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid 
> -I../libdecnumber    ../../gcc/gcc/ada/gcc-interface/decl.c -o ada/decl.o
> ../../gcc/gcc/ada/gcc-interface/decl.c: In function 'tree_node* 
> substitute_in_type(tree_node*, tree_node*, tree_node*)':
> ../../gcc/gcc/ada/gcc-interface/decl.c:7791: error: expected unqualified-id 
> before 'new'
> ../../gcc/gcc/ada/gcc-interface/decl.c:7812: error: expected type-specifier 
> before '=' token
> ../../gcc/gcc/ada/gcc-interface/decl.c:7812: error: lvalue required as left 
> operand of assignment
> ../../gcc/gcc/ada/gcc-interface/decl.c:7813: error: expected type-specifier 
> before ')' token
> ../../gcc/gcc/ada/gcc-interface/decl.c:7813: error: request for member 'base' 
> in '*(int*)__t', which is of non-class type 'int'
> ../../gcc/gcc/ada/gcc-interface/decl.c:7813: error: request for member 'base' 
> in '*(int*)__t', which is of non-class type 'int'
> ../../gcc/gcc/ada/gcc-interface/decl.c:7813: error: request for member 'base' 
> in '*(int*)__t', which is of non-class type 'int'
> ../../gcc/gcc/ada/gcc-interface/decl.c:7813: error: request for member 'base' 
> in '*(int*)__t', which is of non-class type 'int'
> ../../gcc/gcc/ada/gcc-interface/decl.c:7813: error: request for member 'base' 
> in '*(int*)__t', which is of non-class type 'int'
> ../../gcc/gcc/ada/gcc-interface/decl.c:7813: error: cannot convert 'int

Re: Phase 1 of gcc-in-cxx now complete

[Joseph S. Myers]

On Thu, 25 Jun 2009, Ian Lance Taylor wrote:

> * Test starting the bootstrap with earlier versions of the compiler to
>   see which C++ compiler version is required, and document that.

I think the right approach is not documenting observations like that, but 
investigating the causes of failures with older compilers and making it 
build with as wide a range of versions of GCC (and ideally at least one 
non-GCC C++ compiler, probably an EDG-based one such as the Intel 
compiler) as is reasonable.

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

Re: Phase 1 of gcc-in-cxx now complete (Ada)

[Ian Lance Taylor]

Richard Guenther  writes:

>> I guess this has to do with reserved word conflict on "new":
>>
>> <<
>> tree
>> substitute_in_type (tree t, tree f, tree r)
>> {
>>  tree new;

>>
>> Do you have some way to deal with this?
>
> Use a non-reserved identifier.  I guess on trunk Ada doesn't build
> with -Wc++-compat, does it?

Interesting.  I've been testing my -Wc++-compat patches with full
bootstraps including Ada, but I just looked at my make log and it does
indeed appear that -Wc++-compat doesn't make it onto the Ada files.

It seems to be because of this line in ada/gcc-interface/Make-lang.in:

ada-warn = $(ADA_CFLAGS) $(WERROR)

The other languages use

DIR-warn = $(STRICT_WARN)

which is what brings in -Wc++-compat.

Ian

Re: (known?) Issue with bitmap iterators

[Dave Korn]

Jeff Law wrote:

> My biggest concern would be catching all the exit paths from the
> gazillion iterators we use and making sure they all reset the readonly
> flag.  Ick...


  Heh.  GCC-in-CXX would solve that for us :) or we could implement
try...finally clauses 

cheers,
  DaveK

Re: Phase 1 of gcc-in-cxx now complete

[Eric Botcazou]

> I think the right approach is not documenting observations like that, but
> investigating the causes of failures with older compilers and making it
> build with as wide a range of versions of GCC (and ideally at least one
> non-GCC C++ compiler, probably an EDG-based one such as the Intel
> compiler) as is reasonable.

Yes, I don't think we should require GCC to build GCC, this would be a step 
backwards in my opinion.  I can experiment with the Sun Studio compiler.

-- 
Eric Botcazou

Re: Phase 1 of gcc-in-cxx now complete

[Joe Buck]

On Thu, Jun 25, 2009 at 03:19:19PM -0700, Joseph S. Myers wrote:
> On Thu, 25 Jun 2009, Ian Lance Taylor wrote:
> 
> > * Test starting the bootstrap with earlier versions of the compiler to
> >   see which C++ compiler version is required, and document that.
> 
> I think the right approach is not documenting observations like that, but
> investigating the causes of failures with older compilers and making it
> build with as wide a range of versions of GCC (and ideally at least one
> non-GCC C++ compiler, probably an EDG-based one such as the Intel
> compiler) as is reasonable.

Microsoft's and Sun's compilers would be more likely to run into issues,
particularly Sun's; Sun has had a policy of preferring solid backward
compatibility to standards compliance, so I've tended to have more
problems getting correct, standard C++ to run on their compiler than on
others.  This is particularly true of template-based code and nested
classes.

Re: Phase 1 of gcc-in-cxx now complete (Ada)

[Ian Lance Taylor]

Laurent GUERBY  writes:

> Wanting to test Ada on the branch, after checkout I did on x86_64-linux:
>
> ../gcc/configure --enable-languages=c,c++,ada --enable-__cxa_atexit
> --disable-nls --enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.4.1/
> --with-gmp=/opt/cfarm/gmp-4.2.4/  --prefix=/n/16/guerby/cxx/install
> --enable-build-with-cxx
>
> make bootstrap
> ...
> g++ -c  -g -g -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
> -Wmissing-format-attribute -fno-common  -DHAVE_CONFIG_H -I. -I.
> -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
> -I../../gcc/gcc/../libcpp/include -I/opt/cfarm/gmp-4.2.4//include
> -I/opt/cfarm/mpfr-2.4.1//include -I../../gcc/gcc/../libdecnumber
> -I../../gcc/gcc/../libdecnumber/bid
> -I../libdecnumber../../gcc/gcc/c-decl.c -o c-decl.o
> /usr/include/libintl.h:40: error: expected unqualified-id before ‘const’
> /usr/include/libintl.h:40: error: expected `)' before ‘const’
> /usr/include/libintl.h:40: error: expected initializer before ‘const’
> /usr/include/libintl.h:81: error: expected unqualified-id before ‘const’
> /usr/include/libintl.h:81: error: expected `)' before ‘const’
> /usr/include/libintl.h:81: error: expected initializer before ‘const’
> /usr/include/libintl.h:85: error: expected unqualified-id before ‘const’
> /usr/include/libintl.h:85: error: expected `)' before ‘const’
> /usr/include/libintl.h:85: error: expected initializer before ‘const’

I looked at this.  It's due to the use of --disable-nls.  That causes
gcc/intl.h in the gcc sources to do this:

# undef gettext
# define gettext(msgid) (msgid)

Later, gmp.h is #included.  When gmp.h is compiled with C++, it
#includes  which (in gcc 4.1) #includes  which
#include .  libintl.h does this:

extern char *gettext (__const char *__msgid)
 __THROW __attribute_format_arg__ (1);

which fails because of the #define of gettext.

I think the simple fix may be to always have gcc/intl.h include
 if it exists, to ensure that it does not get included later
after the gettext macro is defined.

Ian

gcc-4.5-20090625 is now available

[gccadmin]

Snapshot gcc-4.5-20090625 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090625/
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 148954

You'll find:

gcc-4.5-20090625.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.5-20090625.tar.bz2 C front end and core compiler

gcc-ada-4.5-20090625.tar.bz2  Ada front end and runtime

gcc-fortran-4.5-20090625.tar.bz2  Fortran front end and runtime

gcc-g++-4.5-20090625.tar.bz2  C++ front end and runtime

gcc-java-4.5-20090625.tar.bz2 Java front end and runtime

gcc-objc-4.5-20090625.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.5-20090625.tar.bz2The GCC testsuite

Diffs from 4.5-20090618 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.

Re: Address mode offset spill

[daniel tian]

> But not terribly uncommon.
>
> Do you need to synthesize large constants?  ie, what code would you generate
> to load the value 0x12345 into a register?
>
> If you need to synthesize large constants, do you need any additional
> scratch registers, or can you do so using just r0?
>
Only do using R0.  Like the following with loading 0x12345:

MOVI   0x2345  -L   //To load the lower 16bit data
MOVI   0x1   -H  //Load the up 16bit data

The destination register must only be R0 register, which is determined
by the hardware. R0 is also general register which can be used in all
operation instructions like ADD, Subtract, Multiply and LOAD/STORE.

Now my approach is to define the Macro PREFERRED_RELOAD_CLASS(X,
CLASS), and make sure if the X is const int and larger than 512, it
will return the R0_REG register class.
PS: I think that if I don't define the macro LEGITIMIZE_RELOAD_ADDRESS
which will push reload the larger const int, the
PREFERRED_RELOAD_CLASS won't be called. is  it right?


Thanks.
-- 
Best Regards
daniel tian
Mavrix Technology, Inc.
Address：200 Zhangheng Road, #3501, Building 3, Zhangjiang Hi-tech
Park, Shanghai, P.R.China (201204)
Tel:86(21)51095958 - 8125
Fax:86(21)50277658
email：daniel.t...@mavrixtech.com.cn
www.mavrixtech.com

Re: Address mode offset spill

[daniel tian]

>
> The compiler should work with or without defining LEGITIMIZE_RELOAD_ADDRESS.
>   It's often difficult to write a correct LEGITIMIZE_RELOAD_ADDRESS without
> knowing the internals of how reload works.  Therefore, I strongly recommend
> first writing the port without LEGITIMIZE_RELOAD_ADDRESS -- after the port
> is working correctly you can go back and add LEGITIMIZE_RELOAD_ADDRESS to
> generate more efficient code.
>

Do you mean that I should not write any reload code including
secondary reload? And if it is going to work fine, then keep working
on reload part?

You give a direction. I will do it.

^_^

Thanks. ^_^

-- 
Best Regards
daniel tian
Mavrix Technology, Inc.
Address：200 Zhangheng Road, #3501, Building 3, Zhangjiang Hi-tech
Park, Shanghai, P.R.China (201204)
Tel:86(21)51095958 - 8125
Fax:86(21)50277658
email：daniel.t...@mavrixtech.com.cn
www.mavrixtech.com

Re: Phase 1 of gcc-in-cxx now complete

[Gabriel Dos Reis]

On Thu, Jun 25, 2009 at 5:47 PM, Joe Buck wrote:
> On Thu, Jun 25, 2009 at 03:19:19PM -0700, Joseph S. Myers wrote:
>> On Thu, 25 Jun 2009, Ian Lance Taylor wrote:
>>
>> > * Test starting the bootstrap with earlier versions of the compiler to
>> >   see which C++ compiler version is required, and document that.
>>
>> I think the right approach is not documenting observations like that, but
>> investigating the causes of failures with older compilers and making it
>> build with as wide a range of versions of GCC (and ideally at least one
>> non-GCC C++ compiler, probably an EDG-based one such as the Intel
>> compiler) as is reasonable.
>
> Microsoft's and Sun's compilers would be more likely to run into issues,
> particularly Sun's; Sun has had a policy of preferring solid backward
> compatibility to standards compliance, so I've tended to have more
> problems getting correct, standard C++ to run on their compiler than on
> others.  This is particularly true of template-based code and nested
> classes.

Yes, but I also think that we should aim for a conservative subset
of C++ -- that is solid enough for the last decade.  I don't pretend
that is an easy task, but I believe that can only help us.

-- Gaby


>
>