_cplusplus symbol's value
Hi, I would like to discuss about _cplusplus symbol value. for now, we have: 0 if we do not compile in C++ 1 if we compile in C++ And we have the opportunity to test if we compile in C++1x only by checking the definition of the symbol __GXX_EXPERIMENTAL_CXX0X__. I know that C++1x is not yet finalized, but according http://www2.research.att.com/ ~ bs / C + +0 xFAQ.html # 0x its value should be: 0 if we do not compile in C++, less than or equal to 199711L when compiling C++ (C++03 and above), greater than 199711L (not yet fully defined, according to C++1x finalization date) if we're compiling in C++1x. Also, is it possible to care about those values, even to correct once the final value is known? PS: please excuse my bad English, my native language is French
Re: _cplusplus symbol's value
On 01/28/2010 01:15 PM, koala01 wrote: > Hi, > > I would like to discuss about _cplusplus symbol value. > > for now, we have: > 0 if we do not compile in C++ > 1 if we compile in C++ You mean __cplusplus, double underscore. Anyway, we have a long standing Bugzilla about it: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 who knows, maybe we can make progress relatively soon... Paolo.
FW: http://gcc.gnu.org/ml/gcc/2009-07/msg00484.html
This question is in response to Ian's answer here: Ref: http://gcc.gnu.org/ml/gcc/2009-07/msg00462.html Adding to the referenced inquiry, there are on the machine a condition codes register for each register. I would like to model this by writing define_insns in such a way as to access a register in different modes, i e r0 | r1 | r2 ... accumulator0 So that QImode would mean r0, HImode r0+r1, and CCmode would mean r2 (the corresponding cc-reg). Then, something like this might work: [(set (match_operand:HI 0 "register_operand" "=a") (minus:HI (match_operand:HI 1 "register_operand" "a") (match_operand:HI 2 "register_operand" "a")) ) (clobber (match_operand:CC 3 "register_operand" "=0")) ] This way, GCC would always clobber the corresponding cc-register. Is this possible to implement, in terms of defining a new mode? The trick would be to add a new register next to the register-pair in the hard registers definition array, so as to always reference the cc-reg with an offsetting mode. I tried this a bit, but reload would refuse it. I would appreciate comments on this, /Jonas Paulsson, LTH, Sweden (Thesis project)
Re: porting GCC to a micro with a very limited addressing mode --- what to write in LEGITIMATE_ADDRESS, LEGITIMIZE_ADDRESS and micro.md ?!
Now my GO_IF_LEGITIMATE_ADDRESS refuses anything that is not a REG
or a CONSTANT_ADDRESS:
int legitimate_address1(enum machine_mode MODE,rtx X)
{
if(CONSTANT_ADDRESS_P(X))
return 1;
if(GET_CODE(X)==REG && is_base_reg(REGNO(X)))
return 1;
return 0; /* fails everything else */
} /* this is the strict version, the non strict version is similar */
but GCC (4.0.2, just in case the version is relevant) still aborts the
compilation.
Then I found this wiki note about forcing complex addresses into
registers: http://gcc.gnu.org/wiki/WritingANewBackEnd
...
rtx copy_addr_to_reg (rtx x)
Equivalent to copy_to_mode_reg (Pmode, x). For example, this
function can be used to compute a complex address X in a register for an
instruction which supports only register indirect addressing. See also
replace_equiv_address() below.
...
Thus I changed in the .md file the movXX RTL expand macro to force any
MEM expression into a register:
(define_expand "movhi" /* my micro is 16 bit... */
[(set (match_operand:HI 0 "nonimmediate_operand" "")
(match_operand:HI 1 "general_operand" "")
)]
""
{
if(!no_new_pseudos && GET_CODE(operands[0])==MEM) {
if( /* addr in operands[0] == base reg + offset */ )
operands[0] = copy_addr_to_reg ( operands[0] );
}
)
The GCC still fails to generate the assembly code to do the arithmetic
computation of the baseReg+offset-->tempReg, and then use (tempReg) as
address.
Note that with the current MD GCC is able to generate simple sums like
R1 = R2 + R3 and R1 = R2 + IMM, thus the basic math to compute an
address is there.
Any suggestion on what I am doing wrong ?
Sergio
Michael Hope wrote:
> Hi Sergio. My port has similar addressing modes - all memory must be
> accessed by one of two registers and can only be accessed indirectly,
> indirect with pre increment, and indirect with post increment. The
> key is GO_IF_LEGITIMATE_ADDRESS and the legitimate address helper
> function. Mine looks like this:
>
> /* Return 1 if the address is OK, otherwise 0.
>Used by GO_IF_LEGITIMATE_ADDRESS. */
>
> bool
> tomi_legitimate_address (enum machine_mode mode ATTRIBUTE_UNUSED,
>rtx x,
>bool strict_checking)
> {
> /* (mem reg) */
> if (REG_P (x)
> && tomi_reg_ok (x, strict_checking)
> )
> {
> return 1;
> }
>
> if (GET_CODE(x) == PRE_DEC)
> {
> ...
> }
>
> if (GET_CODE(x) == POST_INC)
> {
> ...
> }
>
> return 0;
> }
>
> tomi_reg_ok returns true if x is any register when strict checking is
> clear and true if x is one of my addressing registers when strict
> checking is set.
>
> GCC will feed any memory accesses through this function to see if they
> are directly supported, and if not it will break them up into
> something smaller and try again.
>
> Hope that helps,
>
> -- Michael
>
>
> 2010/1/26 Sergio Ruocco :
>> Gabriel Paubert wrote:
>>> On Mon, Jan 25, 2010 at 01:34:09PM +0100, Sergio Ruocco wrote:
Hi everyone,
I am porting GCC to a custom 16-bit microcontroller with very limited
addressing modes. Basically, it can only load/store using a (general
purpose) register as the address, without any offset:
LOAD (R2) R1; load R1 from memory at address (R2)
STORE R1 (R2) ; store R1 to memory at address (R2)
As far as I can understand, this is more limited than the current
architectures supported by GCC that I found in the current gcc/config/*.
>>> The Itanium (ia64) has the same limited choice of addressing modes.
>>>
>>> Gabriel
>> Thanks Gabriel.
>>
>> I dived into the ia64 md, but it is still unclear to me how the various
>> parts (macros, define_expand and define_insn in MD etc.) work together
>> to force the computation of a source/dest address plus offset into a
>> register... can anyone help me with this ?
>>
>> Thanks,
>>
>>Sergio
>>
Re: Treatment of builtin that receives function pointer
On Wed, Jan 27, 2010 at 12:25 PM, Paulo J. Matos wrote:
> Now, I wonder in this more general case, where can I obtain the
> function decl (so I can get its assembler name) for the function the
> pointer is pointing to?
>
Allow me to revive this question by asking if I can obtain the
function assembler name given a direct function pointer to the
function.
For example:
void foo1(void) {...}
__get_name(foo1) ==> "foo1"
int foo2(int *x) { ... }
__get_name(foo2) ==> "foo2"
This is all I need. Any tips?
--
Paulo Jorge Matos - pocmatos at gmail.com
http://www.pmatos.net
Problem initializing volatile structures
I've recently upgraded to GCC 4.3.2 from 4.2.2, and I noticed a strange
change in how volatile bitmask structures are optimized.
Consider the following code:
/* 32-bit MMIO */
struct hardware {
int parm1:8;
int :4;
int parm2:4;
int parm3:15;
int parm4:1;
};
void f1()
{
volatile struct hardware *ptr=(void *)0x11223344;
*ptr=(struct hardware) {
.parm1=42,
.parm2=13,
.parm3=11850,
.parm4=1,
};
}
void f2()
{
volatile struct hardware *ptr=(void *)0x11223344;
struct hardware set={
.parm1=42,
.parm2=13,
.parm3=11850,
.parm4=1,
};
*ptr=set;
}
In GCC 4.3.2, this produces the following assembly:
f1:
movl$0, 287454020
movb$42, 287454020
movl287454020, %eax
andb$15, %ah
orb $208, %ah
movl%eax, 287454020
movl287454020, %eax
andl$-2147418113, %eax
orl $776601600, %eax
movl%eax, 287454020
movl287454020, %eax
orl $-2147483648, %eax
movl%eax, 287454020
ret
f2:
movl$-1370828758, 287454020
ret
Aren't both functions syntactically the same, and shouldn't they produce the
same optimized code as in "f2" above? This used to be the case in GCC 4.2.2.
The problem I'm seeing, apart from the lack of optimization, is that "f1"
causes 5 separate writes to a single MMIO register, instead of 1. This
particular hardware register is only expecting one write to this location, and
when multiple writes are received it causes the hardware to fail.
If this new behavior is intended, is there some sort of attribute I can add to
the code to get the original 4.2.2 behavior back?
Thanks for your comments,
-Byron
Best -march & -mtune flags for XScale-PXA270 rev 7 (v5l)
Hello!
I am play with my Asus P535 phone and can't find best cflags
>asusp535 ~ # cat /proc/cpuinfo
>Processor : XScale-PXA270 rev 7 (v5l)
>BogoMIPS: 519.37
>Features: swp half thumb fastmult edsp iwmmxt
>CPU implementer : 0x69
>CPU architecture: 5TE
>CPU variant : 0x0
>CPU part: 0x411
>CPU revision: 7
>Cache type : undefined 5
>Cache clean : undefined 5
>Cache lockdown : undefined 5
>Cache format: Harvard
>I size : 32768
>I assoc : 32
>I line length : 32
>I sets : 32
>D size : 32768
>D assoc : 32
>D line length : 32
>D sets : 32
>
>Hardware: Asus P535
>Revision:
>Serial :
I have error when i try compile this source
>asusp535 ~ # cat test2.c
>int main(void) { __asm__ volatile ("wunpckelub wr6, wr4"); return 0; }
>
>asusp535 ~ # gcc -march=armv5te -mtune=iwmmxt test2.c -o /dev/null
>/tmp/cc3tFpwv.s: Assembler messages:
>/tmp/cc3tFpwv.s:24: Error: selected processor does not support `wunpckelub
>wr6,wr4'
What cflags and chost is a best for my phone?
Thanks
Re: Possible IRA bug in assign_hard_reg
Ian Bolton wrote: Thanks for the detailed answer. While we're on the subject of assign_hard_reg, I notice the costs and min_cost variable are set but never used (decisions are being made with the full_costs array and min_full_cost). Should they be referenced somehow or are they just redundant? Yes, they are redundant. I worked a lot of time on IRA tuning which resulted in many (small or big) code modifications. I tried to remove all experimental code before submitting IRA but some redundant code went through. As you understand in some experiments min_cost was used instead of min_full_cost. Min_cost might work for some targets because I mostly focused on tuning for mainstream targets x86/x86_64 and powerpc. By the way, I am still working on graph coloring based RA without cover classes. Finally, it might help with your target problems. Unfortunately, I have a performance degradation on mainstream targets for this code in comparison with code using the cover classes. It is a long way to fix the degradations. If I fix it, the code will be part of gcc 4.6.
Re: gccgo language contribution accepted
"Joseph S. Myers" writes: > On Tue, 26 Jan 2010, David Edelsohn wrote: > >> I am pleased to announce that the GCC Steering Committee has >> accepted the contribution of the gccgo front-end and gcc-specific runtime >> for the Go language with Ian Taylor appointed maintainer. The GCC > > What has been decided about copyright assignment requirements? This is the general plan as I understand it. I will separate the gcc-specific parts from the rest of the Go frontend. Those gcc-specific parts will be under the GPL and follow the usual gcc rules. The rest will remain under the BSD-style license, and will move to a different hosting site (probably at code.google.com). I will regularly merge from that other hosting site to the gcc sources, much as we do with classpath and other code today. Changes to that part of the code will take a Google copyright assignment, which can be filled out online. Since Google has a copyright agreement with the FSF, filling out the Google form will free the code to be used with gcc. This will mean that any changes to the gcc frontend interface (such as it is) can be done by any gcc maintainer. It will also permit the non-gcc parts of the Go frontend to remain under a BSD style license. This is subject to change if it seems unworkable or wrong. Ian
Re: Treatment of builtin that receives function pointer
On 01/28/2010 04:01 PM, Paulo J. Matos wrote:
> On Thu, Jan 28, 2010 at 2:58 PM, Andrew Haley wrote:
>>
>> dladdr()
>>
>
> Thanks Andrew but this answer seems to assume I am trying to obtain
> this in a C program from a previously compiled function.
>
> However, I am inside GCC which access to the gimple tree of the function.
Ah, okay. Sorry.
> I found out the problem I was having but not the solution yet.
> My builtin function gets angry when given a function pointer which is
> not (void) (*)(void). As a result, it casts the function.
> So something like:
> void foo(int) { }
> ..
> __mybuiltin(foo);
>
> becomes internally:
> void foo(int) { }
> ..
> (void) (foo.0) (void) = ((void) (*)(void) foo);
> __mybuiltin(foo.0);
>
> This is why I am not being able to get my function name from the tree
> of the builtin function call. I guess I need to parse the tree of the
> current function to find the value of foo.0.
>
> I am however open to suggestions.
You have a tree node of type function pointer, and you want somehow to
convert that into the function decl that the pointer points to.
Obviously in the general case this is quite impossible, but you want
to do enough copy propagation to get the original function decl. This
should be easy enough as long as you don't need to do anything too
complicated.
Andrew.
Question about IRA (setup_allocno_priorities)
Hi again, Thanks for your answer to my other question. I just found a case, where an allocno wasn't getting a register, when I thought it should, since it was referenced 24 times. I looked in setup_allocno_priorities() to see how this was used to determine the priority and found this line: mult = floor_log2 (ALLOCNO_NREFS (a)) + 1; All other things being equal, this means something that is referenced 16 times will get the same priority as something referenced 31 times. I just changed this line to remove the floor_log2 and got better results on my test case. I'm wondering what the origins of the floor_log2 are? You scale everything based on max_priority and INT_MAX later, so I don't see the harm in using the nrefs as the multiplier in the first instance, and I actually think this would be more representative of the impact of an allocno not getting a register. NOTE: I am still using the Priority algorithm because that performs better than CB on our architecture at the moment. Cheers, Ian
Re: Question about IRA (setup_allocno_priorities)
Ian Bolton wrote: Hi again, Thanks for your answer to my other question. I just found a case, where an allocno wasn't getting a register, when I thought it should, since it was referenced 24 times. I looked in setup_allocno_priorities() to see how this was used to determine the priority and found this line: mult = floor_log2 (ALLOCNO_NREFS (a)) + 1; All other things being equal, this means something that is referenced 16 times will get the same priority as something referenced 31 times. I just changed this line to remove the floor_log2 and got better results on my test case. I'm wondering what the origins of the floor_log2 are? You scale everything based on max_priority and INT_MAX later, so I don't see the harm in using the nrefs as the multiplier in the first instance, and I actually think this would be more representative of the impact of an allocno not getting a register. It is originated from the old register allocator. I don't think that just nrefs will work well because it is already reflected in the cost. IMHO, log2 (nrefs) is here for taking code size into account which affects code locality and as a consequence its execution performance. But this is just speculations. Only benchmarking a lot of credible tests will show the truth because all widely used RA algorithms are heuristic ones. I am sure that a lot of people (including me about 7 years ago) checked log2 (nrefs) and nrefs and other priority definitions. NOTE: I am still using the Priority algorithm because that performs better than CB on our architecture at the moment. Ok.
gcc-4.5-20100128 is now available
Snapshot gcc-4.5-20100128 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100128/ 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 156335 You'll find: gcc-4.5-20100128.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20100128.tar.bz2 C front end and core compiler gcc-ada-4.5-20100128.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20100128.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20100128.tar.bz2 C++ front end and runtime gcc-java-4.5-20100128.tar.bz2 Java front end and runtime gcc-objc-4.5-20100128.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20100128.tar.bz2The GCC testsuite Diffs from 4.5-20100121 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.
