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
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
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
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
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
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 C
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)
>> : vrp_val_max (
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,
> > because v6 is not
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, 19 Nov 2016 16:1
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.
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 include:
>
>/* { dg-require-effe
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(
+ is_nothrow_default_constructible<_Key_compar
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 before r242569, on i686-linux there is
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 t
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
> >
> > PR fortran/69741
> > * gfor
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, 2016, at 9:56 AM, Rainer Orth
>> 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.
>> * combine.c (reg_nonz
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 obv
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) (N
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",
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 rtl-optimization/59461
>>> * doc/rtl.texi (pa
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 SPARC/Solaris.
2016-11-07 Eric
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 c
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
+sp
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
d
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 conflicts with built-in "
>>> +
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
> descriptions whic
27 matches
Mail list logo
