Our implementation of the stack probe requires the probe interval to
be used as displacement in an address operand. The maximum probe
interval currently is 64k. This would exceed short displacements.
Trim that value down to 4k if that happens. This might result in too
many probes being generated
Hi.
It's quite obvious fix, fixes following param explanations:
The minimum stride ratio for loop interchange to be profitable
size of tiles for loop blocking.
maximum number of parameters in a SCoP.
maximum number of arrays per scop.
maximum number of isl operations, 0 means unlimited
maximum nu
Ok, so I discussed that with Honza, the patch does not make sense any longer.
Reason is that histograms are used in RTL expansion in order to provide
hint for memcpy, memset-like operations.
Please ignore the patch.
Martin
On 09/08/18 06:56 +0200, Sebastian Huber wrote:
On 08/08/18 16:33, Jonathan Wakely wrote:
On 08/08/18 16:22 +0200, Ulrich Weigand wrote:
Jonathan Wakely wrote:
Aha, so newlib was using memalign previously:
@@ -53,20 +54,24 @@ aligned_alloc (std::size_t al, std::size_t sz)
#else
extern "C"
Hi.
This patch adds an argument to the strip predictor pass. Early
version strips only selected hints that are not reliable when
inlining happens. The rest is striped in late tree passes.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Martin
gcc/Ch
On 08/07/2018 02:23 PM, Jan Hubicka wrote:
>> 2018-07-24 Martin Liska
>>
>> PR target/83610
>> * builtin-types.def (BT_FN_LONG_LONG_LONG_DOUBLE): New type.
>> * builtins.c (expand_builtin_expect_with_probability):
>> New function.
>> (expand_builtin): Handle also B
Hi.
One obvious one, error was introduced by my commit r245788.
Martin
gcc/ChangeLog:
2018-08-09 Martin Liska
PR c/86895
* common.opt: Remove extra line.
---
gcc/common.opt | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/common.opt b/gcc/common.opt
index 5bb645291cf
On Thu, 9 Aug 2018, Martin Sebor wrote:
> But for a declaration at file scope and without an initializer,
> GCC warns that the array is assumed to have one element, but
> then gives an error when sizeof is applied to it:
That's how tentative definitions (C17 6.9.2) work. There's an implicit
ini
Hi Jonathan,
> Committed to trunk, gcc-8-branch and gcc-7-branch.
>
> Rainer, please let me know if this still works on Solaris 10, thanks.
I ran i386-pc-solaris2.1[01] and sparc-sun-solaris2.1[01] bootstraps
last night: no regressions.
Thanks.
Rainer
--
---
Andreas Schwab wrote:
> -void
> -m68k_final_prescan_insn (rtx_insn *insn ATTRIBUTE_UNUSED,
> - rtx *operands, int n_operands)
> +static void
> +m68k_adjust_decorated_operand (rtx op)
FWIW, the prototype for m68k_final_prescan_insn in m68k-protos.h was
not removed.
Gunther
Hi,
over the years we reworked and improved the code in decl.c checking
gotos quite a bit. Lately, in some specific unsafe cases, identify_goto
issues upfront an error instead of a permerror, whereas it used to
always issue a permerror. Over the last weeks a few colleagues of mine
noticed tha
> Hi.
>
> This patch adds an argument to the strip predictor pass. Early
> version strips only selected hints that are not reliable when
> inlining happens. The rest is striped in late tree passes.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be install
> gcc/ChangeLog:
>
> 2018-08-09 Martin Liska
>
> PR target/83610
> * builtin-types.def (BT_FN_LONG_LONG_LONG_DOUBLE): Add new
> function type.
> * builtins.c (expand_builtin_expect_with_probability):
> New function.
> (expand_builtin_expect_with_probab
Hi Bernd,
> On 07 Aug 2018, at 19:10, Bernd Edlinger wrote:
>
>>> procedure Array9 is
>>> I see that "1234" is put in the merge section,
>>> but V1 is not. Maybe because of the alignment requirement?
>>>
>>> But it sould not be much different from the C test case,
>>> which is now able to mer
Some of the carryin insn patterns are missing a register constraint.
That means that the register allocator can pick practically anything
to hold that value, including memory locations, or registers of the
wrong class.
PR target/86887
* config/aarch64/aarch64.md (add3_carryinC_zer
> On Aug 7, 2018, at 2:25 PM, Will Schmidt wrote:
>
> Hi
> Enable GIMPLE folding of the vec_splat() intrinsic.
>
> For review.. feedback is expected. :-)
>
> I came up with the following after spending some time poking around
> at the tree_vec_extract() and vector_element() functions as seen
On 08/01/18 22:43, Joseph Myers wrote:
> On Wed, 1 Aug 2018, Marek Polacek wrote:
>
>> I guess you want XALLOCAVAR or XNEWVAR.
>
> Not XALLOCAVAR; GCC supports string constants up to 2 GB (minus one byte),
> which is far too much to put on the stack.
>
I assume you want me to use XNEWVEC/XDELET
The handling of outer-loop uses of inner-loop definitions assumed
that anything that wasn't a PHI would be a gassign, but as the test
shows, it's also possible for it to be a gcall.
Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf and
x86_64-linux-gnu. Applied as obvious to trun
While working on PR 86871, I noticed we were being overly restrictive
when handling variable-length vectors. For:
for (i : ...)
{
res = ...;
for (j : ...)
res op= ...;
a[i] = res;
}
we don't need a reduction operation (although we do for double
reductions like
The series to remove vinfo_for_stmt also removed tests of
flow_bb_inside_loop_p if the call was simply testing whether the
statement was in the vectorisation region. I'd tried to keep calls
that were testing whether the statement was in a particular loop
(inner or outer), but messed up in vect_is_
Hello,
on x86-64, 32-bit division by constants uses mulsi3_highpart pattern that
turns into 'mull ' instruction with source implicitly in eax and
result in edx:eax. However, using 64-bit multiplication with zero-extended
source would be preferable, as the imulq instruction accepts the magic
multi
TestMemoryProfiler uses a too restrictive pattern that fails to match
backtraces that contain two tabs after the function address. That can
happen when the formatted addresses are of different length:
0: 0 [1: 2097152] @ 0x1746c 0x134a00 0x13450e 0x134fd8 0x84396
0x84892 0x17526
When tm.texi.in is updated in the source tree, the following message
gets displayed:
Verify that you have permission to grant a GFDL license for all
new text in tm.texi, then copy it to /gcc/doc/tm.texi.
Having been myself and some colleagues confused several time by that
message as to what tm.te
On Thu, 9 Aug 2018, Thomas Preudhomme wrote:
> 2018-08-09 Thomas Preud'homme
>
> * Makefile.in: Clarify which tm.texi to copy over to assert the
> right to grant a GFDL license for all.
OK.
--
Joseph S. Myers
jos...@codesourcery.com
This patch adds a left margin to the lines of source (and annotations)
printed by diagnostic_show_locus, so that e.g. rather than:
test.c: In function 'test':
test.c:12:15: error: 'struct foo' has no member named 'm_bar'; did you mean
'bar'?
return ptr->m_bar;
^
On Thu, 9 Aug 2018, David Malcolm wrote:
> This patch adds a left margin to the lines of source (and annotations)
> printed by diagnostic_show_locus, so that e.g. rather than:
To confirm: if the lines contain tabs anywhere, will the code replace them
by spaces when a margin is added to ensure th
On August 9, 2018 4:40:41 PM GMT+02:00, Richard Sandiford
wrote:
>While working on PR 86871, I noticed we were being overly restrictive
>when handling variable-length vectors. For:
>
> for (i : ...)
>{
> res = ...;
> for (j : ...)
>res op= ...;
> a[i] = res;
>}
>
On August 9, 2018 4:37:57 PM GMT+02:00, Richard Sandiford
wrote:
>The handling of outer-loop uses of inner-loop definitions assumed
>that anything that wasn't a PHI would be a gassign, but as the test
>shows, it's also possible for it to be a gcall.
>
>Tested on aarch64-linux-gnu (with and withou
On Thu, 2018-08-09 at 15:40 +, Joseph Myers wrote:
> On Thu, 9 Aug 2018, David Malcolm wrote:
>
> > This patch adds a left margin to the lines of source (and
> > annotations)
> > printed by diagnostic_show_locus, so that e.g. rather than:
>
> To confirm: if the lines contain tabs anywhere, wi
On Aug 09 2018, Gunther Nikl wrote:
> FWIW, the prototype for m68k_final_prescan_insn in m68k-protos.h was
> not removed.
Thanks, fixed.
Andreas.
* config/m68k/m68k-protos.h (m68k_final_prescan_insn): Remove
prototype.
diff --git a/gcc/config/m68k/m68k-protos.h b/gcc/config/m6
On 03/08/18 23:44, Sandra Loosemore wrote:
> I've checked in this patch to fix the c-c++-common/spec-barrier-1.c test
> failure on nios2. Per previous discussions about Spectre
> vulnerabilities with Altera/Intel, this architecture is not affected so
> no special handling is required here.
>
> -S
This should have been committed with the most recent DOM change.
DOM compromises this test now that it uses the EVRP range data to
discover more constants.
The fix is trivial, disable DOM for this test.
Committed to the trunk.
Jeff
commit 08482a36034ea41b202c26589fa0907f8c25ff90
Author: law
Dat
On 08/09/2018 10:25 AM, Andreas Schwab wrote:
> On Aug 09 2018, Gunther Nikl wrote:
>
>> FWIW, the prototype for m68k_final_prescan_insn in m68k-protos.h was
>> not removed.
>
> Thanks, fixed.
>
> Andreas.
>
> * config/m68k/m68k-protos.h (m68k_final_prescan_insn): Remove
> prototyp
On Thu, Aug 9, 2018 at 8:03 AM, Andreas Schwab wrote:
> TestMemoryProfiler uses a too restrictive pattern that fails to match
> backtraces that contain two tabs after the function address. That can
> happen when the formatted addresses are of different length:
Your patch seems to be whitespace o
Here is a patch to improve Debug mode safe iterator move semantic.
To summarize where we used to have N mutex locks we now have N - 1.
For instance move constructor used to lock mutex twice, now it only does
it once. Note that move constructor or move assignment operator are
currently
>> + bool one_2_one_ascii
>> += (target_to_host_charmap[0] == 1 && target_to_host ('a') ==
>> 97);
> Hmm. Is this really sufficient?I have nowhere near enough knowledge
> of the potential target character sets to know if this is sufficiently
> tight.
Shouldn't it be targ
Richard Sandiford writes:
> The series to remove vinfo_for_stmt also removed tests of
> flow_bb_inside_loop_p if the call was simply testing whether the
> statement was in the vectorisation region. I'd tried to keep calls
> that were testing whether the statement was in a particular loop
> (inner
On Thu, 2018-08-09 at 11:45 -0400, David Malcolm wrote:
> On Thu, 2018-08-09 at 15:40 +, Joseph Myers wrote:
> > On Thu, 9 Aug 2018, David Malcolm wrote:
> >
> > > This patch adds a left margin to the lines of source (and
> > > annotations)
> > > printed by diagnostic_show_locus, so that e.g.
On 08/08/2018 10:14 PM, Jeff Law wrote:
On 08/04/2018 12:46 PM, Martin Sebor wrote:
The sprintf handling of wide characters neglects to consider
that calling the function may fail due to a conversion error
(when the wide character is invalid or not representable in
the current locale). The hand
On Mon, Aug 06, 2018 at 12:02:31AM +1000, Jason Merrill wrote:
> > OK -- see the patch below. Now, I'm not crazy about adding another bit
> > to struct conversion, but reusing any of the other bits didn't seem
> > safe/possible. Maybe it'll come in handy when dealing with this problem
> > for fun
On Thu, 2018-08-09 at 08:53 -0500, Bill Schmidt wrote:
> > On Aug 7, 2018, at 2:25 PM, Will Schmidt wrote:
> >
> > Hi
> > Enable GIMPLE folding of the vec_splat() intrinsic.
> >
> > For review.. feedback is expected. :-)
> >
> > I came up with the following after spending some time poking aroun
On Wed, 8 Aug 2018, Martin Sebor wrote:
> Done in the attached patch. I've also avoided dealing with
> zero-length arrays and added tests to make sure their size
> stays is regardless of the form of their initializer and
> the appropriate warnings are issued.
The C front-end changes in this patc
On Thu, 9 Aug 2018, Bernd Edlinger wrote:
> On 08/01/18 22:43, Joseph Myers wrote:
> > On Wed, 1 Aug 2018, Marek Polacek wrote:
> >
> >> I guess you want XALLOCAVAR or XNEWVAR.
> >
> > Not XALLOCAVAR; GCC supports string constants up to 2 GB (minus one byte),
> > which is far too much to put on
On Thu, 2 Aug 2018, David Malcolm wrote:
> (a) the c-format.c changes (Joseph?), and
The c-format.c changes are OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, 22 Jun 2018, Steve Ellcey wrote:
> I can see both sides of this and don't feel strongly one way or the
> other. I have attached a new patch that does allow for the use of just
> -l options to force the linker to be called.
I don't think this patch achieves the desired semantics.
My unde
These aliases are placed in the top-level header, e.g. not
. This ensures that they refer to whichever of
std::vector or __debug::vector or __profile::vector is in use when the
header is included.
* include/std/deque (std::pmr::deque): Declare alias.
* include/std/forward_list (s
On Thu, Aug 9, 2018 at 5:00 PM, Alexander Monakov wrote:
> Hello,
>
> on x86-64, 32-bit division by constants uses mulsi3_highpart pattern that
> turns into 'mull ' instruction with source implicitly in eax and
> result in edx:eax. However, using 64-bit multiplication with zero-extended
> source
47 matches
Mail list logo
