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://patchwor
>
> 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
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&&
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
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 t
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/wik
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/Dox
> > 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
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
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
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
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 regi
>> 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 unde
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
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 st
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
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.
> N
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 *
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
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 cr
> 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
>> 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
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
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_
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 thro
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 a
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 t
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 tr
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 t
29 matches
Mail list logo
