On 1/30/20 5:15 PM, David Malcolm wrote:
This test assumes that memset and strlen have been marked with
__attribute__((nonnull)), which isn't necessarily the case for an
arbitrary .
I sometimes find it useful to run tests with a cross-compiler. Those
that include standard library headers that
On Tue, 2020-01-28 at 08:36 +0100, Jakub Jelinek wrote:
> On Mon, Jan 27, 2020 at 09:09:37PM -0500, David Malcolm wrote:
> > > Please see calls.c (special_function_p), you should treat
> > > certainly
> > > also sigsetjmp as a setjmp call, and similarly to
> > > special_function_p,
> > > skip over
Various places in the analyzer use fold_build2, test the result, then
discard it. It's more efficient to use fold_binary, which avoids
building and GC-ing a redundant tree for the cases where folding fails.
gcc/analyzer/ChangeLog:
* constraint-manager.cc
gcc/analyzer/ChangeLog:
PR analyzer/93450
* constraint-manager.cc
(constraint_manager::get_or_add_equiv_class): Only compare constants
if their types are compatible.
* region-model.cc (constant_svalue::eval_condition): Replace check
for identical
On Thu, 2020-01-30 at 15:36 +0100, Jakub Jelinek wrote:
> On Thu, Jan 30, 2020 at 09:27:33AM -0500, David Malcolm wrote:
> > --- a/gcc/analyzer/region-model.cc
> > +++ b/gcc/analyzer/region-model.cc
> > @@ -666,12 +666,16 @@ constant_svalue::eval_condition
> > (constant_svalue *lhs,
> >
I found this useful whilst investigating a bug.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Committed to master as ebe9174e940c94e99cd688a05309833ae64a998b.
gcc/analyzer/ChangeLog:
* program-state.cc (extrinsic_state::dump_to_pp): New.
Here's a cleaned up version of the previous patch I posted. If Iain
reports this fixes the regressions he saw then I will push this.
All feedback welcome.
Thanks,
Andrew
---
>From 876996580d64d31407357787fc5df7bd5699b2c0 Mon Sep 17 00:00:00 2001
From: Andrew Burgess
Date: Thu, 30 Jan 2020
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Committed to master as ebe9174e940c94e99cd688a05309833ae64a998b.
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (for_each_state_change): Use
extrinsic_state::get_num_checkers rather than accessing m_checkers
This is my current work-in-progress version. There still are rough
edges, and not much is done for the output modifiers yet, but it should
be in much better shape wrt the user manual now. The internals manual
also is a bit better I think.
md.texi is not automatically kept in synch with
This test assumes that memset and strlen have been marked with
__attribute__((nonnull)), which isn't necessarily the case for an
arbitrary . This likely explains these failures:
FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 417)
FAIL: gcc.dg/analyzer/malloc-1.c (test for
Successfully regrtested on x86_64-pc-linux-gnu.
Committed to master as e34ad101a4338eab41e38e624f2c7178d0b83d24.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/conditionals-2.c: Move to...
* gcc.dg/analyzer/torture/conditionals-2.c: ...here, converting
to a torture test.
PR analyzer/93356 reports an ICE handling __builtin_isnan due to a
failing assertion:
674 gcc_assert (lhs_ec_id != rhs_ec_id);
with op=UNORDERED_EXPR.
when attempting to add an UNORDERED_EXPR constraint.
This is an overzealous assertion, but underlying it are various forms of
sloppiness
Hi.
This patch adds a new optimization to avoid the redundant calculation
tanh(x)/sinh(x) by replacing it for 1.0/cosh(x), for all cases where x is a
double, a long double or a float.
There should be no need for numerical stability testing, since the division
of the two functions only adds
The RISC-V toolchain doesn't support leb128 because of linker relaxation
to reduce code size. This prevents us from computing the leb128 size of a
value at compile time. So do a configure time gas feature check regardless
of gas version.
The libiconv configure change comes from the recent
On 29/01/2020 12:30, Thomas Schwinge wrote:
As can be seen in the code a few lines below, the very same problem also
exists for the 'wait' clause; it seems reasonable to fix both at the same
time. This is not a recent regression, but a user-visible valid-code ICE
that has existed "forever"; I
Hello-
While working on adding a new option, I noticed there are some options
(e.g. -fdiagnostics-format) that use the two-column form of the option
description, but separate the first column with space(s) rather than a
tab. This results in the help output looking a bit redundant, since the
On Thu, Jan 30, 2020 at 05:14:08PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 22, 2020 at 03:24:54PM +0100, Jakub Jelinek wrote:
> > > It looks like your patch will pessimise code in some cases as well, btw?
> >
> > No, it will solely turn previous wrong-codes into something that works
> > (==
Hi!
The following testcase FAILs on powerpc64le-linux with assembler errors, as we
emit a call to bar.localalias, then .set bar.localalias, bar twice and then
another call to bar.localalias. The problem is that bar.localalias can be
created
at various stages and e.g. ipa-pure-const can slightly
Hi!
What happens on this testcase is with the out of bounds rotate we get:
Trying 13 -> 16:
13: r129:SI=r132:DI#0<-<0x20
REG_DEAD r132:DI
16: r123:DI=r129:SI<0
REG_DEAD r129:SI
Successfully matched this instruction:
(set (reg/v:DI 123 [ ])
(const_int 0 [0]))
during
When instantiating a template tsubst_copy_and_build suppresses -Wtype-limits
warnings about e.g. == always being false because it might not always be
false for an instantiation with other template arguments. But we should
warn if the operands don't depend on template arguments.
I also tried
Jeff Law writes:
> On Wed, 2020-01-29 at 19:18 +, Richard Sandiford wrote:
>> Andreas Schwab writes:
>> > On Jan 27 2020, Richard Sandiford wrote:
>> >
>> > > * simplify-rtx.c (simplify_truncation): Extend sign/zero_extract
>> > > simplification to handle subregs as well as bare regs.
>>
Thanks Bernhard - this is now committed:
https://gcc.gnu.org/g:004ac7b780308dc899e565b887c7def0a6e100f2
On Thursday, January 30, 2020 5:27:55 PM PST Bernhard Reutner-Fischer wrote:
> On 29 January 2020 21:19:52 CET, Andrew Benson
wrote:
> >I think this patch is still waiting to be applied. I
On Wed, 29 Jan 2020, Jeff Law wrote:
> In the last major change in this code was ~5 years ago and twiddled the
> handling of the switch expression to call convert_lvalue_to_rvalue.
>
> The last argument to that function indicates whether or not we should
> mark the switch expression as a use of
On 1/30/20 10:01 AM, Richard Sandiford wrote:
Stam Markianos-Wright writes:
On 1/29/20 12:42 PM, Richard Sandiford wrote:
Stam Markianos-Wright writes:
Hi all,
This fixes:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93300
Genmodes.c was generating the "wider_mode" chain as follows:
On Thu, 2020-01-30 at 18:27 +0100, Jakub Jelinek wrote:
> On Thu, Jan 30, 2020 at 10:23:35AM -0700, Jeff Law wrote:
> > diff --git a/gcc/config/m68k/m68k.md b/gcc/config/m68k/m68k.md
> > index 8e35357ea23..78c4cbe4753 100644
> > --- a/gcc/config/m68k/m68k.md
> > +++ b/gcc/config/m68k/m68k.md
> >
On Thu, Jan 30, 2020 at 10:23:35AM -0700, Jeff Law wrote:
> diff --git a/gcc/config/m68k/m68k.md b/gcc/config/m68k/m68k.md
> index 8e35357ea23..78c4cbe4753 100644
> --- a/gcc/config/m68k/m68k.md
> +++ b/gcc/config/m68k/m68k.md
> @@ -644,12 +644,12 @@
>return m68k_output_branch_integer (code);
On Wed, 2020-01-29 at 19:18 +, Richard Sandiford wrote:
> Andreas Schwab writes:
> > On Jan 27 2020, Richard Sandiford wrote:
> >
> > > * simplify-rtx.c (simplify_truncation): Extend sign/zero_extract
> > > simplification to handle subregs as well as bare regs.
> >
> > That breaks
Am Donnerstag, den 30.01.2020, 16:50 + schrieb Michael Matz:
> Hi,
>
> On Thu, 30 Jan 2020, Uecker, Martin wrote:
>
> > > guarantees face serious implementation difficulties I think
> > > so the only alternative to PVNI (which I think is implementable
> > > but at a optimization opportunity
Hi,
On Thu, 30 Jan 2020, Michael Matz wrote:
> > and the pointers have the same address, then it would evaluate to true
> > at run-time. If I understand correctly, you somehow want to make this
> > case be UB, but I haven't quite understood how (if it is not the
> > comparison of such
* Iain Sandoe [2020-01-30 15:21:08 +]:
> >> Can you clarify why there’s no need to match the configury changes in
> >> libcpp
> >> / gcc / libstdc++ ?
> >
> > This is the same issue that Tobias pointed out, and was a result of me
> > incorrectly trying to regenerate the configure files.
>
This patch adds support for the LTGT FP comparison operator that was
previously missing from the backend, and apparently not optional (unlike
UNLE etc).
It wasn't that we couldn't have it (also unlike UNLE), we just didn't.
Besides just correcting an omission, this also fixes an ICE in
Hi,
On Thu, 30 Jan 2020, Uecker, Martin wrote:
> > guarantees face serious implementation difficulties I think
> > so the only alternative to PVNI (which I think is implementable
> > but at a optimization opportunity cost) is one that makes
> > two pointers with the same value always have the
On 30/01/2020 16:08, Thomas Schwinge wrote:
Hi!
Andrew and Frederik, thanks for your emails reminding/educating me about
'snprintf' as well as this HSA fixed-size buffer API. There doesn't
happen to be something available in the HSA API available so that we
could use 'sizeof [something]'
The recent SRA changes triggered a testsuite regression on the c6x port
for ssa-dse-26.c.
There was always a degree of difference between the targets, for
constraint_expr_equal. Depending on target characteristics there may
or may not be DSE opportunities in this function.
More importantly is
On 29 January 2020 21:19:52 CET, Andrew Benson
wrote:
>I think this patch is still waiting to be applied. I checked that it
>applies
>against trunk (with line offsets) and reg tests cleanly and posted an
>updated
>version (diff'd against current trunk) at:
>
On Wed, Jan 22, 2020 at 03:24:54PM +0100, Jakub Jelinek wrote:
> > It looks like your patch will pessimise code in some cases as well, btw?
>
> No, it will solely turn previous wrong-codes into something that works
> (== cases where gen_addr3_insn would previously fail).
> The 1)+2) variant could
Hi,
this patch implements more careful merging of topn values (tracking regression
we got by the reproducible profiling work). Instead of giving up on the
counter on the overflow we use sign bits to track
1) if there are some vlaues lost
2) if given target was not having probability at least
Hi!
Andrew and Frederik, thanks for your emails reminding/educating me about
'snprintf' as well as this HSA fixed-size buffer API. There doesn't
happen to be something available in the HSA API available so that we
could use 'sizeof [something]' instead of hard-coding '64' etc.?
I understand
Hi!
On 2020-01-10T23:52:11+0100, I wrote:
> On 2019-12-21T23:02:38+0100, I wrote:
>> On 2019-12-20T17:46:57+0100, "Harwath, Frederik"
>> wrote:
> --- a/include/gomp-constants.h
> +++ b/include/gomp-constants.h
>
> +#define GOMP_DEVICE_CURRENT -3
>
Should this
Hi Julian!
Notwithstanding the open question about how to implement this checking in
libgomp in a non-intrusive (performance-wise) yet maintainable (avoid
'#if 0') way, I have two more questions.
Is there a specific reason why this checking isn't also enabled for
libgomp OpenMP 'target' entry
Hi Andrew,
Andrew Burgess wrote:
> * Iain Sandoe [2020-01-28 10:34:52 +]:
>> * Before the patch, libcpp and gcc configury finds this and they agree on
>> the availability of ICONV (#define HAVE_ICONV 1).
>>
>> * After the patch libcpp no longer thinks iconv is available, but gcc
>>
Hi Delia,
On 1/28/20 4:44 PM, Delia Burduv wrote:
Ping.
*From:* Delia Burduv
*Sent:* 22 January 2020 17:26
*To:* gcc-patches@gcc.gnu.org
*Cc:* ni...@redhat.com ; Richard Earnshaw
; Ramana Radhakrishnan
; Kyrylo
On 1/30/20 2:42 PM, Stam Markianos-Wright wrote:
On 1/28/20 10:35 AM, Kyrill Tkachov wrote:
Hi Stam,
On 1/8/20 3:18 PM, Stam Markianos-Wright wrote:
On 12/10/19 5:03 PM, Kyrill Tkachov wrote:
Hi Stam,
On 11/15/19 5:26 PM, Stam Markianos-Wright wrote:
Pinging with more correct
Hi Nathan,
Nathan Sidwell wrote:
> On 1/29/20 10:39 AM, Iain Sandoe wrote:
>> Hi Nathan,
>> + /* If we are missing fundmental information, such as the traits, then
>> don't
>> + emit this for every keyword in a TU. This particular error is per TU
>> + so we don't need to keep the
On 1/28/20 10:35 AM, Kyrill Tkachov wrote:
Hi Stam,
On 1/8/20 3:18 PM, Stam Markianos-Wright wrote:
On 12/10/19 5:03 PM, Kyrill Tkachov wrote:
Hi Stam,
On 11/15/19 5:26 PM, Stam Markianos-Wright wrote:
Pinging with more correct maintainers this time :)
Also would need to backport to
On Thu, Jan 30, 2020 at 09:27:33AM -0500, David Malcolm wrote:
> --- a/gcc/analyzer/region-model.cc
> +++ b/gcc/analyzer/region-model.cc
> @@ -666,12 +666,16 @@ constant_svalue::eval_condition (constant_svalue *lhs,
>gcc_assert (CONSTANT_CLASS_P (lhs_const));
>gcc_assert (CONSTANT_CLASS_P
PR analyzer/93450 reports an ICE trying to fold an EQ_EXPR comparison
of (int)0 with (float)Inf.
Most comparisons inside the analyzer come from gimple conditions, for
which the necessary casts have already been added.
This one is done inside constant_svalue::eval_condition as part of
purging
Am Donnerstag, den 30.01.2020, 09:30 +0100 schrieb Richard Biener:
> On Wed, Jan 29, 2020 at 3:00 PM Uecker, Martin
> wrote:
...
> > > I guess I'd me much more happy if PVNI said that when
> > > an integer is converted to a pointer and the integer
> > > is value-equivalent to pointers { p1, p2,
On 30/01/2020 13:49, Richard Biener wrote:
On Thu, Jan 30, 2020 at 2:04 PM Bin.Cheng wrote:
On Thu, Jan 30, 2020 at 8:53 PM Andrew Stubbs wrote:
On 29/01/2020 08:24, Richard Biener wrote:
On Tue, Jan 28, 2020 at 5:53 PM Andrew Stubbs wrote:
This patch fixes an ICE compiling
On Thu, Jan 30, 2020 at 2:04 PM Bin.Cheng wrote:
>
> On Thu, Jan 30, 2020 at 8:53 PM Andrew Stubbs wrote:
> >
> > On 29/01/2020 08:24, Richard Biener wrote:
> > > On Tue, Jan 28, 2020 at 5:53 PM Andrew Stubbs
> > > wrote:
> > >>
> > >> This patch fixes an ICE compiling fast-math-pr55281.c for
On Thu, Jan 30, 2020 at 11:49 AM Prathamesh Kulkarni
wrote:
>
> On Wed, 29 Jan 2020 at 14:38, Richard Biener
> wrote:
> >
> > On Tue, Jan 28, 2020 at 1:02 PM Jakub Jelinek wrote:
> > >
> > > On Tue, Jan 28, 2020 at 05:09:36PM +0530, Prathamesh Kulkarni wrote:
> > > > On Tue, 28 Jan 2020 at
* Iain Sandoe [2020-01-28 10:34:52 +]:
> Hi Andrew,
>
> Andrew Burgess wrote:
>
> > * Jeff Law [2020-01-22 13:52:27 -0700]:
> >
> > > On Wed, 2020-01-22 at 15:39 +, Andrew Burgess wrote:
> > > > The motivation behind this change is to make it easier for a user to
> > > > link
On Thu, Jan 30, 2020 at 5:31 AM Prathamesh Kulkarni
wrote:
>
> On Tue, 28 Jan 2020 at 17:17, Richard Biener
> wrote:
> >
> > On Fri, Jan 24, 2020 at 7:04 AM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Mon, 20 Jan 2020 at 15:44, Richard Biener
> > > wrote:
> > > >
> > > > On Wed, Jan 8,
This wraps { ... } in _Literal (type) for consumption by the GIMPLE FE.
Bootstrap & regtest ongoing on x86_64-unknown-linux-gnu, will push
to trunk since it eases debugging.
Richard.
2020-01-30 Richard Biener
* tree-pretty-print.c (dump_generic_node): Wrap VECTOR_CST
and
Value-numbering failed to handle __builtin_{memcpy,memset,...}_chk
variants when removing abstraction and also failed to use the
value-numbering lattice when requiring the length argument of the
call to be constant.
Bootstrapped and tested on x86_64-unknown-linux-gnu, queued for GCC 11
unless
On Thu, Jan 30, 2020 at 8:53 PM Andrew Stubbs wrote:
>
> On 29/01/2020 08:24, Richard Biener wrote:
> > On Tue, Jan 28, 2020 at 5:53 PM Andrew Stubbs wrote:
> >>
> >> This patch fixes an ICE compiling fast-math-pr55281.c for amdgcn.
> >>
> >> The problem is that an "iv" is created in which both
On 29/01/2020 08:24, Richard Biener wrote:
On Tue, Jan 28, 2020 at 5:53 PM Andrew Stubbs wrote:
This patch fixes an ICE compiling fast-math-pr55281.c for amdgcn.
The problem is that an "iv" is created in which both base and step are
pointer types,
How did you get a POINTER_TYPE step?
An ICE was noticed in pa_elf_select_rtx_section building googletest on
hppa-unknown-linux-gnu.
This change fixes the problem. It puts function pointer rtx's without a DECL
in .data.rel.ro.local.
Tested on hppa-unknown-linux-gnu. Committed to trunk and gcc-9 branch.
Dave
2020-01-30 John
On 1/29/20 10:39 AM, Iain Sandoe wrote:
Hi Nathan,
Nathan Sidwell wrote:
Made the function type error recorded per function too.
OK now?
Still some things to address ...
diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index e8a6a4033f6..3ad80699ca0 100644
---
Hi All,
Thank you for taking care of that, Jakub. I have been overwhelmed by
daytime work since my last posting and, in addition, have yet to set
up a git workflow. This situation is likely to continue for at least
another 3-4 months. I will release all the PRs assigned to me, except
those
Jakub Jelinek writes:
> Hi!
>
> uaddvdi4 expander has an optimization for the low 32-bits of the 2nd input
> operand known to be 0. Unfortunately, in that case it only emits copying of
> the low 32 bits to the low 32 bits of the destination, but doesn't emit the
> addition with overflow
On Wed, 29 Jan 2020 at 14:38, Richard Biener wrote:
>
> On Tue, Jan 28, 2020 at 1:02 PM Jakub Jelinek wrote:
> >
> > On Tue, Jan 28, 2020 at 05:09:36PM +0530, Prathamesh Kulkarni wrote:
> > > On Tue, 28 Jan 2020 at 17:00, Jakub Jelinek wrote:
> > > >
> > > > On Tue, Jan 28, 2020 at 04:56:59PM
Stam Markianos-Wright writes:
> On 1/29/20 12:42 PM, Richard Sandiford wrote:
>> Stam Markianos-Wright writes:
>>> Hi all,
>>>
>>> This fixes:
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93300
>>>
>>> Genmodes.c was generating the "wider_mode" chain as follows:
>>>
>>> HF -> BF -> SF -
On Thu, Jan 30, 2020 at 09:47:22AM +, Andrew Stubbs wrote:
> > By "that much", I mean that while the host vs. offloading target interfaces
> > should be ok due to structure layout done in the host compiler and then
> > streamed to the offloading compiler, there is the problem when the
> >
On 30/01/2020 09:20, Jakub Jelinek wrote:
On Fri, Jan 24, 2020 at 03:59:28PM +0100, Tobias Burnus wrote:
As reported in PR93409, the build of libgomp/plugin/plugin-gcn.c fails with
a bunch of error messages when building with
--with-multilib-list=m32,m64,mx32
The reason is that the GCN plugin
On Fri, Jan 24, 2020 at 03:59:28PM +0100, Tobias Burnus wrote:
> As reported in PR93409, the build of libgomp/plugin/plugin-gcn.c fails with
> a bunch of error messages when building with
> --with-multilib-list=m32,m64,mx32
>
> The reason is that the GCN plugin assumes 64bit pointers. As with
Hi!
uaddvdi4 expander has an optimization for the low 32-bits of the 2nd input
operand known to be 0. Unfortunately, in that case it only emits copying of
the low 32 bits to the low 32 bits of the destination, but doesn't emit the
addition with overflow detection for the high 64 bits.
Well, to
On Wed, Jan 29, 2020 at 3:00 PM Uecker, Martin
wrote:
>
> Am Mittwoch, den 29.01.2020, 09:45 +0100 schrieb Richard Biener:
> > On Tue, Jan 28, 2020 at 1:24 PM Uecker, Martin
> > wrote:
>
> > > >
> > > > Note for the current PTA implementation there's almost no cases we can
> > > > handle
On 29.01.2020. 22:57, Dragan Mladjenovic wrote:
On 29.01.2020. 12:06, Tobias Burnus wrote:
Hi Dragan,
I think your committed patch was incomplete – at least I see the
following bits when running --enable-maintainer-mode (see attachment,
line numbers wrong as I edited my changes out).
Can you
From: Dragan Mladjenovic
Commit 54b3d52 ("Emit .note.GNU-stack for hard-float linux targets.")
was missing generated files. Add them now.
gcc/ChangeLog:
2020-01-30 Dragan Mladjenovic
* config.in: Regenerated.
* configure: Regenerated.
---
gcc/ChangeLog | 5 +
70 matches
Mail list logo
