On Fri, 2019-01-18 at 19:25 +, Andrea Corallo wrote:
> Hi all,
> this patch add gcc_jit_context_add_driver_option to the libgccjit ABI
> and a testcase for it.
>
> Using this interface is now possible to pass options affecting
> assembler and linker.
>
> Does not introduce any new regression
On Fri, Jan 18, 2019 at 11:15:12PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 16, 2019 at 10:08:46PM +0800, Kewen.Lin wrote:
> > * gcc.target/powerpc/altivec_vld_vst_addr.c: New test.
>
> This test fails on powerpc64-linux, both with -m32 and -m64:
I missed that. Thanks Jakub.
Kewen, please
The test started passing with the fix for bug 88693 (r267852).
I've just removed the xfail via r268090 (copied below). As
the original shows, the failure had been misdiagnosed and
mislabeled as due to the still unresolved bug 86688.
Martin
Index: gcc/testsuite/c-c++-common/attr-nonstring-3.c
=
On Fri, Jan 18, 2019 at 4:45 PM Tom de Vries wrote:
>
> On 18-01-19 15:23, Ian Lance Taylor wrote:
> > On Thu, Jan 17, 2019 at 5:59 AM Tom de Vries wrote:
> >>
> >> now that the rest of the patch series has been committed, here's an
> >> updated version of this patch that applies to trunk.
> >
>
On 18-01-19 15:23, Ian Lance Taylor wrote:
> On Thu, Jan 17, 2019 at 5:59 AM Tom de Vries wrote:
>>
>> now that the rest of the patch series has been committed, here's an
>> updated version of this patch that applies to trunk.
>
> I would much rather put dwarf_data into internal.h than to #includ
On 1/18/19 5:24 AM, Rainer Orth wrote:
Hi Christophe,
After your commit (r268037), I'm seeing excess errors on some arm targets:
FAIL: c-c++-common/Wrestrict.c -Wc++-compat (test for excess errors)
Excess errors:
/gcc/testsuite/c-c++-common/Wrestrict.c:195:3: warning: 'memcpy'
accessing 4 byt
On 1/18/19 2:35 AM, Christophe Lyon wrote:
Hi Martin,
On Thu, 17 Jan 2019 at 02:51, Martin Sebor wrote:
On 1/16/19 6:14 PM, Jeff Law wrote:
On 1/15/19 8:21 AM, Martin Sebor wrote:
On 1/15/19 4:07 AM, Richard Biener wrote:
On Tue, Jan 15, 2019 at 1:08 AM Martin Sebor wrote:
The gimple_f
Some of the -Warray-bounds and -Wrestrict tests are prone to failing
on targets like arm-eabi and others that use different parameters to
decide which memcpy calls should be folded to MEM_REF (those that do
are copies of small power-of-two sizes where the power tends to vary
from target to target
Hi Iain,
On Sat, Jan 12, 2019 at 01:28:05PM +, Iain Sandoe wrote:
> The current implementation of “speculation_barrier” and “group_end_nop” insns
> emit hard-wired register names which causes tests using them to fail on
> Darwin, at least, which uses “rNN” instead of “NN”.
>
> The patch mak
Hi!
The utf-array.c testcase FAILs e.g. on i686-linux or powerpc-linux,
the problem is that wchar_t there isn't int, but long int.
grep shows that WCHAR_TYPE is one of
int
short int
long int
unsigned int
short unsigned int
long unsigned int
depending on exact target and options.
The following pat
Hi!
As mentioned in the PR, on the transfer_intrinsic_3.f90 testcase at -O3
on a few targets we have in number_of_iterations_cond:
code LE_EXPR
iv0->base 0
iv0->step 0
iv1->base -1
iv1->step 1
every_iteration false
The loop starts with:
[local count: 8656061039]:
# n_63 = PHI <0(6), _28(23)>
Hi!
As the testcase shows, gfc_get_symbol_decl can be called multiple times and
we can add the same length multiple times to current or parent function.
As addition of a VAR_DECL to those is done by chaining it into the
DECL_CHAIN linked list, adding the same VAR_DECL twice means a loop in the
cha
Hi!
When processing_template_decl, all we care about is diagnostics
and the return type if it is not dependent; other spots that add
sanitization do nothing if processing_template_decl and the following patch
does that for the two recently added ones.
Without it, save_expr is called on potentiall
On Wed, Jan 16, 2019 at 10:08:46PM +0800, Kewen.Lin wrote:
> * gcc.target/powerpc/altivec_vld_vst_addr.c: New test.
This test fails on powerpc64-linux, both with -m32 and -m64:
/.../gcc/testsuite/gcc.target/powerpc/altivec_vld_vst_addr.c:35:1: error: use
of 'long long' in AltiVec types is
Hi Alan,
On Mon, Jan 07, 2019 at 09:29:18AM +1030, Alan Modra wrote:
> The direct cause of this PR is the fact that tls_gdld_nomark didn't
> handle indirect calls. Adding the missing support revealed that most
> indirect calls were being optimised back to direct calls anyway, due
> to tls_gdld_no
Hi!
On Thu, Jan 17, 2019 at 07:30:34AM +0100, Thomas Koenig wrote:
> 2019-01-17 Thomas Koenig
>
> PR fortran/88871
> * resolve.c (resolve_ref): Fix logic for removal of
> reference.
Just a few ChangeLog formatting nits of what I've seen recently from
multiple people, there
The old version of _Sp_counted_ptr_inplace::_M_get_deleter (up to GCC
8.2.0) expects to be passed a real std::typeinfo object, so mixing that
with the new definition of the __shared_ptr constructor (which always
passes the fake tag) leads to accessing the fake object as a real
std::typeinfo. Inste
Philippe Waroquiers noticed a memory leak in gdb, which he tracked
down to a bug in splay-tree. splay_tree_remove does not call the
`delete_key' function when it removes the old node; but it should.
I looked at every splay tree in GCC and there is only one that passes
a non-NULL delete function -
In my patch for CWG issue 2267, I changed reference_binding to clear
CONSTRUCTOR_IS_DIRECT_INIT on the argument init-list. But that breaks if
there's another candidate for which CONSTRUCTOR_IS_DIRECT_INIT is correct.
So instead, let's encode in the conversion that we want to override the
flag.
Te
Hi Steve,
URLs: done
Copyright assignment: in progress. Thanks for the heads up regarding the wait.
--
Nathan
On Fri, Jan 18, 2019 at 1:27 PM Steve Kargl
wrote:
>
> Nathan,
>
> Can you add URLs in the bug reports to your patch so
> that it doesn't get lost? The copyright assignment
> can take
Nathan,
Can you add URLs in the bug reports to your patch so
that it doesn't get lost? The copyright assignment
can take longer than one might think.
--
steve
On Fri, Jan 18, 2019 at 01:17:03PM -0600, Nathan Weeks wrote:
> I made a mistake in the ChangeLogs: libgfortran.h is in gcc/fortran,
>
Hi all,
this patch add gcc_jit_context_add_driver_option to the libgccjit ABI and a
testcase for it.
Using this interface is now possible to pass options affecting assembler and
linker.
Does not introduce any new regression running make check-jit.
Bests
Andrea
gcc/jit/ChangeLog
2019-01-16
On January 18, 2019 5:37:46 PM GMT+01:00, Richard Sandiford
wrote:
>This patch tries harder to detect cases in which the inner dimension
>of an array access is invariant, such as:
>
> x(i, :) = 100
>
>It fixes some of the code size regression in 548.exchange2_r, with
>size improving by 5% com
I made a mistake in the ChangeLogs: libgfortran.h is in gcc/fortran,
and libcaf.h is in libgfortran/caf. Also, the additional enumerations
in those headers don't go all the way in adding support for
STAT_UNLOCKED_FAILED_IMAGE to ISO_FORTRAN_ENV itself (it looks like
that would be at least a minor m
I have committed a patch to update libgo to the Go 1.12beta2 release.
As usual this sort of update is too large to include all changes in
this e-mail. I've included changes to gccgo-specific files below.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
goto
I thought it would be useful to others who are new to the GCC codebase
to have an example of how to hash keys based on string contents rather
than pointer addresses (the fact that some hash maps key based on
semi-reliable pointers (due to ggc_mark_stringpool) into the symtab
gives a false sense of
On Fri, 2019-01-18 at 15:35 +0100, Christophe Lyon wrote:
>
> Hi Steve,
>
> I've noticed that
> FAIL: g++.dg/vect/simd-clone-7.cc -std=c++14 (test for warnings,
> line 7)
> (and for c++17 and c++98)
> when forcing -mabi=ilp32.
>
> I suspect you want to skip the test in this case?
>
> Christop
Hi all!
The patch for gcc/fortran/resolve.c is the modernized version of Paul’s patch
in comment 4.
It causes some regressions due to "Duplicate SAVE » warnings.
They are silenced by the patch for gcc/fortran/symbol.c unless -pedantic is
used as documented
in the change for gcc/fortran/invoke.t
Atomics use DMB instruction to enforce ordering of loads/stores.
Currently gcc generates DMB w/o any arg which is a no-op. Fix that by
generating DMB 3 which enforces R+W ordering. It is stricter than what
acq/rel expect, but there's no other way.
gcc/
2019-01-18 Vineet Gupta
* config/a
On Fri, Jan 18, 2019 at 8:18 AM Tom de Vries wrote:
>
> On 18-01-19 16:40, Ian Lance Taylor wrote:
> > int
> > backtrace_get_view (struct backtrace_state *state ATTRIBUTE_UNUSED,
> > - int descriptor, off_t offset, size_t size,
> > + int descriptor, off_t offset,
The memory store instructions (stfs[u][x], stxssp[x]) can result in
garbage if the value to be stored isn't already a valid single
precision floating point number. So we cannot use this here.
This needs backporting to 8, according to the PR.
Tested etc.; committing to trunk.
Segher
2019-01-1
Am 17.01.19 um 07:30 schrieb Thomas Koenig:
No test case because, well - it did show up on a few systems, so we will
notice if it regresses. OK for trunk?
Both Dominique and Jürgen confirmed that it fixes the PR.
I will commit this tomorrow unless there are any objections - I'd
like to get th
On Fri, 2019-01-18 at 12:32 -0500, David Malcolm wrote:
[CCing Abel]
> PR rtl-optimization/88423 reports an ICE within sched-ebb.c's
> begin_move_insn, failing the assertion at line 175, where there's
> no fall-through edge:
>
> 171 rtx_insn *x = NEXT_INSN (insn);
> 172 if (e)
>
This test got fixed by r267859, so let's add it. Unfortunately, it still ICEs
on the gcc-8 branch.
Tested on x86_64-linux, applying to trunk.
2019-01-18 Marek Polacek
PR c++/86926
* g++.dg/cpp1z/constexpr-lambda23.C: New test.
diff --git gcc/testsuite/g++.dg/cpp1z/constexpr-
PR rtl-optimization/88423 reports an ICE within sched-ebb.c's
begin_move_insn, failing the assertion at line 175, where there's
no fall-through edge:
171 rtx_insn *x = NEXT_INSN (insn);
172 if (e)
173 gcc_checking_assert (NOTE_P (x) || LABEL_P (x));
174 else
175
This patch tries harder to detect cases in which the inner dimension
of an array access is invariant, such as:
x(i, :) = 100
It fixes some of the code size regression in 548.exchange2_r, with
size improving by 5% compared to before the patch. Of the two other
SPEC 2017 tests affected by loo
On 18-01-19 16:40, Ian Lance Taylor wrote:
> int
> backtrace_get_view (struct backtrace_state *state ATTRIBUTE_UNUSED,
> - int descriptor, off_t offset, size_t size,
> + int descriptor, off_t offset, uint64_t size,
> backtrace_error_callback error
On Mon, Jan 7, 2019 at 5:55 AM H.J. Lu wrote:
>
> On Sun, Dec 30, 2018 at 8:40 AM H.J. Lu wrote:
> >
> > On Wed, Nov 28, 2018 at 12:17 PM Jeff Law wrote:
> > >
> > > On 11/28/18 12:48 PM, H.J. Lu wrote:
> > > > On Mon, Nov 5, 2018 at 7:29 AM Jan Hubicka wrote:
> > > >>
> > > >>> On 11/5/18 7:21
Ping.
(note -- when running the GDB testsuite ensuring that
-fstack-protector-all is used for compiling each testcase, this patch
fixes over 1500 FAIL's)
On 10/01/19 13:28, Matthew Malcomson wrote:
> At the moment NOTE_INSN_FUNCTION_BEG is used for three different purposes.
> The first is as a m
I agree that checking the size passed to backtrace_get_view seems like
the most reliable approach to avoid problems with large files on
32-bit systems. How does this patch look?
Ian
2019-01-18 Ian Lance Taylor
PR libbacktrace/88890
* mmapio.c (backtrace_get_view): Change size parameter to
u
On Fri, 18 Jan 2019 at 13:52, Rainer Orth wrote:
>
> Hi Jason,
>
> > On 1/15/19 12:59 PM, Joseph Myers wrote:
> >> On Tue, 15 Jan 2019, Jason Merrill wrote:
> >>
> >>> I actually incorporated the C++ part of these changes into yesterday's
> >>> commit,
> >>> using Martin's first suggestion. Here'
On Thu, 17 Jan 2019 at 20:11, Steve Ellcey wrote:
>
> On Thu, 2019-01-17 at 09:10 +, Richard Sandiford wrote:
> >
> > > +static bool supported_simd_type (tree t)
> >
> > Missing line break after "static bool".
>
> Fixed.
>
> > > +static bool currently_supported_simd_type (tree t, tree b)
> >
>
On Fri, Jan 18, 2019 at 6:25 AM H.J. Lu wrote:
>
> On Thu, Jan 17, 2019 at 4:51 AM Richard Biener
> wrote:
> >
> > On Thu, Jan 17, 2019 at 12:21 PM Martin Liška wrote:
> > >
> > > On 1/16/19 1:06 PM, Richard Biener wrote:
> > > > On Wed, Jan 16, 2019 at 10:20 AM Martin Liška wrote:
> > > >>
> >
On Thu, Jan 17, 2019 at 6:14 AM Tom de Vries wrote:
>
> On 17-01-19 01:35, Ian Lance Taylor wrote:
> > On Wed, Jan 16, 2019 at 4:17 PM Tom de Vries wrote:
> >>
> >> this handles DW_FORM_GNU_ref_alt which references the .debug_info
> >> section in the .gnu_debugaltlink file.
> >>
> >> OK for trunk
On Thu, Jan 17, 2019 at 4:51 AM Richard Biener
wrote:
>
> On Thu, Jan 17, 2019 at 12:21 PM Martin Liška wrote:
> >
> > On 1/16/19 1:06 PM, Richard Biener wrote:
> > > On Wed, Jan 16, 2019 at 10:20 AM Martin Liška wrote:
> > >>
> > >> Hi.
> > >>
> > >> The patch is about resetting TYPE_MODE of ve
On Thu, Jan 17, 2019 at 5:59 AM Tom de Vries wrote:
>
> now that the rest of the patch series has been committed, here's an
> updated version of this patch that applies to trunk.
I would much rather put dwarf_data into internal.h than to #include
"dwarf.c" from a different file. Using #include w
On Thu, Jan 17, 2019 at 04:17:29PM -0500, Jason Merrill wrote:
> On 1/17/19 2:09 PM, Marek Polacek wrote:
> > This patch ought to fix the rest of 78244, a missing narrowing warning in
> > decltype.
> >
> > As I explained in Bugzilla, there can be three scenarios:
> >
> > 1) decltype is in a templ
On 18/01/2019 11:52, Richard Earnshaw (lists) wrote:
> Most armv7-a implementations support a number of basic extensions to the
> architecture which are not particularly important to the compiler, but
> can matter if code contains inline assembly. This patch adds support
> for these extensions, ba
The following fixes wrong-code when SLP vectorizing shifts where we
may end up detecting the shift amount as scalar even though it
really isn't.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied on trunk
sofar.
Richard.
2019-01-18 Richard Biener
PR tree-optimization/8890
Hi Jason,
> On 1/15/19 12:59 PM, Joseph Myers wrote:
>> On Tue, 15 Jan 2019, Jason Merrill wrote:
>>
>>> I actually incorporated the C++ part of these changes into yesterday's
>>> commit,
>>> using Martin's first suggestion. Here's the adjusted C patch, which I'd
>>> like
>>> a C maintainer to a
Hi Christophe,
> After your commit (r268037), I'm seeing excess errors on some arm targets:
> FAIL: c-c++-common/Wrestrict.c -Wc++-compat (test for excess errors)
> Excess errors:
> /gcc/testsuite/c-c++-common/Wrestrict.c:195:3: warning: 'memcpy'
> accessing 4 bytes at offsets [2, 3] and 0 overl
And this time with the patch...
On 18/01/2019 11:52, Richard Earnshaw (lists) wrote:
> Most armv7-a implementations support a number of basic extensions to the
> architecture which are not particularly important to the compiler, but
> can matter if code contains inline assembly. This patch adds s
Most armv7-a implementations support a number of basic extensions to the
architecture which are not particularly important to the compiler, but
can matter if code contains inline assembly. This patch adds support
for these extensions, based on the capabilities that GAS already
provides for the app
Hi,
This patch adds the documentation needed for the newly-added AMD GCN
back end.
OK to commit?
Andrew
Document AMD GCN.
2019-01-18 Andrew Stubbs
gcc/
* doc/extend.tex (AMD GCN Function Attributes): New section.
* doc/install.texi (amdgcn-unknown-amdhsa): New instructions.
* doc/inv
Hi,
I committed the attached patch to aarch64/sve-acle-branch that
implements svlsl_wide.
Thanks,
Prathamesh
diff --git a/gcc/config/aarch64/aarch64-sve-builtins.c b/gcc/config/aarch64/aarch64-sve-builtins.c
index f080a67ef00..0e3db669422 100644
--- a/gcc/config/aarch64/aarch64-sve-builtins.c
+++
Hi,
a tweak to typespec_loc, where the existing conditional turns out to be
just a special case of the full min_location that we want in order to do
the right thing for testcases like diagnostic/trailing1.C. Tested
x86_64-linux.
Thanks, Paolo.
//
/cp
2018-01-18 Paolo C
On Thu, Jan 17, 2019 at 04:00:47PM -0800, H.J. Lu wrote:
> gcc/c-family/
>
> PR c/51628
> PR c/88664
> * c-common.h (warn_for_address_or_pointer_of_packed_member):
> Remove the boolean argument.
> * c-warn.c (check_address_of_packed_member): Renamed to ...
> (ch
> Hi.
>
> Last GCOV patch renames __gcov_indirect_call_profiler_v2 to
> __gcov_indirect_call_profiler_v3
> as we changed ABI and one should see a linker error instead of strange
> run-time error.
> That can happen when somebody mixes objects built with a different version of
> compiler.
>
> Pa
Hi.
Last GCOV patch renames __gcov_indirect_call_profiler_v2 to
__gcov_indirect_call_profiler_v3
as we changed ABI and one should see a linker error instead of strange run-time
error.
That can happen when somebody mixes objects built with a different version of
compiler.
Patch can bootstrap on
Hi.
The patch is about more explicit error message in libgcov.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
It's approved by Honza.
Thanks,
Martin
libgcc/ChangeLog:
2019-01-17 Martin Liska
* libgcov-driver.c (GCOV_PROF_PREFIX): Define.
(gcov_versio
Hi.
The patch is about better explanation of version mismatch in libgcov
driver. Now we'll print:
profiling:/tmp/main.gcda:Version mismatch - expected 9.0 (experimental) (A90e)
got 8.2 (release) (A82*)
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
It's approved by Honza
Christophe Lyon writes:
> On Fri, 11 Jan 2019 at 23:59, Jeff Law wrote:
>>
>> On 1/8/19 5:03 AM, Richard Sandiford wrote:
>> > Bernd Edlinger writes:
>> >> On 1/7/19 10:23 AM, Jakub Jelinek wrote:
>> >>> On Sun, Dec 16, 2018 at 06:13:57PM +0200, Dimitar Dimitrov wrote:
>> - /* Clobbering t
Hi Martin,
On Thu, 17 Jan 2019 at 02:51, Martin Sebor wrote:
>
> On 1/16/19 6:14 PM, Jeff Law wrote:
> > On 1/15/19 8:21 AM, Martin Sebor wrote:
> >> On 1/15/19 4:07 AM, Richard Biener wrote:
> >>> On Tue, Jan 15, 2019 at 1:08 AM Martin Sebor wrote:
>
> The gimple_fold_builtin_memory_
On Fri, 18 Jan 2019, Jakub Jelinek wrote:
> On Thu, Jan 17, 2019 at 03:43:05PM +0100, Jakub Jelinek wrote:
> > > So we do not care to optimize this to only clobber the vars that
> > > are appear live over the EH edge?
> >
> > Wouldn't that be quite expensive (especially at that spot in the inline
Hi Jakub,
On 17/01/19 13:47, Jakub Jelinek wrote:
Hi!
arm_neon.h on both targets contained a couple of spots with invalid
#pragma GCC target syntax. This doesn't result in errors, just warnings and
those warnings are surpressed in system headers, so are visible with
-Wsystem-headers only. Any
On Thu, Jan 17, 2019 at 03:43:05PM +0100, Jakub Jelinek wrote:
> > So we do not care to optimize this to only clobber the vars that
> > are appear live over the EH edge?
>
> Wouldn't that be quite expensive (especially at that spot in the inliner)?
> I could surely defer that (at the spot in copy_
On Fri, Jan 18, 2019 at 09:18:33AM +0100, Martin Liška wrote:
> What about something as simple as this:
>
> diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
> index 3314e176881..2f2b965f97d 100644
> --- a/gcc/fortran/decl.c
> +++ b/gcc/fortran/decl.c
> @@ -11361,6 +11361,11 @@ gfc_match_gcc_bu
On 1/16/19 9:35 PM, Joseph Myers wrote:
> On Wed, 16 Jan 2019, Jakub Jelinek wrote:
>
>> Perhaps easier would be to add optional if clause to the !GCC$ builtin
>> with constant expression argument which if present and evaluates to .false.
>> would tell us to ignore the attribute. Or, add !GCC$ if
68 matches
Mail list logo
