On Fri, Aug 05, 2016 at 08:31:45PM -0500, Segher Boessenkool wrote:
> On Sat, Aug 06, 2016 at 10:53:33AM +0930, Alan Modra wrote:
> > On Fri, Aug 05, 2016 at 06:01:47PM -0500, Segher Boessenkool wrote:
> > > I agree reg-reg moves should come after reg-mem moves, but is it such
> > > a good idea to
Am 07.08.2016 um 13:52 schrieb Andre Vehreschild:
Hi Andre,
attached patch fixes the ICE caused by a zero-sized string. Assigning
that string to a temporary variable obviously did not work out. The
patch fixes this by checking for zero-sized strings in SOURCE= and not
producing the code to assig
On Mon, Aug 08, 2016 at 01:36:51PM +1000, kugan wrote:
> diff --git a/gcc/tree-ssanames.h b/gcc/tree-ssanames.h
> index c81b1a1..6e34433 100644
> --- a/gcc/tree-ssanames.h
> +++ b/gcc/tree-ssanames.h
> @@ -43,6 +43,9 @@ struct GTY(()) ptr_info_def
> above alignment. Access only through the s
Hi Andre,
the patch is OK.
Ping.
Regards
Thomas
Ping!
On Friday 29 July 2016 05:14 PM, Pitchumani Sivanupandi wrote:
On Friday 29 July 2016 02:06 PM, Georg-Johann Lay wrote:
On 28.07.2016 13:50, Pitchumani Sivanupandi wrote:
On Tuesday 26 July 2016 06:00 PM, Georg-Johann Lay wrote:
On 26.07.2016 12:20, Pitchumani Sivanupandi wrote:
avr-gcc
On 08/04/2016 06:37 PM, Jonathan Wakely wrote:
I've been working on some changes to the libstdc++ manual recently.
A lot of the changes are just using DocBook markup with more semantic
meaning (e.g. or instead of using for
everything that should use a monospace font) but there are some
change
On 08/03/2016 10:17 AM, Georg-Johann Lay wrote:
Index: doc/extend.texi
===
--- doc/extend.texi (revision 238983)
+++ doc/extend.texi (working copy)
@@ -5957,6 +5957,25 @@ memory-mapped peripherals that may lie o
volatile in
On 07/25/2016 07:17 AM, Andre Vieira (lists) wrote:
[PATCH 0/7, GCC, V8M] ARMv8-M Security Extensions
Hello,
This is a respin of a previous patch series for ARMv8-M Security
Extensions. In this version I have removed one patch, rebased the rest
and changed some of them.
This patch series aims
Hi,
This patch tries to add nonnull_p attribute to ptr_info_def. As it
stands, range_info_def is bigger in size than ptr_info_def. Therefore
adding nonnull_p should not change the size.
I am setting this based on the VRP analysis. Right there is no uses for
this. But the idea is, this can b
On Mon, Aug 08, 2016 at 12:13:18PM +0930, Alan Modra wrote:
> This patch fixes a case where reload blindly assumes a subreg mem
> is OK if its address has been partially reloaded by
> legitimize_reload_address. The change ought to be fairly obvious
> considering that the analogous non-subreg case
This patch fixes a case where reload blindly assumes a subreg mem
is OK if its address has been partially reloaded by
legitimize_reload_address. The change ought to be fairly obvious
considering that the analogous non-subreg case only gives a win to
address_reloaded[i] == 1. Bootstrapped and regr
Hi All,
I was experimenting with using ccp mask and value to refine value_ranges
for SSA_NAME. Attached patch does this. This might be particularly
useful for early_vrp. Bootstrap on x86_64-linux-gnu is OK. However,
there are some test-cases (as shown below) are failing.
Is this worth inves
On Sun, Aug 7, 2016 at 8:18 AM, Matthias Klose wrote:
> On 07.08.2016 14:14, Andreas Schwab wrote:
>> That breaks ia64:
>>
>> ../../../libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error:
>> reference to undefined name 'randomTrap'
>> if randomTrap == 0 {
>> ^
>> ../../../libgo/g
Hi Richard,
In the attached version, I tried to address your suggestions from:
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00279.html
In ccp_finalize we do:
wide_int nonzero_bits = wide_int::from (val->mask, precision,
UNSIGNED) | val->value;
Si
On 5 August 2016 at 18:06, Martin Jambor wrote:
> Hi,
Hi Martin,
Thanks for the review. Please find my responses inline.
>
> generally speaking, the ipa-cp.c and ipa-cp.[hc] bits look reasonable,
> but I have a few comments:
>
> On Thu, Aug 04, 2016 at 12:06:18PM +0530, Prathamesh Kulkarni wrote:
On 08/06/2016 12:31 PM, Jakub Jelinek wrote:
On Fri, Aug 05, 2016 at 08:27:39AM -0700, Andrew Pinski wrote:
On Fri, Aug 5, 2016 at 12:32 AM, Martin Liška wrote:
On 08/05/2016 09:30 AM, Martin Liška wrote:
Hi.
Sorry for the mistake with the enum, that was silly ;)
New patch version also handl
On Mon, Jun 6, 2016 at 3:19 AM, Jan Hubicka wrote:
> Hi,
> while looking into profile mismatches introduced by the backward threading
> pass
> I noticed that the heuristics seems quite simplistics. First it should be
> profile sensitive and disallow duplication when optimizing cold paths. Second
On 07.08.2016 14:14, Andreas Schwab wrote:
> That breaks ia64:
>
> ../../../libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error:
> reference to undefined name 'randomTrap'
> if randomTrap == 0 {
> ^
> ../../../libgo/go/internal/syscall/unix/getrandom_linux.go:38:34: error:
> ref
To prevent further confusion: The patch-file
pr72698_1.patch is for trunk and the gcc-6-branch, the
pr72698_v5_1.patch is for gcc-5-branch.
Sorry for not pointing that out immediately.
- Andre
On Sun, 7 Aug 2016 13:52:34 +0200
Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes the
Hi all,
attached patch fixes the ICE by ensuring that when the SOURCE=/MOLD=
expression is an array-valued function call with no ref, the ref of
object to allocate is taken. The array properties nevertheless are
taken from the function's result.
Bootstraps and regtests ok on x86_64-linux-gnu/F23.
That breaks ia64:
../../../libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error:
reference to undefined name 'randomTrap'
if randomTrap == 0 {
^
../../../libgo/go/internal/syscall/unix/getrandom_linux.go:38:34: error:
reference to undefined name 'randomTrap'
r1, _, errno := sys
Hi all,
attached patch fixes the ICE caused by a zero-sized string. Assigning
that string to a temporary variable obviously did not work out. The
patch fixes this by checking for zero-sized strings in SOURCE= and not
producing the code to assign "nothing" to the temporary
variable and later to the
On August 6, 2016 9:09:08 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>As the testcase shows, the C FE can call relayout_decl even on
>FIELD_DECLs
>in certain cases. Trying to call only layout_decl on FIELD_DECL and
>relayout_decl on other decls would be insufficient, we'd need to repeat
>there mos
23 matches
Mail list logo
