Re: Help with reload and naked constant sum causing ICE
2008/5/29 Jeff Law <[EMAIL PROTECTED]>:
> Richard Sandiford wrote:
>>
>> Andy H <[EMAIL PROTECTED]> writes:
If L_R_A does nothing with it,
the normal reload handling will first try:
(const:HI (plus:HI (symbol_ref:HI ("chk_fail_buf") (const_int 2
>>>
>>> This worked just as your described after I added test of
>>> reg_equiv_constant[] inside L_R_A .
>>>
>>> So I guess that looks like the fix for bug I posted.
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34641
>>>
>>> To summarize
>>>
>>> LEGITIMIZE_RELOAD_ADDRESS should now always check reg_equiv_constant
>>> before it trying to do any push_reload of register.
>>
>> TBH, I still think AVR is doing far too much in L_R_A. To quote
>> the current version:
>
> [...]
> Not only should there be some comments, those comments should clearly
> explain how L_R_A is improving the generated code. That is LRA's job, to
> implement target specific reload strategies which improve the generated
> code. If the AVR port is using L_R_A for *correctness*, then the AVR port
> is broken.
I wrote L_R_A for *correctness*, so in your terms AVR port is broken.
It's because AVR have only 3 pointer registers (X,Y,Z) and only 2 of
them Y and Z are base pointers.
Y is a frame pointer, so only one general base pointer - Z.
Offset also very limited -63 to +63.
In L_R_A I play with POINTER_REGS (X,Y,Z) and BASE_POINTER_REGS (Y,Z).
My experiments with reload show me that reload can't handle all
difficult situations.
Also, Jeff I know that you think that reload can.
GCC havn't something like (define_address ...) and reload can't handle
POINTER_REGS and
BASE_POINTER_REGS differently. In my version of L_R_A I tried to do it.
Denis.
Implement #pragma unroll?
Hello, In porting GCC to our VLIW, we would like to implement #pragma unroll to manually specify unrolling factor, hoping to achieve better performance in some cases without changing code itself. As far as I know, #pragma unroll is present in both HPUX aCC and INTEL icc. I examined pragma implementations of some other GCC targets (arm, m32c, etc). It seems that these pragmas are interchangeable with __attribute__, meaning they are attached to either a type or a declaration. But for loop, it is neither a type or a declaration. In fact, when I tracked into GCC, LOOP_EXPR related stuff is never used. Do/while/for loops are lowered to individual statements in parsing stage. At best, I can find a compound statement (statement_list) that represent a loop. Maybe I can invent some attribute for unrolling factor and attach it to the compound statement. But I am not sure whether later optimization (before loop unrolling) will remove or change it. I also need to change many places in the gcc code itself, which is not nice. Is there any better way to do this? Thanks in advance. BTW, I am working on GCC 4.3.0. Is there any future plan for GCC to implement #pragma unroll or provide infrastructure to implement similar #pragma? I can see it will be quite useful for many targets. Cheers, Bingfeng Mei Broadcom UK
Program editor programming c++
Hi I use rhide for programming in c++, but i get errors when i compile the
program. It works in rhide environment but doesn't work when i compile it.
Consider the following example
#include "iostream"
int main(){
printf("olare");
return 0;
}
I get error when compile it with gcc ola.cpp -o ola.exe but it works in
rhide environment.
What's the best option editor for programming in cpp and compile with gcc?
Thank you
--
View this message in context:
http://www.nabble.com/Program-editor-programming-c%2B%2B-tp17532397p17532397.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: Announcement: initial release of a coding rule checker for GCC
2008/5/28 Taras Glek <[EMAIL PROTECTED]>: > Guillem Marpons wrote: >> >> Hello all, >> >> In the context of the GlobalGCC project (http://www.ggcc.info, >> http://gcc.gnu.org/ml/gcc/2006-10/msg00676.html) we are developing a >> facility for automatically enforcing coding rules. >> >> (...) >> >> http://www.ggcc.info/?q=codingrules >> > > In your overview of other available tools you are missing the > Dehydra/Treehydra projects being worked on at Mozilla. I think our work > shares many of the same goals and sounds like there are implementation > similarities. It's great to see that both of us initially focused on C++. I hadn't heard about your project, thanks for the information. Indeed, we've also not mentioned Ada coding rules checking in AdaCore's GNAT Pro, and other (free) tools that I've not tested/compared yet. > There are also some differences. We chose to use an imperative language to > specify our rules. Additionally, we added a plugin interface to GCC to > minimize GCC changes. I'll be presenting at the GCC summit on the work we've > done. This plugin interface sounds interesting, I'd like to have a look at it. We're also trying to be as less intrusive as possible, as this functionality is not to be used by every user, and for sure not in every compilation. > See http://developer.mozilla.org/en/docs/Dehydra (The goals listed on the > web page above describe Dehydra's purpose quite well) and > http://developer.mozilla.org/en/doc/Treehydra > We've done a fair bit of information extraction with Dehydra. I wonder if > Dehydra could output identical prolog information. Generating Prolog facts is usually simple once you've retrieved the necessary information, if you have suitable printing functions for formatting the output. > Would be great if we could pool our efforts together on some level. Sure! I'm looking forward to see your presentation at the Summit! Regards, Guillem
Re: Program editor programming c++
Hi,
On Thu, May 29, 2008 at 03:08:34AM -0700, Lopezio wrote:
> #include "iostream"
> int main(){
> printf("olare");
> return 0;
> }
> I get error when compile it with gcc ola.cpp -o ola.exe but it works in
> rhide environment.
Well, your example is neither valid C-code, nor valid C++-code:
- iostream belongs to C++, and not c
- printf is declared in stdio.h, for C
- you should use #include instead of "iostream". With "", gcc
searches only in the current directory (and in all directories given given as
include directories on command line)
- the filename should end on ".c" instead of ".cpp". ".cpp" is understood as
C++-code by gcc
- If you see nothing in the output: add a newlin "\n" to the printf-command
- If you compile using "gcc", the compiler does not link to the C++-libraries.
use "g++" instead.
If you use (C-version, ola.c)
#include
int main(){
printf("olare\n");
return 0;
}
it should work with gcc ola.c -o ola.exe. This also works with
g++ ola.c -o ola.exe
or as
gc ola.cpp -o ola.exe
if you want
As C++ version, I would propose (in ola.cpp):
#include
int main(){
std::cout << "olare" << std::endl;
}
with
g++ ola.cpp -o ola.exe
The "best" programming environment depends on what you like - I'm using vim
HTH,
Axel
GCC 4.3.1 second Release Candidate available from gcc.gnu.org
A second release candidate for GCC 4.3.1 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.1-RC-20080529 and shortly its mirrors. It has been generated from SVN revision 136151. The branch is still frozen and all checkins until after the final release of GCC 4.3.1 require explicit RM approval. If all goes well this candidate will become the final 4.3.1 release early next week. Thanks, Richard.
Code instrumentation with GCC
Hi, Is there a way to make GCC to instrument every function it compiles with a prologue/epilogue call to a user defined code a la MSVC's _penter and _pexit, e.g.: http://msdn.microsoft.com/en-us/library/c63a9b7h.aspx http://msdn.microsoft.com/en-us/library/xc11y76y.aspx If not, can anyone suggest a place in GCC's source to look at if one was to add such functionality self. Thanks, - NK
Re: Code instrumentation with GCC
On Thu, May 29, 2008 at 2:03 PM, Narech K <[EMAIL PROTECTED]> wrote: > Hi, > > Is there a way to make GCC to instrument every function it compiles with a > prologue/epilogue call to a user defined code a la MSVC's _penter and > _pexit, e.g.: > > http://msdn.microsoft.com/en-us/library/c63a9b7h.aspx > http://msdn.microsoft.com/en-us/library/xc11y76y.aspx > > If not, can anyone suggest a place in GCC's source to look at if one was to > add > such functionality self. Note this is a question for gcc-help. Look for -finstrument-functions in the documentation. Richard.
Re: Code instrumentation with GCC
On Thu, 2008-05-29 12:03:05 +, Narech K <[EMAIL PROTECTED]> wrote: > Is there a way to make GCC to instrument every function it compiles with a > prologue/epilogue call to a user defined code a la MSVC's _penter and > _pexit, e.g.: > > http://msdn.microsoft.com/en-us/library/c63a9b7h.aspx > http://msdn.microsoft.com/en-us/library/xc11y76y.aspx > > If not, can anyone suggest a place in GCC's source to look at if one was to > add > such functionality self. I think that could be done by defining these two functions: void __cyg_profile_func_enter (void *func_address, void *call_site) __attribute__ ((no_instrument_function)); void __cyg_profile_func_exit (void *func_address, void *call_site) __attribute__ ((no_instrument_function)); ...and compile with -finstrument-functions . MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481 Signature of: They that give up essential liberty to obtain temporary safety, the second : deserve neither liberty nor safety. (Ben Franklin) signature.asc Description: Digital signature
Re: Help with reload and naked constant sum causing ICE
Again thank you and Denis for your comment.
Here is what I deduce from code and Denis comments - I am sure he (and
others) will correct me if wrong :-)
The main issue is that we have one pointer register that cannot take
offset and two base pointers with limited offset (0-63).
Reload provides no means to pick the right pointer register. To do so
would require a "preffered base pointer" mechanism.
AVR L_R_A sole purpose is substituting POINTER class where there are
oppertunities to do so.
BUT as L_R_A is in middle of find_reloads_address, we have a problem
in that some normal reload solutions have already been applied and some
have not.
This may mean that 1) We never get here - so miss POINTER oppertunity
or 2) Miss even better solutions that are applied latter.
3)Have code vulnerable to reload changes.
I have added comment below to explain the parts.
I'll probably need to add some debug hooks to check what parts still
contribute.
best regards
Andy
#define LEGITIMIZE_RELOAD_ADDRESS(X, MODE, OPNUM, TYPE, IND_LEVELS,
WIN)\
do {\
if (1&&(GET_CODE (X) == POST_INC || GET_CODE (X) == PRE_DEC)) \
{ \
push_reload (XEXP (X,0), XEXP (X,0), &XEXP (X,0), &XEXP (X,0),
\
POINTER_REGS, GET_MODE (X),GET_MODE (X) , 0, 0, \
OPNUM, RELOAD_OTHER);\
goto WIN; \
} \
The intent is to use POINTER class registers for INC/DEC so we have one
more register available than BASE_POINTER
Has INC/DEC been handled already making this part redundant?
Are there any other solutions that this code skips?
if (GET_CODE (X) == PLUS \
&& REG_P (XEXP (X, 0))\
&& GET_CODE (XEXP (X, 1)) == CONST_INT\
&& INTVAL (XEXP (X, 1)) >= 1) \
{ \
int fit = INTVAL (XEXP (X, 1)) <= (64 - GET_MODE_SIZE (MODE));
\
if (fit) \
{ \
if (reg_equiv_address[REGNO (XEXP (X, 0))] != 0) \
{ \
int regno = REGNO (XEXP (X, 0)); \
rtx mem = make_memloc (X, regno); \
push_reload (XEXP (mem,0), NULL, &XEXP (mem,0), NULL,
\
POINTER_REGS, Pmode, VOIDmode, 0, 0, \
1, ADDR_TYPE (TYPE));\
push_reload (mem, NULL_RTX, &XEXP (X, 0), NULL, \
BASE_POINTER_REGS, GET_MODE (X), VOIDmode, 0, 0, \
OPNUM, TYPE);\
goto WIN; \
}
Im struggling with this part. however, the POINTER class is an
advantageous in the first reloading the address from memory
- where we would not want to waste BASE POINTER and also create overlap
problem.
The implication of using this code is that without it we cannot catch
the inner reload POINTER oppertunity if we leave reload to decompose
BASE+offset. I think this is correct :-(
\
push_reload (XEXP (X, 0), NULL_RTX, &XEXP (X, 0), NULL, \
BASE_POINTER_REGS, GET_MODE (X), VOIDmode, 0, 0, \
OPNUM, TYPE);\
goto WIN;
This part is duplicating reload and should not be here (I have patch
pending with maintainer that removes this - for different bug)
\
} \
else if (! (frame_pointer_needed && XEXP (X,0) ==
frame_pointer_rtx)) \
{ \
push_reload (X, NULL_RTX, &X, NULL, \
POINTER_REGS, GET_MODE (X), VOIDmode, 0, 0, \
OPNUM, TYPE);\
goto WIN; \
} \
} \
This case is where offset is out of range - so we allow POINTER class
on the basis that this is no worse than BASE POINTER. However, we leave
frame_pointer to reload.
} while(0)
-Original Message-
From: Denis Chertykov <[EMAIL PROTECTED]>
To: Jeff Law <[EMAIL PROTECTED]>
Cc: Andy H <[EMAIL PROTECTED]>; GCC Development ;
[EMAIL PROTECTED]
Sent: Thu, 29 May 2008 3:23 am
Subject: Re: Help with reload and naked constant sum causing ICE
2008/5/29 Jeff Law <[EMAIL PROTECTED]>:
Richard Sandiford wrote:
Andy H <[EMAIL PROTECTED]> writes:
If L_R_A does nothing with it,
the normal reload handling will first try:
(const:HI (plus:HI (symbol_ref:HI ("chk_fail_buf") (const_int
2
This worked just as your described after I added test of
reg_equiv_constant[] inside L_R_A .
So I guess t
feature request: new function attribute, "experimental"
http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html
I'd like to suggest a new function attribute, "experimental". Should
work identically to existing function attribute "deprecated", except
with the appropriate warning message. I'm currently using the
function attribute warning ("experimental") for this.
Thanks for your consideration.
-Shane
RE: Implement #pragma unroll?
Dear Bingfeng, Some time ago I had to deal with a similar issue as you. Basically I did as follows: I built a backend function which catches the unroll pragma and replaces it with a target assembly intrinsic (which of course has to be described in an .md file). After that in the RTL unroll phase, I analyze loop by loop and connect them to the corresponding unrolling intrinsic (which as a field contains the unrolling factor, you may add here extra information which allows you to recognize the loop) from where I decide the unrolling factor. After that in the RTL unroll phase I remove all the unroll intrinsics. hope this will help, Alex
Re: Help with reload and naked constant sum causing ICE
2008/5/29 <[EMAIL PROTECTED]>:
> Again thank you and Denis for your comment.
>
> Here is what I deduce from code and Denis comments - I am sure he (and
> others) will correct me if wrong :-)
>
>
> The main issue is that we have one pointer register that cannot take offset
> and two base pointers with limited offset (0-63).
Yes.
Oops I'm sorry. I wrote -63 to +63 in my last mail it's wrong.
The right offset 0 to 63.
>
> Reload provides no means to pick the right pointer register. To do so would
> require a "preffered base pointer" mechanism.
Yes.
>
> AVR L_R_A sole purpose is substituting POINTER class where there are
> oppertunities to do so.
>
> BUT as L_R_A is in middle of find_reloads_address, we have a problem in
> that some normal reload solutions have already been applied and some have
> not.
Yes.
> This may mean that 1) We never get here - so miss POINTER oppertunity or 2)
> Miss even better solutions that are applied latter.
> 3)Have code vulnerable to reload changes.
Yes.
> I have added comment below to explain the parts.
> I'll probably need to add some debug hooks to check what parts still
> contribute.
>
> best regards
>
> Andy
>
>
>
> #define LEGITIMIZE_RELOAD_ADDRESS(X, MODE, OPNUM, TYPE, IND_LEVELS, WIN)
> \
> do {\
> if (1&&(GET_CODE (X) == POST_INC || GET_CODE (X) == PRE_DEC)) \
> { \
> push_reload (XEXP (X,0), XEXP (X,0), &XEXP (X,0), &XEXP (X,0), \
> POINTER_REGS, GET_MODE (X),GET_MODE (X) , 0, 0, \
> OPNUM, RELOAD_OTHER);\
> goto WIN; \
> } \
>
>
> The intent is to use POINTER class registers for INC/DEC so we have one more
> register available than BASE_POINTER
>
> Has INC/DEC been handled already making this part redundant?
> Are there any other solutions that this code skips?
Really, I forgot why this part of L_R_A exists.
Look at strange 'if (1&&'.
I remember that once I have disabled it (add 0&&), but after some
testing I have
enablet it again.
> if (GET_CODE (X) == PLUS \
> && REG_P (XEXP (X, 0))\
> && GET_CODE (XEXP (X, 1)) == CONST_INT\
> && INTVAL (XEXP (X, 1)) >= 1) \
> { \
> int fit = INTVAL (XEXP (X, 1)) <= (64 - GET_MODE_SIZE (MODE)); \
> if (fit) \
> { \
> if (reg_equiv_address[REGNO (XEXP (X, 0))] != 0) \
> { \
> int regno = REGNO (XEXP (X, 0)); \
> rtx mem = make_memloc (X, regno); \
> push_reload (XEXP (mem,0), NULL, &XEXP (mem,0), NULL, \
> POINTER_REGS, Pmode, VOIDmode, 0, 0, \
> 1, ADDR_TYPE (TYPE));\
> push_reload (mem, NULL_RTX, &XEXP (X, 0), NULL, \
> BASE_POINTER_REGS, GET_MODE (X), VOIDmode, 0, 0, \
> OPNUM, TYPE);\
> goto WIN; \
> }
>
> Im struggling with this part. however, the POINTER class is an advantageous
> in the first reloading the address from memory
> - where we would not want to waste BASE POINTER and also create overlap
> problem.
Yes.
> The implication of using this code is that without it we cannot catch the
> inner reload POINTER oppertunity if we leave reload to decompose
> BASE+offset. I think this is correct :-(
>
>
> \
> push_reload (XEXP (X, 0), NULL_RTX, &XEXP (X, 0), NULL, \
> BASE_POINTER_REGS, GET_MODE (X), VOIDmode, 0, 0, \
> OPNUM, TYPE);\
> goto WIN;
>
> This part is duplicating reload and should not be here (I have patch pending
> with maintainer that removes this - for different bug)
>
> \
> } \
> else if (! (frame_pointer_needed && XEXP (X,0) == frame_pointer_rtx)) \
> { \
> push_reload (X, NULL_RTX, &X, NULL, \
> POINTER_REGS, GET_MODE (X), VOIDmode, 0, 0, \
> OPNUM, TYPE);\
> goto WIN; \
> } \
> } \
>
> This case is where offset is out of range
and we must reload not-the-frame_pointer.
The frame_pointer can be handled by reload more optimal because we have
Z register (Z+offset).
> - so we allow POINTER class on the
> basis that this is no worse than BASE POINTER. However, we leave
> frame_pointer to reload.
Because reload-pass can reload frame_pointer+big_offset because we have
anower one
Re: Program editor programming c++
Hi
Thank you for your help.I'm a beginer on cpp. I'm programming in windows/dos
mode and i get error when i compile the program
#include
int main(){
std::cout << "olare" << std::endl;
}
I get error when i compile the program with gcc ola.cpp -o ola.exe
Can you help me?
Thank you
Axel Freyn wrote:
>
> Hi,
> On Thu, May 29, 2008 at 03:08:34AM -0700, Lopezio wrote:
>> #include "iostream"
>> int main(){
>> printf("olare");
>> return 0;
>> }
>> I get error when compile it with gcc ola.cpp -o ola.exe but it works in
>> rhide environment.
> Well, your example is neither valid C-code, nor valid C++-code:
> - iostream belongs to C++, and not c
> - printf is declared in stdio.h, for C
> - you should use #include instead of "iostream". With "", gcc
>searches only in the current directory (and in all directories given
> given as
>include directories on command line)
> - the filename should end on ".c" instead of ".cpp". ".cpp" is understood
> as
>C++-code by gcc
> - If you see nothing in the output: add a newlin "\n" to the
> printf-command
> - If you compile using "gcc", the compiler does not link to the
> C++-libraries.
>use "g++" instead.
>
> If you use (C-version, ola.c)
> #include
> int main(){
> printf("olare\n");
> return 0;
> }
> it should work with gcc ola.c -o ola.exe. This also works with
> g++ ola.c -o ola.exe
> or as
> gc ola.cpp -o ola.exe
> if you want
>
> As C++ version, I would propose (in ola.cpp):
> #include
> int main(){
> std::cout << "olare" << std::endl;
> }
> with
> g++ ola.cpp -o ola.exe
>
>
> The "best" programming environment depends on what you like - I'm using
> vim
>
> HTH,
>
> Axel
>
>
>
>
>
--
View this message in context:
http://www.nabble.com/Program-editor-programming-c%2B%2B-tp17532397p17545760.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: Program editor programming c++
On Thu, 2008-05-29 14:04:24 -0700, Lopezio <[EMAIL PROTECTED]> wrote:
> Thank you for your help.I'm a beginer on cpp. I'm programming in windows/dos
> mode and i get error when i compile the program
> #include
> int main(){
> std::cout << "olare" << std::endl;
> }
> I get error when i compile the program with gcc ola.cpp -o ola.exe
> Can you help me?
It would have helped if you had the error message included...
But I know what's missing. Remember what was said? The gcc compiler
(being a C compiler that's capable of recognizing and compiling C++
sources) won't include libstdc++ in the linker run. So either add that:
gcc foo.cpp -lstdc++
...or use g++ to compile and link.
MfG, JBG
--
Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481
Signature of: Ich hatte in letzter Zeit ein bißchen viel Realitycheck.
the second : Langsam möchte ich mal wieder weiterträumen können.
-- Maximilian Wilhelm (18. Mai 2006, #lug-owl.de)
signature.asc
Description: Digital signature
Re: Program editor programming c++
On Thu, May 29, 2008 at 02:04:24PM -0700, Lopezio wrote:
> Hi
> Thank you for your help.I'm a beginer on cpp. I'm programming in windows/dos
> mode and i get error when i compile the program
> #include
> int main(){
> std::cout << "olare" << std::endl;
> }
> I get error when i compile the program with gcc ola.cpp -o ola.exe
> Can you help me?
This list is where the developers of gcc communicate; it is not for
user questions. Please use gcc-help. And on that list, please don't
say "I get error". Include the exact error message that you got.
Re: Program editor programming c++
Thank you guys
g++ solved my problem
Jan-Benedict Glaw wrote:
>
> On Thu, 2008-05-29 14:04:24 -0700, Lopezio <[EMAIL PROTECTED]> wrote:
>> Thank you for your help.I'm a beginer on cpp. I'm programming in
>> windows/dos
>> mode and i get error when i compile the program
>> #include
>> int main(){
>> std::cout << "olare" << std::endl;
>> }
>> I get error when i compile the program with gcc ola.cpp -o ola.exe
>> Can you help me?
>
> It would have helped if you had the error message included...
>
> But I know what's missing. Remember what was said? The gcc compiler
> (being a C compiler that's capable of recognizing and compiling C++
> sources) won't include libstdc++ in the linker run. So either add that:
>
> gcc foo.cpp -lstdc++
>
> ...or use g++ to compile and link.
>
> MfG, JBG
>
> --
> Jan-Benedict Glaw [EMAIL PROTECTED]
> +49-172-7608481
> Signature of: Ich hatte in letzter Zeit ein bißchen viel
> Realitycheck.
> the second : Langsam möchte ich mal wieder weiterträumen
> können.
> -- Maximilian Wilhelm (18. Mai 2006,
> #lug-owl.de)
>
>
>
--
View this message in context:
http://www.nabble.com/Program-editor-programming-c%2B%2B-tp17532397p17546848.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
gcc-4.3-20080529 is now available
Snapshot gcc-4.3-20080529 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080529/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 136189 You'll find: gcc-4.3-20080529.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20080529.tar.bz2 C front end and core compiler gcc-ada-4.3-20080529.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20080529.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20080529.tar.bz2 C++ front end and runtime gcc-java-4.3-20080529.tar.bz2 Java front end and runtime gcc-objc-4.3-20080529.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20080529.tar.bz2The GCC testsuite Diffs from 4.3-20080522 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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: Implement #pragma unroll?
Alex, Thanks for your suggestion. What target hook do you use for the backend function? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Turjan Sent: 29 May 2008 14:45 To: gcc@gcc.gnu.org Subject: RE: Implement #pragma unroll? Dear Bingfeng, Some time ago I had to deal with a similar issue as you. Basically I did as follows: I built a backend function which catches the unroll pragma and replaces it with a target assembly intrinsic (which of course has to be described in an .md file). After that in the RTL unroll phase, I analyze loop by loop and connect them to the corresponding unrolling intrinsic (which as a field contains the unrolling factor, you may add here extra information which allows you to recognize the loop) from where I decide the unrolling factor. After that in the RTL unroll phase I remove all the unroll intrinsics. hope this will help, Alex
Re: GCC 4.1 snapshots
On Wed, 28 May 2008, Joe Buck wrote: > On Wed, May 28, 2008 at 08:15:20PM +0200, Richard Guenther wrote: > > On Wed, May 28, 2008 at 7:13 PM, Joe Buck <[EMAIL PROTECTED]> wrote: > > > On Tue, May 27, 2008 at 09:11:18PM -0400, NightStrike wrote: > > >> On 5/27/08, Joe Buck <[EMAIL PROTECTED]> wrote: > > >> > A third alternative is to issue a snapshot (at whatever time interval > > >> > is chosen) iff there's been a checkin on the branch. > > >> > > >> I thought that's how it worked already. > > > > > > No, a new 4.1 snapshot was created May 26, even though the last checkin > > > was April 8. > > > > That's because the tree is still daily updated with the DATESTAMP changes. > > Ah. Then the DATESTAMP change shouldn't happen if there is no > modification to the branch since the last DATESTAMP. The snapshots know nothing of whether there were any changes on the branch at all. I'd rather just close the branch (disable the update of DATESTAMP, disable snapshots, close bugs only open as 4.1 regressions after updating the milestones to indicate where they were fixed, switch other bugs marked as 4.1 regressions to more recent milestones and remove "4.1/" from their summaries) than add extra complexity for the sake of a dead branch. -- Joseph S. Myers [EMAIL PROTECTED]
Re: GCC 4.1 snapshots
On Wed, 28 May 2008, Joe Buck wrote: > > Ah. Then the DATESTAMP change shouldn't happen if there is no > > modification to the branch since the last DATESTAMP. On Thu, May 29, 2008 at 11:48:31PM +, Joseph S. Myers wrote: > The snapshots know nothing of whether there were any changes on the branch > at all. > > I'd rather just close the branch (disable the update of DATESTAMP, disable > snapshots, close bugs only open as 4.1 regressions after updating the > milestones to indicate where they were fixed, switch other bugs marked as > 4.1 regressions to more recent milestones and remove "4.1/" from their > summaries) than add extra complexity for the sake of a dead branch. I does seem like a lot of work for little gain. Suggestion withdrawn. I did a search (summary contains all of the strings in "4.1 regression", summary does not contain the string "4.2"), and got 103 bugs. Assuming that they are all marked correctly, these would all close.
Graphical representation of data structures
Hi,
I am not sure if this is the appropriate list for the question but
I have tried, without success, to find a tool to accomplish the
following:
"I am trying to understand a large project written in C and I am
looking for a tool that takes all the .h and .cpp file and build a
graphical (or even textual) representations of all the data structure
used in the code and the cross links between them (resolving all data
structure to the basic C data types)"
For e.g for
typedef struct a {
int i;
B dataB;
} A;
typedef struct b {
int k;
int m;
} B;
It would generate something like
|--|
| i |
| dataB | ---> |--|
---| k|
| m |
--
Any pointers to any such tool or library/modules to implement one
would be very helpful.
Thanks,
Sumit
