On Tue, May 21, 2019 at 5:01 PM H.J. Lu wrote:
>
> get_frame_size () returns used stack slots during compilation, which
> may be optimized out later. This patch does the followings:
>
> 1. Add no_stack_frame to machine_function to indicate that the function
> doesn't need a stack frame.
Can you
Hi.
The patch is about using of uintptr_t instead unsigned long that's
being used for printing value of a pointer.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-05-22 Martin Liska
PR bootstrap/90543
Jakub asked me to backport the fix for PR c++/85400 initially intended for
SPARC/Solaris but which also helps on x86-64/Linux apparently.
Tested on the latter platform, applied on the 8 branch.
2019-05-22 Eric Botcazou
c-family/
Backport from mainline
2018-05-10 Eric Botcaz
The hash-table checker discovered a bug in LIMs new fancy hash/compare
logic, fixed as follows.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk,
queued for branch.
Richard.
2019-05-22 Richard Biener
PR tree-optimization/90450
* tree-ssa-loop-im.c (stru
On Wed, May 22, 2019 at 09:39:52AM +0200, Martin Liška wrote:
> The patch is about using of uintptr_t instead unsigned long that's
> being used for printing value of a pointer.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
No. You haven't
An old one…
This test can never pass on 32b Darwin (or AIX) because the ABI demands a
different result to that being tested. So XFAIL it.
Tested on powerpc-darwin9, powerpc-ibm-aix
Applied to mainline
Iain
gcc/testsuite/
2019-05-22 Iain Sandoe
PR testsuite/27221
* g++.dg/ext/
On 13/05/2019 10:45, Mark Eggleston wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89100 see comment 4
Please can someone commit the attached patch as I do not have commit
rights.
Change logs:
For gcc/fortran
Jeff Law
Mark Eggleston
PR fortran/89100
* gfortran.texi
On 5/22/19 9:50 AM, Jakub Jelinek wrote:
> On Wed, May 22, 2019 at 09:39:52AM +0200, Martin Liška wrote:
>> The patch is about using of uintptr_t instead unsigned long that's
>> being used for printing value of a pointer.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
[Gah, wrote this a few days ago but just realised I never sent it.
Was wondering why hadn't been applied. :-)]
Matthew Malcomson writes:
> @@ -16008,6 +16008,17 @@ generation. This option is enabled by default for
> @option{-march=armv8.5-a}.
> +@item bitperm
> +Enable SVE2 bitperm Extension.
On Fri, 17 May 2019 at 10:12, Vladislav Ivanishin wrote:
>
> Hi!
>
> Without the patch, two of the newly added tests fail with bogus warnings:
>
> - gcc.dg/uninit-28-gimple.c (Definition guarded with NE_EXPR, use with
> BIT_AND_EXPR. This is an FP my previous patch [1] knowingly
> overlooks.)
Hi.
The patch fixes couple of tests that I've just tested on ppc64le-linux-gnu.
I'm going to install the patch.
Thanks,
Martin
gcc/testsuite/ChangeLog:
2019-05-22 Martin Liska
PR testsuite/90564
* gcc.target/powerpc/pr80315-1.c: Add one extra \ to escape
brackets.
On Tue, 21 May 2019 at 13:03, Paolo Carlini wrote:
>
> Hi,
>
> also in my back queue a few more location fixes (of course ;) Tested
> x86_64-linux.
>
> Thanks, Paolo.
>
>
>
Hi,
I think you incorrectly committed an additional chunk:
diff --git a/gcc/testsuite/g++.dg/cpp0x/decltyp
On 21/05/2019 16:28, Christophe Lyon wrote:
> --- a/gcc/config/arm/linux-eabi.h
> +++ b/gcc/config/arm/linux-eabi.h
> @@ -89,7 +89,7 @@
> #define MUSL_DYNAMIC_LINKER_E "%{mbig-endian:eb}"
> #endif
> #define MUSL_DYNAMIC_LINKER \
> - "/lib/ld-musl-arm" MUSL_DYNAMIC_LINKER_E "%{mfloat-abi=hard:hf
On Wed, 22 May 2019 at 10:39, Szabolcs Nagy wrote:
>
> On 21/05/2019 16:28, Christophe Lyon wrote:
> > --- a/gcc/config/arm/linux-eabi.h
> > +++ b/gcc/config/arm/linux-eabi.h
> > @@ -89,7 +89,7 @@
> > #define MUSL_DYNAMIC_LINKER_E "%{mbig-endian:eb}"
> > #endif
> > #define MUSL_DYNAMIC_LINKER \
On 22/05/19 10:28, Christophe Lyon wrote:
On Tue, 21 May 2019 at 13:03, Paolo Carlini wrote:
Hi,
also in my back queue a few more location fixes (of course ;) Tested
x86_64-linux.
Thanks, Paolo.
Hi,
I think you incorrectly committed an additional chunk:
I fixed that ear
Hi Christophe,
> On Fri, 17 May 2019 at 10:12, Vladislav Ivanishin wrote:
>>
>> Hi!
>>
>> Without the patch, two of the newly added tests fail with bogus warnings:
>>
>> - gcc.dg/uninit-28-gimple.c (Definition guarded with NE_EXPR, use with
>> BIT_AND_EXPR. This is an FP my previous patch [1]
Hi Uros,
> Based on the recent work that enabled vectorization of
> __builtin_signbit on aarch64.
>
> 2019-05-21 Uroš Bizjak
>
> * config/i386/sse.md (VF1_AVX2): New mode iterator.
> (signbit2): New expander
>
> testsuite/ChangeLog:
>
> 2019-05-21 Uroš Bizjak
>
> * gcc.target/i38
On Wed, May 22, 2019 at 12:34 AM Indu Bhagat wrote:
>
> Thanks for your feedback. Comments inline.
>
>
> On 05/21/2019 03:28 AM, Richard Biener wrote:
>
> GCC RFC patch set :
> Patch 1 is a simple addition of a new function lang_GNU_GIMPLE to check for
> GIMPLE frontend.
>
> I don't think you shou
Rainer Orth writes:
>> On Fri, 17 May 2019 at 10:12, Vladislav Ivanishin wrote:
>>>
>>> Hi!
>>>
>>> Without the patch, two of the newly added tests fail with bogus warnings:
>>>
>>> - gcc.dg/uninit-28-gimple.c (Definition guarded with NE_EXPR, use with
>>> BIT_AND_EXPR. This is an FP my previ
On Wed, May 22, 2019 at 9:43 AM Eric Botcazou wrote:
>
> Jakub asked me to backport the fix for PR c++/85400 initially intended for
> SPARC/Solaris but which also helps on x86-64/Linux apparently.
>
> Tested on the latter platform, applied on the 8 branch.
Probably also required for GCC 7 then?
Hi,
On Wed, May 22, 2019 at 10:24:32AM +0200, Martin Liška wrote:
> The patch fixes couple of tests that I've just tested on ppc64le-linux-gnu.
>
> I'm going to install the patch.
Could you please not use double quotes, instead? E.g.
> - res = __builtin_crypto_vshasigmaw (test, 1, 0xff); /* {
On Wed, May 22, 2019 at 11:04 AM Rainer Orth
wrote:
>
> Hi Uros,
>
> > Based on the recent work that enabled vectorization of
> > __builtin_signbit on aarch64.
> >
> > 2019-05-21 Uroš Bizjak
> >
> > * config/i386/sse.md (VF1_AVX2): New mode iterator.
> > (signbit2): New expander
> >
> >
On 5/21/19 1:51 PM, Richard Biener wrote:
> On Tue, May 21, 2019 at 1:02 PM Martin Liška wrote:
>>
>> On 5/21/19 11:38 AM, Richard Biener wrote:
>>> On Tue, May 21, 2019 at 12:07 AM Jeff Law wrote:
On 5/13/19 1:41 AM, Martin Liška wrote:
> On 11/8/18 9:56 AM, Martin Liška wrote:
>>>
On 5/22/19 11:13 AM, Segher Boessenkool wrote:
> Hi,
>
> On Wed, May 22, 2019 at 10:24:32AM +0200, Martin Liška wrote:
>> The patch fixes couple of tests that I've just tested on ppc64le-linux-gnu.
>>
>> I'm going to install the patch.
>
> Could you please not use double quotes, instead? E.g.
>
This enables -ftree-loop-distribute-patterns at -O[2s] and also
arranges cold loops to be still processed but for pattern
recognition to save code-size.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Martin has done extensive compile-time testing on SPEC
identifying only a single re
On Wed, May 22, 2019 at 10:07:33AM +0200, Martin Liška wrote:
> On 5/22/19 9:50 AM, Jakub Jelinek wrote:
> > On Wed, May 22, 2019 at 09:39:52AM +0200, Martin Liška wrote:
> >> The patch is about using of uintptr_t instead unsigned long that's
> >> being used for printing value of a pointer.
> >>
>
This patch fixes a bug observed on amdgcn in which the Fortran frontend
creates function calls using the 32-bit parameters where they ought to
be 64-bit, resulting in UB.
The issue is caused by the use of "integer_zero_node" where the
definition of the function calls for "size_zero_node". I pr
The coarray_lock_7.f90 test has fixed-width patterns for matching the
variable numbers in the dumps. This has caused recent test failures for
at least amdgcn because changes elsewhere have happened to increase
those numbers too far.
This patch adds a "\\d+" match to allow variable-width matche
On 5/22/19 11:40 AM, Jakub Jelinek wrote:
> On Wed, May 22, 2019 at 10:07:33AM +0200, Martin Liška wrote:
>> On 5/22/19 9:50 AM, Jakub Jelinek wrote:
>>> On Wed, May 22, 2019 at 09:39:52AM +0200, Martin Liška wrote:
The patch is about using of uintptr_t instead unsigned long that's
being
On Wed, May 22, 2019 at 01:19:37PM +0200, Martin Liška wrote:
> > and another similar block with ptr1/ptr2 later. So, I wonder if you just
> > shouldn't follow what is done for var_opt_string vs. var_opt_other even in
> > the var_target_other case, do:
> > + else if (otype ~ "^co
On Wed, May 22, 2019 at 1:54 PM Andrew Stubbs wrote:
>
> This patch fixes a bug observed on amdgcn in which the Fortran frontend
> creates function calls using the 32-bit parameters where they ought to
> be 64-bit, resulting in UB.
>
> The issue is caused by the use of "integer_zero_node" where th
On Wed, May 22, 2019 at 1:59 PM Andrew Stubbs wrote:
>
> The coarray_lock_7.f90 test has fixed-width patterns for matching the
> variable numbers in the dumps. This has caused recent test failures for
> at least amdgcn because changes elsewhere have happened to increase
> those numbers too far.
>
On 5/22/19 1:27 PM, Jakub Jelinek wrote:
> On Wed, May 22, 2019 at 01:19:37PM +0200, Martin Liška wrote:
>>> and another similar block with ptr1/ptr2 later. So, I wonder if you just
>>> shouldn't follow what is done for var_opt_string vs. var_opt_other even in
>>> the var_target_other case, do:
>>
On Wed, May 22, 2019 at 01:27:04PM +0200, Jakub Jelinek wrote:
> No, IMHO you do want to use %s, patch below. I've found a couple of other
> bugs in optc-save-gen.awk. Attached is a diff between aarch64 target
> options-save.c before and after this patch.
>
> The other bugs were that cl_optimiza
Hi,
The attached patch fixes a typo in cse_dump_path, which I came across
while debugging another issue. OK to commit ?
Thanks,
Prathamesh
2019-05-22 Prathamesh Kulkarni
* cse.c (cse_dump_path): s/dump_file/f.
diff --git a/gcc/cse.c b/gcc/cse.c
index 6c9cda16a98..35840a6d5ca 100644
--
On Tue, 21 May 2019, Richard Biener wrote:
> And that should be done at RTL creation time instead of
> repeatedly over and over. Like with the following.
>
> Bootstrap / regtest on x86_64-unknown-linux-gnu in progress.
But we can't get away w/o unsharing the expr we change so committed
as follo
On 5/22/19 5:46 AM, Prathamesh Kulkarni wrote:
> Hi,
> The attached patch fixes a typo in cse_dump_path, which I came across
> while debugging another issue. OK to commit ?
OK
jeff
On Wed, May 22, 2019 at 10:58 AM Mark Eggleston
wrote:
>
> On 13/05/2019 10:45, Mark Eggleston wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89100 see comment 4
> >
> > Please can someone commit the attached patch as I do not have commit
> > rights.
> >
> > Change logs:
> >
> > For gcc/f
On 22/05/2019 12:35, Janne Blomqvist wrote:
Thanks for the catch. Though for size_t you should use build_zero_cst
(size_type_node). size_zero_node is a zero constant of type sizetype,
which is not the same as size_type_node (size_t in C). Ok with that
change.
So, integer_zero_node is compatible
On Wed, May 22, 2019 at 3:20 PM Andrew Stubbs wrote:
>
> On 22/05/2019 12:35, Janne Blomqvist wrote:
> > Thanks for the catch. Though for size_t you should use build_zero_cst
> > (size_type_node). size_zero_node is a zero constant of type sizetype,
> > which is not the same as size_type_node (size
On Tue, 21 May 2019, Jiufu Guo wrote:
> Hi,
>
> This patch implements a new opportunity of jump threading for PR77820.
> In this optimization, conditional jumps are merged with unconditional jump.
> And then moving CMP result to GPR is eliminated.
>
> It looks like below:
>
>
> p0 = a CMP
Hi!
On Tue, 21 May 2019 13:11:54 +0200 (CEST), Richard Biener
wrote:
> On Mon, 20 May 2019, Richard Biener wrote:
> > On Sun, 19 May 2019, Richard Sandiford wrote:
> > > Richard Biener writes:
> > > > This adds, incrementally ontop of moving VEC_PERM_EXPR folding
> > > > to match.pd (but not in
On 22/05/2019 13:28, Janne Blomqvist wrote:
Just to confirm, is the attached what you mean?
Yes, looks good.
Thanks, now committed.
Andrew
On 22/05/2019 12:38, Janne Blomqvist wrote:
Ok.
Thanks, committed.
Andrew
Hi Uros,
>> the new testcase FAILs on i386-pc-solaris2.11 (both with the default
>> -m32 and -m64), but also on i586-unknown-freebsd11.2, i686-pc-linux-gnu:
>>
>> +FAIL: gcc.target/i386/vect-signbitf.c scan-assembler-not -2147483648
>
> It works for me on x86_64-linux-gnu with -32, so I'm at loss
On Wed, 22 May 2019, Thomas Schwinge wrote:
> Hi!
>
> On Tue, 21 May 2019 13:11:54 +0200 (CEST), Richard Biener
> wrote:
> > On Mon, 20 May 2019, Richard Biener wrote:
> > > On Sun, 19 May 2019, Richard Sandiford wrote:
> > > > Richard Biener writes:
> > > > > This adds, incrementally ontop of
Hi,
On Tue, 21 May 2019, Richard Biener wrote:
> > Index: gcc/tree-ssa-dce.c
> > ===
> > --- gcc/tree-ssa-dce.c (revision 271415)
> > +++ gcc/tree-ssa-dce.c (working copy)
> > @@ -417,7 +417,7 @@ find_obviously_necessary_stmts (boo
Ping, on behalf of Martin, CC:ing diagnostics maintainers.
On Fri, 3 May 2019, Martin Li?ka wrote:
> Hi.
>
> The patch prints all values requested in multiple --help options.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
Christophe, Rainer,
Rainer Orth writes:
> Hi Christophe,
>
>> On Fri, 17 May 2019 at 10:12, Vladislav Ivanishin wrote:
>>>
>> As you have probably noticed already, the new test uninit-28.c fails:
>> /gcc/testsuite/gcc.dg/uninit-28-gimple.c:9:16: warning: 'undef' may be
>> used uninitialized in
On Wed, May 22, 2019 at 12:31 AM Uros Bizjak wrote:
>
> On Tue, May 21, 2019 at 5:01 PM H.J. Lu wrote:
> >
> > get_frame_size () returns used stack slots during compilation, which
> > may be optimized out later. This patch does the followings:
> >
> > 1. Add no_stack_frame to machine_function to
On 5/22/19 8:44 AM, Vladislav Ivanishin wrote:
> Christophe, Rainer,
>
> Rainer Orth writes:
>
>> Hi Christophe,
>>
>>> On Fri, 17 May 2019 at 10:12, Vladislav Ivanishin wrote:
>>> As you have probably noticed already, the new test uninit-28.c fails:
>>> /gcc/testsuite/gcc.dg/uninit-28-gim
> On 22 May 2019, at 16:19, Jeff Law wrote:
>
> On 5/22/19 8:44 AM, Vladislav Ivanishin wrote:
>> Christophe, Rainer,
>>
>> Rainer Orth writes:
>>
>>> Hi Christophe,
>>>
On Fri, 17 May 2019 at 10:12, Vladislav Ivanishin wrote:
>
As you have probably noticed already, the new
On Wed, May 22, 2019 at 6:36 AM Rainer Orth
wrote:
>
> Hi Uros,
>
> >> the new testcase FAILs on i386-pc-solaris2.11 (both with the default
> >> -m32 and -m64), but also on i586-unknown-freebsd11.2, i686-pc-linux-gnu:
> >>
> >> +FAIL: gcc.target/i386/vect-signbitf.c scan-assembler-not -2147483648
Incorporating the feedback I got on the -Wformat-diag checker
provided an opportunity to tighten up existing and implement
a small number of few additional rules based on GCC Coding
Conventions (https://gcc.gnu.org/codingconventions.html).
The checker now also warns for incorrect uses of the follo
Attached is a revised implementation of the -Wformat-diag checker
incorporating the feedback I got on the first revision.
Martin
gcc/c-family/ChangeLog:
* c-format.c (function_format_info::format_type): Adjust type.
(function_format_info::is_raw): New member.
(decode_format_type): Adjust sign
Hi,
This patch introduces the infrastructure to support -mcpu=future, used for
features
in a future architecture, as yet unnamed.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions.
Is
this okay for trunk?
Thanks,
Bill
Add infrastructure to support -mcpu=future to
On Wed, May 22, 2019 at 5:10 PM H.J. Lu wrote:
>
> On Wed, May 22, 2019 at 12:31 AM Uros Bizjak wrote:
> >
> > On Tue, May 21, 2019 at 5:01 PM H.J. Lu wrote:
> > >
> > > get_frame_size () returns used stack slots during compilation, which
> > > may be optimized out later. This patch does the fo
As Dominque noted in PR 64895, somewhere between revisions
r244915 and r244957 we see the fuse-caller-save* tests started to
XPASS on Darwin, which is a PIC target by default.
The XFAILed parts of the tests never seem to be exercised on
Linux, and therefore the change would be unnoticed there.
This pattern needs TARGET_MMX as it uses mmx registers.
2019-05-22 Uroš Bizjak
* config/i386/sse.md (sse_cvtpi2ps): Use TARGET_MMX in insn condition.
(+ some trivial code reorg parts).
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
diff
On Wed, May 22, 2019 at 5:52 PM H.J. Lu wrote:
>
> On Wed, May 22, 2019 at 6:36 AM Rainer Orth
> wrote:
> >
> > Hi Uros,
> >
> > >> the new testcase FAILs on i386-pc-solaris2.11 (both with the default
> > >> -m32 and -m64), but also on i586-unknown-freebsd11.2, i686-pc-linux-gnu:
> > >>
> > >> +
On Tue, May 7, 2019 at 4:43 PM Jason Merrill wrote:
>
> * typeck.c (build_static_cast_1): Use cp_build_addr_expr.
>
> For GCC 9 I fixed this bug with a patch to gimplify_cond_expr, but this
> function was also doing the wrong thing.
>
> Using build_address does not push the ADDR_EXPR down
Here initializing the argument from a TARGET_EXPR isn't an empty class
copy even though the type is !TREE_ADDRESSABLE, so we should check
simple_empty_class_p.
Tested x86_64-pc-linux-gnu, applying to trunk.
* call.c (build_call_a): Use simple_empty_class_p.
---
gcc/cp/cp-tree.h
On Wed, May 22, 2019 at 12:56:15PM +0930, Alan Modra wrote:
> On Tue, May 21, 2019 at 09:48:10AM -0500, Segher Boessenkool wrote:
> > (Is Power5 2.4? Not 2.2?)
>
> Yes, I think power5 was 2.02, but I haven't looked at cpu and arch
> books to verify exactly what power5 and power5+ was.
My notes s
Hi,
This patch adds basic infrastructure support to enable PC-relative addressing.
It adds the -mpcrel / -mno-pcrel option (defaulted on for -mcpu=future,
otherwise
off), and provides a couple of interfaces to determine whether PC-relative
addressing should be used when generating a single functi
Remove the hardcoded whitelist of allocators expected to return memory
aligned to alignof(max_align_t), because that doesn't work when the
platform's malloc() and GCC's max_align_t do not agree what the largest
fundamental alignment is. It's also sub-optimal for user-defined
allocators that return
0001-Patch-Rename-PSTL-macro-s-consistent-with-libstdc-st.patch.bz2
Description: Compressed patch
* include/bits/c++config: Rename all macros of the form __PSTL* to
_PSTL*.
* include/std/algorithm: Likewise.
* include/std/execution: Likewise.
* include/std/numeri
-Wreturn-local-addr detects a subset of instances of returning
the address of a local object from a function but the warning
doesn't try to handle alloca or VLAs, or some non-trivial cases
of ordinary automatic variables[1].
The attached patch extends the implementation of the warning to
detect t
I noticed this test fails since r271492. Probably obvious, but...
Tested on x86_64-linux, ok for trunk?
2019-05-22 Marek Polacek
* g++.dg/cpp1y/udlit-char-template-neg.C: Expect the error on a
different line. Check the column number too.
diff --git gcc/testsuite/g++.dg/cpp1
On Wed, May 22, 2019 at 12:17:04AM -0400, Jason Merrill wrote:
> On 5/20/19 6:08 PM, Marek Polacek wrote:
> > We ICE here because we are accessing call_args even though it's empty:
> >
> > (gdb) p (*call_args).is_empty()
> > $5 = true
> >
> > It's empty because the pack processed by tsubst_pack_e
On 22/05/19 14:02 -0700, Thomas Rodgers wrote:
* include/bits/c++config: Rename all macros of the form __PSTL* to
_PSTL*.
Please keep the ChangeLog lines to 80 columns, so break before
"_PSTL*" here.
* include/std/algorithm: Likewise.
* include/std/execution: Likewise
On Tue, May 7, 2019 at 4:43 PM Jason Merrill wrote:
>
> * typeck.c (build_static_cast_1): Use cp_build_addr_expr.
>
> For GCC 9 I fixed this bug with a patch to gimplify_cond_expr, but this
> function was also doing the wrong thing.
>
> Using build_address does not push the ADDR_EXPR down
Hi,
On 22/05/19 23:45, Marek Polacek wrote:
I noticed this test fails since r271492. Probably obvious, but...
Tested on x86_64-linux, ok for trunk?
I was wondering why I didn't notice it... It's because it only fails
with check-c++-all not with check-c++. Anyway, it seems obvious to me
too
On Thu, May 23, 2019 at 12:00:22AM +0200, Paolo Carlini wrote:
> Hi,
>
> On 22/05/19 23:45, Marek Polacek wrote:
> > I noticed this test fails since r271492. Probably obvious, but...
> >
> > Tested on x86_64-linux, ok for trunk?
>
> I was wondering why I didn't notice it... It's because it only
Hi,
On 23/05/19 00:04, Marek Polacek wrote:
On Thu, May 23, 2019 at 12:00:22AM +0200, Paolo Carlini wrote:
Hi,
On 22/05/19 23:45, Marek Polacek wrote:
I noticed this test fails since r271492. Probably obvious, but...
Tested on x86_64-linux, ok for trunk?
I was wondering why I didn't notice
PR libstdc++/90557
* src/c++17/fs_path.cc (path::_List::operator=(const _List&)): Fix
reversed arguments to uninitialized_copy_n.
* testsuite/27_io/filesystem/path/assign/copy.cc: Check that source
is unchanged by copy assignment.
* testsuite/util/te
Hi,
My last patch was a result of refactoring, and I missed one important line.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu; okay for turnk
with the other patch?
Thanks,
Bill
2019-05-22 Bill Schmidt
Michael Meissner
* config/rs6000/rs6000.c (rs6000_opt_mas
On 22/05/19 21:40 +0100, Jonathan Wakely wrote:
Remove the hardcoded whitelist of allocators expected to return memory
aligned to alignof(max_align_t), because that doesn't work when the
platform's malloc() and GCC's max_align_t do not agree what the largest
fundamental alignment is. It's also su
Trampolines work just fine on GCN3 devices, but GCN5 devices have
execute permission hardware, and the driver sets permission off for the
private segment allocation in which the stacks are located.
It may be possible to implement indirect calls to nested functions
another way, but for now this
On 22/05/19 23:17 +0100, Jonathan Wakely wrote:
On 22/05/19 21:40 +0100, Jonathan Wakely wrote:
Remove the hardcoded whitelist of allocators expected to return memory
aligned to alignof(max_align_t), because that doesn't work when the
platform's malloc() and GCC's max_align_t do not agree what t
This patch adds support for constructors that run before "main", and
destructors that run afterwards. This is prerequisite for supporting
more of libgfortran (and other libraries, including libstdc++).
The init_array and fini_array sections are created, and gcn-run is
modified to launch the in
> Probably also required for GCC 7 then?
The problem is (probably) present there too, but that's not my call.
--
Eric Botcazou
On Wed, May 22, 2019 at 01:41:56PM +0200, Jakub Jelinek wrote:
> Ok for trunk if it passes full bootstrap/regtest on x86_64-linux (passed
> already normal build on aarch64-linux cross)?
Successfully bootstrapped/regtested on x86_64-linux and i686-linux.
> 2019-05-22 Jakub Jelinek
>
> PR
Hi!
For stack_protect_test_[sd]i we don't use comparison, so that we clear the
content of the register and don't keep the stack canary in any register for
security reasons, but as mentioned in the PR, using sub instead of xor
achieves the same effect in the likely case (no failure), in the failure
On Thu, May 23, 2019 at 12:11:24AM +0200, Paolo Carlini wrote:
> Hi,
>
> On 23/05/19 00:04, Marek Polacek wrote:
> > On Thu, May 23, 2019 at 12:00:22AM +0200, Paolo Carlini wrote:
> > > Hi,
> > >
> > > On 22/05/19 23:45, Marek Polacek wrote:
> > > > I noticed this test fails since r271492. Proba
Hi Bill,
On Wed, May 22, 2019 at 12:51:50PM -0500, Bill Schmidt wrote:
> +/* Define if your assembler supports FUTURE instructions. */
> +#ifndef USED_FOR_TARGET
> +#undef HAVE_AS_FUTURE
> +#endif
Let's not use that? I removed HAVE_AS_* (for ISA version support) in
r264675:
"""
rs6000: Delete
Although this is a Darwin-specific change, I need to touch
target-supports.exp and several tests in i386.exp.
tested on x86_64-darwin and x86_64-linux-gnu
doc change tested with “make pdf”,
OK for trunk?
backports? (where the tests fail).
gcc/
* config/i386/darwin.h: Reject -mfentry*.
Hi,
Functions using PC-relative addressing do not use a TOC, so there is no need for
a global entry point for TOC setup. Ensure we never generate a global entry
point, and use a .localentry directive that sets the upper st_other bits to 1.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu
On 5/22/19 6:05 PM, Segher Boessenkool wrote:
> Hi Bill,
>
> On Wed, May 22, 2019 at 12:51:50PM -0500, Bill Schmidt wrote:
>> +/* Define if your assembler supports FUTURE instructions. */
>> +#ifndef USED_FOR_TARGET
>> +#undef HAVE_AS_FUTURE
>> +#endif
> Let's not use that? I removed HAVE_AS_* (f
PR c++/90462 reports an ICE with -fdiagnostics-format=json when
attempting to serialize a malformed location to JSON.
The compound location_t in question has meaningful "caret" and "start"
locations, but has UNKNOWN_LOCATION for its "finish" location,
leading to a NULL pointer dereference when att
Jim, thank you for the fix! The patch looks good to me. Maybe we should
also apply this to __atomic_add_fetch_4 and __atomic_add_fetch_8?
Thanks,
Cherry
On Tue, May 21, 2019 at 11:25 PM Jim Wilson wrote:
> On Sun, May 19, 2019 at 5:22 AM Andreas Schwab
> wrote:
> > ../../../libgo/go/runtime/
On Wed, May 22, 2019 at 9:36 PM Cherry Zhang wrote:
>
> Jim, thank you for the fix! The patch looks good to me. Maybe we should also
> apply this to __atomic_add_fetch_4 and __atomic_add_fetch_8?
>
> Thanks,
> Cherry
>
>
>
> On Tue, May 21, 2019 at 11:25 PM Jim Wilson wrote:
>>
>> On Sun, May 19
On Wed, May 22, 2019 at 12:51:50PM -0500, Bill Schmidt wrote:
> * config/rs6000/rs6000.c (rs6000_option_override_internal): Treat
> PROCESSOR_FUTURE similarly to PROCESSOR_POWER9 for now.
> (rs6000_machine_from_flags): Handle future cpu.
> (rs6000_reassociation_width): Treat
There was a regression for gfortran.dg/fmt_en.f90 for cris-elf
that on inspection was due to it having acquired a truncation
call through the runtime. I updated that and the new tests that
had "Fortran runtime error: required ftruncate or chsize support
not present" messages in gfortran.log, ran p
On 5/22/19 8:54 PM, Alan Modra wrote:
> On Wed, May 22, 2019 at 12:51:50PM -0500, Bill Schmidt wrote:
>> * config/rs6000/rs6000.c (rs6000_option_override_internal): Treat
>> PROCESSOR_FUTURE similarly to PROCESSOR_POWER9 for now.
>> (rs6000_machine_from_flags): Handle future cpu.
>>
aarch64_asan_shadow_offset is using the wrong
offset for ILP32. Change it to be a decent one.
OK? Bootstrapped and tested on aarch64-linux-gnu
with no regressions,
Thanks,
Andrew Pinski
ChangeLog:
* config/aarch64/aarch64.c (aarch64_asan_shadow_offset):
Fix ILP32 value.
---
gcc/config/aarch64
Hi
So here what I come up with.
_GLIBCXX_DEBUG_BACKTRACE controls the feature. If the user define
it and there is a detectable issue with libbacktrace then I generate a
compilation error. I want to avoid users defining it but having no
backtrace in the end in the debug assertion.
PING*2
On 5/15/19 12:36 PM, Aldy Hernandez wrote:
Sorry, I meant to PING this one.
Aldy
On Wed, May 8, 2019 at 5:08 PM Aldy Hernandez wrote:
On 5/8/19 2:30 AM, Richard Biener wrote:
On Tue, May 7, 2019 at 11:55 PM Jeff Law wrote:
On 5/7/19 3:45 AM, Richard Biener wrote:
On Tue, May 7,
On Wed, May 22, 2019 at 8:41 PM Iain Sandoe wrote:
>
> As Dominque noted in PR 64895, somewhere between revisions
> r244915 and r244957 we see the fuse-caller-save* tests started to
> XPASS on Darwin, which is a PIC target by default.
>
> The XFAILed parts of the tests never seem to be exercised
On Thu, May 23, 2019 at 1:09 AM Iain Sandoe wrote:
>
> Although this is a Darwin-specific change, I need to touch
> target-supports.exp and several tests in i386.exp.
>
> tested on x86_64-darwin and x86_64-linux-gnu
> doc change tested with “make pdf”,
>
> OK for trunk?
> backports? (where the tes
On 20 May 2019 11:40:17 CEST, Richard Biener wrote:
>On Sun, 19 May 2019, Jan Hubicka wrote:
>
>> > On Fri, 17 May 2019, Jan Hubicka wrote:
>> >
>> > > Hi,
>> > > this patch cuts walks in aliasing_component_refs_p if the type we
>look for
>> > > can not fit into a given type by comparing their si
100 matches
Mail list logo
