From: Trevor Saunders
Hi,
the idea in the pr of providing a warning that tells people where they can add
override seems reasonable to me.
bootstrapped + regtested x86_64-unknown--linux-gnu (new test passes), ok?
Trev
c-family/
* c.opt (Wsuggest-override): New option.
cp/
*
From: Trevor Saunders
Hi,
I'll claim this is kind of a bug fix in so much as excessive gc allocation and
use of tree_list is a bug.
bootstrapped + regtested x86_64-unknown-linux-gnu, ok?
Trev
cp/
* class.c (warn_hidden): Use auto_vec instead of tree_list to
hold base_fndecls
On Wed, Nov 26, 2014 at 09:49:52AM -0500, David Malcolm wrote:
> On Wed, 2014-11-26 at 09:13 +0100, Uros Bizjak wrote:
> > Hello!
> >
> > > cgraph*.c and ipa-*.c use xstrdup on strings when dumping them via
> > > fprintf, leaking all of the duplicated buffers.
> > >
> > > Is/was there a reason for
OK applying to arm/embedded-4_9-branch, though you still need
maintainer approval into trunk.
- Joey
On Wed, Nov 26, 2014 at 11:43 AM, Hale Wang wrote:
> Hi,
>
> This patch ports the aeabi_idiv routine from Linaro Cortex-Strings
> (https://git.linaro.org/toolchain/cortex-strings.git), which was
The AIX ABI unfortunately does not use natural alignment. Type
"double" is 4 word aligned. However, the alignment of structs with a
first member of double are bumped to doubleword alignment. This
exactly conflicts with the testcase.
Thanks, David
* g++.dg/ext/alignof2.C: xfail-run-if o
First independent infrastructure patch for the branch. These sort of
patches I will commit to the branch without any tree-type specific
changes so I can maintain it as a patch to submit in stage 1 independent
of the overall larger change. I'll make the tree-type specific changes
last.
dec
If necessary to add related test case, please let me know.
Thanks.
Send from Lenovo A788t.
Jakub Jelinek wrote:
>On Mon, Nov 24, 2014 at 04:28:10PM +0800, Chen Gang wrote:
>> On 11/24/14 15:41, Jakub Jelinek wrote:
>> > On Sun, Nov 23, 2014 at 09:13:27AM +0800, Chen Gang wrote:
>>
>> [...]
>>
OK, I shall send related test case within two weeks (2014-12-10).
Thanks.
Send from Lenovo A788t.
Joseph Myers wrote:
>On Thu, 27 Nov 2014, Chen Gang wrote:
>
>> The original length 18 is not enough for HOST_WIDE_INT printing, need
>> use 20 instead of.
>>
>> Also need additional bytes for pr
On Mon, Nov 24, 2014 at 4:23 PM, H.J. Lu wrote:
> On Fri, Nov 21, 2014 at 1:32 PM, Vladimir Makarov wrote:
>> The following patch fixes PR63897. The details can be found on
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63897
>>
>> The patch was successfully bootstrapped and tested on x86 an
On Tuesday 2014-11-11 20:17, David Malcolm wrote:
> The attached patch adds a news entry about the JIT merge to the
> frontpage of the website.
Yes. Except you may want to add your name to the entry as we
have in some older examples. Kudos where kudos is due. :-)
Oh, and gcc/doc/contrib.texi pr
On Wednesday 2014-11-26 11:17, Terry Guo wrote:
> This patch will document support and tuning for Cortex-M7 in GCC 5.0
> changes. Is it ok to commit?
Looks good to me.
Thanks,
Gerald
On 09 Oct 08:25, H.J. Lu wrote:
> On Thu, Oct 9, 2014 at 1:37 AM, Uros Bizjak wrote:
> > On Thu, Oct 9, 2014 at 10:25 AM, Kirill Yukhin
> > wrote:
> >> On 08 Oct 23:02, Petr Murzin wrote:
> >>> Hi,
> >>> I have measured performance impact on Haswell platform according to this
> >>> input:
> >>>
On Wed, Nov 26, 2014 at 2:00 PM, Andrew Pinski wrote:
> Hi,
> The problem here is lra_substitute_pseudo calls gen_rtx_SUBREG with
> a VOIDmode (const_int) argument but really it should not be calling
> gen_rtx_SUBREG directly instead it should be using
> gen_lowpart_if_possible. This patch fixe
Hi,
The problem here is lra_substitute_pseudo calls gen_rtx_SUBREG with
a VOIDmode (const_int) argument but really it should not be calling
gen_rtx_SUBREG directly instead it should be using
gen_lowpart_if_possible. This patch fixes that and adds a testcase
that had happened on x86_64.
OK? I bo
On Wed, Nov 26, 2014 at 11:14:36AM -0700, Jeff Law wrote:
> >Are you talking about create_log_links? There can be no duplicates there
> >(anymore), that would be multiple defs of the same reg in the same insn,
> >indeed.
> Yes, I was referring to the code in create_log_links. You dropped the
> c
Another member of the C++ committee playing with our new support for
variable templates noted that we didn't allow partial specialization of
them. Fixed thus.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit d85e489036f70718a12063345db0894797252938
Author: Jason Merrill
Date: Wed Nov 2
This pulls in the missing Binutils pieces into the ./config
directory. Contains these missing Binutils changes:
2014-08-14 Alan Modra
* plugins.m4: Test for dlfcn.h or windows.h here to set default
for --enable-plugins. Report error if someone tries to enable
plugins o
2014-11-26 Jan-Benedict Glaw
* configure: Regenerate.
---
ChangeLog | 4
configure | 14 --
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index f5ce738..4c8adff 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2014-11-26
GCC and Binutils had a common ./configure.ac after this commit:
commit 08d081652f50df83f7e9768f8dbb7a99b0df50a2
Author: sandra
Date: Wed May 14 23:20:59 2014 +
2014-05-14 Sandra Loosemore
* configure.ac (target_makefile_frag): Set for nio
2014-11-26 Jan-Benedict Glaw
* config/ChangeLog: Merge entries from Binutils
---
config/ChangeLog | 15 +++
1 file changed, 15 insertions(+)
diff --git a/config/ChangeLog b/config/ChangeLog
index ab3a773..2cbc885 100644
--- a/config/ChangeLog
+++ b/config/ChangeLog
@@ -26,
On Mon, 2014-11-24 12:43:40 -0700, Jeff Law wrote:
[Merging top-level configury files from Binutils]
> It's pretty isolated stuff (in terms of what clauses are being
> changed in the configure bits), so I'm not too worried about
> breaking anything. We can reach out to Joel to ensure the RTEMS
>
On Wed, Nov 26, 2014 at 10:20:39PM +0100, Richard Biener wrote:
> Well, if you want to aggressively prune unused bits then you could
> "back-propagate" the shift count value-range.
>
> And note that all the frontend shorten-optimizations should move to the
> middle-end.
>
> That said, instead o
Hi, Sandra.
FWIW, I tried this patch on A15 Juno with Coremark and any difference, if
any, between specifying this option and not was below 1%.
Cheers,
--
Evandro Menezes Austin, TX
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patc
On November 26, 2014 8:33:52 PM CET, Jakub Jelinek wrote:
>On Wed, Nov 26, 2014 at 02:25:54PM -0500, Jason Merrill wrote:
>> How about converting the rhs to unsigned int if it is already
>unsigned?
>
>That is fine. I'm just worried about the casts to wider types.
>So perhaps just promote and cast
On November 26, 2014 8:25:54 PM CET, Jason Merrill wrote:
>How about converting the rhs to unsigned int if it is already unsigned?
Does the standard say so? I think not.
IMHO it's not the front ends business to do this. And I don't see how it helps
either.
Richard.
>Jason
On Thu, 27 Nov 2014, Chen Gang wrote:
> The original length 18 is not enough for HOST_WIDE_INT printing, need
> use 20 instead of.
>
> Also need additional bytes for printing related prefix and suffix, and
> give a related check.
>
> It passes testsuite under fedora 20 x86_64-unknown-linux-gnu.
The original length 18 is not enough for HOST_WIDE_INT printing, need
use 20 instead of.
Also need additional bytes for printing related prefix and suffix, and
give a related check.
It passes testsuite under fedora 20 x86_64-unknown-linux-gnu.
2014-11-27 Chen Gang
* c-family/c-cppbuil
Looks good to me.
Thanks!
On Wed, Nov 26, 2014 at 10:43 PM, Jakub Jelinek wrote:
> On Fri, Nov 21, 2014 at 04:20:44PM +0400, Dmitry Vyukov wrote:
>> Yes, I think it's the way to go.
>> I've just committed the following revision to clang that removes -pie
>> when compiling with tsan:
>> http://llv
On Fri, Nov 21, 2014 at 04:20:44PM +0400, Dmitry Vyukov wrote:
> Yes, I think it's the way to go.
> I've just committed the following revision to clang that removes -pie
> when compiling with tsan:
> http://llvm.org/viewvc/llvm-project?view=revision&revision=222526
> The tests in llvm tree pass wit
On 11/26/14 09:27, Tobias Burnus wrote:
On Wed, Nov 26, 2014 at 04:55:40PM +0100, Tobias Burnus wrote:
>This patch adds a configure check for
isl_schedule_constraints_compute_schedule,
>which is new in ISL 0.13 - and uses it for conditional compilation.
Repeating the test on a massively multic
Hi!
I've looked at which tests are still too expensive
on heavily loaded many thread configurations (where other threads
during normal testing run many other tests), and found these:
The patch attempts to limit number of target or parallel regions
to something smaller than hundreds or thousands.
On Wed, Nov 26, 2014 at 02:25:54PM -0500, Jason Merrill wrote:
> How about converting the rhs to unsigned int if it is already unsigned?
That is fine. I'm just worried about the casts to wider types.
So perhaps just promote and cast to int if the promoted type is
signed or unsigned if it is unsig
OK.
Jason
Hi Manuel,
Manuel López-Ibáñez wrote:
I think the changes to the common diagnostics part could be as simple as:
Good – that's simpler than I had feared.
However, I'm less familiar with the Fortran buffering mechanism.
I am not sure you find someone who really is. At least I also have
troub
How about converting the rhs to unsigned int if it is already unsigned?
Jason
Hi,
On 11/26/2014 05:24 PM, Jason Merrill wrote:
On 11/24/2014 01:55 PM, Paolo Carlini wrote:
in this rejects-valid, as part of build_user_type_conversion_1,
standard_conversion is called by implicit_conversion with a *null* expr,
thus the condition in standard_conversion
/* [conv.ptr]
Hi!
The testcase shows that when expanding ARRAY_REF from a const static var
with initializer that contains COMPOUND_LITERAL_EXPR, we can try to expand
COMPOUND_LITERAL_EXPR even when modifier is not EXPAND_INITIALIZER (it is
EXPAND_SUM in that testcase, but could be many others).
While gimplifica
On November 26, 2014 7:49:55 PM CET, Jakub Jelinek wrote:
>On Wed, Nov 26, 2014 at 07:20:04PM +0100, Marek Polacek wrote:
>> On Wed, Nov 26, 2014 at 06:50:29PM +0100, Jakub Jelinek wrote:
>> > On Wed, Nov 26, 2014 at 06:39:44PM +0100, Marek Polacek wrote:
>> > > Both C11 and C++14 standards specif
Hi!
As discussed in the PR and on IRC, the problem here is that peeling
for alignment can for some linear argument that during vect analysis
passed simple_iv no longer pass it during vect transform phase.
So, to fix this, this patch remembers the base and step values from
simple_iv during vect an
On Tue, Nov 25, 2014 at 09:20:13AM +0100, Jakub Jelinek wrote:
> Actually, thinking about it more, at least according to
> commutative_operand_precedence the canonical order is
> what we used to return (i.e. (something - _G_O_T_) + (symbol_ref)
> or
> (something - _G_O_T_) + (const (symbol_ref +- c
On Wed, Nov 26, 2014 at 11:42:57AM -0700, ygribov wrote:
> > Testing SANITIZE_ADDRESS bit in flag_sanitize_recover doesn't make sense,
> > testing it in flag_sanitize of course does, but for recover you care
> > whether
> > the SANITIZE_{KERNEL,USER}_ADDRESS bit in flag_sanitize_recover is set
>
On Wed, Nov 26, 2014 at 07:20:04PM +0100, Marek Polacek wrote:
> On Wed, Nov 26, 2014 at 06:50:29PM +0100, Jakub Jelinek wrote:
> > On Wed, Nov 26, 2014 at 06:39:44PM +0100, Marek Polacek wrote:
> > > Both C11 and C++14 standards specify that integral promotions are
> > > performed on both operands
Hello!
> I've added avx512f support to __builtin_cpu_supports.
> I'm not sure about bw+vl, i think for compound values like
> avx512bd+dq+vl, arch is better. Also for such cases prority is unclear,
> what should we choose bw+vl or e. g. avx512f+er?
> I've left MPX bits in cpuid.h, in case we will
> Testing SANITIZE_ADDRESS bit in flag_sanitize_recover doesn't make sense,
> testing it in flag_sanitize of course does, but for recover you care
> whether
> the SANITIZE_{KERNEL,USER}_ADDRESS bit in flag_sanitize_recover is set
> depending on if SANITIZE_{KERNEL,USER}_ADDRESS is set in
> flag
OK, thanks.
Jason
On Wed, Nov 26, 2014 at 11:21:06AM -0700, ygribov wrote:
> > Formatting. The {} should be indented like static
> > and return 2 columns to the right of that.
>
> Right.
>
> > For base_addr computation, you don't really need g or ptr_checks,
> > do you? So why not move the:
> > auto_vec *ptr
> Formatting. The {} should be indented like static
> and return 2 columns to the right of that.
Right.
> For base_addr computation, you don't really need g or ptr_checks,
> do you? So why not move the:
> auto_vec *ptr_checks = &ctx->asan_check_map.get_or_insert (ptr);
> gimple g = maybe
On 11/26/2014 01:18 PM, Joseph Myers wrote:
On Wed, 26 Nov 2014, Marek Polacek wrote:
Joseph, is that C FE part ok?
The C changes are OK once Jakub's middle-end/expander issue is resolved
(possibly by adding execution tests of shifts by in-range 64-bit and
128-bit integers, both constant and
On Wed, Nov 26, 2014 at 06:50:29PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 26, 2014 at 06:39:44PM +0100, Marek Polacek wrote:
> > Both C11 and C++14 standards specify that integral promotions are
> > performed on both operands of a shift-expression. This we do just
> > fine. But then we convert
1) It occurred to me that now that there are side-effects in
constant-expressions, we need to guard against multiple evaluation of
SAVE_EXPR.
2) We don't want to complain about flowing off the end of a function
because something in the function was non-constant.
Tested x86_64-pc-linux-gnu, a
On Wed, 26 Nov 2014, Marek Polacek wrote:
> Joseph, is that C FE part ok?
The C changes are OK once Jakub's middle-end/expander issue is resolved
(possibly by adding execution tests of shifts by in-range 64-bit and
128-bit integers, both constant and non-constant, and compilation tests of
shif
On 11/25/14 14:47, Segher Boessenkool wrote:
On Tue, Nov 25, 2014 at 11:46:52AM -0700, Jeff Law wrote:
On 11/14/14 12:19, Segher Boessenkool wrote:
With this new field in place, we can have LOG_LINKS for insns that set
more than one register and distribute them properly in distribute_links.
Thi
On Wed, Nov 26, 2014 at 10:09 AM, Renlin Li wrote:
> On 26/11/14 12:16, H.J. Lu wrote:
>>
>> On Wed, Nov 26, 2014 at 4:07 AM, Renlin Li wrote:
>>>
>>> On 20/11/14 16:17, Renlin Li wrote:
Hi all,
This is a backport for gcc-4_9-branch of the patch "[PR63762]GCC
generates
>>
On 26/11/14 12:16, H.J. Lu wrote:
On Wed, Nov 26, 2014 at 4:07 AM, Renlin Li wrote:
On 20/11/14 16:17, Renlin Li wrote:
Hi all,
This is a backport for gcc-4_9-branch of the patch "[PR63762]GCC generates
UNPREDICTABLE STR with Rn = Rt for arm" posted in:
https://gcc.gnu.org/ml/gcc-patches/2014
On 25 November 2014 at 23:42, Tobias Burnus wrote:
> FX:
>>>
>>> (a) those majority which might need buffering (gfc_error, gfc_warning);
>>
>> Is there a plan for those in the longer term?
>
>
> Well, the long-term solution is of course to support them. That requires
> adding buffering+discarding
Ok. Adjusted patch attached. Nevertheless we should use here
unsigned HWI instead of possible truncation to signed int. I admit
that it is unlikely to have more then 2^31 elements, but well
Ok for apply with adjusted ChangeLog?
Regards,
Kai
Index: constexpr.c
On Wed, Nov 26, 2014 at 06:39:44PM +0100, Marek Polacek wrote:
> Both C11 and C++14 standards specify that integral promotions are
> performed on both operands of a shift-expression. This we do just
> fine. But then we convert the right operand to integer_type_node.
> Not only is this unnecessary
On 11/26/14 06:11, Andrew MacLeod wrote:
So the question to the maintainers is whether its permissible to do a
bit of flattening into the early parts of stage 3, or whether you'd
rather it stay on a branch until next stage 1.
Andrew
PIng.. anyone want to chime in? :-)
Apparently not :-) I'd h
On Wed, Oct 08, 2014 at 09:05:30PM +0200, Pierre-Marie de Rodat wrote:
> gcc/
> * dwarf2out.h (struct array_descr_info): Remove the base_decl field.
> * dwarf2out.c (enum dw_scalar_form): New.
> (struct loc_descr_context): New.
> (add_scalar_info): New.
> (add_bound_in
On 11/25/14 18:39, David Malcolm wrote:
I suspect this is papering over a real problem, but I've been
applying this workaround locally to keep my valgrind output clean.
gcc/ChangeLog:
PR/64003
* final.c (shorten_branches): Allocate insn_lengths with
XCNEWVEC rather than X
Both C11 and C++14 standards specify that integral promotions are
performed on both operands of a shift-expression. This we do just
fine. But then we convert the right operand to integer_type_node.
Not only is this unnecessary, it can also be harfmul, because for
e.g.
void
foo (unsigned int x)
{
On 26/11/14 17:23 -, Thomas Preud'homme wrote:
Ping?
I'm OK with backporting it if a release manager approves it.
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
Sent: Wednesday, November 19, 2014 6:00
Ping?
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Wednesday, November 19, 2014 6:00 PM
> To: Tony Wang; gcc-patches@gcc.gnu.org; d...@debian.org; aph-
> g...@littlepinkcloud.com; Richard Earnsh
On 11/25/14 18:45, David Malcolm wrote:
Various cleanups of the jit code
Successfully bootstrapped & regrtested on x86_64-unknown-linux-gnu
(Fedora 20).
OK for trunk?
(am not yet officially blessed as the JIT maintainer, so I require
review for the non-obvious patches)
You're now the official
On 09/22/2014 09:06 PM, Andrew Dixie wrote:
- || ((fde_encoding & 0x70) != DW_EH_PE_absptr
- && (fde_encoding & 0x70) != DW_EH_PE_aligned
- && (per_encoding & 0x70) != DW_EH_PE_absptr
- && (per_encoding & 0x70) !=
On 11/20/2014 02:04 PM, Marek Polacek wrote:
+ if (fun == NULL_TREE)
+switch (CALL_EXPR_IFN (t))
+ {
+ case IFN_UBSAN_NULL:
+ case IFN_UBSAN_BOUNDS:
+ return void_node;
+ default:
+ break;
+ }
Other IFNs should make the call non-constant.
-/* { dg-err
Please give diagnostics explaining what's wrong with the shift rather
than the generic "is not a constant expression".
+ tree t = build_int_cst (unsigned_type_node, uprec - 1);
+ t = fold_build2 (MINUS_EXPR, unsigned_type_node, t, rhs);
+ tree ulhs = fold_convert (unsigned_type_f
On Wed, Nov 26, 2014 at 03:56:03PM +, Alan Lawrence wrote:
> So in case there's any confusion about the behaviour expected of *the vabs
> intrinsic*, here's a testcase (failing without patch, passing with it)...
>
> --Alan
>
> Alan Lawrence wrote:
> > ...as the former is defined as returning
On 26.11.2014 17:27, Tobias Burnus wrote:
On Wed, Nov 26, 2014 at 04:55:40PM +0100, Tobias Burnus wrote:
This patch adds a configure check for isl_schedule_constraints_compute_schedule,
which is new in ISL 0.13 - and uses it for conditional compilation.
Repeating the test on a massively multic
On Wed, Nov 26, 2014 at 04:55:40PM +0100, Tobias Burnus wrote:
> This patch adds a configure check for
> isl_schedule_constraints_compute_schedule,
> which is new in ISL 0.13 - and uses it for conditional compilation.
Repeating the test on a massively multicore system, it fails at stage2 with an
On 11/24/2014 01:55 PM, Paolo Carlini wrote:
in this rejects-valid, as part of build_user_type_conversion_1,
standard_conversion is called by implicit_conversion with a *null* expr,
thus the condition in standard_conversion
/* [conv.ptr]
A null pointer constant can be converted to a poi
On 10/28/2014 08:44 AM, Jakub Jelinek wrote:
+cp_ubsan_check_member_access_r (tree *stmt_p, int *walk_subtrees, void *data)
This function needs a longer comment about exactly what forms it's
trying to instrument.
+ /* T t; t.foo (); doesn't need instrumentation, if the type is known. */
+
2014-11-26 19:07 GMT+03:00 Jan Hubicka :
>> On 25 Nov 15:03, Ilya Enkovich wrote:
>> > 2014-11-25 14:11 GMT+03:00 Richard Biener :
>> > > On Tue, Nov 25, 2014 at 11:19 AM, Ilya Enkovich
>> > > wrote:
>> > >
>> > > Ok, then it's get_for_asmname (). That said - the above loops look
>> > > bogus to
Hello,
Ping for https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00694.html
Thanks in advance!
Regards,
--
Pierre-Marie de Rodat
> On 25 Nov 15:03, Ilya Enkovich wrote:
> > 2014-11-25 14:11 GMT+03:00 Richard Biener :
> > > On Tue, Nov 25, 2014 at 11:19 AM, Ilya Enkovich
> > > wrote:
> > >
> > > Ok, then it's get_for_asmname (). That said - the above loops look
> > > bogus to me. Honza - any better ideas?
> >
> > get_for
On Sat, Nov 15, 2014 at 06:59:23AM -0600, Segher Boessenkool wrote:
> On Fri, Nov 14, 2014 at 08:35:48PM +0100, Bernd Schmidt wrote:
> > On 11/14/2014 08:19 PM, Segher Boessenkool wrote:
> > >+ /* If I2 is a PARALLEL of two SETs of REGs (and perhaps some CLOBBERs),
> > >+ make those two SETs s
FWIW, I agree this is the right fix, but:
Andrew Bennett writes:
> + /* When using branch likely (-mfix-r1), the delay slot instruction
> + will be annulled on false. The normal delay slot instructions
> + calculate the overall result of the atomic operation and must not
> + be
On 26.11.2014 16:55, Tobias Burnus wrote:
This patch adds a configure check for isl_schedule_constraints_compute_schedule,
which is new in ISL 0.13 - and uses it for conditional compilation.
The graphite*c patch is based on the one of Jack Howarth,
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg0
On 11/26/2014 10:48 AM, Manuel López-Ibáñez wrote:
If I understand correctly, the cxx11 standard requires to diagnose
this. Thus, it should be always a pedwarn, independently of Wpedantic.
I agree. This is what I checked in:
commit 2aeccf739475ee181f4ca6422776b46bc9526352
Author: jason
Date:
So in case there's any confusion about the behaviour expected of *the vabs
intrinsic*, here's a testcase (failing without patch, passing with it)...
--Alan
Alan Lawrence wrote:
...as the former is defined as returning MIN_VALUE for argument MIN_VALUE,
whereas the latter is 'undefined', and gcc
This patch adds a configure check for isl_schedule_constraints_compute_schedule,
which is new in ISL 0.13 - and uses it for conditional compilation.
The graphite*c patch is based on the one of Jack Howarth,
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00906.html - without checking
whether the ISL
Sorry to be pedantic, but I think this is not exactly right:
+if (cxx_dialect >= cxx11)
+ {
+ if (pedantic)
+ pedwarn (input_location, OPT_Wpedantic,
+ "ISO C++ forbids converting a string constant to %qT",
+ totype);
+ else
+ warning (OPT_Wwrite_strings,
+ "ISO C++ forbids conver
> >> I think using cpuid for that is just fine. __builtin_cpu_supports
> >> is for ISA additions users might actually want to version code for,
> >> MPX stuff, as the instructions are nops without hw support, are not
> >> something one would multi-version a function for.
> >> If anything, AVX512F
I ran a quick test to see if the output after this patch matches the
examples in D.7, and it does. So the patch is OK.
Jason
On Wed, 2014-11-26 at 09:13 +0100, Uros Bizjak wrote:
> Hello!
>
> > cgraph*.c and ipa-*.c use xstrdup on strings when dumping them via
> > fprintf, leaking all of the duplicated buffers.
> >
> > Is/was there a reason for doing this?
>
> Yes, please see [1] and PR 53136 [2]. As said in [1]:
>
>
On Wed, Nov 26, 2014 at 02:57:20PM +0100, Marek Polacek wrote:
> Ping.
Ok, thanks.
>
> On Wed, Nov 19, 2014 at 08:09:21PM +0100, Marek Polacek wrote:
> > As discussed in the PR, the problem here is that when running gfortran,
> > the __builtin_object_size decl isn't available, because c-family's
Ping.
On Wed, Nov 19, 2014 at 08:09:21PM +0100, Marek Polacek wrote:
> As discussed in the PR, the problem here is that when running gfortran,
> the __builtin_object_size decl isn't available, because c-family's
> c_define_builtins wasn't called. One way how to fix this is to build
> the __builti
The following fixes the assert in mems_in_disjoint_alias_sets_p trigger.
What the comment says can easily happen by using
attribute((optimize("O3"))) inside a -fno-strict-aliasing TU. Dependent
on luck a global variable may get a alias-set non-zero MEM if expanded
from the -O3 context and thus t
On Wed, Nov 26, 2014 at 04:48:13PM +0300, Ilya Enkovich wrote:
> 2014-11-26 Ilya Enkovich
>
> PR bootstrap/63995
> * tree-chkp-opt.c (chkp_reduce_bounds_lifetime): Ignore
> debug statement when searching for a new position for
> bounds load/creation statement.
>
> gcc/t
On 26 Nov 13:46, Jakub Jelinek wrote:
> On Wed, Nov 26, 2014 at 03:41:46PM +0300, Ilya Enkovich wrote:
> > Hi,
> >
> > This patch makes optimization for bounds lifetime reduction to ignore
> > debug stetments. This fixes stage2 and stage3 comparision for
> > instrumented boostrap. OK for trunk?
The 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc currently
FAILs on Solaris
FAIL: 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc execution test
As determined in the PR, this happens because Solaris only supports
hexfloats in C99 mode, but gcc doesn't correctly link with va
Two tests scanning for get_pc_thunk were FAILing on Solaris/x86:
FAIL: gcc.target/i386/mcount_pic.c (test for excess errors)
WARNING: gcc.target/i386/mcount_pic.c compilation failed to produce executable
FAIL: gcc.target/i386/mcount_pic.c scan-assembler get_pc_thunk
FAIL: gcc.target/i386/pr63620.c
On Tuesday 2014-11-25 16:08, Kyrill Tkachov wrote:
The change is to the behaviour of -mcpu, not -march. -march is only
mentioned as a way of getting the previous behaviour if the user so
wishes.
Ah, okay.
How about this amendment?
Where you have "add the +crypto extension to the value"
I s
On 12-11-14 11:00, Tom de Vries wrote:
Jakub,
this patch fixes a gcc_assert in expand_omp_for_static_chunk.
The assert follows a loop with composite loop condition:
...
vec *head = redirect_edge_var_map_vector (re);
ene = single_succ_edge (entry_bb);
psi = gsi_start_phis (
On 11/20/2014 03:14 PM, Andrew MacLeod wrote:
On 11/20/2014 03:05 PM, Michael Collison wrote:
This is a part one of two part patch that flattens gimple-streamer.h,
lto-streamer.h and tree-streamer.h. This work is part of the GCC
Re-Architecture effort being led by Andrew MacLeod.
In gimple-st
On Wed, Nov 26, 2014 at 03:41:46PM +0300, Ilya Enkovich wrote:
> Hi,
>
> This patch makes optimization for bounds lifetime reduction to ignore
> debug stetments. This fixes stage2 and stage3 comparision for
> instrumented boostrap. OK for trunk?
Please add a small testcase (with -fcompare-debug
Hi,
This patch makes optimization for bounds lifetime reduction to ignore debug
stetments. This fixes stage2 and stage3 comparision for instrumented boostrap.
OK for trunk?
Thanks,
Ilya
--
2014-11-26 Ilya Enkovich
PR bootstrap/63995
* tree-chkp-opt.c (chkp_reduce_bounds_li
On 25 Nov 15:03, Ilya Enkovich wrote:
> 2014-11-25 14:11 GMT+03:00 Richard Biener :
> > On Tue, Nov 25, 2014 at 11:19 AM, Ilya Enkovich
> > wrote:
> >
> > Ok, then it's get_for_asmname (). That said - the above loops look
> > bogus to me. Honza - any better ideas?
>
> get_for_asmname () retur
On 14/11/14 11:12, Andrew Stubbs wrote:
On 07/11/14 10:35, Andrew Stubbs wrote:
if armv6 never co-exist with NEON, personally I think your original
patch is better
because TARGET_NEON generally will be used when all options are
processed.
any way, this needs gate keeper's approval.
P
On Wed, Nov 26, 2014 at 4:07 AM, Renlin Li wrote:
> On 20/11/14 16:17, Renlin Li wrote:
>>
>> Hi all,
>>
>> This is a backport for gcc-4_9-branch of the patch "[PR63762]GCC generates
>> UNPREDICTABLE STR with Rn = Rt for arm" posted in:
>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02253.html
>
1 - 100 of 119 matches
Mail list logo