Re: Experimental Patchwork setup
On 9 June 2010 02:21, Jeremy Kerr wrote: > > There is one header you can add to emails: > > X-Patchwork-Hint: ignore I am not sure how to add headers with gmail which is what I use for GCC development. I would rather have patchwork recognize something like: :patchwork: ignore: in the body of the email. Thanks for doing this! Manuel.
Re: Experimental Patchwork setup
On 9 June 2010 02:21, Jeremy Kerr wrote: > Hi Ian, > >> I can see already that to be useful for gcc today it will need some >> curating. E.g., http://patchwork.ozlabs.org/patch/54974/ is both 1) >> committed; 2) on a branch. This one >> http://patchwork.ozlabs.org/patch/54958/ is committed to trunk. > > There are a number of ways to keep the patch states up-to-date: > 2) Use the command-line patchwork client to update patch state when a patch is > committed. People have done this with a git post-commit hook to update the > state of the patch in patchwork; I'm not sure if svn has something equivalent. Yes it does. If you tell us how the git pots-commit hook works, we could try to implement a version for svn and GCC. Cheers, Manuel.
Re: Experimental Patchwork setup
Hi Manuel, > > 2) Use the command-line patchwork client to update patch state when a > > patch is committed. People have done this with a git post-commit hook to > > update the state of the patch in patchwork; I'm not sure if svn has > > something equivalent. > > Yes it does. If you tell us how the git pots-commit hook works, we > could try to implement a version for svn and GCC. This is what I've used for git: [...@pororo helloworld]$ cat .git/hooks/post-applypatch #!/bin/bash sha=$(git rev-parse HEAD) hash=$(git show $sha | pwparser --hash) pwclient update -s Accepted -c $sha -h $hash - where 'pwparser' is symlink to parser.py from the patchwork tree (http://git.ozlabs.org/?p=patchwork;a=blob;f=apps/patchwork/parser.py), and 'pwclient' is downloadable from the patchwork setup. And for those unfamiliar with git: 'git rev-parse HEAD' prints the commit ID of the latest commit, and 'git show $sha' prints out the commit itself - all we need is the diff, pwparser will ignore everything else. Cheers, Jeremy
Re: Experimental Patchwork setup
Hi, On Wed, Jun 09, 2010 at 08:21:17AM +0800, Jeremy Kerr wrote: > There is one header you can add to emails: > > X-Patchwork-Hint: ignore > > - this will tell patchwork to ignore the patch completely. I use this when > sending a "this is the stuff I'm merging for the next release" email, as all > of the patches have already been through the list. > I believe the common practice for such patches is to put the string "RFC" somewhere into the subject of such patches, usually into square brackets. Would you consider looking for that instead? Editing headers is often inconvenient, especially if the email messages are generated, for example by quilt. Thanks for doing this, Martin
Re: Experimental Patchwork setup
Hi Martin, > > There is one header you can add to emails: > > > > X-Patchwork-Hint: ignore > > > > - this will tell patchwork to ignore the patch completely. I use this > > when sending a "this is the stuff I'm merging for the next release" > > email, as all of the patches have already been through the list. > > I believe the common practice for such patches is to put the string > "RFC" somewhere into the subject of such patches, usually into square > brackets. Would you consider looking for that instead? In the example I gave, they're not really RFC, they're just a last call for objections before the patches are sent upstream. So, probably not - I don't want RFC patches to be dropped immediately, especially as other projects using patchwork.ozlabs.org will be affected. However, I believe the plan is to move the gcc patchwork instance to its own server if the ozlabs.org patchwork provides to be useful; in this case, the gcc folks are free to do whatever they like :) Cheers, Jeremy
a typo in ira-emit.c?
Hi :
I am studying ira right now, there is following code in change_loop
if (parent_allocno == NULL
|| REGNO (ALLOCNO_REG (parent_allocno)) == REGNO (original_reg))
{
if (internal_flag_ira_verbose > 3 && ira_dump_file)
fprintf (ira_dump_file, " %i vs parent %i:",
ALLOCNO_HARD_REGNO (allocno),
ALLOCNO_HARD_REGNO (parent_allocno));
set_allocno_reg (allocno, create_new_reg (original_reg));
}
Is it possible that parent_allocno == NULL here? or the fprintf might broken.
Thanks.
--
Best Regards.
No output files on 4.6/Cygwin
I have a problem with recent builds of GCC4.6 (trunk)
on Cygwin 1.7. The compiler itself builds correctly, but
when I run it on even the simplest input, e.g.
gcc in.c -o a.exe
with in.c = int main() {}, no executable file is created.
No oputput is created even with the -S and -E options.
The same used to happen with GCC 4.5 experimental
in its early development days, but later started to work
again. Is it a known issue of GCC or Cygwin? Has
anyone managed to get a working 4.6 build on Cygwin?
Best regards,
Piotr Wyderski
Re: Experimental Patchwork setup
>> Yes it does. If you tell us how the git pots-commit hook works, we >> could try to implement a version for svn and GCC. > > This is what I've used for git: > > [...@pororo helloworld]$ cat .git/hooks/post-applypatch > #!/bin/bash > > sha=$(git rev-parse HEAD) > hash=$(git show $sha | pwparser --hash) > pwclient update -s Accepted -c $sha -h $hash We'll need to cut out the ChangeLog parts before computing the hash. I'll work on something. Segher
Re: Experimental Patchwork setup
> Two things: 1) we should make the [bracket] prefixes more standard for > patches destined to feature branches; > Another point about (1): I believe patchwork should *not* track most of > the branch patches, and the commit detection shouldn't care about > release branch commits, only trunk. This is because those are 99% of > the time for trunk too, and whether the patches went on the release > branches is effectively already tracked via bugzilla. Patches that go to trunk first, and then to some branch, should already be handled correctly as far as I can see. So there is no need to mark email messages specially for this. > 2) we should likely not send > multiple patches in one email as attachments. We shouldn't do that anyway :-) Maybe patchwork can even handle this, dunno. Segher
Re: No output files on 4.6/Cygwin
On Wed, Jun 9, 2010 at 11:51 AM, Piotr Wyderski
wrote:
> I have a problem with recent builds of GCC4.6 (trunk)
> on Cygwin 1.7. The compiler itself builds correctly, but
> when I run it on even the simplest input, e.g.
>
> gcc in.c -o a.exe
>
> with in.c = int main() {}, no executable file is created.
> No oputput is created even with the -S and -E options.
Maybe a mismatched cygwin1.dll. Do you have the right version of
cygwin1.dll on path? e.g the one against which gcc was compiled?.
Cygwin fails silently to execute the image in case of a mismatched
dll.
>
> Best regards,
> Piotr Wyderski
>
Wojciech
Re: No output files on 4.6/Cygwin
Wojciech Meyer wrote: > Maybe a mismatched cygwin1.dll. Do you have the right version of > cygwin1.dll on path? e.g the one against which gcc was compiled?. > Cygwin fails silently to execute the image in case of a mismatched > dll. I am not 100% sure that my Cygwin installation is OK, as it has been upgraded from 1.5 without uninstalling the latter (i.e. I wiped it out using a mere rm -rf), but the image itself works: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/i686-pc-cygwin/4.6.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ../configure --prefix=/opt/gcc-trunk -v --enable-bootstrap --enable-version-specific-runtime-libs --ena ble-shared --enable-shared-libgcc --with-gnu-ld --with-gnu-as --enable-dwarf2-exceptions --disable-symvers --disable-nls --with-arch=core2 --with-tune=generic --enable-threads=posix --enable-languages=c,c++ AM_CXXFLAGS=-w Thread model: posix gcc version 4.6.0 20100607 (experimental) (GCC) Best regards Piotr Wyderski
Vector subscription, register storage class
Hi,
I'm working on the vector subscription patch in terms of GSoC 2010 project.
The patch basically does the following, if we have a vector subscription like:
#define vector __attribute__((vector_size(16)))
vector int a;
a[1] = 10;
then the code "a[1] = 10" is transformed into the code "*((int *)a + 1) = 10".
The problem however is, when we have a register-declared variable like:
register vector int a = {1,2,3,4};
It should be addressable, but register keyword disallows it. To solve
this problem I modify c-decl.c:start_decl like this:
Index: c-decl.c
===
--- c-decl.c(revision 160230)
+++ c-decl.c(working copy)
@@ -4071,6 +4071,11 @@
}
}
+ /* Vectors need to be addressable for subscripting to work,
+ so drop the qualifier. */
+ if (TREE_CODE (TREE_TYPE (decl)) == VECTOR_TYPE)
+C_DECL_REGISTER (decl) = 0;
+
if (TREE_CODE (decl) == FUNCTION_DECL
&& DECL_DECLARED_INLINE_P (decl)
&& DECL_UNINLINABLE (decl)
Which allows now to subscript register-declared variables.
But still I have an example that does not work:
struct vec_s {
vector short member;
};
int main () {
register struct vec_s v2;
v2.member[2] = 4;
return 0;
}
The question is should it work at all? And what would be the optimal
way to implement it?
--
Thank you,
Artem Shinkarov
Re: No output files on 4.6/Cygwin
On 09/06/2010 11:51, Piotr Wyderski wrote:
> I have a problem with recent builds of GCC4.6 (trunk)
> on Cygwin 1.7. The compiler itself builds correctly, but
> when I run it on even the simplest input, e.g.
>
>gcc in.c -o a.exe
>
> with in.c = int main() {}, no executable file is created.
> No oputput is created even with the -S and -E options.
>
> The same used to happen with GCC 4.5 experimental
> in its early development days, but later started to work
> again. Is it a known issue of GCC or Cygwin? Has
> anyone managed to get a working 4.6 build on Cygwin?
Yeh, I posted testresults just a little while ago(*). Are you sure you're
picking up the newest version of cyggcc_s-1.dll (and all the other language
runtimes) that got built with the compiler, rather than the standard system
one(s)? You did a full "make install" and put the new $prefix/bin (if not
using the standard prefix) at the head of your PATH?
cheers,
DaveK
--
(*) - http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg02996.html
Re: No output files on 4.6/Cygwin
On 09/06/2010 17:10, Dave Korn wrote:
Oh, and an afterthought:
> On 09/06/2010 11:51, Piotr Wyderski wrote:
>> I have a problem with recent builds of GCC4.6 (trunk)
>> on Cygwin 1.7. The compiler itself builds correctly, but
>> when I run it on even the simplest input, e.g.
>>
>>gcc in.c -o a.exe
>>
>> with in.c = int main() {}, no executable file is created.
>> No oputput is created even with the -S and -E options.
>>
>> The same used to happen with GCC 4.5 experimental
>> in its early development days, but later started to work
>> again. Is it a known issue of GCC or Cygwin? Has
>> anyone managed to get a working 4.6 build on Cygwin?
Wasn't it last time because you didn't have "--disable-sjlj-exceptions" in
your configure command and so you ended up with sjlj-based DLLs that didn't
play nicely with the Cygwin distro's DW2-based ones? Sorry, that setting
still isn't defaulted on for Cygwin targets yet; it should be, and I'll make a
note to fix it.
cheers,
DaveK
Re: No output files on 4.6/Cygwin
Dave, > Are you sure you're picking up the newest version of cyggcc_s-1.dll > (and all the other language runtimes) that got built with the compiler, > rather than the standard system one(s)? How can I check that? > You did a full "make install" and put the new $prefix/bin (if not > using the standard prefix) at the head of your PATH? Yes: export PATH=/opt/gcc-trunk/bin/:$PATH > Wasn't it last time because you didn't have "--disable-sjlj-exceptions" in > your configure command and so you ended up with sjlj-based DLLs that didn't > play nicely with the Cygwin distro's DW2-based ones? Yes, then it was the case. But doesn't my --enable-dwarf2-exceptions already imply --disable-sjlj-exceptions? It works with gcc-4.5. I've just updated my repo and will schedule a nightly build of trunk with configure settings taken from the bundled gcc4 compiler from Cygwin pack in order to see what will happen. Best regards Piotr Wyderski
Re: No output files on 4.6/Cygwin
On 09/06/2010 17:31, Piotr Wyderski wrote: >> Are you sure you're picking up the newest version of cyggcc_s-1.dll >> (and all the other language runtimes) that got built with the compiler, >> rather than the standard system one(s)? > > How can I check that? Well, verifying your path is correct should be sufficient. >> You did a full "make install" and put the new $prefix/bin (if not >> using the standard prefix) at the head of your PATH? > > Yes: export PATH=/opt/gcc-trunk/bin/:$PATH That should be fine then. >> Wasn't it last time because you didn't have "--disable-sjlj-exceptions" in >> your configure command and so you ended up with sjlj-based DLLs that didn't >> play nicely with the Cygwin distro's DW2-based ones? > > Yes, then it was the case. But doesn't my > > --enable-dwarf2-exceptions > > already imply --disable-sjlj-exceptions? It works with gcc-4.5. It does? I've never been aware of any such option; as far as I know, you have to disable sjlj exceptions, and there's no configure option to positively enable dw2 ones. > I've just updated my repo and will schedule a nightly build > of trunk with configure settings taken from the bundled gcc4 > compiler from Cygwin pack in order to see what will happen. That's the simplest way to guarantee compatibility. cheers, DaveK
Re: externally_visible and resoultion file
>> Yes, this is also what I saw without plugin. I just wonder why "v" >> is linked with plugin if resolution file is not used to eliminate need >> of externally_visible attribute here. > > Probably because of the same linker-plugin bug that causes bar > to be resolved. Just to make sure I understand the problem: - The IR file for a.c contains definitions for v and bar. - The linker identifies that both symbols are referenced from outside the LTO world (PREVAILING_DEF rather than PREVAILING_DEF_IRONLY), but gcc isn't (yet) reading that info from the resolution file. - WPA eliminates bar() and makes v static in the replacement object file. - There are still references to those symbols in b.o, which was compiled outside LTO. - The linker should be complaining about undefined symbols in both cases, but isn't (perhaps because it's still seeing defs left over from the IR files). The symbol bar has a value of 0, while the reference to v seems to have the right address. Is that about right? What you're expecting is a link-time error reporting both bar and v as undefined, right? -cary
Re: Vector subscription, register storage class
On Wed, 9 Jun 2010, Artem Shinkarov wrote:
> It should be addressable, but register keyword disallows it. To solve
> this problem I modify c-decl.c:start_decl like this:
I think that's too early, since you still want "&vector" (explicitly
taking the address) to be rejected for a vector with register storage
class. I don't claim it's optimal, but Andrew Pinski's patch handles
marking vectors addressable even when they have the register storage
class.
> But still I have an example that does not work:
> struct vec_s {
>vector short member;
> };
>
> int main () {
>register struct vec_s v2;
>v2.member[2] = 4;
>return 0;
> }
>
> The question is should it work at all? And what would be the optimal
> way to implement it?
If you allow subscripting register vectors, then surely this case should
work as well.
--
Joseph S. Myers
jos...@codesourcery.com
Re: license & copyright patch to MELT for dual GPLv3+ & GFDL1.2+
On Wed, Jun 09, 2010 at 12:11:01PM -0700, Mark Mitchell wrote:
>
> I think that "literate programming" approaches (whether the full Knuth
> version, or the more mild JavaDoc version, or auto-extraction of
> command-line options or whatever) are valuable. RMS, based on my
> communications with him, is less convinced that they are valuable. I
> think he agrees that his opinions of the technical merits shouldn't
> override a consensus opinion of the developers, but it does influence
> how hard he wants to work on changing the licensing regime, and it is a
> legitimately hard problem to solve.
>
> Meanwhile, I think we should try to make use of the fact that RMS is
> permitting auto-generated reference documentation (which I have been
> instructed not to call a manual) using JavaDoc/Doxygen tools. If we use
> those tools, and demonstrate their value, we're then in a stronger
> position to say how generation of actual manuals is important.
>
What I don't understand is what is so special about Doxygen.
MELT is a lispy dialect, and is bootstrapped in the sense of being its
own tranlator.
Could you understand that for me Basile (who don't know doxygen's
internals), since I am MELT designer & implementor, and since MELT
translator (i.e. the code generating C code from MELT source) has been
implemented by me Basile in MELT, it is much easier to implement MELT
documentation's generator in MELT than to patch Doxygen for that
purpose.
So why using Doxygen is permitted for documentation generation, while
using a GCC plugin or branch (this is what MELT is) is prohibited?
Could people understand at least my misunderstanding? Why generating
documentation with Doxygen (probably not a GNU, FSF copyrighted,
software like GCC is) is permitted, while generating the documentation
of a branch of GCC [=MELT] with itself, [MELT=] a branch or plugin of GCC is
prohibited?
Sorry, I don't understand the logic here. And I am not sure it is only a
cultural (I am French, not US American) or language issue (I am not a
native English speaker).
OF course, I don't claim that MELT documentation generating mode is as
powerful & as complete as Doxygen. It is actally a very simple hack
(only generating .texi format) much less powerful than doxygen.
Please explain me why using Doxygen is permitted, while using a branch
of GCC is not permitted, to generate that same's branch documentation.
Sorry, I don't understand the logic.
Please also explain who should I contact, and how? Please also explain
how the GNU Emacs is generated. I guess it is by a software of the GNU
emacs package.
Cheers.
PS. What I probably did understand or at least guess, is that to be
permitted to redistribute the generated documention of MELT, I'll have
to wait many [dozens?] years. I probably will lose interest in GCC by
then, or perhaps even I'll be already dead (and perhaps RMS also, since
he is born in 1953, and I was born in 1959). I even could imagine that
GCC won't be very relevant by then (hint: the SIGPLAN programming
language award went to a C compiler which is free -at least for some
definition of free- but not GCC).
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: license & copyright patch to MELT for dual GPLv3+ & GFDL1.2+
Basile Starynkevitch wrote: >> Meanwhile, I think we should try to make use of the fact that RMS is >> permitting auto-generated reference documentation (which I have been >> instructed not to call a manual) using JavaDoc/Doxygen tools. If we use >> those tools, and demonstrate their value, we're then in a stronger >> position to say how generation of actual manuals is important. > What I don't understand is what is so special about Doxygen. Basile, there's nothing special about Doxygen. It's just an example of a tool that generates cross-reference information. I think you can reasonably distinguish the kind of thing that comes out of JavaDoc or Doxygen from a manual. If you don't know what kind of output JavaDoc and Doxygen produce, please go read about them for a while and look at some examples. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: license & copyright patch to MELT for dual GPLv3+ & GFDL1.2+
On Wed, Jun 09, 2010 at 10:46:26PM +0200, Basile Starynkevitch wrote:
> Please also explain who should I contact, and how? Please also explain
> how the GNU Emacs is generated. I guess it is by a software of the GNU
> emacs package.
Sorry for the typo, I mean
"how the GNU emacs documentation is generated"
GNU emacs has documentation annotations, like MELT has (I copied the
idea from Emacs)!
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Patch pinging
> > Still, we'll see... > > Apparently not :( Why not? At most, you just need not to make sure nothing ever send mail to people who think that kind of thing is bozoid... M
Re: license & copyright patch to MELT for dual GPLv3+ & GFDL1.2+
On Wed, Jun 09, 2010 at 01:57:03PM -0700, Mark Mitchell wrote:
> Basile Starynkevitch wrote:
>
> >> Meanwhile, I think we should try to make use of the fact that RMS is
> >> permitting auto-generated reference documentation (which I have been
> >> instructed not to call a manual) using JavaDoc/Doxygen tools. If we use
> >> those tools, and demonstrate their value, we're then in a stronger
> >> position to say how generation of actual manuals is important.
>
> > What I don't understand is what is so special about Doxygen.
>
> Basile, there's nothing special about Doxygen. It's just an example of
> a tool that generates cross-reference information. I think you can
> reasonably distinguish the kind of thing that comes out of JavaDoc or
> Doxygen from a manual. If you don't know what kind of output JavaDoc
> and Doxygen produce, please go read about them for a while and look at
> some examples.
I did read many doxygen generated documentation, and in my eyes, the
documentation generated by MELT is ofvery similar nature: also, the
cross-reference, inheritance, etc.
The MELT generated documentation was heavily inspired by what Emacs &
Doxygen are doing.
So I still don't understand why generating cross-reference documentation
with Doxygen for C++ code is permitted, while generating cross-reference
documentation witb ÂMELT for MELT code is prohibited.
Did *you* have a tiny look at the documentation of MELT generated by MELT?
http://gcc.gnu.org/wiki/MELT%20tutorial?action=AttachFile&do=view&target=GCC-MELT--gcc-internals-snapshot.pdf
Cheers!
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: license & copyright patch to MELT for dual GPLv3+ & GFDL1.2+
Basile Starynkevitch wrote: > So I still don't understand why generating cross-reference > documentation with Doxygen for C++ code is permitted, while > generating cross-reference documentation witb ÂMELT for MELT code is > prohibited. As far as I know, nobody said that. > http://gcc.gnu.org/wiki/MELT%20tutorial?action=AttachFile&do=view&target=GCC-MELT--gcc-internals-snapshot.pdf That contains much more than cross-reference documentation! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: externally_visible and resoultion file
On Wed, Jun 9, 2010 at 7:43 PM, Cary Coutant wrote: >>> Yes, this is also what I saw without plugin. I just wonder why "v" >>> is linked with plugin if resolution file is not used to eliminate need >>> of externally_visible attribute here. >> >> Probably because of the same linker-plugin bug that causes bar >> to be resolved. > > Just to make sure I understand the problem: > > - The IR file for a.c contains definitions for v and bar. > - The linker identifies that both symbols are referenced from outside > the LTO world (PREVAILING_DEF rather than PREVAILING_DEF_IRONLY), but > gcc isn't (yet) reading that info from the resolution file. > - WPA eliminates bar() and makes v static in the replacement object file. > - There are still references to those symbols in b.o, which was > compiled outside LTO. > - The linker should be complaining about undefined symbols in both > cases, but isn't (perhaps because it's still seeing defs left over > from the IR files). The symbol bar has a value of 0, while the > reference to v seems to have the right address. > > Is that about right? What you're expecting is a link-time error > reporting both bar and v as undefined, right? That's correct. Richard. > -cary >
Re: Experimental Patchwork setup
On 06/09/2010 10:03 AM, Jeremy Kerr wrote: Hi Manuel, 2) Use the command-line patchwork client to update patch state when a patch is committed. People have done this with a git post-commit hook to update the state of the patch in patchwork; I'm not sure if svn has something equivalent. Yes it does. If you tell us how the git pots-commit hook works, we could try to implement a version for svn and GCC. This is what I've used for git: [...@pororo helloworld]$ cat .git/hooks/post-applypatch #!/bin/bash sha=$(git rev-parse HEAD) hash=$(git show $sha | pwparser --hash) pwclient update -s Accepted -c $sha -h $hash The hash would be different for git diff and svn diff due to the different headers. So, git people would have to add the hook themselves, while svn people could skip that step assuming that a centralized hook is running on the svn server. On the other hand, svn patch ids are not stable, for two reasons. The first is the "(revision )" and "(working tree)" markers, which differ from the time the patch is made, to the time it is committed. These markers could be removed by pwparser using a simple regex. The second is that paths in svn patches are relative, so people can run "svn diff" from the GCC directory and get a different patch id than if they ran "svn diff gcc". Certainly, we don't want to require svn people to run "svn diff" from the toplevel exclusively. So, maybe the commit hook would have to try removing common paths one by one and pass all the resulting hashes to pwclient... Paolo
Re: a typo in ira-emit.c?
On 06/09/2010 06:45 AM, Amker.Cheng wrote:
Hi :
I am studying ira right now, there is following code in change_loop
if (parent_allocno == NULL
|| REGNO (ALLOCNO_REG (parent_allocno)) == REGNO (original_reg))
{
if (internal_flag_ira_verbose> 3&& ira_dump_file)
fprintf (ira_dump_file, " %i vs parent %i:",
ALLOCNO_HARD_REGNO (allocno),
ALLOCNO_HARD_REGNO (parent_allocno));
set_allocno_reg (allocno, create_new_reg (original_reg));
}
Is it possible that parent_allocno == NULL here? or the fprintf might broken.
Yes, I think it can be NULL in some complicated cases when a loop exit
edge comes not in the parent loop.
Re: a typo in ira-emit.c?
> > Yes, I think it can be NULL in some complicated cases when a loop exit edge > comes not in the parent loop. By that, you mean the case an regno lives on edges which transfer between adjacent loops, and not lives in parent loop? So, the fprintf would access null pointer in this case. Thanks for explanation. -- Best Regards.
Re: Experimental Patchwork setup
Hi Paolo, > The hash would be different for git diff and svn diff due to the > different headers. The headers are not included in the hash. However, the filenames will need to be the same - patchwork expects '-p1' patches, but normalises the top-level directory. For example, at http://patchwork.ozlabs.org/patch/55140/ --- gcc/config/rs6000/e500.h(revision 160245) +++ gcc/config/rs6000/e500.h(working copy) The parser normalises this to: --- a/config/rs6000/e500.h +++ b/config/rs6000/e500.h which may or may not be what you want here (svn outputs -p0?). The only difficulty is that the parser does not specify an order for the files in a patch; I believe git orders the file changes alphabetically by filename, but svn does not. This may cause different hashes. Cheers, Jeremy
