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 +
gcc/conf
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
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 conserva
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 be
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 HSA,
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 a
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
> > offlo
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 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 +0
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 detection
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 associa
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
--- a/gcc/cp/coroutine
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 Davi
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? That'
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 b
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 so
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 CONS
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, 2020
* 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 against
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 17:0
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 a
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 fast-math-pr
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,
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 sm-s
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 (
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 gcc7
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 ind
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 maintaine
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 Tkachov
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
>> cont
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 po
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 actu
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 cor
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 1/T
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
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:
>
>https://gcc.gnu.org/bugzilla/show_b
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 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]' instea
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 sam
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 testcas
* 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.
>
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 pointers
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 c
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 gcc.ta
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 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 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:
HF
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 t
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 ch
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.
>> >
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 givin
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 combin
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
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
> > (== case
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
option
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 fi
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 config
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 numeri
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 rega
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. Remov
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 warnings
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 constrain
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
di
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 12:
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.
(extrinsic_state::dump_to_
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 type
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,
> >gcc_asse
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 (range::constrained_to_single_elem
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
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
70 matches
Mail list logo
