On Wed, Apr 12, 2017 at 11:16 PM, Jeff Law wrote:
> On 04/07/2017 08:02 AM, Xi Ruoyao wrote:
>>
>> On 2017-04-06 11:12 -0600, Jeff Law wrote:
>>
>>> With the likely deprecation in mind, I've only done a cursory review of
>>> the changes -- mostly to verify that they hit Cilk+ paths only.
>>
>>
>>>
On Wed, Apr 12, 2017 at 6:55 PM, Christophe Lyon
wrote:
> Hi,
>
> It looks like we forgot to backport the fix for PR68390 to gcc-5-branch.
> The patch applies cleanly, and fwiw we've had it in the linaro-5
> branch for a while.
>
> OK to apply to gcc-5-branch?
>
OK if there are no regressions (th
Hi,
In the testcase for PR (which I do not know how to turn in to a testuiste
version becuase it requires LTOed dynamic library) there is comdat group
with one hiddena and one global symbol. At LTO we realize that hidden
symbol can be brought static, but at that time we also accidentally localize
On 12/04/17 19:02, Josh Conner via gcc-patches wrote:
Ping^3?
I think this should be very straightforward - it just adds fuchsia target
support to libgcc. Please do let me know if there are any concerns...
The arm parts look ok to me. You'll still need approval for the other parts
though.
On Wed, 12 Apr 2017, Peter Bergner wrote:
> This patch is the second attempt to fix PR51513, namely the generation of
> wild branches due to switch case statements that only contain calls to
> __builtin_unreachable(). With the first attempt:
>
> https://gcc.gnu.org/ml/gcc-patches/2016-04/msg
Hi Gerald, Jerry,
as the author of this program (and the maintainer of that site) I am
honoured that you refer to this. But I would like to tell you a bit
about the history:
I started CHKSYS in the time that FORTRAN 77 was still the main
standard, so much of the tests that are contained in this pr
Hello everyone.
I have patch to fix segfault with -fsanitize=undefined on 32 bit host.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80414
Can someone please review it.
Thanks.
commit 3bb53510ae11a9fa1f79ae83469c2650abe81ab4
Author: Denis Khalikov
Date: Thu Apr 13 12:03:19 2017 +0300
On Fri, Apr 7, 2017 at 11:42 PM, Jakub Jelinek wrote:
> Hi!
>
> The following C and Ada testcases show ICE due to endless recursion in
> dwarf2out.c. The problem is that when processing BLOCK_NONLOCALIZED_VARS,
> we want to treat all the FUNCTION_DECLs in there as mere declarations,
> but gen_sub
The following hopefully fixes asm constraints (works for ia64 now,
still works on x86_64).
Richard.
2017-04-13 Richard Biener
PR testsuite/80416
* g++.dg/torture/pr79671.C: Fix asm constraints.
Index: gcc/testsuite/g++.dg/torture/pr79671.C
===
On Thu, Apr 13, 2017 at 10:14:51AM +0200, Richard Biener wrote:
> now I do not remember the reason why we keep __builtin_unreachable ()
> at the RTL level -- on GIMPLE we keep it to be able to extract
I believe we don't. In RTL __builtin_unreachable () is represented
as a basic block without succ
The behavior of the copy/copyin/copyout/create clauses has been changed
in OpenACC 2.5 to be like the present_or_* variants, and the original
present_or_* syntax relegated to legacy status.
This patch removes the presence of any PRESENT_OR_* symbols, and
changes the mapping of the copy/copyin/copy
>On Wed, Apr 12, 2017 at 09:29:55AM +, Sudi Das wrote:
> > Hi all
> >
> > This is a fix for PR 80131
> > Currently the code A << (B - C) is not simplified.
>> However at least a more specific case of 1U << (C -x) where C =
>> precision(type) - 1 can be simplified to (1 << C) >> x.
>
> Is tha
Hello.
As the function is called with argument equal to zero, the memcpy should be
done just in case alloc is greater than zero.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
And gcov.exp works on x86_64-linux-gnu.
Ready to be installed?
Martin
>From 82f609465a9702a0
On Thu, Apr 13, 2017 at 11:16:08AM +, Wilco Dijkstra wrote:
> >On Wed, Apr 12, 2017 at 09:29:55AM +, Sudi Das wrote:
> > > Hi all
> > >
> > > This is a fix for PR 80131
> > > Currently the code A << (B - C) is not simplified.
> >> However at least a more specific case of 1U << (C -x) wher
On 04/13/2017 07:19 AM, Martin Liška wrote:
Hello.
As the function is called with argument equal to zero, the memcpy should be
done just in case alloc is greater than zero.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
And gcov.exp works on x86_64-linux-gnu.
the p
Jakub Jelinek wrote:
> No. Some constants sometimes even 7 instructions (e.g. sparc64; not talking
> in particular about 1ULL << 63 constant), or have one instruction
> that is more expensive than normal small constant load. Compare say x86_64
> movl/movq vs. movabsq, I think the latter has
On Thu, Apr 13, 2017 at 11:33:12AM +, Wilco Dijkstra wrote:
> Jakub Jelinek wrote:
>
> > No. Some constants sometimes even 7 instructions (e.g. sparc64; not talking
> > in particular about 1ULL << 63 constant), or have one instruction
> > that is more expensive than normal small constant
On Thu, Apr 13, 2017 at 1:41 PM, Jakub Jelinek wrote:
> On Thu, Apr 13, 2017 at 11:33:12AM +, Wilco Dijkstra wrote:
>> Jakub Jelinek wrote:
>>
>> > No. Some constants sometimes even 7 instructions (e.g. sparc64; not
>> > talking
>> > in particular about 1ULL << 63 constant), or have one inst
On Thu, Apr 13, 2017 at 01:49:01PM +0200, Richard Biener wrote:
> It is IMHO a valid GIMPLE optimization / canonicalization.
As I said, we can do it as GIMPLE canonicalization, but
we should have code to undo it if beneficial at RTL level.
And the patch has not included that.
>
> movabsq
Richard Biener wrote:
> It is IMHO a valid GIMPLE optimization / canonicalization.
>
> movabsq $-9223372036854775808, %rax
>
> so this should then have been generated as 1<<63?
>
> At some point variable shifts were quite expensive as well..
Yes I don't see a major difference between movabs
On Thu, Apr 13, 2017 at 12:28:40PM +0300, Denis Khalikov wrote:
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/ubsan/bounds-15.c
> @@ -0,0 +1,11 @@
> +/* { dg-do run } */
> +/* { dg-options "-fsanitize=bounds" } */
> +/* { dg-skip-if "" { *-*-* } { "*" } { "-O0" } } */
> +
> +int main()
> +{
>
On 04/12/2017 06:33 PM, Kelvin Nilsen wrote:
>
> 1. As input arguments, out_insn represents an rtl expression that
> potentially "produces" a store to memory and in_insn represents an rtl
> expression that potentially "consumes" a value recently stored to memory.
>
You have this reversed, the cod
Thanks for review.
I updated the patch.
On 04/13/2017 04:10 PM, Jakub Jelinek wrote:
On Thu, Apr 13, 2017 at 12:28:40PM +0300, Denis Khalikov wrote:
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/ubsan/bounds-15.c
@@ -0,0 +1,11 @@
+/* { dg-do run } */
+/* { dg-options "-fsanitize=bounds" } */
On Thu, Apr 13, 2017 at 04:55:52PM +0300, Denis Khalikov wrote:
> +2017-04-13 Denis Khalikov
> +
> + PR sanitizer/80414
> + * ubsan.c (ubsan_expand_bounds_ifn): Fix wrong tree val generation
> + for 32 bit host.
I'd say here instead ...): Pass original index to ubsan_encode_value.
>
The mn103 port fails to build newlib/libgcc because it's got a
non-simplifyable (subreg (mem)) in a debug insn.
reload will call eliminate_regs_1 on the debug insn. It'll see the
subreg and call gen_rtx_SUBREG. That asserts that the subreg is valid.
Which (of course) fails.
The key here
On Thu, Apr 13, 2017 at 08:03:48AM -0600, Jeff Law wrote:
>
> The mn103 port fails to build newlib/libgcc because it's got a
> non-simplifyable (subreg (mem)) in a debug insn.
>
> reload will call eliminate_regs_1 on the debug insn. It'll see the subreg
> and call gen_rtx_SUBREG. That asserts t
On 04/13/2017 08:06 AM, Jakub Jelinek wrote:
On Thu, Apr 13, 2017 at 08:03:48AM -0600, Jeff Law wrote:
The mn103 port fails to build newlib/libgcc because it's got a
non-simplifyable (subreg (mem)) in a debug insn.
reload will call eliminate_regs_1 on the debug insn. It'll see the subreg
and
Hi,
I've applied the patch for Denis in r246909. Also, the issue seems to
appear at least in GCC 6 (and perhaps in 5, I need to check).
Is it OK to apply the patch on branches after testing?
-Maxim
On 13/04/17 17:03, Jakub Jelinek wrote:
On Thu, Apr 13, 2017 at 04:55:52PM +0300, Denis Khalik
Hi,
On Wed, Apr 12, 2017 at 01:55:01PM +0200, Richard Biener wrote:
> On Wed, 12 Apr 2017, Martin Jambor wrote:
>
> > Hi,
> >
> > the patch below is an attempt to deal with PR 80293 as non-invasively
> > as possible. Basically, it switches off total SRA scalarization of
> > any local aggregates
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80343
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 246914.
Index: ChangeLog
===
--- ChangeLog (revision 246907)
+++ Ch
Dear Dominique,
The attached fixes the problem withPR51218 and bootstraps and regtests
on FC23/x86_64 - OK for trunk?
Cheers
Paul
2017-04-13 Paul Thomas
PR fortran/34640
* expr.c (gfc_check_pointer_assign): Exclude pointer array
components in test for 'subref_array_pointer' attr
On Thu, Apr 13, 2017 at 05:56:56PM +0300, Maxim Ostapenko wrote:
> Hi,
>
> I've applied the patch for Denis in r246909. Also, the issue seems to appear
> at least in GCC 6 (and perhaps in 5, I need to check).
> Is it OK to apply the patch on branches after testing?
Yes.
Jakub
On April 13, 2017 7:41:29 PM GMT+02:00, Martin Jambor wrote:
>Hi,
>
>On Wed, Apr 12, 2017 at 01:55:01PM +0200, Richard Biener wrote:
>> On Wed, 12 Apr 2017, Martin Jambor wrote:
>>
>> > Hi,
>> >
>> > the patch below is an attempt to deal with PR 80293 as
>non-invasively
>> > as possible. Basica
On 04/13/2017 02:13 AM, Arjen Markus wrote:
> Hi Gerald, Jerry,
>
> as the author of this program (and the maintainer of that site) I am
> honoured that you refer to this. But I would like to tell you a bit
> about the history:
> I started CHKSYS in the time that FORTRAN 77 was still the main
> st
On Wed, Apr 12, 2017 at 06:12:57PM +0200, Jakub Jelinek wrote:
> @@ -11542,7 +11544,7 @@ fold_ternary_loc (location_t loc, enum t
> && (code == VEC_COND_EXPR || !VECTOR_TYPE_P (type)))
> return fold_build2_loc (loc, code == VEC_COND_EXPR ? BIT_AND_EXPR
>
Hi!
Finally got to debug why most libgomp offloading tests fail on
powerpc64le-linux when configured for NVPTX offloading.
The problem is -funsigned-char by default, so
if (cuda_lib_inited != -1)
was always true. Fixed thusly, bootstrapped/regtested on x86_64-linux
and powerpc64le-linux, committ
Bah, fixing up my return address.
On 4/13/17 3:14 AM, Richard Biener wrote:
> To recap the situation (from what I can deciper out of the ppc asm
> and the expand RTL) we seem to expand to
>
> if (cond > 2)
> __builtin_unreachable (); // jumps to the jump table data(?)
> goto *tbl[cond];
Resending as plain text:
On April 12, 2017 at 3:03:19 PM, Jeff Law
(l...@redhat.com(mailto:l...@redhat.com)) wrote:
> >
> > 2017-04-05 Damian Rouson
> >
> > * download_prerequisites (md5_check): New function emulates Linux
> > 'md5 --check' on macOS. Modified script for macOS compatib
On 04/12/17 17:58, Yvan Roux wrote:
> Hi,
>
> On 20 February 2017 at 18:53, Bruce Korb wrote:
>> On 02/18/17 01:01, Bernd Edlinger wrote:
>>> On 02/18/17 00:37, Bruce Korb wrote:
On 02/06/17 10:44, Bernd Edlinger wrote:
> I tested this change with different arm-linux-gnueabihf cross
>
The mips64vr-elf target will fail building newlib, particularly the
mips16 newlib as we emit bogus assembly code.
In particular the compiler will emit something like
lwu $2,0($sp)
That's invalid in mips16 mode AFAICT.
That's emitted by the extendsidi pattern. It's a case where the operand
40 matches
Mail list logo
