Patch pings

Patch pings

[Ben Elliston]

The following patches received negligible comment, let alone approval. I
know they are in some of the less exciting parts of the compiler, so
perhaps they require a GWP maintainer to approve them?  ;-)

  PATCH: silence warnings from gengtype-lex.c
  http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00320.html

  PATCH: fix warning in insn-preds.c
  http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00322.html

Thanks,
Ben

Re: Patch pings

[Bernd Schmidt]

Ben Elliston wrote:

>   PATCH: fix warning in insn-preds.c
>   http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00322.html

Ok.


Bernd

Re: Patch pings

[Mike Stump]

On Jan 16, 2007, at 8:50 PM, Ben Elliston wrote:
> The following patches received negligible comment, let alone  
> approval. I
> know they are in some of the less exciting parts of the compiler, so
> perhaps they require a GWP maintainer to approve them?  ;-)
>
>   PATCH: silence warnings from gengtype-lex.c
>   http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00320.html

I reviewed this, seems reasonable, if you tested with flex-2.5.4, as  
that is the version documented to be used.  I'm not a listed  
maintainer for this, but I hope my post encourages one to chime in.

Re: Patch pings

[Ian Lance Taylor]

Ben Elliston <bje@au1.ibm.com> writes:

> The following patches received negligible comment, let alone approval. I
> know they are in some of the less exciting parts of the compiler, so
> perhaps they require a GWP maintainer to approve them?  ;-)
> 
>   PATCH: silence warnings from gengtype-lex.c
>   http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00320.html

gcc/doc/install.texi says that we require flex 2.54 or later.  Ben,
can you confirm that the options you are adding are all supported by
flex 2.54?  If they are, then this patch is approved.

Thanks.

(David Edelsohn suggested on IRC that middle-end maintainers should be
permitted to approve patches to gen* files that generates file which
are part of the middle-end.  If anybody feels that this is
inappropriate, please let me know.)

Ian

Re: Patch pings

[Ben Elliston]

On Wed, 2007-01-17 at 10:54 -0800, Ian Lance Taylor wrote:

> gcc/doc/install.texi says that we require flex 2.54 or later.  Ben,
> can you confirm that the options you are adding are all supported by
> flex 2.54?  If they are, then this patch is approved.

I assume you mean 2.5.4?

At any rate, bother: they don't work with 2.5.4. :-(  I don't suppose it
would be possible to raise our minimum version requirement, would it?

Ben

Re: Patch pings

[Mike Stump]

On Jan 17, 2007, at 2:21 PM, Ben Elliston wrote:
> At any rate, bother: they don't work with 2.5.4. :-(  I don't  
> suppose it
> would be possible to raise our minimum version requirement, would it?

The file changes so infrequently and by so few people, that I  
actually don't mind bumping the version for flex even though my  
system hangs around 2.5.4 currently.  I'd propose that we allow the  
bump up to 2.5.31.  99% of developers won't even need to update their  
flex and no user would need to as we ship the output, right?

Any argument against?  (Did you run flex in the past 3 years for  
gcc?)  If not, maybe someone wouldn't feel bad approving the patch  
and doc update...  :-)

Re: Patch pings

[Ben Elliston]

On Wed, 2007-01-17 at 18:59 -0800, Mike Stump wrote:

> The file changes so infrequently and by so few people, that I  
> actually don't mind bumping the version for flex even though my  
> system hangs around 2.5.4 currently.  I'd propose that we allow the  
> bump up to 2.5.31.  99% of developers won't even need to update their  
> flex and no user would need to as we ship the output, right?

Right.  The stricter requirement I am proposing is pretty conservative:
I am proposing that we move up to a new point release of flex that is
coming up to its 4th birthday in March.  It's not exactly bleeding edge.

> Any argument against?  (Did you run flex in the past 3 years for  
> gcc?)  If not, maybe someone wouldn't feel bad approving the patch  
> and doc update...  :-)

I will, of course, need to write the doc update.

Ben

Re: Patch pings

[Ben Elliston]

> Right.  The stricter requirement I am proposing is pretty conservative:
> I am proposing that we move up to a new point release of flex that is
> coming up to its 4th birthday in March.  It's not exactly bleeding edge.

I think this discussion is taking place in a thread with an
uninteresting subject on the busy gcc-patches list.  I'll raise my idea
on gcc@ where it will be seen.

Ben

Re: Patch pings

[Ben Elliston]

On Wed, 2007-01-17 at 10:54 -0800, Ian Lance Taylor wrote:

> gcc/doc/install.texi says that we require flex 2.54 or later.  Ben,
> can you confirm that the options you are adding are all supported by
> flex 2.54?  If they are, then this patch is approved.

It works with flex 2.5.31, released on March 3, 2003.

Ben

Patch pings

[Richard Sandiford]

Update the POINTERS_EXTEND_UNSIGNED documentation:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01321.html

Fix a !TRULY_NOOP_TRUNCATION problem (keeping the current behaviour for
TRULY_NOOP_TRUNCATION targets):
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01411.html

Richard

Re: Patch pings

[Richard Guenther]

On 9/23/07, Richard Sandiford <rsandifo@nildram.co.uk> wrote:
> Update the POINTERS_EXTEND_UNSIGNED documentation:
> http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01321.html

