Re: Moving statements from one BB to other BB.
Hi,
Consider the 2 for loops given below.
for (i = 0; i < N ; i++)
{
a[i]= 1;
}
for (i = 0; i < N ; i++)
{
j = j+a[i];
}
The headers of these 2 loops are bb_3, bb_6 respectively. They are as follows.
bb_3 (preds = {bb_4 bb_2 }, succs = {bb_4 bb_5 })
{
:
# a_27 = PHI
# i_24 = PHI
# a_18 = VDEF { a }
a[i_24] = 1;
i_7 = i_24 + 1;
if (i_7 <= 999)
goto ;
else
goto ;
}
bb_6 (preds = {bb_5 bb_7 }, succs = {bb_7 bb_8 })
{
:
# j_26 = PHI <0(5), j_12(7)>
# i_25 = PHI <0(5), i_13(7)>
# VUSE { a }
D.1189_10 = a[i_25];
D.1190_11 = (unsigned int) D.1189_10;
j_12 = D.1190_11 + j_26;
i_13 = i_25 + 1;
if (i_13 <= 999)
goto ;
else
goto ;
}
I am transfering statements from bb_6 to bb_3 using code -
for (bsi = bsi_start (loop_a->header); !bsi_end_p (bsi);)
{
if ((TREE_CODE (bsi_stmt (bsi)) != LABEL_EXPR) && (TREE_CODE
(bsi_stmt (bsi)) != COND_EXPR))
{
bsi_move_before (&bsi, &bsi_b_last);
}
else
{
bsi_next (&bsi);
}
}
After this the two BBs look like -
bb_6 (preds = {bb_5 bb_7 }, succs = {bb_7 bb_8 })
{
:
# j_26 = PHI <0(5), j_12(7)>
# i_25 = PHI <0(5), i_13(7)>
if (i_13 <= 999)
goto ;
else
goto ;
}
bb_3 (preds = {bb_4 bb_2 }, succs = {bb_4 bb_5 })
{
:
# a_27 = PHI
# i_24 = PHI
# a_18 = VDEF { a }
a[i_24] = 1;
# VUSE { a }
D.1189_10 = a[i_25];
D.1190_11 = (unsigned int) D.1189_10;
j_12 = D.1190_11 + j_26;
i_13 = i_25 + 1;
i_7 = i_24 + 1;
if (i_7 <= 999)
goto ;
else
goto ;
}
The iterator variables for the 2 loops are i_24, i_25 respectively. So
when the statements are transferred, there is a problem with i_25 in
bb_3 . How can I change the name of i_25 to i_24 ?
Thanks,
Sandeep.
Re: [tuples] Branch status and merge scenarios
On Thu, Apr 17, 2008 at 05:58:26PM -0700, Diego Novillo wrote: > So, I see a couple different scenarios that we may want to consider: > > 1- Push back and tell us to come back at the next stage 1. This is >certainly the easiest for everyone else, and will create a few >challenges for us on the LTO branch. > > 2- Once bootstrap is working for the major languages and targets, merge >and finish fixing remaining passes during stage 2. Pass conversion >is highly mechanical, so I don't consider it risky for stage 2 >stabilization. We will be at this point in the 5-7 weeks I mentioned >earlier. 3- Delay the end of stage 1 till mid June or so. I don't see the need to rush out with 4.4 release, when it would have only limited advantages over 4.3 to offer. Having IRA, Tuples, OpenMP3 (what other branches might be mergeable by the GCC Summit time?) all in 4.4 is IMHO worth goal. We could then shorten stage2, or delay the expected 4.4. release date (the length of stage4 is always unclear anyway). The current OpenMP3 status is that most of the support is there, with the major missing part is real unstubbed tasking support in libgomp (already started, but could take 2-3 weeks), and more importantly the OpenMP 3.0 standard not released yet (I'm still hoping they can release it in the spring as originally written somewhere, but no guarantees). To resolve the Tuples vs. OpenMP3 conflicts before the standard is released, there is an option to merge the gomp-3_0-branch to the trunk early (say in a month) and just disallow new OpenMP 3.0 constructs in the frontends and reenable them only when the standard is released, or create a separate branch for tuples + OpenMP3 where I could work together with Aldy on tuplifying the OpenMP3 additions. Or OpenMP3 stuff can be made optional, turned on with a separate option similarly to how G++ supports -std=c++0x, and mark the -fopenmp3 support experimental. Jakub
Assert failed in purge_dead_edges in cfgrtl.c
Hi, I have some problems with an assert in purge_dead_edges in cfgrtl.c:2319. I use gcc version 4.2.2. and I add a new function to the callgraph with cgraph_add_new_function. My new function body is obtained by current_function body using move_sese_region_to_fn and all seems go well but when the new function is processed to obtain rtl, I have an assertion failed. So, this is the cfg dump that I obtain in my pass for the new function and I'm not be able to find the error. Basic block 2 (new, reachable) Predecessors: ENTRY [100.0%] (fallthru,exec) Successors: 3 [100.0%] (fallthru,exec) Basic block 3 (new, reachable) Predecessors: 8 [100.0%] (fallthru) 2 [100.0%] (fallthru,exec) Successors: 4 [100.0%] (fallthru,exec) Basic block 4 (new, reachable) Predecessors: 3 [100.0%] (fallthru,exec) 7 [100.0%] (fallthru) Successors: 7 [89.0%] (dfs_back,true,exec) 5 [11.0%] (loop_exit,false,exec) Basic block 7 (new) Predecessors: 4 [89.0%] (dfs_back,true,exec) Successors: 4 [100.0%] (fallthru) Basic block 5 (new, reachable) Predecessors: 4 [11.0%] (loop_exit,false,exec) Successors: 8 [89.0%] (dfs_back,true,exec) 6 [11.0%] (loop_exit,false,exec) Basic block 8 (new) Predecessors: 5 [89.0%] (dfs_back,true,exec) Successors: 3 [100.0%] (fallthru) Basic block 6 (new, reachable) Predecessors: 5 [11.0%] (loop_exit,false,exec) Successors: EXIT [100.0%] The dump of wrong basic block is ( unfortunately it doesn't have a successor ) ;;basic block 6, loop depth 0, count 0 ;;prev block 5, next block 8 ;;pred: 5 [11.0%] (fallthru,loop_exit) ;;succ: ;;Registers live at start: (nil) (code_label 66 65 67 6 8 "" [0 uses]) (note 67 66 68 6 [bb 6] NOTE_INSN_BASIC_BLOCK) ;;Registers live at end: (nil) What am I doing wrong? Regards, Mario Fanelli
Re: Moving statements from one BB to other BB.
On Fri, Apr 18, 2008 at 9:34 AM, Sandeep Maram <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Consider the 2 for loops given below.
>
> for (i = 0; i < N ; i++)
> {
> a[i]= 1;
> }
>
> for (i = 0; i < N ; i++)
> {
> j = j+a[i];
> }
>
> The headers of these 2 loops are bb_3, bb_6 respectively. They are as
> follows.
>
> bb_3 (preds = {bb_4 bb_2 }, succs = {bb_4 bb_5 })
> {
> :
> # a_27 = PHI
> # i_24 = PHI
> # a_18 = VDEF { a }
> a[i_24] = 1;
> i_7 = i_24 + 1;
> if (i_7 <= 999)
> goto ;
> else
> goto ;
>
> }
>
> bb_6 (preds = {bb_5 bb_7 }, succs = {bb_7 bb_8 })
> {
> :
> # j_26 = PHI <0(5), j_12(7)>
> # i_25 = PHI <0(5), i_13(7)>
> # VUSE { a }
>
> D.1189_10 = a[i_25];
> D.1190_11 = (unsigned int) D.1189_10;
> j_12 = D.1190_11 + j_26;
> i_13 = i_25 + 1;
> if (i_13 <= 999)
> goto ;
> else
> goto ;
>
> }
>
> I am transfering statements from bb_6 to bb_3 using code -
>
> for (bsi = bsi_start (loop_a->header); !bsi_end_p (bsi);)
> {
> if ((TREE_CODE (bsi_stmt (bsi)) != LABEL_EXPR) && (TREE_CODE
> (bsi_stmt (bsi)) != COND_EXPR))
>{
> bsi_move_before (&bsi, &bsi_b_last);
>}
> else
>{
> bsi_next (&bsi);
>}
> }
>
> After this the two BBs look like -
>
> bb_6 (preds = {bb_5 bb_7 }, succs = {bb_7 bb_8 })
> {
> :
> # j_26 = PHI <0(5), j_12(7)>
> # i_25 = PHI <0(5), i_13(7)>
> if (i_13 <= 999)
> goto ;
> else
> goto ;
>
> }
>
> bb_3 (preds = {bb_4 bb_2 }, succs = {bb_4 bb_5 })
> {
> :
> # a_27 = PHI
> # i_24 = PHI
> # a_18 = VDEF { a }
> a[i_24] = 1;
> # VUSE { a }
>
> D.1189_10 = a[i_25];
> D.1190_11 = (unsigned int) D.1189_10;
> j_12 = D.1190_11 + j_26;
> i_13 = i_25 + 1;
> i_7 = i_24 + 1;
> if (i_7 <= 999)
> goto ;
> else
> goto ;
>
> }
>
> The iterator variables for the 2 loops are i_24, i_25 respectively. So
> when the statements are transferred, there is a problem with i_25 in
> bb_3 . How can I change the name of i_25 to i_24 ?
You can for example add a copy instruction
i_25 = i_24
at the top of the new loop (but you have to remove the existing definition
for i_25 in the old loop then). Otherwise you can change and walk
operands of trees using the immediate use iterators and SET_USE.
Just grep for it and you'll find example uses.
Richard.
Re: Official GCC git repository
> "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes: Daniel> I put my version of the gcc conversion (which has all branches Daniel> but no tags) at git://gcc.gnu.org/git/gcc.git and set a script Daniel> up to update it appropriately. Daniel, how is the GIT repository synced? Is there a hook which updates it after a svn commit? I'm about to switch from infradead to gcc.gnu.org, and I want to make sure that the latter is synced at least as frequently as the former before I do that. Sam -- Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/
RE: Uncessary long long produced in tree-ssa?
Ian, Thanks. My pointer type is 32-bit. But when I tried the ARM target, GCC 4.3.0 does produce simpler code. It is likely my porting has some issue. Bingfneg -Original Message- From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] Sent: 17 April 2008 18:31 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Uncessary long long produced in tree-ssa? "Bingfeng Mei" <[EMAIL PROTECTED]> writes: > I noticed in some cases GCC 4.3.0 produces unnecessary long long data > type in tree ssa form. It results in inefficient 64-bit arithmetic in > our porting. You neglected to mention the target. I assume that pointers are 64-bits. Otherwise this behaviour is inexplicable. With 64-bit pointers, you need 64-bit arithmetic. gcc thinks it is being clever by using an induction variable of the right type, rather than sign extending the variable in the middle of the loop. That may be the wrong choice for your target. In general gcc is not well optimized for cases where pointers are larger than the ordinary register size. If pointers are not 64-bits, then I have no idea what is going on. Ian
Re: protect label from being optimized
> Kunal Parmar <[EMAIL PROTECTED]> writes: > > > Is this correct : > >ret_label = gen_label_rtx (); > >emit_move_insn (gen_rtx_REG (HImode, 7), > >gen_rtx_LABEL_REF (VOIDmode, > > ret_label)); > >emit_call_insn (gen_brc_call_simulate (addr, args_size)); > >emit_label (ret_label); Ian Lance Taylor: > It looks plausible. It looks like a mis-optimization waiting to happen. Nothing tells the compiler that it can't move an instruction bewteen the call and the label. You are better off generating the label or immediately emitting the assembly for the label when you emit the assembly code for the call.
Re: Official GCC git repository
On Fri, Apr 18, 2008 at 6:31 AM, Samuel Tardieu <[EMAIL PROTECTED]> wrote: > > "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes: > > Daniel> I put my version of the gcc conversion (which has all branches > Daniel> but no tags) at git://gcc.gnu.org/git/gcc.git and set a script > Daniel> up to update it appropriately. > > Daniel, > > how is the GIT repository synced? Is there a hook which updates it > after a svn commit? No. It is synced every 30 minutes. > > I'm about to switch from infradead to gcc.gnu.org, and I want to make > sure that the latter is synced at least as frequently as the former > before I do that. I have strong doubts that whether it is synced every commit or every 30 minutes seriously affects your development.
Re: Official GCC git repository
On 18/04, Daniel Berlin wrote: | > how is the GIT repository synced? Is there a hook which updates it | > after a svn commit? | | No. | It is synced every 30 minutes. | | > | > I'm about to switch from infradead to gcc.gnu.org, and I want to make | > sure that the latter is synced at least as frequently as the former | > before I do that. | | I have strong doubts that whether it is synced every commit or every | 30 minutes seriously affects your development. Where did I wrote that it would "seriously affect my development"? However, having it synced periodically rather than after every commit is an annoyance. For example, when I see an interesting commit, I sometimes want to look at it once installed in the sources; the easiest solution is to refresh my git repository and look at it. If it's not there yet, it's an annoyance. When one of my patches get approved, before committing it, I rebase it on the latest sources and put it at the bottom of my patch stack and checks that it at least still compiles cleanly. If git is not in sync, it's an annoyance. When I commit one of my patches, I remove it from my git patch stack and rebase other patches on top of the upstream git repository, which should now include the patch I just checked in. If git is not in sync, I have to either leave for up to 30 minutes with one patch missing, or I have to wait for up to 30 minutes before I can remove the original from my tree. It's an annoyance. As you see, no, it doesn't "seriously affect my development", it just makes it less practical and, more importantly from my point of view, less fun. Especially when there are no obstacles to making it be more practical but a one-time setup. So having git refresh itself after a SVN commit would be great :)
Re: http://gcc.gnu.org/onlinedocs/libstdc++/ needs a bit of help
> I've moved ext/pb_assoc now. Looking in the libstdc++ directory, > there are a couple of further files/directories I'm not sure about: > > -rw-r--r-- 1 bkoz gcc 1862 Feb 12 20:27 bk02.html > -rw-r--r-- 1 gccadmin gcc724 Apr 12 00:55 bk02.html.gz > -rw-r--r-- 1 bkoz gcc 1821 Feb 12 20:27 bk03.html > -rw-r--r-- 1 gccadmin gcc717 Apr 12 00:55 bk03.html.gz > drwxr-sr-x 2 bkoz gcc 114688 Feb 13 21:39 these are new, and part of the auto-generated html from the docbook xml files. They should stay. > libstdc++-html.20080213 drwxr-sr-x 2 bkoz gcc 258048 Mar 26 > 06:05 libstdc++-html.20080326 drwxr-sr-x 2 bkoz gcc 237568 Jan > 18 06:49 libstdc++-html-USERS-20080118 These are just the latest doxygen files, ie things that the "latest-doxgen" symlink finds. We really only need what's current (ie, 20080326). (I was keeping some of the older ones around because sometimes output changes depending on doxygen version, and I wanted a quick way to check. However, the 20080328 version is correct.) > As part of addressing the second issue, I will commit the patch below > in a minute which adjust our internal links as well as redirecting all > external ones and bookmarks. Thanks! -benjamin
Re: http://gcc.gnu.org/onlinedocs/libstdc++/ needs a bit of help
> Some changes I have committed already or plan to commit shortly, but > there are some where I'd appreciate some help. Sure. > As a consequence of the restructuring of the libstdc++ documentation, > the following prominent links are broken. Do you have current > replacements for these? > > http://gcc.gnu.org/onlinedocs/libstdc++/parallel_mode.html > http://gcc.gnu.org/onlinedocs/libstdc++/ext/parallel_mode.html http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode.html > http://gcc.gnu.org/onlinedocs/libstdc++/ext/tr1.html http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch01.html#manual.intro.status.standard.tr1 Sadly, this link is pretty weak compared to the old one's simplicity. Instead, I wanted this URL: http://gcc.gnu.org/onlinedocs/libstdc++/manual/status_cxxtr1.html (see doc/xml/manual/status_cxxtr1.xml's markup. I don't know why this is not working, probably due to the type of document (sec2)?) -benjamin
Re: Official GCC git repository
On Fri, Apr 18, 2008 at 12:15 PM, Samuel Tardieu <[EMAIL PROTECTED]> wrote: > On 18/04, Daniel Berlin wrote: > > | > how is the GIT repository synced? Is there a hook which updates it > | > after a svn commit? > | > | No. > | It is synced every 30 minutes. > | > | > > | > I'm about to switch from infradead to gcc.gnu.org, and I want to make > | > sure that the latter is synced at least as frequently as the former > | > before I do that. > | > | I have strong doubts that whether it is synced every commit or every > | 30 minutes seriously affects your development. > > Where did I wrote that it would "seriously affect my development"? Then who cares whether it is synced instantaneously or not? > > However, having it synced periodically rather than after every commit is > an annoyance. True, but it won't change anytime soon because it would place more load, and require more locking (since there is no guarantee a git sync will finish before the next commit occurs). > So having git refresh itself after a SVN commit would be great :) Again, not gonna happen anytime soon. Sorry.
Re: Official GCC git repository
On 18/04, Daniel Berlin wrote: | > However, having it synced periodically rather than after every commit is | > an annoyance. | | True, but it won't change anytime soon because it would place more | load, and require more locking (since there is no guarantee a git sync | will finish before the next commit occurs). More load? Come on, you are doing 48 "svn update" a day right now by syncing every 30 minutes without even knowing if a commit took place or not. What I am proposing would make one "svn update" per svn commit. Hardly more load, probably even less. As far as locking is concerned, I was thinking of a procmail script catching mail received from gcc-cvs and doing something like: :0:/tmp/svn2git * ^To: [EMAIL PROTECTED] | (cd /to/git/repo && git svn fetch) This is not hard to do, put an equivalent or a lighter strain on the svn server, gives a much better synchronized repository and takes care of the locking. And if you want to make sure that you don't have more than one svn update per minute in case something goes wrong, adding a "sleep 60" between the parentheses won't change the number of "svn update" done by this procmail script but will at least space them in time. | > So having git refresh itself after a SVN commit would be great :) | | Again, not gonna happen anytime soon. | Sorry. I know that you don't like git, but I was happy to see that you volunteered anyway to setup the GIT repository when the person who was supposed to do it became MIA. But now that you have done the hard part, I don't understand why you explicitly refuse to do the small part which is needed to make the GIT repository that you populated easy and pleasant to use. If it is because you don't have time to do it, I am volunteering to finish the setup, make it ready for wide use, and setup what is necessary to keep it up-to-date, just send me the required credentials so that I can take care of it. Sam
Adding knowledge of the int_fastN_t types to the compiler, take 2
Hi all, I've tried to take into account the remarks from Joseph and Ian, here's an updated patch. I welcome comments, ideas on how to best add testcases in the testsuite (for example, comparing Fortran information and C headers). After that, I will submit the complete patch + testcases + doc + ChangeLog entries for formal review. Thanks, FX PS: though this is a first step towards implementing a fallback stdint.h header file for targets that don't have one, I don't plan to do this work; having them available to Fortran is what I am interested in :) intfast-2.diff Description: Binary data -- François-Xavier Coudert http://www.homepages.ucl.ac.uk/~uccafco/
Re: Adding knowledge of the int_fastN_t types to the compiler, take 2
On Fri, 18 Apr 2008, FX wrote: > I've tried to take into account the remarks from Joseph and Ian, here's an > updated patch. I welcome comments, ideas on how to best add testcases in the > testsuite (for example, comparing Fortran information and C headers). After > that, I will submit the complete patch + testcases + doc + ChangeLog entries > for formal review. Defining these types with preprocessor conditionals such as +#elif LONG_TYPE_SIZE >= 8 is simply wrong. LONG_TYPE_SIZE is not a preprocessor constant. You need to use conditional expressions with ? : instead to produce an expression that evaluates when the compiler is run to different strings based on compiler options. (If for a particular target LONG_TYPE_SIZE etc. are in fact constants, of course this conditional expression will get constant-folded.) Also, I think the conclusion was that the compiler should not claim any knowledge of these types unless specifically configured for a particular target - that is, defaults.h should not contain any default definitions. -- Joseph S. Myers [EMAIL PROTECTED]
GNAT Breakage on Trunk
Hi, I was trying to update and test since there was another flurry of Ada commits. Compiling for sparc-rtems which has previously had good test results, I got this: /home/joel/work-gnat/svn/b-gcc2-sparc/./gcc/xgcc -B/home/joel/work-gnat/svn/b-gcc2-sparc/./gcc/ -nostdinc -B/home/joel/work-gnat/svn/b-gcc2-sparc/sparc-rtems4.9/newlib/ -isystem /home/joel/work-gnat/svn/b-gcc2-sparc/sparc-rtems4.9/newlib/targ-include -isystem /home/joel/work-gnat/svn/gcc/newlib/libc/include -B/home/joel/work-gnat/svn//install/sparc-rtems4.9/bin/ -B/home/joel/work-gnat/svn//install/sparc-rtems4.9/lib/ -isystem /home/joel/work-gnat/svn//install/sparc-rtems4.9/include -isystem /home/joel/work-gnat/svn//install/sparc-rtems4.9/sys-include -c -g -O2 -W -Wall -gnatpg a-strunb.adb -o a-strunb.o a-strunb.ads: In function 'Ada.Strings.Unbounded.Unbounded_Stringip': a-strunb.ads:394: error: non-trivial conversion at assignment const struct string___XUB * struct string___XUB * _init->reference.P_BOUNDS = &ada__strings__unbounded__null_string.F.BOUNDS +===GNAT BUG DETECTED======+ | 4.4.0 20080418 (experimental) (sparc-unknown-rtems4.9) GCC error:| | verify_gimple failed | | Error detected around a-strunb.ads:394 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: GNAT Breakage on Trunk
Joel Sherrill <[EMAIL PROTECTED]> writes: > a-strunb.ads: In function 'Ada.Strings.Unbounded.Unbounded_Stringip': > a-strunb.ads:394: error: non-trivial conversion at assignment > const struct string___XUB * > struct string___XUB * > _init->reference.P_BOUNDS = &ada__strings__unbounded__null_string.F.BOUNDS > +===GNAT BUG DETECTED==+ > | 4.4.0 20080418 (experimental) (sparc-unknown-rtems4.9) GCC error:| > | verify_gimple failed | That appears to be caused by this change: 2008-04-17 Eric Botcazou <[EMAIL PROTECTED]> * decl.c (gnat_to_gnu_entity) : Promote the alignment of objects by default. * fe.h (Debug_Flag_Dot_A): Delete. * debug.adb (-gnatd.a): Update documentation. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Official GCC git repository
On Fri, Apr 18, 2008 at 1:40 PM, Samuel Tardieu <[EMAIL PROTECTED]> wrote: > On 18/04, Daniel Berlin wrote: > > > | > However, having it synced periodically rather than after every commit is > | > an annoyance. > | > | True, but it won't change anytime soon because it would place more > | load, and require more locking (since there is no guarantee a git sync > | will finish before the next commit occurs). > > More load? Come on, you are doing 48 "svn update" a day right now by > syncing every 30 minutes without even knowing if a commit took place or > not. What I am proposing would make one "svn update" per svn commit. I know you think this is personal, as per your email below, but it really isn't. I had it set up to do it after every commit, and it drove our load average up a noticeable amount. As such, I stopped doing it and set it to run every 30 minutes. > I know that you don't like git, but I was happy to see that you volunteered > anyway to setup the GIT repository when the person who was supposed to > do it became MIA. But now that you have done the hard part, I don't > understand why you explicitly refuse to do the small part which is > needed to make the GIT repository that you populated easy and pleasant > to use. I'm not sure why you think this is some personal vendetta I have. I tried what you ask, it causes noticeably more load, so i stopped doing it. I can't see how only being updated every 30 minutes is somehow "less easy and pleasant to use". This is the price you pay for not being the main version control system. The same is true of the mercurial mirror, it is only updated every 30 minutes. I have not discriminated against git in any way, shape or form, and in fact had tried what you suggest before moving to this model. FWIW, if the git repo or the mercurial repo started seriously driving up the load average of the server, we would turn them off, because neither is the main version control system of gcc. This is just the price you pay for not being the official repo. --Dan
Re: protect label from being optimized
Kunal Parmar wrote: >> But my return label is getting optimized away. Could you please tell >> me how to avoid this. You may also need to add a (USE (REG RA)) to the call pattern. Gcc will see that you set a register to the value of the return label, but it won't see any code that uses that register, so it will optimize away both the load and the label. To prevent this, you need to add an explicit use of that register to the call insn pattern. Jim
Re: Official GCC git repository
On 18/04, Daniel Berlin wrote: | I know you think this is personal, as per your email below, but it really isn't. | I had it set up to do it after every commit, and it drove our load | average up a noticeable amount. | As such, I stopped doing it and set it to run every 30 minutes. | | > I know that you don't like git, but I was happy to see that you volunteered | > anyway to setup the GIT repository when the person who was supposed to | > do it became MIA. But now that you have done the hard part, I don't | > understand why you explicitly refuse to do the small part which is | > needed to make the GIT repository that you populated easy and pleasant | > to use. | | I'm not sure why you think this is some personal vendetta I have. | I tried what you ask, it causes noticeably more load, so i stopped doing it. I don't think this is personal at all, on the contrary: you stated publicly that GIT is not your SCM of choice, which is of course perfectly right, and you set it up anyway, so I don't think you have a personal vendetta running against git :) | I can't see how only being updated every 30 minutes is somehow "less | easy and pleasant to use". | This is the price you pay for not being the main version control system. | The same is true of the mercurial mirror, it is only updated every 30 minutes. | I have not discriminated against git in any way, shape or form, and in | fact had tried what you suggest before moving to this model. | | FWIW, if the git repo or the mercurial repo started seriously driving | up the load average of the server, we would turn them off, because | neither is the main version control system of gcc. | This is just the price you pay for not being the official repo. I think the mistake is to have them (git & hg) hosted on the same machine as svn. Having them on "hg.gcc.gnu.org" and "git.gcc.gnu.org" would allow to split the load between machines (even if "hg.gcc.gnu.org" and "git.gcc.gnu.org" are the same machines originally).
Re: Official GCC git repository
On Fri, Apr 18, 2008 at 3:07 PM, Samuel Tardieu <[EMAIL PROTECTED]> wrote: > On 18/04, Daniel Berlin wrote: > > > > I think the mistake is to have them (git & hg) hosted on the same > machine as svn. Having them on "hg.gcc.gnu.org" and "git.gcc.gnu.org" > would allow to split the load between machines (even if "hg.gcc.gnu.org" > and "git.gcc.gnu.org" are the same machines originally). This would be a great idea, if only we had more machines :) Sadly, machines and dns names are tricky for political reasons around gcc.
Re: GNAT Breakage on Trunk
> That appears to be caused by this change: > > 2008-04-17 Eric Botcazou <[EMAIL PROTECTED]> > > * decl.c (gnat_to_gnu_entity) : Promote the alignment of > objects by default. > * fe.h (Debug_Flag_Dot_A): Delete. > * debug.adb (-gnatd.a): Update documentation. On which platform(s)? x86 and x86-64 are OK: http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg01383.html http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg01386.html -- Eric Botcazou
Re: GNAT Breakage on Trunk
Eric Botcazou wrote: That appears to be caused by this change: 2008-04-17 Eric Botcazou <[EMAIL PROTECTED]> * decl.c (gnat_to_gnu_entity) : Promote the alignment of objects by default. * fe.h (Debug_Flag_Dot_A): Delete. * debug.adb (-gnatd.a): Update documentation. On which platform(s)? x86 and x86-64 are OK: http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg01383.html http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg01386.html x86 Fedora-> sparc-rtems cross. I am trying x86 Fedora -> powerpc-rtems now. But it is only in the C/C++ build stage I always build a native of the trunk, followed by crosses built using that native. -- Eric Botcazou -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: protect label from being optimized
Hi Jim, >>> But my return label is getting optimized away. Could you please tell >>> me how to avoid this. > >You may also need to add a (USE (REG RA)) to the call pattern. Gcc will see that you set a register to the value of the >return label, but it won't see any code that uses that register, so it will optimize away both the load and the label. To >prevent this, you need to add an explicit use of that register to the call insn pattern. I have that.. :). Here is the pattern for the call_insn produced. (define_insn "brc_call_simulate" [(call (mem:HI (match_operand 0 "register_operand" "r")) (match_operand 1 "" "i")) (use (reg:HI 7)) (clobber (reg:HI 7))] "" "jr\t%0") But GCC is not optimizing the load away. Its just the the return label that gets optimized away. CMIIW, I think the problem is this : 1. The label output is local to this function 2. The label creates a new basic block. There is no jump to this label. As a result, there is only one incoming edge to this block and that is the fall through edge after the return from the call. 3. As a result, GCC tries to merge those two blocks and in the process removes the label. How do I prevent this ? Thanks in advance, Kunal
Re: GNAT Breakage on Trunk
Eric Botcazou <[EMAIL PROTECTED]> writes: >> That appears to be caused by this change: >> >> 2008-04-17 Eric Botcazou <[EMAIL PROTECTED]> >> >> * decl.c (gnat_to_gnu_entity) : Promote the alignment of >> objects by default. >> * fe.h (Debug_Flag_Dot_A): Delete. >> * debug.adb (-gnatd.a): Update documentation. > > On which platform(s)? Fails here on ia64. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Adding knowledge of the int_fastN_t types to the compiler, take 2
> Also, I think the conclusion was that the compiler should not claim > any knowledge of these types unless specifically configured for a > particular target - that is, defaults.h should not contain any default > definitions. My strong preference is to just predefine: __INT8_T__ __INT16_T__ __INT32_T__ __INT64_T__ __UINT8_T__ __UINT16_T__ __UINT32_T__ __UINT64_T__ __INTMAX_T__ __INTPTR_T__ __UINTMAX_T__ __UINTPTR_T__ etc. Along with all the rest of the predefined bits here: http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html That way we get to avoid playing games with include file defines, which will just get as ratty as stddef.h over time. -benjamin -benjamin
Re: Official GCC git repository
> I think the mistake is to have them (git & hg) hosted on the > same machine as svn. Having them on "hg.gcc.gnu.org" and > "git.gcc.gnu.org" would allow to split the load between machines > (even if "hg.gcc.gnu.org" and "git.gcc.gnu.org" are the same > machines originally). This would be a great idea, if only we had more machines :) Sadly, machines and dns names are tricky for political reasons around gcc. Maybe they could be hosted on Savannah? The CVS repo. used to be synced there.
Re: Adding knowledge of the int_fastN_t types to the compiler, take 2
My strong preference is to just predefine: __INT8_T__ [...] Along with all the rest of the predefined bits here: I think that would defeat the purpose of knowing these types in the Fortran front-end. FX -- François-Xavier Coudert http://www.homepages.ucl.ac.uk/~uccafco/
Re: Official GCC git repository
On Fri, Apr 18, 2008 at 3:57 PM, Alfred M. Szmidt <[EMAIL PROTECTED]> wrote: >> I think the mistake is to have them (git & hg) hosted on the >> same machine as svn. Having them on "hg.gcc.gnu.org" and >> "git.gcc.gnu.org" would allow to split the load between machines >> (even if "hg.gcc.gnu.org" and "git.gcc.gnu.org" are the same >> machines originally). > >This would be a great idea, if only we had more machines :) Sadly, >machines and dns names are tricky for political reasons around gcc. > > Maybe they could be hosted on Savannah? The CVS repo. used to be > synced there. > Used to, and then one day they just stopped doing it without telling anyone, and questions went unanswered. So uh, thanks but no thanks :)
Re: Adding knowledge of the int_fastN_t types to the compiler, take 2
On Fri, 18 Apr 2008, Benjamin Kosnik wrote: > My strong preference is to just predefine: First the compiler needs to know all the types, in a way consistent with existing headers (including the choice between long and int where they have the same size, etc.) for any system which has such headers or for which a more recent version has such headers, which is what the present discussion is about. Then, once it knows the types (or any subset of them), you can indeed predefine such macros for the types it knows. You can also write a stdint.h, only installed on systems which don't have their own if you so wish, that uses the macros. > __INT8_T__ I'd suggest __INT8_TYPE__ for consistency with the macros such as __SIZE_TYPE__. -- Joseph S. Myers [EMAIL PROTECTED]
Re: Official GCC git repository
>> I think the mistake is to have them (git & hg) hosted on >> the same machine as svn. Having them on "hg.gcc.gnu.org" >> and "git.gcc.gnu.org" would allow to split the load between >> machines (even if "hg.gcc.gnu.org" and "git.gcc.gnu.org" >> are the same machines originally). > >This would be a great idea, if only we had more machines :) >Sadly, machines and dns names are tricky for political reasons >around gcc. > > Maybe they could be hosted on Savannah? The CVS repo. used to > be synced there. Used to, and then one day they just stopped doing it without telling anyone, and questions went unanswered. Sorry, that never happend AFAIK. I used the GCC CVS repo there, was never out of sync for me. So uh, thanks but no thanks :) Same thing can happen here; nothing extraordinary with that...
Another GNAT Breakage
Hi, I switched to x86 Fedora to PowerPC and got farther. There were some changes which did not get reflected into the RTEMS specific files again but I am past those and now have this failure which does not appear to be RTEMS related. Remember .. I am using a native compiler built from the trunk as well. gnatmake -c -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/../adainclude -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/ -I. -I/home/joel/work-gnat/svn/gcc/gcc/ada gnatmake --GCC="gcc -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -gnatpg -gnata" gcc -c -I./ -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/../adainclude -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/ -I. -I/home/joel/work-gnat/svn/gcc/gcc/ada -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -gnatpg -gnata -I- /home/joel/work-gnat/svn/gcc/gcc/ada/make.adb make.adb:662:39: expected type "Gnat.Strings.String_Access" defined at g-string.ads:41 make.adb:662:39: found type "System.Strings.String_Access" make.adb:663:39: expected type "Gnat.Strings.String_Access" defined at g-string.ads:41 make.adb:663:39: found type "System.Strings.String_Access" make.adb:664:39: expected type "Gnat.Strings.String_Access" defined at g-string.ads:41 make.adb:664:39: found type "System.Strings.String_Access" make.adb:689:39: "Get_Target_Object_Suffix" is not visible make.adb:689:39: non-visible declaration at s-os_lib.ads:556 make.adb:1700:19: no candidate interpretations match the actuals: make.adb:1700:19: too many arguments in call to "Normalize_Compiler_Switches" make.adb:1702:22: expected type "System.Strings.String_List_Access" make.adb:1702:22: found type "Gnat.Strings.String_List_Access" defined at g-string.ads:51 make.adb:1702:22: ==> in call to "Normalize_Compiler_Switches" at switch-m.ads:45 make.adb:4459:36: expected type "System.Os_Lib.File_Descriptor" make.adb:4459:36: found type "Gnat.Os_Lib.File_Descriptor" defined at g-os_lib.ads:160 make.adb:6603:13: expected type "System.Os_Lib.File_Descriptor" make.adb:6603:13: found type "Gnat.Os_Lib.File_Descriptor" defined at g-os_lib.ads:160 ali.ads:473:51: "No_Restrictions" is undefined (more references follow) gnatmake: "/home/joel/work-gnat/svn/gcc/gcc/ada/make.adb" compilation error -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
gcc-4.4-20080418 is now available
Snapshot gcc-4.4-20080418 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080418/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 134452 You'll find: gcc-4.4-20080418.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20080418.tar.bz2 C front end and core compiler gcc-ada-4.4-20080418.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20080418.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20080418.tar.bz2 C++ front end and runtime gcc-java-4.4-20080418.tar.bz2 Java front end and runtime gcc-objc-4.4-20080418.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20080418.tar.bz2The GCC testsuite Diffs from 4.4-20080411 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
Another GNAT Breakage
Hi, The first attempt at this one isn't showing up in the archives. :( I switched to x86 Fedora to PowerPC and got farther. There were some changes which did not get reflected into the RTEMS specific files again but I am past those and now have this failure which does not appear to be RTEMS related. Remember .. I am using a native compiler built from the trunk as well. gnatmake -c -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/../adainclude -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/ -I. -I/home/joel/work-gnat/svn/gcc/gcc/ada gnatmake --GCC="gcc -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -gnatpg -gnata" gcc -c -I./ -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/../adainclude -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/ -I. -I/home/joel/work-gnat/svn/gcc/gcc/ada -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -gnatpg -gnata -I- /home/joel/work-gnat/svn/gcc/gcc/ada/make.adb make.adb:662:39: expected type "Gnat.Strings.String_Access" defined at g-string.ads:41 make.adb:662:39: found type "System.Strings.String_Access" make.adb:663:39: expected type "Gnat.Strings.String_Access" defined at g-string.ads:41 make.adb:663:39: found type "System.Strings.String_Access" make.adb:664:39: expected type "Gnat.Strings.String_Access" defined at g-string.ads:41 make.adb:664:39: found type "System.Strings.String_Access" make.adb:689:39: "Get_Target_Object_Suffix" is not visible make.adb:689:39: non-visible declaration at s-os_lib.ads:556 make.adb:1700:19: no candidate interpretations match the actuals: make.adb:1700:19: too many arguments in call to "Normalize_Compiler_Switches" make.adb:1702:22: expected type "System.Strings.String_List_Access" make.adb:1702:22: found type "Gnat.Strings.String_List_Access" defined at g-string.ads:51 make.adb:1702:22: ==> in call to "Normalize_Compiler_Switches" at switch-m.ads:45 make.adb:4459:36: expected type "System.Os_Lib.File_Descriptor" make.adb:4459:36: found type "Gnat.Os_Lib.File_Descriptor" defined at g-os_lib.ads:160 make.adb:6603:13: expected type "System.Os_Lib.File_Descriptor" make.adb:6603:13: found type "Gnat.Os_Lib.File_Descriptor" defined at g-os_lib.ads:160 ali.ads:473:51: "No_Restrictions" is undefined (more references follow) gnatmake: "/home/joel/work-gnat/svn/gcc/gcc/ada/make.adb" compilation error -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: US-CERT Vulnerability Note VU#162289
BTW,
It occurs to me that the optimisation is just as likely (if not more
likely) to remove security holes as it is to introduce them.
If someone writes comparison involving 'buf+len' because they
incorrectly ignored a possibility of 'buf+len' wrapping, then
the optimisation fixes, not breaks, the code.
My evidence-free opinion is that this scenario is in fact more likely
than the apparently contrived example in the CERT note.
Ralph.
PS The CERT note refers to "existing programs" broken by the
optimisation. I wrote to their feedback address asking about the
"existing programs" and heard nothing back, which makes me suspect that
the authors of the note don't know of any, despite their claim.
> The GCC SC was aware of this CERT posting before it was public. Our
> feeling is that this is not a GCC bug, although it is something that
> we would like GCC to warn about. I talked to Ian Taylor and he
> agreed to work on the warning.
>
> Some other compilers do this optimization too, so compiling similar
> applications with them will also lead to the removal of the test.
> We've identified one specific highly-optimizing compiler that does
> this optimization. If you have information about other such
> compilers, please send it to me, and I will forward to CERT. We
> would like to counter the idea that GCC is unique in this regard.
> (In fact, I expect that the reason that this issue was found with GCC
> is that GCC is used so widely!)
>
> Here is the test program:
>
> int f(char *buf, int len) {
>len = 1 << 30;
>if (buf + len < buf)
> return 1;
>
>return 0;
> }
>
> If you know of a non-GCC compiler that optimizes away the test (so
> that the function always returns 0), please post here, and let me
> know the name, version number, command-line options, etc. you used to
> demonstrate that.
>
> Thanks,
>
gcc compiler for pdp10
Hi, I'm am the proprietor of a gcc compiler for the PDP10 architecture. (This is a compiler previously worked on by Lars Brinkhoff who left XKL some while before I joined XKL. It's possible some of you may have been familiar with him or the compiler from that time.) The compiler is currently in a state where it is synched with the both the 4.3 and 4.4 branches, and it passes the testsuite tests (with the exception of some I've flagged as expected failures for the pdp10). My employer is happy to release my work on the gcc compiler back to the gcc community and I've sent in a request for the necessary forms. The PDP10 architecture is unusual in various ways that distinguish it from the mainstream architectures supported by the gcc compiler and this has made the development of this compiler a significant task. Undoubtedly I've made customizations in inappropriate ways. I'm seeking contacts with people who might be able to advise me on how to cleanup my implementation to reduce the amount of #ifdef __PDP10_H__ I've sprinkled liberally throughout the source. Also, if its possible to get simple changes made to prevent breaking my PDP10 version and that are otherwise innocuous that would be wonderful. For example, the PDP10 word size is 36 bits; Fairly recently people have taken to writing code that assumes word size is a power of 2 even when it's straightforward to write in a manner that doesn't make that assumption. Considering the large number of files customized to get the PDP10 compiler working, I'm not sure whether it's possible to get it to build directly from the gcc trunk, but it would be nice to work toward that goal. Some other things which distinguish the PDP10 architecture from assumptions in the gcc code base include: its variety of formats of pointers only one of which can be viewed as an integer and that one is capable of referencing only word aligned data, a functional difference between signed and unsigned integers, and peculiarities to the use of PDP10 byte arrays which are very difficult to describe. Any help or advise would be appreciated. Martin Chaney XKL, LLC
Re: GNAT Breakage on Trunk
> Fails here on ia64. OK, this should be fixed everywhere now. -- Eric Botcazou
Re: Another GNAT Breakage
Eric Botcazou wrote: gnatmake -c -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/../adainclude -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/ -I. -I/home/joel/work-gnat/svn/gcc/gcc/ada gnatmake --GCC="gcc -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -gnatpg -gnata" Looks like you're building the 4.4 cross-compiler with the 4.1.2 system compiler. Use the 4.4 native compiler instead. Grrr.. time to call it a weekend. I forgot to set my path to put the test install directory first. Thanks for catching my stupid mistake. -- Eric Botcazou -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Another GNAT Breakage
> gnatmake -c -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/../adainclude > -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/ -I. > -I/home/joel/work-gnat/svn/gcc/gcc/ada gnatmake --GCC="gcc -g -O2 -W > -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -fno-common -gnatpg -gnata" Looks like you're building the 4.4 cross-compiler with the 4.1.2 system compiler. Use the 4.4 native compiler instead. -- Eric Botcazou
Re: gcc compiler for pdp10
Martin, I did a port of GCC to the Analog Devices SHARC chip. I ended up supporting 3 kinds of pointers for this chip (two for address spaces and one for byte pointers - the chip itself is only word addressable (although words can be from 16 to 48 bits in size depending on what memory is being accessed.) I also worked on the Bliss-36 compiler at DEC, so I'm well acquainted with the PDP10 architecture. I don't have access to any 10/20 HW, but I'd be happy to act as a reviewer/advisor to your changes. Al Lehotsky On Apr 18, 2008, at 20:21, Martin Chaney wrote: Hi, I'm am the proprietor of a gcc compiler for the PDP10 architecture. (This is a compiler previously worked on by Lars Brinkhoff who left XKL some while before I joined XKL. It's possible some of you may have been familiar with him or the compiler from that time.) The compiler is currently in a state where it is synched with the both the 4.3 and 4.4 branches, and it passes the testsuite tests (with the exception of some I've flagged as expected failures for the pdp10). My employer is happy to release my work on the gcc compiler back to the gcc community and I've sent in a request for the necessary forms. The PDP10 architecture is unusual in various ways that distinguish it from the mainstream architectures supported by the gcc compiler and this has made the development of this compiler a significant task. Undoubtedly I've made customizations in inappropriate ways. I'm seeking contacts with people who might be able to advise me on how to cleanup my implementation to reduce the amount of #ifdef __PDP10_H__ I've sprinkled liberally throughout the source. Also, if its possible to get simple changes made to prevent breaking my PDP10 version and that are otherwise innocuous that would be wonderful. For example, the PDP10 word size is 36 bits; Fairly recently people have taken to writing code that assumes word size is a power of 2 even when it's straightforward to write in a manner that doesn't make that assumption. Considering the large number of files customized to get the PDP10 compiler working, I'm not sure whether it's possible to get it to build directly from the gcc trunk, but it would be nice to work toward that goal. Some other things which distinguish the PDP10 architecture from assumptions in the gcc code base include: its variety of formats of pointers only one of which can be viewed as an integer and that one is capable of referencing only word aligned data, a functional difference between signed and unsigned integers, and peculiarities to the use of PDP10 byte arrays which are very difficult to describe. Any help or advise would be appreciated. Martin Chaney XKL, LLC
Re: Official GCC git repository
After consultation with Dan, I have set things up on gcc.gnu.org so that the git repository is updated every time an email message is received from the gcc-cvs mailing list. We'll be monitoring the system to see if there is a load hit. If so, we'll probably drop back to Dan's original method. cgf
Re: protect label from being optimized
Hi Joern, >The insn that loads the return register with the label needs a REG_LABEL >note to avoid the ref count dropping to zero. The insn has a REG_LABEL (foo.c.110r.vregs) and the label also has a ref count of 1. >You would have to put a (set (pc) (reg RA)) into the pattern of the >call insn. And no matter if you make this a call_insn, jump_insn, >or some newly invented type of insn, I think you will have to change >some middle-end code to cope with an insn that is both a call and a jump. Does this mean that there is no way for me to handle this in RTL without changing target independent code ? In that case, since I don't want to change the target independent code, will it be sufficient if I create a new pattern that holds the label number in the pattern and during final pattern matching, uses this to spit the label manually ? Can I assume that there won't be multiple labels with the same number ? Thanks in advance, Kunal
