On Thu, Nov 17, 2016 at 05:39:57PM -0800, Marek Polacek wrote:
> > Yes, there will be 119 SAVE_EXPRs, and when you -fdump-tree-original it,
> > it will be just insanely huge, but each SAVE_EXPR appears exactly twice
> > in its containing SAVE_EXPR and the second time cp_genericize_r sees
> > the SA
On Thu, 17 Nov 2016, Segher Boessenkool wrote:
> For code like the testcase in PR71785 GCC factors all the indirect branches
> to a single dispatcher that then everything jumps to. This is because
> having many indirect branches with each many jump targets does not scale
> in large parts of the c
On Fri, Nov 18, 2016 at 09:09:40AM +0100, Richard Biener wrote:
> > + /* Make a copy of BB, merge it into PRED. */
> > + basic_block copy = duplicate_block (bb, e, NULL);
> > + emit_barrier_after_bb (copy);
> > + reorder_insns_nobb (BB_HEAD (copy), BB_END (copy), BB_END (pred))
Hi Naveen,
On 18/11/16 05:30, Hurugalawadi, Naveen wrote:
Hi,
Please find attached the patch that fixes PR78382.
The "SYMBOL_SMALL_TLSGD" was not handled for ILP32.
Hence it generates error when compiled for ILP32.
The attached patch adds the support and handles it properly as expected
for ILP
On 17/11/16 20:41, Thomas Preudhomme wrote:
On 17/11/16 09:10, Kyrill Tkachov wrote:
On 16/11/16 18:09, Thomas Preudhomme wrote:
Hi,
I've rebased the patch to make arm_feature_set agree with type of FL_* macros
on top of trunk rather than on top of the optional -mthumb patch. That
involved
On 17/11/16 17:45, Segher Boessenkool wrote:
On Thu, Nov 17, 2016 at 04:50:46PM +, Kyrill Tkachov wrote:
Is loading/storing a pair as cheap as loading/storing a single register?
In that case you could shrink-wrap per pair of registers instead.
I suppose it can vary by microarchitecture. Fo
Hi Dominik,
On Thu, Nov 17, 2016 at 04:53:47PM +0100, Dominik Vogt wrote:
> +/* A convenience macro to determine whether a SIZE lies inclusively
> + within [1, RANGE], POS lies inclusively within between
> + [0, RANGE - 1] and the sum lies inclusively within [1, RANGE]. */
> +#define SIZE_POS
Eric Botcazou writes:
>> 2016-11-15 Richard Sandiford
>> Alan Hayward
>> David Sherwood
>>
>> * rtl.h (load_extend_op): Declare.
>> * rtlanal.c (load_extend_op): New function.
>
> I'd make it an inline function.
Sorry, I'd committed it before I got this message
Hi Kyrill,
Thanks for the comment.
Bootstrapped successfully on AArch64 (thunder) system.
And also regression tested on AArch64(thunder) with no regressions.
Thanks,
Naveen
Hi,
This is a rework of https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02005.html.
According to review comment, I extended the original patch and made it covering
last kind simplification of fold_cond_expr_with_comparison (Well, this patch
handles <, <=, > and >=. == will be handled by a follow
On Sun, Nov 13, 2016 at 08:02:41PM +0100, Martin Jambor wrote:
> @@ -143,6 +240,12 @@ init_enviroment_variables (void)
> suppress_host_fallback = true;
>else
> suppress_host_fallback = false;
> +
> + hsa_runtime_lib = getenv ("HSA_RUNTIME_LIB");
> + if (hsa_runtime_lib == NULL)
> +
Hi all,
This patch brings the new CPU support announcements in line with the format
used in the GCC 6 notes.
That is, rather than have a separate "The is now supported via
the..." entry for each new core
just list them and give a use example with the -mcpu,-mtune options.
Ok to commit?
Thank
On Sun, Nov 13, 2016 at 08:39:35PM +0100, Martin Jambor wrote:
> Hello,
>
> this patch adds a small file hsa-builtins.def which defines a few
> builtins that I then use in OpenMP lowering and expansion.
>
> After we split gridification stuff in omp-low.c to a separate file, we
> should be able to
On Sun, Nov 13, 2016 at 10:42:01PM +0100, Martin Jambor wrote:
> + size_t collapse = gimple_omp_for_collapse (for_stmt);
> + struct omp_for_data_loop *loops
> += (struct omp_for_data_loop *)
> +alloca (gimple_omp_for_collapse (for_stmt)
> + * sizeof (struct omp_for_data_loop));
U
Hi Bruce, Mike,
> On Fri, Nov 11, 2016 at 3:18 AM, Mike Stump wrote:
>>
>> No objections from me.
>>
> Or me. Thanks!
as discussed at length in the PR, the fixincludes route alone isn't
enough to get libsanitizer to build on Darwin 15: we stay with undefined
references to a function which had t
> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
>
> Thanks,
> Richard
>
>
> gcc/
> * rtlanal.c (load_extend_op): Move to...
> * rtl.h: ...here and make inline.
OK, thanks.
--
Eric Botcazou
On Thu, Nov 17, 2016 at 05:27:14PM +0800, Chung-Lin Tang wrote:
> I've updated the patch as you suggested.
> Here's the v2 of the first patch, mainly gimplify.c adjusted.
>
> About the ChangeLog issues, I'll make sure the final committed diffs will
> solve them.
Ok.
Jakub
Hi Jonathan,
> On 03/11/16 15:11 +0100, Rainer Orth wrote:
>>Fortunately, this is all easily fixed by wrapping the affected templates
>>in a new macro. That's what this patch does. The new libstdc++
>>acinclude.m4 test may well need wording changes in comments etc. and can
>>perhaps be shortened
On Fri, Nov 18, 2016 at 03:07:27AM -0600, Segher Boessenkool wrote:
> rtl_merge_blocks does not check rtl_can_merge_blocks_p (and you get a
> quite spectacular ICE when you get it wrong: everything between the two
> blocks is deleted :-) ). I'll make a separate patch that checks it
> (layout mode
> On 17 Nov 2016, at 21:19, Jeff Law wrote:
>
> On 11/08/2016 05:49 PM, Iain Sandoe wrote:
>>
>>> On 8 Nov 2016, at 13:39, Mike Stump wrote:
>>>
>>> On Nov 8, 2016, at 1:05 PM, Iain Sandoe
>>> wrote:
Simple for the simple case is already part of my patch, but
capability for t
Hi!
On Thu, Nov 17, 2016 at 05:31:40PM +0800, Chung-Lin Tang wrote:
> +#ifndef ACCEL_COMPILER
> + span = integer_one_node;
> +#else
> + if (!e_mask)
> +/* Not paritioning. */
> +span = integer_one_node;
...
This goes against the recent trend of avoiding #if/#ifdef guarded blocks
of code
On Thu, Nov 17, 2016 at 05:34:34PM +0800, Chung-Lin Tang wrote:
> Updated C/C++ front-end patches, adjusted as reviewed.
Jason is right, finish_omp_clauses will verify the tile operands
when !processing_template_decl are non-negative host INTEGER_CSTs,
so can't you just tsubst it like OMP_CLAUSE_C
On Sat, Nov 12, 2016 at 08:51:00AM -0800, Cesar Philippidis wrote:
> On 11/11/2016 02:34 AM, Jakub Jelinek wrote:
> > On Thu, Nov 10, 2016 at 06:46:46PM +0800, Chung-Lin Tang wrote:
>
> And here's the patch.
The patch doesn't look like OpenACC tile clause fortran support,
but bind/nohost clause C
On 17 November 2016 at 10:23, Kyrill Tkachov
wrote:
>
> On 09/11/16 12:58, Bernd Edlinger wrote:
>>
>> Hi!
>>
>>
>> This patch enables the ldrd/strd peephole rules unconditionally.
>>
>> It is meant to fix cases, where the patch to reduce the sha512
>> stack usage splits ldrd/strd instructions int
> From: Moore, Catherine [mailto:catherine_mo...@mentor.com]
> Sent: 17 November 2016 21:53
> To: Matthew Fortune; Toma Tabacu; Andrew Bennett; 'gcc-
> patc...@gcc.gnu.org'
> Cc: Moore, Catherine
> Subject: RE: [PATCH] MIPS: If a test in the MIPS testsuite requires standard
> library support check
On Fri, Nov 18, 2016 at 03:31:40AM -0600, Segher Boessenkool wrote:
> Hi Dominik,
>
> On Thu, Nov 17, 2016 at 04:53:47PM +0100, Dominik Vogt wrote:
> > +/* A convenience macro to determine whether a SIZE lies inclusively
> > + within [1, RANGE], POS lies inclusively within between
> > + [0, RA
On Fri, Nov 11, 2016 at 03:43:02PM -0800, Cesar Philippidis wrote:
> + error_at (OMP_CLAUSE_LOCATION (c),
> + "%qs specifies a conflicting level of parallelism",
> + omp_clause_code_name[OMP_CLAUSE_CODE (c)]);
> + inform (OMP_CLAUSE_LOCATION (c_le
On Fri, Nov 11, 2016 at 03:43:23PM -0800, Cesar Philippidis wrote:
> @@ -11801,12 +11807,11 @@ c_parser_oacc_shape_clause (c_parser *parser,
> omp_clause_code kind,
> }
>
> location_t expr_loc = c_parser_peek_token (parser)->location;
> - c_expr cexpr = c_parser_expr_no_c
On 16 November 2016 at 23:12, Andrew Burgess
wrote:
> * Mike Stump [2016-11-16 12:59:53 -0800]:
>
>> On Nov 16, 2016, at 12:09 PM, Andrew Burgess
>> wrote:
>> > My only remaining concern is the new tests, I've tried to restrict
>> > them to targets that I suspect they'll pass on with:
>> >
>> >
On Fri, Nov 11, 2016 at 03:44:07PM -0800, Cesar Philippidis wrote:
> --- a/gcc/fortran/gfortran.h
> +++ b/gcc/fortran/gfortran.h
> @@ -314,6 +314,15 @@ enum save_state
> { SAVE_NONE = 0, SAVE_EXPLICIT, SAVE_IMPLICIT
> };
>
> +/* Flags to keep track of ACC routine states. */
> +enum oacc_functi
On Fri, Nov 11, 2016 at 03:44:29PM -0800, Cesar Philippidis wrote:
> This patch contains new and adjusted, runtime and compiler test cases
> for the new OpenACC routine functionality.
>
> Is this ok for trunk?
Ok (though of course, if the diagnostic wording is adjusted, then
the test will need to
Hi Segher,
Thanks for the review,
> On 6 Nov 2016, at 22:09, Segher Boessenkool
> wrote:
>
> On Sun, Nov 06, 2016 at 12:13:16PM -0800, Iain Sandoe wrote:
>> 2016-11-06 Iain Sandoe
>>
>> PR target/57438
>> * config/i386/i386.c (ix86_code_end): Note that we emitted code where
>>
Toma Tabacu writes:
> The version below has a more detailed comment about marking tests as
> unsupported.
> Matthew, does it look good to you ?
>
> Also, should we document our expectations for the rest of do_what's
> format (elements 0 and 2) ?
I don’t think it is necessary. The explanation is
On 18/11/16 12:10 +0100, Rainer Orth wrote:
The change is OK in principle, but I'd prefer more meaningful names
for the macros ...
Fine with me: I know close to nothing of C++, so please bear with me ;-)
No problem, that's what the rest of us are here to help with :-)
I don't mind whether y
On Fri, Nov 18, 2016 at 09:09:40AM +0100, Richard Biener wrote:
> > This patch rewrites the algorithm to deal with this. It also makes it
> > simpler: it does not need the "candidates" array anymore, it does not
> > need RTL layout mode, it does not need cleanup_cfg, and it does not
> > need to ke
On Fri, Nov 18, 2016 at 09:29:13AM +, Kyrill Tkachov wrote:
> >So your COMPONENTS_FOR_BB returns both components in a pair whenever one
> >of those is needed? That should work afaics.
>
> I mean I still want to have one component per register and since
> emit_{prologue,epilogue}_components kn
Moore, Catherine writes:
> > gcc/testsuite/ChangeLog:
> >
> > 2016-11-15 Toma Tabacu
> >
> > * gcc.target/mips/branch-cost-1.c (dg-options): Use
> > (HAS_MOVN) instead
> > of isa>=4, in order to downgrade to R5.
> >
> > diff --git a/gcc/testsuite/gcc.target/mips/branch-cost-1.c
> > b/gc
Hi all,
the attached patch fixes an ice-on-valid problem, simply by removing
an assert. The generated code works as expected and the patch regtests
cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
2016-11-18 Janus Weil
PR fortran/78392
* trans-array.c (gfc_trans_auto_array_
On 17 November 2016 at 15:24, Richard Biener wrote:
> On Thu, 17 Nov 2016, Prathamesh Kulkarni wrote:
>
>> On 17 November 2016 at 14:21, Richard Biener wrote:
>> > On Thu, 17 Nov 2016, Prathamesh Kulkarni wrote:
>> >
>> >> Hi Richard,
>> >> Following your suggestion in PR78154, the patch checks i
On 11 November 2016 at 09:56, Richard Biener wrote:
> On Thu, 10 Nov 2016, Christophe Lyon wrote:
>
>> On 10 November 2016 at 09:34, Richard Biener wrote:
>> > On Wed, 9 Nov 2016, Christophe Lyon wrote:
>> >
>> >> On 9 November 2016 at 09:36, Bin.Cheng wrote:
>> >> > On Tue, Nov 8, 2016 at 9:11
On 15 November 2016 at 15:41, Yuri Rumyantsev wrote:
> Hi All,
>
> Here is patch for non-masked epilogue vectoriziation.
>
> Bootstrap and regression testing did not show any new failures.
>
> Is it OK for trunk?
>
> Thanks.
> Changelog:
>
> 2016-11-15 Yuri Rumyantsev
>
> * params.def (PARAM_VE
Currently, Binutils still comes with an AVR_TINY linker description file
which puts .rodata into RAM so that LDS is applicable for reading such
objects.
However, as these devices come with a linearised address model, linker
descriptions which put .rodata into flash are much more reasonable.
T
The attached patch makes the htm tests on s390 less sensitive to
spurious abort. Please check the commit comment for details. The
modified tests have been run once on a zEC12.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
gcc/testsuite/ChangeLog
* gcc.target/s390/htm-builtins-1.
Joseph Myers writes:
> On Tue, 15 Nov 2016, Richard Sandiford wrote:
>> Richard Sandiford writes:
>> > This isn't intended to change the behaviour, just rewrite the
>> > existing logic in a different (and hopefully clearer) way.
>> > The new form -- particularly the part based on the "block"
>> >
On 17/11/16 23:38 +0200, Ville Voutilainen wrote:
The first patch does everything but the container adaptor parts (which
are wrong in the p/r) and the tuple part (which is icky). The second
part does the tuple parts, and needs some serious RFC. I know
it's ugly as sin, but it works. I don't think
On 18 November 2016 at 15:54, Jonathan Wakely wrote:
> I agree, but if we'd just refused to support such undefined behaviour
> in stage 1 we wouldn't now be in a position of saying we can't change
> it in stage 3.
I want to support the code that the previous attempt breaks. I don't
think I can do
On Fri, Nov 18, 2016 at 01:09:24PM +0100, Dominik Vogt wrote:
> How about this:
>
> --
> /* A convenience macro to determine whether a SIZE lies inclusively
>within [1, UPPER], POS lies inclusively within between
>[0, UPPER - 1] and the sum lies inclusively within [1, UPPER].
>UPPER mu
On 10 November 2016 at 12:06, Pierre-Marie de Rodat wrote:
> On 11/09/2016 10:02 AM, Richard Biener wrote:
>>
>> Using scan-assembler-times on the dwarf?
>
>
> I always have a bad feeling about this kind of check as I imagine it can
> break very easily with legit changes. But I have nothing better
Hi Janus,
> the attached patch fixes an ice-on-valid problem, simply by removing an
> assert. ...
I have several instances in my test suite showing that the proposed patch
removes the ICE but generates wrong code:
pr42359, second test, => ICE on another place
pr54613, sixth and eighth tests,
On Fri, Nov 11, 2016 at 10:33:16AM +0100, Dominik Vogt wrote:
> gcc/ChangeLog
>
> * config/rs6000/rs6000.c (rs6000_stack_info): PR/77359: Properly align
> local variables in functions calling alloca. Also update the ASCII
> drawings
> * config/rs6000/rs6000.h (STARTING_FRA
On Fri, Nov 18, 2016 at 02:48:30PM +0100, Dominik Vogt wrote:
> gcc/testsuite/ChangeLog
>
> * gcc.target/s390/htm-builtins-1.c (DEFAULT_MAX_REPETITIONS)
> (DEFAULT_REQUIRED_QUORUM, NUM_WARMUP_RUNS): Lower requirements for
> successful test.
> * gcc.target/s390/htm-builtins-
The directories old/regexp and old/template were removed from the
master Go library in 2012 (https://golang.org/cl/5979046) but somehow
that was not reflected in libgo. This patch removes them from libgo.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
patc
On Fri, Nov 18, 2016 at 08:02:08AM -0600, Segher Boessenkool wrote:
> On Fri, Nov 18, 2016 at 01:09:24PM +0100, Dominik Vogt wrote:
> > IN_RANGE(POS...) makes sure that POS is a non-negative number
> > smaller than UPPER, so (UPPER) - (POS) does not wrap. Or is there
> > some case that the new mac
gcc.dg/tree-ssa/builtin-sprintf-2.c is showing intermittent failures, which
valgrind shows to be a read past the end of a buffer.
The root cause is that the on-demand substring loc code isn't set up
to cope with -ftrack-macro-expansion != 2 (the default).
In the failing case, it attempts to use t
On Wed, Nov 16, 2016 at 3:05 PM, Andreas Schwab wrote:
> On Nov 14 2016, Michael Matz wrote:
>
>> PR missed-optimization/77881
>> * combine.c (simplify_comparison): Remove useless subregs
>> also inside the loop, not just after it.
>> (make_compound_operation): Recognize s
It is very strange that this test failed on arm, since it requires
target avx2 to check vectorizer dumps:
/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 2 "vect" {
target avx2_runtime } } } */
/* { dg-final { scan-tree-dump-times "LOOP EPILOGUE VECTORIZED
\\(VS=16\\)" 2 "vect" { target avx
On 11/18/16 12:58, Christophe Lyon wrote:
> On 17 November 2016 at 10:23, Kyrill Tkachov
> wrote:
>>
>> On 09/11/16 12:58, Bernd Edlinger wrote:
>>>
>>> Hi!
>>>
>>>
>>> This patch enables the ldrd/strd peephole rules unconditionally.
>>>
>>> It is meant to fix cases, where the patch to reduce the
On 18 November 2016 at 16:46, Yuri Rumyantsev wrote:
> It is very strange that this test failed on arm, since it requires
> target avx2 to check vectorizer dumps:
>
> /* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 2 "vect" {
> target avx2_runtime } } } */
> /* { dg-final { scan-tree-dump-t
Hi,
On Fri, 18 Nov 2016, Bin.Cheng wrote:
> On Wed, Nov 16, 2016 at 3:05 PM, Andreas Schwab wrote:
> > On Nov 14 2016, Michael Matz wrote:
> >
> >> PR missed-optimization/77881
> >> * combine.c (simplify_comparison): Remove useless subregs
> >> also inside the loop, not just a
On 11/17/2016 10:34 PM, Sandra Loosemore wrote:
On 11/16/2016 09:49 AM, Martin Sebor wrote:
I'm looking for an approval of the attached patch.
I've adjusted the documentation based on Sandra's input (i.e.,
documented the negative of the option rather than the positive;
thank you for the review,
This patch to libgo changes the environment support routines to not
call __go_alloc/__go_free, but to instead use malloc/free. This code
just needs temporary buffers, it is natural to write it in C because
it calls setenv/unsetenv, and C code can safely call malloc/free but
with the future GC can
On 11/18/2016 12:58 AM, Jakub Jelinek wrote:
On Thu, Nov 17, 2016 at 05:32:31PM -0700, Martin Sebor wrote:
The point is warning on an alloca (0) may not be as clear cut as it
might seem. It's probably a reasonable thing to do on the host, but on
a target, which might be embedded and explicitly
Hi,
The if-conversion patch for PR77848 missed a case where an outer loop
should not be versioned for vectorization; this was caught by an assert
in tests recorded in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78413.
This patch fixes the problem by ensuring that both inner and outer loop
latches
On Fri, Nov 18, 2016 at 09:21:38AM -0700, Martin Sebor wrote:
> >In the libiberty/alloca.c, I don't see anything special about alloca (0).
> >Yes, alloca (0) reclaims garbage, but so does alloca (1) and alloca (4035).
> >alloca (0) just returns NULL after it. The diffutils link is the same
> >allo
On 2016.11.18 at 10:27 -0600, Bill Schmidt wrote:
> ===
> --- gcc/testsuite/gcc.dg/tree-ssa/pr78413.c (revision 0)
> +++ gcc/testsuite/gcc.dg/tree-ssa/pr78413.c (working copy)
> @@ -0,0 +1,35 @@
> +/* PR78413. These previously fai
Committed as r242595.
Thanks,
Toma Tabacu
Index: ChangeLog
===
--- ChangeLog (revision 242594)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2016-11-18 Toma Tabacu
+
+ * MAINTAINERS (Write After Approval): Add myself.
+
> On Nov 18, 2016, at 10:33 AM, Markus Trippelsdorf
> wrote:
>
> On 2016.11.18 at 10:27 -0600, Bill Schmidt wrote:
>> ===
>> --- gcc/testsuite/gcc.dg/tree-ssa/pr78413.c (revision 0)
>> +++ gcc/testsuite/gcc.dg/tree-ssa/pr78413.c
On 11/11/16 14:35, Kyrill Tkachov wrote:
On 08/11/16 13:36, Thomas Preudhomme wrote:
Ping?
Best regards,
Thomas
On 25/10/16 18:07, Thomas Preudhomme wrote:
Hi,
Currently when a user compiles for a thumb-only target (such as Cortex-M
processors) without specifying the -mthumb option GCC thr
Martin: are the changes to your test cases OK by you, or is there
a better way to rewrite them?
Thanks for looking into it!
Since the purpose of the test_sprintf_note function in the test is
to verify the location of the caret within the warnings I think we
should keep it if it's possible. Wou
On 11/18/16, Jakub Jelinek wrote:
> On Fri, Nov 18, 2016 at 09:21:38AM -0700, Martin Sebor wrote:
>> >In the libiberty/alloca.c, I don't see anything special about alloca
>> > (0).
>> >Yes, alloca (0) reclaims garbage, but so does alloca (1) and alloca
>> > (4035).
>> >alloca (0) just returns NULL
Hi,
On Thu, 17 Nov 2016, Bin.Cheng wrote:
> B) Depending on ilp, I think below test strings fail for long time with
> haswell:
> ! { dg-final { scan-tree-dump-times "Executing predictive commoning
> without unrolling" 1 "pcom" { target lp64 } } }
> ! { dg-final { scan-tree-dump-times "Executing
Hi,
This is a follow up patch for
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01898.html
It moves remaining simplification for (A == C1) ? A : C2 in
fold_cond_expr_with_comparison
to match.pd. Bootstrap and test on x86_64 and AArch64, is it OK?
Thanks,
bin
2016-11-17 Bin Cheng
*
Hi,
This is a rework of https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02007.html.
Though review comments suggested it could be merged with last kind
simplification
of fold_cond_expr_with_comparison, it's not really applicable. As a matter of
fact,
the suggestion stands for patch
@https://gcc
On Nov 18, 2016, at 3:13 AM, Iain Sandoe wrote:
>
> Thanks, at least I’m not going completely crazy ;-)
I'll just note for completeness that Jeff also couldn't explain a failure of
your latest patch. If you run into one, let me know.
> OK now for trunk?
Ok.
> open branches?
Ok.
On Fri, Nov 18, 2016 at 4:52 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 17 Nov 2016, Bin.Cheng wrote:
>
>> B) Depending on ilp, I think below test strings fail for long time with
>> haswell:
>> ! { dg-final { scan-tree-dump-times "Executing predictive commoning
>> without unrolling" 1 "pcom" { tar
Hi all,
attached patch fixes the issue which was given by nesting calls to typebound
procedures. The expression of the inner typebound procedure call was resolved
correctly, but in the case of it's having a class type the ref-list was
discarded. Leaving the list of references untouched, resolves t
Hi Andre,
Btw, when using the in gcc-7 available
polymorphic assign, then v6 is actually auto-allocated and the program runs
fine. So what are your opinions on the auto-allocation issue?
It is my experience that such questions can speedily and correctly
be answered by the regulars on comp.lan
Hi,
On Wed, 16 Nov 2016, Jakub Jelinek wrote:
> If inner is a MEM, make_extraction requires that pos is a multiple of
> bytes and deals with offsetting it. Or otherwise requires that pos is a
> multiple of BITS_PER_WORD and for REG inner it handles that too. But if
> inner is something diffe
Hi!
I'd like to ping 2 patches:
http://gcc.gnu.org/ml/gcc-patches/2016-11/msg01074.html
- C++ ABI - mangling of TLS aux symbols; either the posted
patch or one with if (abi_version_at_least (11))
http://gcc.gnu.org/ml/gcc-patches/2016-11/msg00351.html
- DWARF Solaris bootstrap fix
Jak
On 11/18/2016 09:29 AM, Jakub Jelinek wrote:
On Fri, Nov 18, 2016 at 09:21:38AM -0700, Martin Sebor wrote:
In the libiberty/alloca.c, I don't see anything special about alloca (0).
Yes, alloca (0) reclaims garbage, but so does alloca (1) and alloca (4035).
alloca (0) just returns NULL after it.
On Nov 18, 2016, at 4:33 AM, Iain Sandoe wrote:
>
> As discussed on IRC, I was under the impression that it is desired to move
> away from #ifdef towards if() and I have been adding those where locally
> things have been touched - in this case it was only partially possible.
>
> However, FAOD
Hi Mike,
> On 18 Nov 2016, at 17:16, Mike Stump wrote:
>
> On Nov 18, 2016, at 4:33 AM, Iain Sandoe wrote:
>>
>> As discussed on IRC, I was under the impression that it is desired to move
>> away from #ifdef towards if() and I have been adding those where locally
>> things have been touched
On 16/11/16 16:53, Szabolcs Nagy wrote:
> ieee_support_halting only checked the availability of status
> flags, not trapping support. On some targets the later can
> only be checked at runtime: feenableexcept reports if
> enabling traps failed.
>
> So check trapping support by enabling/disabling
On 11/14/2016 01:05 PM, Mark Wielaard wrote:
You can either choose a signed/unsigned form not giving the consumer
a hint about the size of the underlying constant value or one of the
sized data forms that don't give a hint about the value
representation/signedness. So in both cases the consumer l
I think restoring bootstrap is likely a good thing.
On Fri, Nov 18, 2016 at 2:45 AM, Rainer Orth
wrote:
>
> I guess this is ok for mainline now to restore bootstrap?
Hi Christophe,
On 11/18/2016 03:03 PM, Christophe Lyon wrote:
Hi,
Part of the new testcase added with this commit fails on arm* targets:
g++.dg/pr78112.C scan-assembler-times DW_AT_object_pointer 37
Thank you for the report.
As I said on the bugzilla
(https://gcc.gnu.org/bugzilla/show_b
On Fri, Nov 18, 2016 at 10:14:09AM -0700, Martin Sebor wrote:
> Because people make mistakes and warnings help us avoid them (isn't
> that obvious?) Just because we get it right most of the time doesn't
> mean we get right all of the time. The papers and exploits I pointed
> to should provide amp
On Fri, Nov 18, 2016 at 05:19:31PM +, Iain Sandoe wrote:
> I’d like to do that; is there a way to force a jump table for a limited set
> of cases?
> (the example was about the smallest I could get where GCC elected to produce
> a jump table instead of branches)
--param case-values-threshol
2016-11-17 20:01 GMT+03:00 Jeff Law :
> On 11/17/2016 09:56 AM, Ilya Verbin wrote:
>>
>> 2016-11-17 18:50 GMT+03:00 Rainer Orth :
>>>
>>> Rainer Orth writes:
>>>
I happened to notice that my libcilkrts SPARC port has been applied
upstream. So to reach closure on this issue for the GCC 7
On 11/18/2016 09:01 AM, Martin Sebor wrote:
On 11/17/2016 10:34 PM, Sandra Loosemore wrote:
On 11/16/2016 09:49 AM, Martin Sebor wrote:
I'm looking for an approval of the attached patch.
I've adjusted the documentation based on Sandra's input (i.e.,
documented the negative of the option rather
On Nov 18, 2016, at 2:45 AM, Rainer Orth wrote:
> So the current suggestion is to combine my fixincludes patch and Jack's
> patch to disable use if !__BLOCKS__.
> I guess this is ok for mainline now to restore bootstrap?
I think we are down to everyone likes this, Ok. The big question is, does
This patch simply moves the schedt (aka Sched) type and the sched
variable from C to Go. This is a step toward further changes.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
On Fri, Nov 11, 2016 at 03:37:17PM +, James Greenhalgh wrote:
>
> Hi,
>
> This patch set enables the _Float16 type specified in ISO/IEC TS 18661-3
> for AArch64 and ARM. The patch set has been posted over the past two months,
> with many of the target-independent changes approved. I'm reposti
On 11/08/2016 08:13 PM, Martin Sebor wrote:
The -fprintf-return-value optimization has been disabled since
the last time it caused a bootstrap failure on powerpc64le. With
the underlying problems fixed GCC has bootstrapped fine on all of
powerpc64, powerpc64le and x86_64 and tested with no regre
On 11/17/2016 05:32 PM, Martin Sebor wrote:
I confess I haven't heard of such an implementation before but after
some searching I have managed to find a few examples of it online,
such as in QNX or in the BlackBerry SDK, or in the GCC shipped by
Texas Instruments. For instance:
I have the "adva
On 11/18/2016 12:58 AM, Jakub Jelinek wrote:
On Thu, Nov 17, 2016 at 05:32:31PM -0700, Martin Sebor wrote:
The point is warning on an alloca (0) may not be as clear cut as it
might seem. It's probably a reasonable thing to do on the host, but on
a target, which might be embedded and explicitly
On 11/18/2016 10:38 AM, Sandra Loosemore wrote:
On 11/18/2016 09:01 AM, Martin Sebor wrote:
On 11/17/2016 10:34 PM, Sandra Loosemore wrote:
On 11/16/2016 09:49 AM, Martin Sebor wrote:
I'm looking for an approval of the attached patch.
I've adjusted the documentation based on Sandra's input (i
On 11/18/2016 11:52 AM, Martin Sebor wrote:
I think it would be be ideal if all the options were sorted the same
way in all sections. Is there some command to have texinfo sort them
for us? If not, can we write a script to sort them, either each time
just before generating the docs or manually
On Fri, Nov 18, 2016 at 9:42 AM, Mike Stump wrote:
> On Nov 18, 2016, at 2:45 AM, Rainer Orth
> wrote:
>> So the current suggestion is to combine my fixincludes patch and Jack's
>> patch to disable use if !__BLOCKS__.
>
>> I guess this is ok for mainline now to restore bootstrap?
>
> I think we
Hi!
On Thu, Nov 17, 2016 at 02:18:57PM -0800, H.J. Lu wrote:
> > Hi HJ, could you please commit it?
>
> Done.
I'm seeing lots of ICEs with this.
E.g. reduced:
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
typedef unsigned char __mmask8;
typedef float __v4sf __attr
1 - 100 of 137 matches
Mail list logo