This is ok.

>
> Fix a !TRULY_NOOP_TRUNCATION problem (keeping the current behaviour for
> TRULY_NOOP_TRUNCATION targets):
> http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01411.html

This also.

Thanks,
Richard.

> Richard
>

patch pings

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01060.html
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02247.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNqFOfAAoJEBRtltQi2kC7ijYH/ibLT2HNaFXjdE9SKT5Ih1JV
dTEWPnY7QBP5Xe6FVwZ09ibPCOxJsK7yGdQBYqy5gRQor8ebifI4kenwcBcdET/m
NogdM8DPWbuhgGda7cETNkru7FifSe9mRsKQGhNzVQl48oEKWmcGkm/l3a7gndfD
cX08lFzqIH1wcPWUqQPf6gcUMRE4W/0j92E4PEoIbigMoSIRFcduVouBlld8NLBV
aicTihAC+MFMVKSkpXGjMLCbn/HkNOyV9s9T+Or1/XuCIZy9zlB1JSfR/EJqVmPm
mNmg0bUrtzXN2uImL6ohIV32i732KKcNhNm/FupZTHfbI50nDc1h8SnCgEHc2t0=
=i7zA
-----END PGP SIGNATURE-----

Re: patch pings

[Bernd Schmidt]

On 04/15/2011 04:18 PM, Jeff Law wrote:

> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02247.html

I don't know. I sympathize with the goal, but I'm not too happy about
the structure of this patch. Doesn't this do the scan once for every
reload in an insn? It seems to me like the loop (or rather, a function
call to it) should at least be placed at the top of choose_reload_regs
rather than in allocate_reload_reg.

In my tests (i686-linux, compiling my standard set of testcases) the
patch appears to have, in general, very little effect on code quality.
It might on average be slightly better, but I've also seen several cases
where we do worse. If we go to so much effort to do scanning of
subsequent insns it ought to be possible to do better.

AFAICT the patch ignores whether the pseudo that's being reloaded will
be reloaded again in the current ebb - if not, it should get a "bad"
spill register, where "bad" in this case only includes hard regs that
don't currently hold a spilled pseudo. Likewise, once we've reloaded the
last occurrence of a pseudo in an ebb, we should forget the
reg_reloaded_contents to make sure we consider the spill reg good again.
However, I'm not sure whether changes such as these alone will reduce
the number of cases where the patch regresses.


Bernd

Re: patch pings

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/15/11 10:26, Bernd Schmidt wrote:
> On 04/15/2011 04:18 PM, Jeff Law wrote:
> 
>> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02247.html
> 
> I don't know. I sympathize with the goal, but I'm not too happy about
> the structure of this patch. Doesn't this do the scan once for every
> reload in an insn? It seems to me like the loop (or rather, a function
> call to it) should at least be placed at the top of choose_reload_regs
> rather than in allocate_reload_reg.
Perhaps.  As you noted in the original discussion we could do something
like save distance to next reuse or something like that in the reload
chain, the use that information to help drive selection of the reload
register.

I poked at it a little and it just didn't seem to be worth the
additional effort.

In reality while we potentially scan for each reload, the cost in
practice is very very small.

> 
> In my tests (i686-linux, compiling my standard set of testcases) the
> patch appears to have, in general, very little effect on code quality.
> It might on average be slightly better, but I've also seen several cases
> where we do worse. If we go to so much effort to do scanning of
> subsequent insns it ought to be possible to do better.
That is consistent with my tests.  Remember the main purpose was to
improve the predictability, the minor improvement in code generation was
a pleasant side effect.  And yes, it sometimes regressed as well, my
overall impression was it was a minor improvement.

I'm not going to push hard for these changes -- I'm comfortable keeping
them on my branch -- I've already spent more time on them than I can
reasonably justify :-)

Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNtexgAAoJEBRtltQi2kC7wvEH/15/GJwEZJXI5CV/Ra6ftsuc
oyr2ay6OeWNAxa3fg4G+0zBIxY7oCONxav8lm4vn9P49oDLj7XpUMou5QfKamihv
5BO29pfUz5MCQ7ZH68DKFtN+/nmLRRHs5MuFiPa6OHDNRlO8bmjeRcEoZGeZd9Dp
GES+lzWRS5dRxhv2BzLo9XsGbarGvQ1qeKhsRZhieSJS17nTVHIyc2tCJx7KOHGB
+Rn9ikuLywSmo87nT8DoSkKLxIHZ51vciHYpONMiBWH3WNLwCXzFKfLMzPTs68dX
PEu6yFUcfHMrT/17nPDGr6o/ExyY4bYJtImaYzCqg6xCdF3U3DQs2JVjMiDFBIg=
=Vjgk
-----END PGP SIGNATURE-----

patch pings

[Iyer, Balaji V]

Hello Everyone,	
	I would like to patch these two patches:

	http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00408.html -- _Cilk_for

	http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00116.html -- SIMD enabled functions for C++

They have been under review for a while now (~1 month). This is pretty much the last feature to make Cilk Plus feature-complete in trunk. I would greatly appreciate if anyone could take a look at it and approve it. It does not interfere with any other work (i.e. PASS things that are failing or fail things that are passing).

Thanks,

Balaji V. Iyer.