Re: [patch,avr] Disallow LDS / STS for .rodata on AVR_TINY.

2016-11-18 16:31 GMT+03:00 Georg-Johann Lay : > 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 >

Re: [PATCHv2, C++] Warn on redefinition of builtin functions (PR c++/71973)

OK. On Sat, Nov 19, 2016 at 6:11 AM, Bernd Edlinger wrote: > Hi, > > On 11/18/16 22:19, Jason Merrill wrote: >> On 11/05/2016 12:44 PM, Bernd Edlinger wrote: >>> + warning_at (DECL_SOURCE_LOCATION (newdecl), 0, >>> + "declaration of %q+#D

Re: [PATCH] [AArch64] Fix PR78382

Hi Kugan, >> Why don't you use the mode of dest as done in other similar places. Like: Thanks for the pointer. Modified the patch as per your suggestion. Please find attached the modified patch and let me know your comments. Bootstrapped and regression tested on Thunderx. Thanks, Naveen

Re: [PATCH] Delete GCJ

On 11/20/2016 01:42 PM, Matthias Klose wrote: +The options @option{--with-target-bdw-gc-include} and +@option{--with-target-bdw-gc-include} must always specified together for +each multilib variant and take precedence over +@option{--with-target-bdw-gc-include}. If none of these options are

[PR target/48551] Make double_reg_address_ok a per-mode test

Sigh. Reload. Reload has the assumption that if reg+reg addressing is valid in QImode that it is valid in all modes. This has been baked into reload as long as I can remember. It's part of a larger problem that reload doesn't handle some cases where address validity is dependent upon the

Re: [RFC] Fix PR rtl-optimization/59461

On Mon, Nov 21, 2016 at 12:49 AM, Uros Bizjak wrote: > On Sun, Nov 20, 2016 at 10:00 PM, Uros Bizjak wrote: This also eliminate quite a few zero-extensions in the compile.exp testsuite at -O2 on the SPARC. Tested on x86-64/Linux and

Re: [RFC] Fix PR rtl-optimization/59461

On Sun, Nov 20, 2016 at 10:00 PM, Uros Bizjak wrote: >>> This also eliminate quite a few zero-extensions in the compile.exp testsuite >>> at -O2 on the SPARC. Tested on x86-64/Linux and SPARC/Solaris. >>> >>> >>> 2016-11-07 Eric Botcazou >>> >>> PR

Re: [PATCH] warn on overflow in calls to allocation functions (bugs 77531 and 78284)

On 11/20/2016 04:56 AM, Bernd Edlinger wrote: Hi, when you add a returns_nonnull to the builtin alloca then this code in tree-vrp.c (gimple_stmt_nonzero_warnv_p) should go away: if (flag_delete_null_pointer_checks && lookup_attribute ("returns_nonnull",

Re: [PATCH] avoid calling alloca(0)

On 11/20/2016 01:03 AM, Bernd Edlinger wrote: On 11/20/16 00:43, Martin Sebor wrote: As best I can tell the result isn't actually used (the code that uses the result gets branched over). GCC just doesn't see it. I verified this by changing the XALLOCAVEC macro to #define XALLOCAVEC(T, N)

Re: [PATCH] avoid calling alloca(0)

On 11/19/2016 11:18 PM, Jakub Jelinek wrote: On Sat, Nov 19, 2016 at 04:43:29PM -0700, Martin Sebor wrote: Thanks for calling out the realloc(0, p) case! Realloc(0, p) is ?? The DR you refer to deprecates realloc(p, 0), not realloc(0, p). We are discussing zero size allocation so I was

Re: [RFC] Fix PR rtl-optimization/59461

>> This also eliminate quite a few zero-extensions in the compile.exp testsuite >> at -O2 on the SPARC. Tested on x86-64/Linux and SPARC/Solaris. >> >> >> 2016-11-07 Eric Botcazou >> >> PR rtl-optimization/59461 >> * doc/rtl.texi (paradoxical subregs): Add missing word.

Re: [PATCH] Delete GCJ

On 10.10.2016 09:58, Iain Sandoe wrote: > >> On 10 Oct 2016, at 05:03, Matthias Klose wrote: >> >> On 07.10.2016 10:30, Iain Sandoe wrote: >>> On 7 Oct 2016, at 00:58, Matthias Klose wrote: On 06.10.2016 20:00, Mike Stump wrote: > On Oct 6,

Re: PR69741: Bad error in formal with array scalar loop counters

On Sat, Nov 19, 2016 at 03:44:12PM +0100, Harald Anlauf wrote: > > > > 2016-11-19 Harald Anlauf > > > > PR fortran/69741 > > * resolve.c (gfc_resolve_forall): Check for non-scalar index > > variables. > > > > 2016-11-19 Harald Anlauf > > > >

Re: PR61409: -Wmaybe-uninitialized false-positive with -O2

On 11/20/2016 09:36 AM, Aldy Hernandez wrote: On 11/16/2016 03:57 PM, Jeff Law wrote: On 11/02/2016 11:16 AM, Aldy Hernandez wrote: Hi Jeff. As discussed in the PR, here is a patch exploring your idea of ignoring unguarded uses if we can prove that the guards for such uses are invalidated by

Re: [PATCH] Enable Intel AVX512_4FMAPS and AVX512_4VNNIW instructions

On Sat, Nov 19, 2016 at 7:52 PM, Uros Bizjak wrote: > On Sat, Nov 19, 2016 at 6:24 PM, Jakub Jelinek wrote: >> On Sat, Nov 19, 2016 at 12:28:22PM +0100, Jakub Jelinek wrote: >>> On x86_64-linux with the 3 patches I'm not seeing any new FAILs >>> compared to

Re: Default associative containers constructors/destructor/assignment

On 17/11/2016 18:52, Jonathan Wakely wrote: On 28/10/16 21:42 +0200, François Dumont wrote: + template +struct _Rb_tree_key_compare +{ + _Key_compare_M_key_compare; + + _Rb_tree_key_compare() + _GLIBCXX_NOEXCEPT_IF( +

Re: Ping: Re: [PATCH 1/2] gcc: Remove unneeded global flag.

On Nov 19, 2016, at 1:59 PM, Andrew Burgess wrote: >> So, your new test fails on arm* targets: > > After a little digging I think the problem might be that > -freorder-blocks-and-partition is not supported on arm. > > This should be detected as the new tests

Re: PR61409: -Wmaybe-uninitialized false-positive with -O2

On 11/16/2016 03:57 PM, Jeff Law wrote: On 11/02/2016 11:16 AM, Aldy Hernandez wrote: Hi Jeff. As discussed in the PR, here is a patch exploring your idea of ignoring unguarded uses if we can prove that the guards for such uses are invalidated by the uninitialized operand paths being executed.

Re: [PATCH, Fortran, pr78395, v1] [OOP] error on polymorphic assignment

Whoops, hit send to fast. Here's the patch committed. - Andre On Sun, 20 Nov 2016 15:23:16 +0100 Andre Vehreschild wrote: > Hi Janus, > > thanks for the review. Committed to trunk as r242637. Will wait one week > before committing to 6. > > Regards, > Andre > > On Sat,

Re: [PATCH, Fortran, pr78395, v1] [OOP] error on polymorphic assignment

Hi Janus, thanks for the review. Committed to trunk as r242637. Will wait one week before committing to 6. Regards, Andre On Sat, 19 Nov 2016 16:14:54 +0100 Janus Weil wrote: > Hi Andre, > > > When checking the shortened example in comment #3 one gets a segfault, >

Re: PR78153

On 20 November 2016 at 19:34, Jakub Jelinek wrote: > On Sun, Nov 20, 2016 at 07:20:20PM +0530, Prathamesh Kulkarni wrote: >> --- a/gcc/tree-vrp.c >> +++ b/gcc/tree-vrp.c >> @@ -4013,6 +4013,16 @@ extract_range_basic (value_range *vr, gimple *stmt) >>

Re: PR78153

On Sun, Nov 20, 2016 at 07:20:20PM +0530, Prathamesh Kulkarni wrote: > --- a/gcc/tree-vrp.c > +++ b/gcc/tree-vrp.c > @@ -4013,6 +4013,16 @@ extract_range_basic (value_range *vr, gimple *stmt) > : vrp_val_max (type), NULL); > } > return; > + case

PR78153

Hi, As suggested by Martin in PR78153 strlen's return value cannot exceed PTRDIFF_MAX. So I set it's range to [0, PTRDIFF_MAX - 1] in extract_range_basic() in the attached patch. However it regressed strlenopt-3.c: Consider fn1() from strlenopt-3.c: __attribute__((noinline, noclone)) size_t fn1

Re: [libgcc] Protect __TMC_END__ - __TMC_LIST__ == 0

On Fri, 4 Nov 2016, Andrew Pinski wrote: On Fri, Nov 4, 2016 at 7:08 AM, Marc Glisse wrote: Ping https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02220.html I think this is obvious. Ok, I've committed it. -- Marc Glisse

Re: [PATCH] warn on overflow in calls to allocation functions (bugs 77531 and 78284)

Hi, when you add a returns_nonnull to the builtin alloca then this code in tree-vrp.c (gimple_stmt_nonzero_warnv_p) should go away: if (flag_delete_null_pointer_checks && lookup_attribute ("returns_nonnull", TYPE_ATTRIBUTES (gimple_call_fntype

New French PO file for 'gcc' (version 6.2.0)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the French team of translators. The file is available at: http://translationproject.org/latest/gcc/fr.po (This file, 'gcc-6.2.0.fr.po', has just

Re: [PATCH] avoid calling alloca(0)

On 11/20/16 00:43, Martin Sebor wrote: > As best I can tell the result isn't actually used (the code that > uses the result gets branched over). GCC just doesn't see it. > I verified this by changing the XALLOCAVEC macro to > > #define XALLOCAVEC(T, N) (N ? alloca (sizeof (T) * N) : 0) > > and