The vrbit_1 test was missing a flag to disable code sharing.
Committed as obvious.
ChangeLog:
2019-11-20 Wilco Dijkstra
testsuite/
* gcc.target/aarch64/simd/vrbit_1.c: Add -fno-ipa-icf.
--
diff --git a/gcc/testsuite/gcc.target/aarch64/simd/vrbit_1.c
b/gcc/testsuite/gcc.target/aar
On Wed, 20 Nov 2019, Matthew Malcomson wrote:
> I don't have much of a plan.
>
> The most promising lead I have is that libiberty/alloca.c has a similar
> functionality but with macros to account for a special case.
The comment in libiberty/aclocal.m4 is:
# We always want a C version of alloca
On Wed, 20 Nov 2019, Jakub Jelinek wrote:
> On Wed, Nov 20, 2019 at 10:17:38AM -0600, Segher Boessenkool wrote:
> > On Wed, Nov 20, 2019 at 03:46:29PM +, Richard Sandiford wrote:
> > > Segher Boessenkool writes:
> > > > UNLT & ORDERED is always LT. When would it not be true?
> > >
> > > LT
Segher Boessenkool writes:
>> /* Make sure that the value that is to be substituted for the register
>> does not use any registers whose values alter in between. However,
>> If the insns are adjacent, a use can't cross a set even though we
>> think it might (this can happe
When compiling __RTL functions with a start pass, `skip_pass` needs to
set global state when skipping a pass that would have marked something
for future passes to see.
Existing examples are setting `reload_completed` and
`epilogue_completed` when skipping the reload and pro_and_epilogue
passes res
On 11/20/19 9:16 AM, Jakub Jelinek wrote:
On Tue, Nov 19, 2019 at 11:35:02PM -0500, Jason Merrill wrote:
It would seem better to break after consuming the token, so we just skip the
extra processing and still give the same error.
And instead of this, maybe set CP_PARSER_FLAGS_NO_TYPE_DEFINITION
On 11/19/19 11:29 PM, Jakub Jelinek wrote:
Hi!
The following patch fixes build of older GCC releases with newer ones.
In GCC 4.6 and earlier, we had:
struct cgraph_node;
struct cgraph_node *cgraph_node (tree);
and that is something on which GCC 9+ code errors on if it sees any
__gcc_diag__ and s
On 11/20/19 4:40 PM, Paolo Carlini wrote:
Hi,
while working on improving the locations of cp_build_indirect_ref_1 &
co, I noticed this nit which seems a separate issue.
In a nutshell, at variance with many other cases, in build_x_arrow we
don't immediately check for error_mark_node the retur
On 11/20/19 10:54 AM, David Malcolm wrote:
On Wed, 2019-11-20 at 00:38 +0100, Jakub Jelinek wrote:
Hi!
The following patch is a minimal fix to avoid
cannot convert ‘‘addr_expr’ not supported by dump_type’
to ‘X*’
and similar messages. The recently added complain_about_bad_argument
function exp
On Mon, Nov 18, 2019 at 02:41:48PM -0500, Jason Merrill wrote:
> > 2019-11-11 Jakub Jelinek
> >
> > PR c++/92458
> > * constraint.cc: Include tree-hash-traits.h.
> > (decl_tree_cache_traits): New type.
> > (decl_tree_cache_map): New typedef.
> > (decl_constraints): Change ty
On Wed, Nov 20, 2019 at 3:16 PM Bernd Schmidt wrote:
>
> On 11/20/19 2:50 PM, Mikael Pettersson wrote:
> > On Mon, Nov 18, 2019 at 9:57 PM Mikael Pettersson
> > wrote:
> >>
> >> On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt
> >> wrote:
> >>>
> >>> Hi Mikael,
> >>>
> This fixed the problem
On Wed, Nov 20, 2019 at 5:46 PM Tobias Burnus wrote:
>
> Hi Janne,
>
> On 11/18/19 9:34 PM, Janne Blomqvist wrote:
> > Now that we require a minimum of MPFR 3.1.0+ to build GCC, we can do
> > some modernization of the MPFR usage in the GFortran frontend.
>
> OK – thanks for the cleanup.
>
> [For r
On 11/20/19 12:27 PM, Mikael Pettersson wrote:
> On Wed, Nov 20, 2019 at 3:16 PM Bernd Schmidt
> wrote:
>>
>> On 11/20/19 2:50 PM, Mikael Pettersson wrote:
>>> On Mon, Nov 18, 2019 at 9:57 PM Mikael Pettersson
>>> wrote:
On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt
wrote:
>
On Wed, Nov 20, 2019 at 7:53 PM Joseph Myers wrote:
>
> This patch is OK with http changed to https. (That is, with it changed
> where the patch is already changing the URL. While changing http to https
> makes sense more generally in the documentation whenever a site supports
> https, that's pr
On Tue, Nov 19, 2019 at 05:33:09PM -0500, Jason Merrill wrote:
> On 11/19/19 1:44 AM, Marek Polacek wrote:
> > > It also looks like you're using the LOOKUP flag to mean two different
> > > things:
> > >
> > > 1) try to treat parenthesized args as an aggregate initializer
> > > (build_new_method_ca
On Wed, Nov 20, 2019 at 8:00 PM Bernhard Reutner-Fischer
wrote:
>
> On 19 November 2019 23:54:55 CET, Thomas Koenig wrote:
> >Am 19.11.19 um 11:39 schrieb Bernhard Reutner-Fischer:
> >> + char name[GFC_MAX_SYMBOL_LEN + 1];
> >> + snprintf (name, GFC_MAX_SYMBOL_LEN, "__dummy_%d_%s", var_
On Sat, Nov 16, 2019 at 10:34 PM Thomas Koenig wrote:
>
> Hello world,
>
> here is an update to the patch.
>
> I have now included variables where the user did not specify INTENT(IN)
> by checking that the dummy variables to be replaced by temporaries
> are not, indeed, assigned a value. This also
On Wed, Nov 20, 2019 at 06:20:34PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > So this would work if you had pseudos here, instead of the hard reg?
> > Because it is a hard reg it is the same number in both places, making it
> > hard to move.
>
> Yeah, probably. But the hard
On 11/20/19 8:27 PM, Mikael Pettersson wrote:
> On Wed, Nov 20, 2019 at 3:16 PM Bernd Schmidt wrote:
>> Probably best to just run tests on stage1 and hope something shows up.
>
> Ok, how do I did that? I've always just done 'make -k check' after
> full bootstraps.
> I assume the stage 1 artifact
On Tue, Nov 19, 2019 at 05:34:45PM -0500, Jason Merrill wrote:
> On 11/18/19 7:04 PM, Marek Polacek wrote:
> > The newly added diagnostic causes an ICE because the new grokdeclarator call
> > returned error_mark_node and DECL_SOURCE_LOCATION crashes on that. So don't
> > attempt to print the new d
On 11/7/19 1:06 PM, Peter Bergner wrote:
> Before, LRA, we have an insn that sets a TImode pseudo with an integer
> constant and a following insn that copies that TImode pseudo to a PTImode
> pseudo. During LRA spilling, we generate a new insn that sets a PTImode
> pseudo to that constant directly
On Wed, Nov 20, 2019 at 10:38:30PM +0200, Janne Blomqvist wrote:
> On Wed, Nov 20, 2019 at 8:00 PM Bernhard Reutner-Fischer
> wrote:
> >
> > On 19 November 2019 23:54:55 CET, Thomas Koenig
> > wrote:
> > >Am 19.11.19 um 11:39 schrieb Bernhard Reutner-Fischer:
> > >> + char name[GFC_MAX_SYMB
gcc/ChangeLog:
* analyzer/analysis-plan.cc: Remove include of "params.h".
(analysis_plan::use_summary_p): Update for conversion of params to
options.
* analyzer/engine.cc: Remove include of "params.h".
(exploded_graph::get_or_create_node): Update for conversi
r277284 eliminated json::number in favor of json::float_number and
json::integer_number. Update the diagnostic metadata code accordingly.
gcc/ChangeLog:
* diagnostic-format-json.cc (json_from_metadata): Use
json::integer_number.
---
gcc/diagnostic-format-json.cc | 3 ++-
1 file c
I've rebased my static analysis work (from r276961 to r278495)
This patch kit contains the changes that were needed (patches 1-4),
along with various followups (patches 5-11).
These patches fix the worst of the issues with LTO compatibility;
an example LTO diagnostic is:
https://dmalcolm.fedorap
Various commits on 2019-11-12 including r278083 through r278087
reimplemented parameter-handling in terms of options, so that
params are defined in params.opt rather than params.def.
This patch adds the params for the analyzer to plugin.opt,
replacing the patch:
[PATCH 22/49] analyzer: params.d
This patch fixes the missing leak report in setjmp-7.c, which failed
to report on an unchecked "malloc" result leaking due to a longjmp
skipping past its frame to a setjmp in its caller.
The root cause issue is that impl_region_model_context::on_state_leak
would call the state machine's on_leak vf
r277284 eliminated json::number in favor of json::float_number and
json::integer_number. Update the diagnostic_path code accordingly.
gcc/ChangeLog:
* tree-diagnostic-path.cc (default_tree_make_json_for_path): Fix
overlong line. Use json::integer_number.
---
gcc/tree-diagnostic-
"convert" is not implemented in lto1, leading to an ICE when used.
This patch implements a build_cast function for the analyzer and uses it
to replace the call to "convert" when handling casts in region_model.
This fixes numerous ICEs when running the analyzer from LTO.
gcc/ChangeLog:
*
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/malloc-ipa-8-lto-a.c: New test.
* gcc.dg/analyzer/malloc-ipa-8-lto-b.c: New test.
* gcc.dg/analyzer/malloc-ipa-8-lto-c.c: New test.
* gcc.dg/analyzer/malloc-ipa-8-lto.h: New test.
---
gcc/testsuite/gcc.dg/analyzer/malloc-ip
This patch adds some special-case logic to how paths are generated
so that leaks due to longjmp rewinding past a frame now show where the
longjmp rewinds to (longjmp and setjmp are already something of a
special-case so this seems reasonable).
A colorized LTO example of the output can be seen at:
This patch adds a new debugging function.
gcc/ChangeLog:
* analyzer/checker-path.cc (checker_path::debug): New member
function.
* analyzer/checker-path.h (checker_path::debug): New decl.
---
gcc/analyzer/checker-path.cc | 19 +++
gcc/analyzer/checker-path.h
gcc/ChangeLog:
* doc/analyzer.texi (Analyzer Paths): Add path pruning and
precision-of-wording vfuncs.
(Debugging the Analyzer): Consolidate duplicated material.
---
gcc/doc/analyzer.texi | 47 +--
1 file changed, 37 insertions(+)
There was a bad upper limit in diagnostic_manager::prune_path's test for
pruning redundant interprocedural pass information, leading to an ICE.
Additional, the test for pruning
[..., call, function-entry, return, ...]
triples doesn't work for -fanalyzer-verbosity=0, which doesn't generate
functi
On Wed, 2019-11-20 at 16:07 +0100, Martin Liška wrote:
> On 11/20/19 4:02 PM, David Malcolm wrote:
> > On Wed, 2019-11-20 at 15:51 +0100, Martin Liška wrote:
> > > On 11/20/19 3:49 PM, David Malcolm wrote:
> > > > On Wed, 2019-11-06 at 11:30 +0100, Martin Liska wrote:
> > > > > gcc/ChangeLog:
> > >
On Wed, 20 Nov 2019 22:38:30 +0200
Janne Blomqvist wrote:
> On Wed, Nov 20, 2019 at 8:00 PM Bernhard Reutner-Fischer
> wrote:
> >
> > On 19 November 2019 23:54:55 CET, Thomas Koenig
> > wrote:
> > >Am 19.11.19 um 11:39 schrieb Bernhard Reutner-Fischer:
> > >> + char name[GFC_MAX_SYMBO
Am 20.11.19 um 21:45 schrieb Janne Blomqvist:
BTW, since this is done for the purpose of optimization, have you done
testing on some suitable benchmark suite such as polyhedron, whether
it a) generates any different code b) does it make it go faster?
I haven't run any actual benchmarks.
Howeve
On 20/11/2019 20:48, Bernd Schmidt wrote:
> On 11/20/19 8:27 PM, Mikael Pettersson wrote:
>> On Wed, Nov 20, 2019 at 3:16 PM Bernd Schmidt wrote:
>>> Probably best to just run tests on stage1 and hope something shows up.
>>
>> Ok, how do I did that? I've always just done 'make -k check' after
>>
On Wed, Nov 20, 2019 at 11:35 PM Thomas König wrote:
>
> Am 20.11.19 um 21:45 schrieb Janne Blomqvist:
> > BTW, since this is done for the purpose of optimization, have you done
> > testing on some suitable benchmark suite such as polyhedron, whether
> > it a) generates any different code b) does
On 11/20/19 10:35 PM, Thomas König wrote:
I haven't run any actual benchmarks.
I think it would be interesting – I think there can be quite some
advantages in some cases, while in most cases, it is not really noticable.
Of course, Fortran language rules specify that the call to bar cannot
do a
On Wed, 20 Nov 2019, Janne Blomqvist wrote:
> On Wed, Nov 20, 2019 at 7:53 PM Joseph Myers wrote:
> >
> > This patch is OK with http changed to https. (That is, with it changed
> > where the patch is already changing the URL. While changing http to https
> > makes sense more generally in the do
On Thu, Nov 21, 2019 at 12:18 AM Janne Blomqvist
wrote:
>
> On Wed, Nov 20, 2019 at 11:35 PM Thomas König wrote:
> > (Why do we zero %eax
> > before each call? It should not be a variadic call right?)
>
> Not sure. Maybe some belt and suspenders thing? I guess someone better
> versed in ABI minut
On 11/20/19 11:18 PM, Janne Blomqvist wrote:
Of course, Fortran language rules specify that the call to bar
cannot do anything to n
Hmm, does it? What about the following modification to your testcase:
This code violates (quote from F2018):
"15.5.2.13 Restrictions on entities associated wit
Am 20.11.19 um 23:18 schrieb Janne Blomqvist:
On Wed, Nov 20, 2019 at 11:35 PM Thomas König wrote:
Am 20.11.19 um 21:45 schrieb Janne Blomqvist:
BTW, since this is done for the purpose of optimization, have you done
testing on some suitable benchmark suite such as polyhedron, whether
it a) ge
On Tue, Nov 19, 2019 at 08:00:22PM +0100, Tim Rühsen wrote:
> Thanks. Where exactly did it go ? Still can't see it in
> git://sourceware.org/git/binutils-gdb.git. Is there another repository ?
It will appear in the binutils repo when someone syncs libiberty with
the master sources in the gcc repo.
This started crashing with the <=> implementation but has now been
fixed by r278465.
Tested on x86_64-linux, applying to trunk.
2019-11-20 Marek Polacek
PR c++/92443
* g++.dg/cpp0x/constexpr-92443.C: New test.
diff --git gcc/testsuite/g++.dg/cpp0x/constexpr-92443.C
gcc/tests
Various bad uses of the [[fallthrough]] attribute are constraint
violations in C2x, so need pedwarns rather than warnings.
This patch duly turns the relevant warnings into pedwarns. The
relevant code is not specific to C, and does not know which form the
attribute was given in ([[fallthrough]] or
We currently expand various floating point comparisons early, to some
sequences with cror insns and the like. This doesn't optimize well.
Change that to allow any of the 14 floating point comparisons in the
instruction stream, and split them after combine (at split1).
Tested on powerpc64-linux {
On Wed, Nov 20, 2019 at 11:15:56PM +, Joseph Myers wrote:
> Various bad uses of the [[fallthrough]] attribute are constraint
> violations in C2x, so need pedwarns rather than warnings.
>
> This patch duly turns the relevant warnings into pedwarns. The
> relevant code is not specific to C, and
This patch is for PR target/92499, a bug reported by GLIBC maintainers
against nios2 target. The initial failure symptom was a linker error
resulting from use of GP-relative addressing on an object that wasn't
allocated in the small data section. It turns out that the real problem
is that the
On Tue, Nov 05, 2019 at 05:17:10PM +, Wilco Dijkstra wrote:
> Passes bootstrap and regress on AArch64 and x64. OK for commit?
This broke bootstrap on x86_64-linux as well as i686-linux (guess all
targets that go supports).
The following patch fixes it for me, though not sure which *.c file is
Hi Jakub,
> On Tue, Nov 05, 2019 at 05:17:10PM +, Wilco Dijkstra wrote:
>> Passes bootstrap and regress on AArch64 and x64. OK for commit?
>
> This broke bootstrap on x86_64-linux as well as i686-linux (guess all
> targets that go supports).
indeed: just saw it on Solaris with the native ld.
On 11/20/19 7:21 PM, Jakub Jelinek wrote:
On Mon, Nov 18, 2019 at 02:41:48PM -0500, Jason Merrill wrote:
2019-11-11 Jakub Jelinek
PR c++/92458
* constraint.cc: Include tree-hash-traits.h.
(decl_tree_cache_traits): New type.
(decl_tree_cache_map): New typedef.
On 11/20/19 8:49 PM, Marek Polacek wrote:
On Tue, Nov 19, 2019 at 05:34:45PM -0500, Jason Merrill wrote:
On 11/18/19 7:04 PM, Marek Polacek wrote:
The newly added diagnostic causes an ICE because the new grokdeclarator call
returned error_mark_node and DECL_SOURCE_LOCATION crashes on that. So
On Thu, Nov 21, 2019 at 01:41:47AM +0100, Rainer Orth wrote:
> Same on sparc-sun-solaris2.11 and i386-pc-solaris2.11.
>
> There where quite a number of non-Go regressions all over the place.
> Many are like this:
>
> FAIL: gcc.c-torture/execute/complex-6.c -O0 (test for excess errors)
>
> ld:
This patch to the libgo mksysinfo script uses type aliases for time
struct field types. It also fixes a case where grep wasn't
redirecting to /dev/null. This lets some syscall package types be
identical to some golang.org/x/sys/unix types, and fixes
https://golang.org/issue/35713. Bootstrapped a
This libgo patch declares runtime_usestackmaps in stack.c, not
runtime.h. This fixes https://gcc.gnu.org/PR92605. Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
=
On Wed, Nov 20, 2019 at 4:18 PM Jakub Jelinek wrote:
>
> On Tue, Nov 05, 2019 at 05:17:10PM +, Wilco Dijkstra wrote:
> > Passes bootstrap and regress on AArch64 and x64. OK for commit?
>
> This broke bootstrap on x86_64-linux as well as i686-linux (guess all
> targets that go supports).
> The
On 11/20/19 8:37 PM, Marek Polacek wrote:
On Tue, Nov 19, 2019 at 05:33:09PM -0500, Jason Merrill wrote:
On 11/19/19 1:44 AM, Marek Polacek wrote:
It also looks like you're using the LOOKUP flag to mean two different
things:
1) try to treat parenthesized args as an aggregate initializer
(build
Hi,
The issue seems to happen with -O1, because header only contains phi:
[local count: 118111600]:
# iter.12_9 = PHI <0(2), iter.12_10(10)>
and thus we hit segfault in following hunk in find_loop_guard:
else
{
cond = dyn_cast (last_stmt (header));
if (! con
While fixing some bugs in __attribute__((section)), I found it difficult
to write tests. Make testing easier: introduce the
scan-assembler-symbol-section and scan-symbol-section helpers. See
in-line documentation for details.
Testing:
* Run `make check` on x86_64-linux-gnu with --disable-multilib
When building an executable with LTO, GCC effectively ignores
__attribute__((section)) on C++ inline member functions. Moving such
functions into the .text section seems to be intentional, but I think
ignoring the section attribute is unintentional:
https://gcc.gnu.org/ml/gcc-patches/2010-07/msg00
On 11/20/19 7:54 AM, Szabolcs Nagy wrote:
> On 14/11/2019 20:23, Szabolcs Nagy wrote:
>> Sorry v2 had a bug.
>>
>> v2: added documentation and tests.
>> v3: fixed expand_simd_clones so different isa variants are actually
>> generated.
>>
>> GCC currently supports two ways to declare the availa
On Wed, 20 Nov 2019, Jan Hubicka wrote:
> Hi,
> I have noticed that for Firefox around 1GB of peak memory use goes into
> the fact that we never free memory_block_pool::freelist.
>
> This patch adds memory_block_pool::trim which reduces freelist to a given
> size. It is called from ggc_collect w
101 - 164 of 164 matches
Mail list logo
