the value if the mode is BLKmode. Remove
specific path for big-endian targets and tidy things up a little bit.
2019-03-13 Eric Botcazou
* gcc.c-torture/compile/20200313-1.c: New test.
--
Eric Botcazoudiff --git a/gcc/expmed.c b/gcc/expmed.c
index 04610276209..e7c03fbf92c 10
mode is BLKmode. Remove
> specific path for big-endian targets and tidy things up a little bit.
>
>
> 2019-03-13 Eric Botcazou
>
> * gcc.c-torture/compile/20200313-1.c: New test.
>
> --
> Eric Botcazou
This avoids HWI -> unsigned truncation to end up with zero alignment
which set_ptr_info_alignment ICEs on.
Bootstrap and regtest in progress.
Richard.
2020-03-13 Richard Biener
PR tree-optimization/94163
* tree-ssa-pre.c (create_expression_by_pieces): Check
whether
Hi,
On Thu, 12 Mar 2020 at 23:12, Jeff Law via Gcc-patches
wrote:
>
> On Thu, 2020-03-12 at 13:23 -0500, Segher Boessenkool wrote:
> > On Thu, Mar 12, 2020 at 12:03:08PM -0600, Jeff Law wrote:
> > > On Sat, 2020-02-08 at 10:41 -0600, Segher Boessenkool wrote:
> > > > I don't think each stanza of
On Thu, Mar 12, 2020 at 03:24:31PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Mar 12, 2020 at 12:27:48PM +0100, Andreas Schwab wrote:
> > I'm getting this ICE with -mabi=ilp32:
> >
> > during RTL pass: fwprop1
> > /opt/gcc/gcc-20200312/gcc/testsuite/gcc.dg/pr94121.c: In function 'bar':
This is a regression present on all active branches: the dbr pass goes awry on
a branchy testcase compiled at -O2 for the MIPS, with specific set of options
(-fno-reorder-blocks -mlong-calls) which leave the CFG in a convoluted state.
The underlynig issue is that relax_delay_slots can streamline
On 12/03/2020 14:24, Jakub Jelinek via Gcc-patches wrote:
On Thu, Mar 12, 2020 at 12:27:48PM +0100, Andreas Schwab wrote:
I'm getting this ICE with -mabi=ilp32:
during RTL pass: fwprop1
/opt/gcc/gcc-20200312/gcc/testsuite/gcc.dg/pr94121.c: In function 'bar':
/opt/gcc/gcc-20200312/gcc/testsuite/
[See:
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541694.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541759.html
for a walkthrough of what goes wrong in the testcase, but hopefully
the change makes sense on first principles.]
simplify_operand_subreg tries to detect whe
Jeff, thanks for picking this up.
Jeff Law writes:
> On Thu, 2020-03-12 at 15:26 -0500, Segher Boessenkool wrote:
>> On Thu, Mar 12, 2020 at 12:47:04PM -0600, Jeff Law wrote:
>> > On Thu, 2020-03-12 at 13:23 -0500, Segher Boessenkool wrote:
>> > > > else if (n_sets == 1
>> > > > -
> I think there are two problems with this:
>
> (1) It never actually checks whether the hard register is valid for the
> outer mode (in the hard_regno_mode_ok sense). If it isn't, any attempt
> to reload in the outer mode is likely to cycle, because the implied
> regno/mode combinati
Eric Botcazou writes:
>> I think there are two problems with this:
>>
>> (1) It never actually checks whether the hard register is valid for the
>> outer mode (in the hard_regno_mode_ok sense). If it isn't, any attempt
>> to reload in the outer mode is likely to cycle, because the implie
Tamar Christina writes:
> Hi Richard,
>
> I have updated the patch, changelog is the same.
>
> bootstrapped and regtested on aarch64-none-linux-gnu and no issues.
>
> OK for gcc 9 and 8?
>
> Thanks,
> Tamar
>
> [...]
> diff --git a/gcc/config/aarch64/aarch64-simd.md
> b/gcc/config/aarch64/aarch64
Hi.
The patch fixed wrong strcat to a char pointer received
with getenv.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2020-03-12 Martin Liska
PR lto/94157
* lto-wrapper.c (run_gcc): Allocate a n
On Wed, 11 Mar 2020 at 00:37, Joseph Myers wrote:
>
> On Tue, 10 Mar 2020, Christophe Lyon wrote:
>
> > sizeless-1.c and sizeless-2.c have the same code, but the latter is
> > compiled with -msve-vector-bits=256 and expects different
> > warnings/errors.
> > For line 33:
> > svint8_t *invalid_sve_
On Fri, Mar 13, 2020 at 01:26:02PM +0100, Martin Liška wrote:
> diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
> index b8a35c85714..84a0bd24e91 100644
> --- a/gcc/lto-wrapper.c
> +++ b/gcc/lto-wrapper.c
> @@ -1317,7 +1317,11 @@ run_gcc (unsigned argc, char *argv[])
>
>char *xassembler
On 3/13/20 1:39 PM, Jakub Jelinek wrote:
collect_gcc_options = concat (collect_gcc_options,
xassembler_opts_string, NULL);
instead?
Ah, I forgot that concat is available here. I would choose
this way, even though it's a small memory leak.
I'm going to
"J.W. Jagersma" writes:
> On 2020-03-12 10:59, Richard Sandiford wrote:
>> The other case I mentioned was equivalent to:
>>
>> int
>> test_mem2 ()
>> {
>>int i = 2;
>>try
>> {
>>asm volatile ("ud2; mov%z0 $1, %0" : "=m" (i));
>> }
>>
Hi.
I played a bit with -flinker-output=nolto-rel of gimple-match.ii and I
identified
that current default of min-lto-partition leads to too many LTRANS. We pay with
LTO overhead and so that user time is high.
Base is:
$ g++ -O2 /tmp/gimple-match.ii -c -fno-checking -o x.o
real0m40.130s
use
> Hi.
>
> I played a bit with -flinker-output=nolto-rel of gimple-match.ii and I
> identified
> that current default of min-lto-partition leads to too many LTRANS. We pay
> with
> LTO overhead and so that user time is high.
>
> Base is:
> $ g++ -O2 /tmp/gimple-match.ii -c -fno-checking -o x.o
>
Hi!
On Fri, Mar 13, 2020 at 01:31:19PM +, Richard Sandiford wrote:
> This might not be what you mean, but for:
>
> int
> f1 (void)
> {
> int x = 1;
> asm volatile ("": "=m" (x));
> return x;
> }
>
> struct s { int i[5]; };
> struct s
> f2 (void)
> {
> struct s x = { 1, 2, 3, 4, 5 };
> > $ time g++ -O2 /tmp/gimple-match.ii -c -flto -fno-checking
> > real0m8.709s
> > user0m8.543s
> >
> > WPA+LTRANS:
> >
> > $ time gcc -flto=auto -flinker-output=nolto-rel gimple-match.o -r -o
> > gimple-match2.o --param lto-partitions=4 -fno-checking
> > real0m11.220s
On 3/13/20 4:11 PM, Jan Hubicka wrote:
$ time g++ -O2 /tmp/gimple-match.ii -c -flto -fno-checking
real0m8.709s
user0m8.543s
WPA+LTRANS:
$ time gcc -flto=auto -flinker-output=nolto-rel gimple-match.o -r -o
gimple-match2.o --param lto-partitions=4 -fno-checking
real0m11.220s
user
And using EPYC2 with 64 cores I get:
$ time gcc -flto=auto -flinker-output=nolto-rel gimple-match.o -fno-checking
--param lto-partitions=4 -r
real0m11.040s
user0m33.479s
sys 0m0.718s
$ time gcc -flto=auto -flinker-output=nolto-rel gimple-match.o -fno-checking
--param lto-partition
2020-03-13 Uroš Bizjak
* gcc.target/i386/pr64409.c: Do not limit compilation to x32 targets.
(dg-error): Quote 'ms_abi' attribute.
* gcc.target/i386/pr71958.c: Do not limit compilation to x32 targets.
Require maybe_x32 effective target.
(dg-options): Add -mx32.
(dg-error
Hi!
On Fri, Mar 13, 2020 at 10:06:01AM +1030, Alan Modra wrote:
> On Thu, Mar 12, 2020 at 11:57:17AM -0500, Segher Boessenkool wrote:
> > On Thu, Mar 12, 2020 at 01:18:50PM +1030, Alan Modra wrote:
> > > With lazy PLT resolution the first load of a PLT entry may be a value
> > > pointing at a reso
On Fri, Mar 13, 2020 at 02:06:13AM +0100, J.W. Jagersma wrote:
> I don't want to unnecessarily pessimize register outputs if it can be
> avoided. And even if you do change register outputs to in+out, they
> are still more likely to contain some intermediate value that you would
> want to discard o
On Fri, Mar 13, 2020 at 03:21:18AM +, Yangfei (Felix) wrote:
> > On Wed, Mar 04, 2020 at 08:39:36AM +, Yangfei (Felix) wrote:
> > > This is a simple fix for PR94026.
> > > With this fix, combine will try make an extraction if we are in a
> > > equality
> > comparison and this is an AND
[https://encrypted-tbn0.gstatic.com/images?q=tbn%3AANd9GcRRRtgAilx9qs7bQ5XpBzodzVNZfCkpc_jR3xdjbzBzdqjR2KSv]
Shipping Confirmation
Order ID: 645-8653-8267689766
Hello Customer,
Your order is on the way. If you need to return an item from this shipment or
manage other orders, please call .
If yo
On 2020-03-13 14:31, Richard Sandiford wrote:
> "J.W. Jagersma" writes:
>> On 2020-03-12 10:59, Richard Sandiford wrote:
>>> The other case I mentioned was equivalent to:
>>>
>>> int
>>> test_mem2 ()
>>> {
>>>int i = 2;
>>>try
>>> {
>>>asm volati
On 3/12/20 7:17 PM, Joseph Myers wrote:
On Thu, 5 Mar 2020, Martin Sebor wrote:
Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9?
OK for GCC 10.
Thank you. I committed it to trunk in r10-7162.
Do you not want me to commit it to GCC 9 or are you leaving it up to me?
Ma
On Fri, Mar 13, 2020 at 07:30:17AM +0100, Richard Biener wrote:
> On March 12, 2020 11:29:45 PM GMT+01:00, Segher Boessenkool
> wrote:
> >The df dataflow solvers use the aux field in the basic_block struct,
> >although that is reserved for any use by passes. And not only that,
> >it is required
On 3/6/20 2:11 AM, Richard Biener wrote:
On Fri, Mar 6, 2020 at 2:04 AM Martin Sebor wrote:
Treating incompatible redeclarations of built-in functions as built-ins
is a problem not just for the middle-end but even for the C front-end
itself, when different parts of it make different assumptio
Jeff's build-bot reported warnings in the test as a result of the recent
tightening up of the -Wbuiltin-declaration-mismatch checking. The commit
at the following link adjusts the test to avoid the warning:
https://gcc.gnu.org/pipermail/gcc-cvs/2020-March/271705.html
Tested on x86_64-linux bot
The following committed patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303
The patch was successfully bootstrapped and tested on x86-64.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index d63b83194d5..4ea81e6c404 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+20
Hi all,
This patch is part of a series that adds support for the ARMv8.m Custom
Datapath Extension (CDE).
It enables the ACLE intrinsics calling VCX1, VCX2, and VCX3
instructions who work with FPU/MVE 32-bit/64-bit registers.
This patch depends on the CDE feature patch:
https://gcc.gnu.org/pip
x32 does not support MS ABI, skip testcases that require it.
2020-03-13 Uroš Bizjak
* testsuite/20_util/bind/91371.cc: Skip for x32.
* testsuite/20_util/is_function/91371.cc: Ditto.
* testsuite/20_util/is_member_function_pointer/91371.cc: Ditto.
* testsuite/20_util/is_object/91
Hello,
The commit [1], as referenced below, which added a new test case,
contains a typo in the dg-final directive, which eventually causes
the gcc.log file to not be produced. This patch fixes the typo.
Tested by running regressions for aarch64-none-elf.
OK for trunk?
gcc/testsuite/ChangeLo
Vasee Vinayagamoorthy writes:
> Hello,
>
> The commit [1], as referenced below, which added a new test case,
> contains a typo in the dg-final directive, which eventually causes
> the gcc.log file to not be produced. This patch fixes the typo.
>
> Tested by running regressions for aarch64-none-elf
This is the libiberty (mainly for binutils/gdb) counterpart of
https://github.com/alexcrichton/rustc-demangle/pull/23.
Relevant links for the new Rust mangling scheme (aka "v0"):
* Rust RFC: https://github.com/rust-lang/rfcs/pull/2603
* tracking issue: https://github.com/rust-lang/rust/issues/6070
On Thu, 2020-03-12 at 14:43 -0700, Jim Wilson wrote:
> On Thu, Mar 12, 2020 at 2:38 AM Richard Biener via Gcc-patches
> wrote:
> > On Thu, Mar 12, 2020 at 4:06 AM Jeff Law via Gcc-patches
> > wrote:
> > > On Wed, 2020-03-11 at 13:04 +, Nidal Faour via Gcc-patches wrote:
> > > > This patch is
On Fri, 13 Mar 2020, Christophe Lyon via Gcc-patches wrote:
> The attached small patch fixes the problem (tested on arm and aarch64).
> OK?
>
> gcc/c/ChangeLog:
>
> 2020-03-13 Christophe Lyon
>
> * c-typeck.c (process_init_element): Handle constructor_type with
> type size re
On Fri, 2020-03-13 at 09:09 +0100, Christophe Lyon wrote:
> Hi,
>
>
> On Thu, 12 Mar 2020 at 23:12, Jeff Law via Gcc-patches
> wrote:
> > On Thu, 2020-03-12 at 13:23 -0500, Segher Boessenkool wrote:
> > > On Thu, Mar 12, 2020 at 12:03:08PM -0600, Jeff Law wrote:
> > > > On Sat, 2020-02-08 at 10:
On Fri, 13 Mar 2020, Martin Sebor via Gcc-patches wrote:
> On 3/12/20 7:17 PM, Joseph Myers wrote:
> > On Thu, 5 Mar 2020, Martin Sebor wrote:
> >
> > > Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9?
> >
> > OK for GCC 10.
>
> Thank you. I committed it to trunk in r10-71
On Thu, 2020-03-12 at 14:21 -0600, Sandra Loosemore wrote:
> On 1/27/20 2:02 PM, Jeff Law wrote:
> > [snip]
> >
> > While I think we've missed the boat for gcc-10, I think these
> > patches
> > should go forward in gcc-11. I'll own getting the paths sorted so
> > that
> > this problem is avoided
On Fri, Mar 13, 2020 at 10:40:38AM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Mar 13, 2020 at 10:06:01AM +1030, Alan Modra wrote:
> > On Thu, Mar 12, 2020 at 11:57:17AM -0500, Segher Boessenkool wrote:
> > > On Thu, Mar 12, 2020 at 01:18:50PM +1030, Alan Modra wrote:
> > > > With lazy PLT
PR analyzer/94099 and PR analyzer/94105 both report ICEs relating to
calling region_model::get_lvalue on a NOP_EXPR.
PR analyzer/94099's ICE happens when generating a checker_path when
encountering an unhandled tree code (NOP_EXPR) in get_lvalue with a
NULL context (from for_each_state_change).
P
This is a fix for PR92379. Passes regstrap on ppc64le. Pre-approved by
Segher, committing after posting.
2020-03-13 Aaron Sawdey
PR target/92379
* config/rs6000/rs6000.c (num_insns_constant_multi) Don't shift a
64-bit value by 64 bits (UB).
diff --git a/gcc/config/rs6000/rs6000.c
47 matches
Mail list logo
