On 29 November 2016 at 03:59, Martin Sebor wrote:
> On 11/28/2016 06:35 PM, David Edelsohn wrote:
>>
>> Martin,
>>
>> I am seeing a number of new failures with the testcases on AIX.
>>
>> FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)
>>
>> Excess errors:
>>
>> /nasfarm/ed
Hi all,
This ICE only occurs on big-endian ILP32 -fpie code. The expansion code
generates the invalid load:
(insn 6 5 7 (set (reg/f:SI 76)
(unspec:SI [
(mem/u/c:SI (lo_sum:SI (nil)
(symbol_ref:SI ("dbs") [flags 0x40] )) [0 S4 A8])
] UN
With this patch EQ and NE compares on CC mode reader patterns are
folded. This allows using the result of the vec_all_* and vec_any_*
builtins directly in a conditional jump instruction as in the attached
testcase.
gcc/ChangeLog:
2016-11-29 Andreas Krebbel
* config/s390/s390-protos.h
gcc/ChangeLog:
2016-11-29 Andreas Krebbel
* config/s390/vector.md (vec_halfhalf): New mode iterator.
("vec_pack_trunc_", "vec_pack_ssat_")
("vec_pack_usat_", "vec_unpacks_hi_v16qi")
("vec_unpacks_low_v16qi", "vec_unpacku_hi_v16qi")
("vec_unpacku_low_v16q
Although the S/390 backend states that the machine supports unaligned
vector accesses the loop vectorizer still tries to peel loop
iterations to get higher alignments. Setting
vect_max_peeling_for_alignment to 0 prevents this.
gcc/ChangeLog:
2016-11-29 Andreas Krebbel
* config/s390/s
This fixes a problem with the vector compares producing CC mode
results.
The instructions produce condition code modes which can be either
interpreted to check an ALL elements or an ANY element result. As the
modes where used before they could not be inverted by the middle-end
by inverting the co
Please see the patches for descriptions.
The first one is an important bugfix which needs to go also into GCC 5
and 6 branches.
I'll commit the patches in a few days to give some time for comments.
Andreas Krebbel (4):
S/390: Fix vector all/any cc modes.
S/390: Merge compare of compare resul
On 17/11/16 10:00, Ramana Radhakrishnan wrote:
> On Thu, Oct 6, 2016 at 2:57 PM, Andre Vieira (lists)
> wrote:
>> Hello,
>>
>> This patch tackles the issue reported in PR71607. This patch takes a
>> different approach for disabling the creation of literal pools. Instead
>> of disabling the pattern
Hi All,
The new patch contains the proper types for the intrinsics that should be
returning uint64x1
and has the rest of the comments by Christophe in them.
Kind Regards,
Tamar
From: Tamar Christina
Sent: Friday, November 25, 2016 4:01:30 PM
To: Christop
Hi Tamar,
On 29 November 2016 at 10:50, Tamar Christina wrote:
> Hi All,
>
> The new patch contains the proper types for the intrinsics that should be
> returning uint64x1
> and has the rest of the comments by Christophe in them.
>
LGTM.
One more question: maybe we want to add explicit tests
On Mon, Nov 28, 2016 at 6:28 PM, Martin Jambor wrote:
> Hi Jeff,
>
> On Mon, Nov 28, 2016 at 08:46:05AM -0700, Jeff Law wrote:
>> On 11/28/2016 07:27 AM, Martin Jambor wrote:
>> > Hi,
>> >
>> > one of a number of symptoms of an otherwise unrelated HSA bug I've
>> > been debugging today is gcc cras
This is a fix for a wrong warning from -Wlto-type-mismatch that reports
a type mismatch for two built-in functions.
The avr backend has several built-ins that have the same asm name
because their assembler implementation in libgcc is exactly the same.
The prototypes might differ, however.
Th
On Mon, Nov 28, 2016 at 7:41 PM, Jeff Law wrote:
> On 11/28/2016 06:10 AM, Paolo Bonzini wrote:
>>
>>
>>
>> On 27/11/2016 00:28, Marc Glisse wrote:
>>>
>>> On Sat, 26 Nov 2016, Paolo Bonzini wrote:
>>>
--- match.pd(revision 242742)
+++ match.pd(working copy)
@@ -2554,6 +2554
On Mon, Nov 28, 2016 at 10:23 PM, Jeff Law wrote:
>
>
> I was digging into issues around the patches for 78120 when I stumbled upon
> undesirable bb copying in bb-reorder.c on the m68k.
>
> The core issue is that the m68k does not define a length attribute and
> therefore generic code assumes tha
On Tue, Nov 29, 2016 at 7:36 AM, Andrew Pinski wrote:
> While rewriting PHI-OPT to use match and simplify infrastructure, I
> ran into a problem where VRP pass would create a EQ_EXPR which has a
> non boolean type inside the VRP pass. This currently works on
> accident as it seems we don't check
On 21/11/16 08:42, Christophe Lyon wrote:
> Hi,
>
>
> On 17 November 2016 at 11:45, Kyrill Tkachov
> wrote:
>>
>> On 17/11/16 10:31, Andre Vieira (lists) wrote:
>>>
>>> Hi Kyrill,
>>>
>>> On 17/11/16 10:11, Kyrill Tkachov wrote:
Hi Andre,
On 09/11/16 10:00, Andre Vieira (list
On 29/11/16 10:35, Andre Vieira (lists) wrote:
On 21/11/16 08:42, Christophe Lyon wrote:
Hi,
On 17 November 2016 at 11:45, Kyrill Tkachov
wrote:
On 17/11/16 10:31, Andre Vieira (lists) wrote:
Hi Kyrill,
On 17/11/16 10:11, Kyrill Tkachov wrote:
Hi Andre,
On 09/11/16 10:00, Andre Vieira (
On Tue, Nov 29, 2016 at 10:42 AM, Andreas Krebbel
wrote:
> Although the S/390 backend states that the machine supports unaligned
> vector accesses the loop vectorizer still tries to peel loop
> iterations to get higher alignments. Setting
> vect_max_peeling_for_alignment to 0 prevents this.
Hmm,
Currently we an assert that prevents proper use-after-scope sanitization
in nested functions. With the attached patch, we are able to do so.
I'm adding 2 test-cases, first one is the ICE reported in PR and the second
one tests proper report of use-after-scope passed by FRAME belonging to a
nested f
Following ICE has been reduced from bash, where a new CFG does not properly
fill a newly added PHI argument. Problem is solved by adding one extra BB that
precedes the original BB with the PHI. Doing so, we do not add a new PHI
argument.
Tests have been running.
Ready to be installed after it fin
On Mon, Nov 14, 2016 at 02:25:28PM +, Kyrill Tkachov wrote:
>
> On 11/11/16 15:31, Kyrill Tkachov wrote:
> >
> >On 11/11/16 10:17, Kyrill Tkachov wrote:
> >>
> >>On 10/11/16 23:39, Segher Boessenkool wrote:
> >>>On Thu, Nov 10, 2016 at 02:42:24PM -0800, Andrew Pinski wrote:
> On Thu, Nov 1
Merge the movdi_vfp_cortexa8 pattern into movdi_vfp and remove it to avoid
unnecessary duplication and repeating bugs like PR78439 due to changes being
applied only to one of the duplicates.
Bootstrap OK for ARM and Thumb-2 gnueabihf targets. OK for commit?
ChangeLog:
2016-11-29 Wilco Dijkstra
GCC caches the whether a function is a leaf in crtl->is_leaf. Using this
in the backend is best as leaf_function_p may not work correctly (eg. while
emitting prolog or epilog code). There are many reads of crtl->is_leaf
before it is initialized. Many targets do in targetm.frame_pointer_required
(
Hi James,
On 29/11/16 10:57, James Greenhalgh wrote:
On Mon, Nov 14, 2016 at 02:25:28PM +, Kyrill Tkachov wrote:
On 11/11/16 15:31, Kyrill Tkachov wrote:
On 11/11/16 10:17, Kyrill Tkachov wrote:
On 10/11/16 23:39, Segher Boessenkool wrote:
On Thu, Nov 10, 2016 at 02:42:24PM -0800, Andrew
Hi,
This patch fixes a bogus testsuite failure (gcc.dg/pr31096-1.c) for
the avr target.
The dump expects constants which would only be present if the target's
int size is 32 bits.
Fixed by explicitly using 32 bit ints for targets with __SIZEOF_INT__
< 4. Committed to trunk as obvious
On 29/11/16 11:18, Kyrill Tkachov wrote:
Hi James,
On 29/11/16 10:57, James Greenhalgh wrote:
On Mon, Nov 14, 2016 at 02:25:28PM +, Kyrill Tkachov wrote:
On 11/11/16 15:31, Kyrill Tkachov wrote:
On 11/11/16 10:17, Kyrill Tkachov wrote:
On 10/11/16 23:39, Segher Boessenkool wrote:
On Th
On Tue, Nov 29, 2016 at 11:46 AM, Martin Liška wrote:
> Following ICE has been reduced from bash, where a new CFG does not properly
> fill a newly added PHI argument. Problem is solved by adding one extra BB that
> precedes the original BB with the PHI. Doing so, we do not add a new PHI
> argumen
On Tue, Nov 29, 2016 at 11:32:41AM +, Kyrill Tkachov wrote:
> >>+
> >>+/* Implement TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB. */
> >>+
> >>+static sbitmap
> >>+aarch64_components_for_bb (basic_block bb)
> >>+{
> >>+ bitmap in = DF_LIVE_IN (bb);
> >>+ bitmap gen = &DF_LIVE_BB_INFO (bb)->gen;
>
On 29/11/2016 11:16, Richard Biener wrote:
>>> >> (bit_and
>>> >> (if (shift > 0)
>>> >>(lshift (convert @0) { build_int_cst (integer_type_node, shift); })
>>> >>(convert (rshift @0 { build_int_cst (integer_type_node, -shift); })))
>>> >> @3)
>>> >>
>>> >> What do you think?
>> >
>>
On Tue, Nov 29, 2016 at 12:50 PM, Paolo Bonzini wrote:
>
>
> On 29/11/2016 11:16, Richard Biener wrote:
>> (bit_and
>> (if (shift > 0)
>>(lshift (convert @0) { build_int_cst (integer_type_node, shift); })
>>(convert (rshift @0 { build_int_cst (integer_type_node, -shi
Adjusted and re-tested using the way you advised, attached updated patch.
Thanks,
Chung-Lin
On 2016/11/18 7:15 PM, Jakub Jelinek wrote:
> 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)
Ping.
> -Original Message-
> From: Claudiu Zissulescu
> Sent: Wednesday, November 16, 2016 11:18 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Claudiu Zissulescu ;
> francois.bed...@synopsys.com; andrew.burg...@embecosm.com
> Subject: [PATCH 3/4] [ARC] Refurbish mul64 support.
>
> gcc/
> 2016-07
Ping.
> -Original Message-
> From: Claudiu Zissulescu
> Sent: Wednesday, November 16, 2016 11:18 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Claudiu Zissulescu ;
> francois.bed...@synopsys.com; andrew.burg...@embecosm.com
> Subject: [PATCH 2/4] [ARC] Cleanup implementation.
>
> gcc/
> 2016-06-
On 2016/11/18 7:23 PM, Jakub Jelinek wrote:
> 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 INTEGE
On Tue, Nov 29, 2016 at 08:23:45PM +0800, Chung-Lin Tang wrote:
> Adjusted and re-tested using the way you advised, attached updated patch.
Ok, thanks.
Jakub
On Tue, Nov 29, 2016 at 08:27:04PM +0800, Chung-Lin Tang wrote:
> On 2016/11/18 7:23 PM, Jakub Jelinek wrote:
> > 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 t
Committed as obvious.
gcc/
2016-11-29 Claudiu Zissulescu
* config/arc/arc.opt (marclinux): Fix typo.
(marclinux_prof): Likewise.
---
gcc/ChangeLog | 5 +
gcc/config/arc/arc.opt | 4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/gcc/ChangeLog
Fixing casesi option for ARCv2 cpus.
Ok to apply?
Claudiu
gcc/
2016-11-28 Claudiu Zissulescu
* config/arc/arc.c (arc_override_options): Avoid selection of
compact casesi for ARCv2.
---
gcc/config/arc/arc.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff
On 29 November 2016 at 11:12, Christophe Lyon
wrote:
> Hi Tamar,
>
>
> On 29 November 2016 at 10:50, Tamar Christina wrote:
>> Hi All,
>>
>> The new patch contains the proper types for the intrinsics that should be
>> returning uint64x1
>> and has the rest of the comments by Christophe in them.
Hi Claudiu and Andrew
This patches solves the dejagnu PIE failing tests.
Looking forward to your review.
Best regards,
Cupertino
gcc/
2016-07-27 Cupertino Miranda
* config/arc/arc.h (STARTFILE_SPEC): Use default linux specs.
(ENDFILE_SPEC): Likewise.
libgcc/
2016-07-27 Cupe
On 29/11/16 09:50, Tamar Christina wrote:
Hi All,
The new patch contains the proper types for the intrinsics that should be
returning uint64x1
and has the rest of the comments by Christophe in them.
Ok with an appropriate ChangeLog entry.
Thanks,
Kyrill
Kind Regards,
Tamar
___
* Claudiu Zissulescu [2016-11-29 13:43:21
+0100]:
> Fixing casesi option for ARCv2 cpus.
>
> Ok to apply?
> Claudiu
Approved.
Thanks,
Andrew
>
> gcc/
> 2016-11-28 Claudiu Zissulescu
>
> * config/arc/arc.c (arc_override_options): Avoid selection of
> compact casesi for ARCv2
On Tue, Nov 29, 2016 at 01:48:22PM +, Kyrill Tkachov wrote:
>
> On 29/11/16 09:50, Tamar Christina wrote:
> >Hi All,
> >
> >The new patch contains the proper types for the intrinsics that should be
> >returning uint64x1
> >and has the rest of the comments by Christophe in them.
>
> Ok with a
$subject
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2016-11-29 Richard Biener
* tree-cfg.c (lower_phi_internal_fn): Do not look for further
PHIs after a regular stmt.
(stmt_starts_bb_p): PHIs not preceeded by a PHI or a label
start
* Jeff Law [2016-11-28 15:08:46 -0700]:
> On 11/24/2016 02:40 PM, Andrew Burgess wrote:
> > * Christophe Lyon [2016-11-21 13:47:09 +0100]:
> >
> > > On 20 November 2016 at 18:27, Mike Stump wrote:
> > > > On Nov 19, 2016, at 1:59 PM, Andrew Burgess
> > > > wrote:
> > > > > > So, your new tes
Building gcc with -fsanitize=undefined shows:
rtlanal.c:5210:38: runtime error: shift exponent 4294967295 is too
large for 64-bit type 'long unsigned int'
5210 return nonzero & (HOST_WIDE_INT_1U << (bitwidth - 1))
5211 ? 1 : bitwidth - floor_log2 (nonzero) - 1;
Here (bitwidth - 1) wr
On Tue, Nov 29, 2016 at 03:08:15PM +0100, Markus Trippelsdorf wrote:
> Building gcc with -fsanitize=undefined shows:
> rtlanal.c:5210:38: runtime error: shift exponent 4294967295 is too
> large for 64-bit type 'long unsigned int'
>
> 5210 return nonzero & (HOST_WIDE_INT_1U << (bitwidth - 1))
>
Committed as r242960.
2016-11-28 14:36 GMT+01:00 Janus Weil :
> Hi all,
>
> the attached patch was posted on bugzilla by Tobias three years ago,
> but left unattended since then. It is simple, works well (fixing a
> bogus warning) and regtests cleanly on x86_64-linux-gnu.
>
> If no one objects,
On 2016.11.29 at 15:14 +0100, Jakub Jelinek wrote:
> On Tue, Nov 29, 2016 at 03:08:15PM +0100, Markus Trippelsdorf wrote:
> > Building gcc with -fsanitize=undefined shows:
> > rtlanal.c:5210:38: runtime error: shift exponent 4294967295 is too
> > large for 64-bit type 'long unsigned int'
> >
> >
> Approved.
>
Committed, thank you for ur review,
Claudiu
Hi,
Attached patch is addressing PR67520. Would that approach work for the
problem? Should I also change the version of the library?
2016-11-29 Alexander Ivchenko
* mpxrt/mpxrt-utils.c (set_mpx_rt_stop_handler): New function.
(print_help): Add help for CHKP_RT_STOP_HANDLER environment
variabl
allback_mangled, "", 1))
d_type();
}
markus@x4 libsupc++ % UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=1
/var/tmp/gcc_build_dir_/./gcc/cc1 -w -fpreprocessed cp-demangle.i -quiet
-dumpbase cp-demangle.i -mtune=generic -march=x86-64 -auxbase cp-demangle -O2
-version -o /dev/null
GNU
On Tue, Nov 29, 2016 at 11:38:15AM +0100, Richard Biener wrote:
> So - please instead of setting this param provide
> TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST.
Right, that's way better.
gcc/ChangeLog:
2016-11-29 Andreas Krebbel
* gcc/config/s390/s390.c (s390_builtin_vectorization_
/* VOID */
> > 236 0, /* BLK */
>
> markus@x4 libsupc++ % cat cp-demangle.i
> d_demangle_callback_mangled() {
> if (strncmp(d_demangle_callback_mangled, "", 1))
> d_type();
> }
>
> markus@x4 libsupc++ % UBSAN_OPTIONS
In working on pr78252 I noticed a source formatting nit. Fixed thusly
and committed.
nathan
--
Nathan Sidwell
2016-11-29 Nathan Sidwell
* cp-demangle.c (d_print_comp_inner): Fix parameter indentation.
Index: cp-demangle.c
===
And again with the costs for unaligned loads/stores actually changed:
gcc/ChangeLog:
2016-11-29 Andreas Krebbel
* gcc/config/s390/s390.c (s390_builtin_vectorization_cost): New
function.
(TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST): Define target
macro.
gcc/te
Here is v2 of the fix.
Building gcc with -fsanitize=undefined shows:
rtlanal.c:5210:38: runtime error: shift exponent 4294967295 is too large for
64-bit type 'long unsigned int'
This happens because if_then_else_cond() in combine.c calls
num_sign_bit_copies() in rtlanal.c with mode==BLKmode.
5
On 11/29/2016 03:23 AM, Richard Biener wrote:
On Mon, Nov 28, 2016 at 10:23 PM, Jeff Law wrote:
I was digging into issues around the patches for 78120 when I stumbled upon
undesirable bb copying in bb-reorder.c on the m68k.
The core issue is that the m68k does not define a length attribute
On 11/29/2016 03:16 AM, Richard Biener wrote:
On Mon, Nov 28, 2016 at 7:41 PM, Jeff Law wrote:
On 11/28/2016 06:10 AM, Paolo Bonzini wrote:
On 27/11/2016 00:28, Marc Glisse wrote:
On Sat, 26 Nov 2016, Paolo Bonzini wrote:
--- match.pd(revision 242742)
+++ match.pd(working copy)
On 18 November 2016 at 16:54, Christophe Lyon
wrote:
> 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" {
>> ta
This fixes the gcc.dg/uninit-pred-6* failures I seem to have caused on
some non x86 platforms. Sorry for the delay.
The problem is that my fix for PR61409 had the logic backwards. I was
proving that all the uses of a PHI are invalidated by any one undefined
PHI path, whereas what we want is t
2016-11-28 10:17 GMT+03:00 Pitchumani Sivanupandi
:
> On Saturday 26 November 2016 12:11 AM, Denis Chertykov wrote:
>>
>> I'm sorry for delay.
>>
>> I have a problem with the patch:
>> (Stripping trailing CRs from patch; use --binary to disable.)
>> patching file avr-arch.h
>> (Stripping trailing C
On 29 November 2016 at 17:33, Aldy Hernandez wrote:
> This fixes the gcc.dg/uninit-pred-6* failures I seem to have caused on some
> non x86 platforms. Sorry for the delay.
>
> The problem is that my fix for PR61409 had the logic backwards. I was
> proving that all the uses of a PHI are invalidate
On 11/29/2016 12:47 AM, Richard Biener wrote:
Balaji added this check explicitly. There should be tests in the testsuite
(spawnee_inline, spawner_inline) which exercise that code.
Yes he did, but no, nothing in the testsuite.
I believe the tests are:
c-c++-common/cilk-plus/CK/spawnee_inline.c
On 11/28/2016 05:42 PM, Joseph Myers wrote:
On Sun, 27 Nov 2016, Martin Sebor wrote:
Finally, the patch also tightens up the constraint on the upper bound
of bounded functions like snprintf to be INT_MAX. The functions cannot
produce output in excess of INT_MAX + 1 bytes and some implementatio
On 11/29/2016 03:13 AM, Richard Biener wrote:
On Mon, Nov 28, 2016 at 6:28 PM, Martin Jambor wrote:
Hi Jeff,
On Mon, Nov 28, 2016 at 08:46:05AM -0700, Jeff Law wrote:
On 11/28/2016 07:27 AM, Martin Jambor wrote:
Hi,
one of a number of symptoms of an otherwise unrelated HSA bug I've
been deb
On Mon, 2016-11-28 at 14:47 +0100, Bernd Schmidt wrote:
> Been looking at this off and on, and I'm still not sure I entirely
> get
> it - sorry.
>
> On 11/11/2016 10:15 PM, David Malcolm wrote:
> > > > Implementing an RTL frontend by using the RTL reader from read
> > > > -rtl.c
> > > > means tha
On 11/29/2016 06:20 PM, David Malcolm wrote:
if that distinction makes sense. Clearly we already have a diagnostics
subsystem on the host; what this patch is adding is the separate, rtl-s
pecific diagnostic subsystem to cc1 on the host.
So that still seems odd to me. Why not use the normal di
2016-11-29 17:43 GMT+03:00 Alexander Ivchenko :
> Hi,
>
> Attached patch is addressing PR67520. Would that approach work for the
> problem? Should I also change the version of the library?
Hi!
Overall patch is OK. But you need to change version because you
change default behavior. How did you tes
On 11/28/2016 07:57 PM, Martin Sebor wrote:
PR 78512 - r242674 miscompiles Linux kernel observes that the Linux
kernel fails to boot as a result of enabling the -fprintf-return-value
optimization in GCC. This is likely because the kernel has its own
sprintf with a large set of extensions to the
On 11/29/2016 07:02 AM, Andrew Burgess wrote:
* Jeff Law [2016-11-28 15:08:46 -0700]:
On 11/24/2016 02:40 PM, Andrew Burgess wrote:
* Christophe Lyon [2016-11-21 13:47:09 +0100]:
On 20 November 2016 at 18:27, Mike Stump wrote:
On Nov 19, 2016, at 1:59 PM, Andrew Burgess wrote:
So, your
Separate from ulimit, 32 bit AIX processes have the concept of memory
segments. By default, AIX devotes one 256MB segment to the data
section of an executable. Some libstdc++ testcases allocate more than
that amount of memory. Instead of individually fixing tests, this
patch always adds the AIX
On 29/11/16 10:37, Kyrill Tkachov wrote:
>
> On 29/11/16 10:35, Andre Vieira (lists) wrote:
>> On 21/11/16 08:42, Christophe Lyon wrote:
>>> Hi,
>>>
>>>
>>> On 17 November 2016 at 11:45, Kyrill Tkachov
>>> wrote:
On 17/11/16 10:31, Andre Vieira (lists) wrote:
> Hi Kyrill,
>
> On
On 11/29/2016 04:10 AM, Wilco Dijkstra wrote:
GCC caches the whether a function is a leaf in crtl->is_leaf. Using this
in the backend is best as leaf_function_p may not work correctly (eg. while
emitting prolog or epilog code). There are many reads of crtl->is_leaf
before it is initialized. Man
On 11/22/2016 10:25 PM, Hurugalawadi, Naveen wrote:
Hi,
Please consider this as a personal reminder to review the patch
at following link and let me know your comments on the same.
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01049.html
I believe Richi asked for a small change after which you
Jeff Law wrote:
> On 11/29/2016 04:10 AM, Wilco Dijkstra wrote:
> > GCC caches the whether a function is a leaf in crtl->is_leaf. Using this
> > in the backend is best as leaf_function_p may not work correctly (eg. while
> > emitting prolog or epilog code).
I forgot to ask, would it be reasonable
On 11/29/2016 11:39 AM, Wilco Dijkstra wrote:
Jeff Law wrote:
On 11/29/2016 04:10 AM, Wilco Dijkstra wrote:
GCC caches the whether a function is a leaf in crtl->is_leaf. Using this
in the backend is best as leaf_function_p may not work correctly (eg. while
emitting prolog or epilog code).
I f
On Tue, 2016-11-29 at 18:23 +0100, Bernd Schmidt wrote:
> On 11/29/2016 06:20 PM, David Malcolm wrote:
> >
> > if that distinction makes sense. Clearly we already have a
> > diagnostics
> > subsystem on the host; what this patch is adding is the separate,
> > rtl-s
> > pecific diagnostic subsyste
I was developing the next round of ISA 3.0 code changes to use the vector
extract byte, half word, and word instructions (VEXTU{B,H,W}{R,L}X) that
deposit the value into a general purpose register instead of a vector register,
and I was running the changes through the simulator. I discovered that
... and fix gcc.target/i386/avx512f-kmovw-1.c scan-asm failure.
2016-11-29 Uros Bizjak
* config/i386/sse.md (UNSPEC_MASKOP): Move from i386.md.
(mshift): Ditto.
(SWI1248_AVX512BWDQ): Ditto.
(SWI1248_AVX512BW): Ditto.
(k): Ditto.
(kandn): Ditto.
(kxnor): Ditto.
(
> 2016-11-26 Segher Boessenkool
>
> * combine.c (change_zero_ext): Also handle extends from a subreg
> to a mode bigger than that of the operand of the subreg.
This patch introduced:
FAIL: gcc.target/i386/pr44578.c (internal compiler error)
on i686 (or x86_64 32bit multi-lib).
./cc1 -O2 -mtu
Hi!
The following testcase ICEs because DECL_RTL/DECL_INCOMING_RTL are adjusted
by the stv pass through the PUT_MODE modifications, which means that for
var-tracking.c they contain a bogus mode.
Fixed by wrapping those into TImode subreg or adjusting the MEMs to have the
correct mode.
Bootstrapp
Hi!
As mentioned in the PR, the LSHIFT_EXPR computation of values that
will need longest or shortest string is both incorrect (it shifts
integer_one_node left, so for precisions above precision of integer
it returns 0 (not to mention that it is invalid GENERIC, because the types
of first operand a
Jeff Law wrote:
> On 11/29/2016 11:39 AM, Wilco Dijkstra wrote:
> > I forgot to ask, would it be reasonable to add an assert to check we're not
> > in
> > a sequence in leaf_function_p? I guess this will trigger on several targets
> > (leaf_function_p is used in several backends) but it's a real b
On 11/29/2016 09:56 AM, Martin Sebor wrote:
On 11/28/2016 05:42 PM, Joseph Myers wrote:
On Sun, 27 Nov 2016, Martin Sebor wrote:
Finally, the patch also tightens up the constraint on the upper bound
of bounded functions like snprintf to be INT_MAX. The functions cannot
produce output in exces
On 28/11/16 22:19 +0100, François Dumont wrote:
Hi
Here is a patch to fix pretty printers when versioned namespace is
activated.
You will see that I have hesitated in making the fix independant
of the version being used. In source files you will find (__7::)?
patterns while in xmethod
On 16/11/16 22:18 +0100, Christophe Lyon wrote:
On 15 November 2016 at 12:50, Jonathan Wakely wrote:
On 14/11/16 14:32 +0100, Christophe Lyon wrote:
On 20 October 2016 at 19:40, Jonathan Wakely wrote:
On 20/10/16 10:33 -0700, Mike Stump wrote:
On Oct 20, 2016, at 9:34 AM, Jonathan Wakel
Hi James, Kyrill,
On Tue, Nov 29, 2016 at 10:57:33AM +, James Greenhalgh wrote:
> > +static sbitmap
> > +aarch64_components_for_bb (basic_block bb)
> > +{
> > + bitmap in = DF_LIVE_IN (bb);
> > + bitmap gen = &DF_LIVE_BB_INFO (bb)->gen;
> > + bitmap kill = &DF_LIVE_BB_INFO (bb)->kill;
> > +
On 27/11/16 20:50 +0200, Ville Voutilainen wrote:
Implement LWG 2534, Constrain rvalue stream operators.
* include/std/istream (__is_convertible_to_basic_istream): New.
(__is_extractable): Likewise.
(operator>>(basic_istream<_CharT, _Traits>&&, _Tp&&)):
Turn the stream parameter in
Hi!
The x86_64 stv pass uses PUT_MODE to change REGs and MEMs in place to affect
all setters and users, but that is undesirable in debug insns which are
intentionally ignored during the analysis and we should keep using correct
modes (TImode) instead of the new one (V1TImode).
The current fix_deb
I merged GCC trunk revision 242967 to the gccgo branch.
Ian
On 11/29/2016 07:53 PM, David Malcolm wrote:
Would you prefer that I went with approach (B), or is approach (A)
acceptable?
Well, I was hoping there'd be an approach (C) where the read-rtl code
uses whatever diagnostics framework that is available. Maybe it'll turn
out that's too hard. Someh
On 29 November 2016 at 20:38, Uros Bizjak wrote:
>> 2016-11-26 Segher Boessenkool
>>
>> * combine.c (change_zero_ext): Also handle extends from a subreg
>> to a mode bigger than that of the operand of the subreg.
>
> This patch introduced:
>
> FAIL: gcc.target/i386/pr44578.c (internal compiler
On 11/21/2016 04:23 PM, Matthias Klose wrote:
On 21.11.2016 18:16, Rainer Orth wrote:
Hi Matthias,
ahh, didn't see that :-/ Now fixed, is this clearer now?
The options @option{--with-target-bdw-gc-include} and
@option{--with-target-bdw-gc-lib} must always specified together for
On Tue, Nov 29, 2016 at 05:00:05PM +0100, Markus Trippelsdorf wrote:
> Building gcc with -fsanitize=undefined shows:
> rtlanal.c:5210:38: runtime error: shift exponent 4294967295 is too large for
> 64-bit type 'long unsigned int'
>
> This happens because if_then_else_cond() in combine.c calls
>
On 11/17/2016 06:06 AM, Rainer Orth wrote:
I happened to notice that my libcilkrts SPARC port has been applied
upstream. So to reach closure on this issue for the GCC 7 release, I'd
like to import upstream into mainline which seems to be covered by the
free-for-all clause in https://gcc.gnu.org/
On 11/11/2016 07:30 AM, Martin Liška wrote:
Hello.
Motivation for the patch is to dump IPA clones that were created
by all inter-procedural optimizations. Usage of such input is to track
set of functions where a code from another function can eventually occur.
Usage of the dump file can be seen
libiberty's implementations of strndup and xstrndup call strlen on
the input string, and hence can read past the end of the input buffer
if it isn't zero-terminated (such as is the case in PR c/78498, where
the input string is from the input.c line cache).
This patch converts them to use strnlen i
On 11/29/16 16:06, Wilco Dijkstra wrote:
> Bernd Edlinger wrote:
>
> - "TARGET_32BIT && reload_completed
> + "TARGET_32BIT && ((!TARGET_NEON && !TARGET_IWMMXT) || reload_completed)
> && ! (TARGET_NEON && IS_VFP_REGNUM (REGNO (operands[0])))"
>
> This is equivalent to "&& (!TARGET_IWMMXT || re
On 11/28/2016 10:51 PM, Waldemar Brodkorb wrote:
Hi,
add common defines _REENTRANT and _POSIX_SOURCE for bfin.
Patch is used in Buildroot for a while to fix issues compiling
some software.
See here, why this should be always enabled:
https://lists.gnu.org/archive/html/autoconf-archive-maintainer
1 - 100 of 143 matches
Mail list logo
