Bootstrapped (with BOOT_CFLAGS='-g -O2 -Wno-error=maybe-uninitialized')
and regtested on s390x-redhat-linux. Ok for master?
Certain alternatives of *vec_tf_to_v1tf use "v" constraint for its
TFmode source operand. Therefore it is assigned to VEC_REGS class, and
when it is reloaded using *movtf_6
For pattern A * C +- B * C -> (A +- B) * C, simplification is disabled
when A and B are not single-use. This patch is a minor enhancement
on the pattern, which allows folding if final result is found to be a
simple gimple value (constant/existing SSA).
Bootstrapped/regtested on x86_64-linux and aa
Hi Segher,
on 2020/9/2 下午6:25, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Sep 02, 2020 at 11:16:00AM +0800, Kewen.Lin wrote:
>> on 2020/9/1 上午3:41, Segher Boessenkool wrote:
>>> On Tue, Aug 25, 2020 at 08:46:55PM +0800, Kewen.Lin wrote:
1) Currently address_cost hook on rs6000 always return
On Wed, Sep 2, 2020 at 5:58 PM Jakub Jelinek wrote:
>
> On Wed, Sep 02, 2020 at 09:57:08AM +0800, Hongtao Liu via Gcc-patches wrote:
> > +
> > + first = XVECEXP (constant, 0, 0);
> > + /* There could be some rtx like
> > + (mem/u/c:V16QI (symbol_ref/u:DI ("*.LC1")))
> > + but w
#pragma region is a feature introduced by Microsoft in order to allow
manual grouping and folding of code within Visual Studio. It is
entirely ignored by the compiler. Clang has supported this feature
since 2012 when in MSVC compatibility mode, and enabled it across the
board in 2018.
As it stan
Note - ignore previous version of this patch, didn't filter out
Makefile.in
Adds support for -
atomic wait/notify_one/notify_all
counting_semaphore
binary_semaphore
latch
* include/Makefile.am (bits_headers): Add new header.
* include/Makefile.in: R
Adds support for -
atomic wait/notify_one/notify_all
counting_semaphore
binary_semaphore
latch
* include/Makefile.am (bits_headers): Add new header.
* include/Makefile.in: Regenerate.
* include/bits/atomic_base.h (__atomic_base<_Itp>::wait):
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html
On 8/25/20 12:44 PM, Martin Sebor wrote:
Joseph, do you have any more comments on the rest of the most recent
revision of the patch?
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html
Martin
On 8/19/20 6:09
On Wed, 2 Sep 2020, Jason Merrill via Gcc-patches wrote:
On 9/1/20 6:13 AM, Marc Glisse wrote:
On Tue, 1 Sep 2020, Jakub Jelinek via Gcc-patches wrote:
As discussed in the PR, fold-const.c punts on floating point constant
evaluation if the result is inexact and -frounding-math is turned on.
On Wed, Sep 02, 2020 at 05:06:45PM -0400, Jason Merrill wrote:
> On 9/2/20 4:37 PM, Marek Polacek wrote:
> > I've added do_aggregate_paren_init to factor some common code. It's not
> > perfect because the enclosing conditions couldn't really be factored out,
>
> This condition:
>
> > +
On 8/27/20 6:19 AM, Richard Biener wrote:
On Thu, 27 Aug 2020, Jakub Jelinek wrote:
On Fri, Jul 31, 2020 at 04:28:05PM -0400, Jason Merrill via Gcc-patches wrote:
On 7/31/20 6:06 AM, Jakub Jelinek wrote:
On Fri, Jul 31, 2020 at 10:54:46AM +0100, Jonathan Wakely wrote:
Does the standard requi
On 9/2/20 4:37 PM, Marek Polacek wrote:
On Wed, Sep 02, 2020 at 12:00:29PM -0400, Jason Merrill via Gcc-patches wrote:
On 9/1/20 6:23 PM, Marek Polacek wrote:
This patch nails down the remaining P0960 case in PR92812:
struct A {
int ar[2];
A(): ar(1, 2) {} // doesn't work witho
On 9/1/20 6:13 AM, Marc Glisse wrote:
On Tue, 1 Sep 2020, Jakub Jelinek via Gcc-patches wrote:
As discussed in the PR, fold-const.c punts on floating point constant
evaluation if the result is inexact and -frounding-math is turned on.
/* Don't constant fold this floating point operation if
On Wed, Sep 02, 2020 at 12:00:29PM -0400, Jason Merrill via Gcc-patches wrote:
> On 9/1/20 6:23 PM, Marek Polacek wrote:
> > This patch nails down the remaining P0960 case in PR92812:
> >
> >struct A {
> > int ar[2];
> > A(): ar(1, 2) {} // doesn't work without this patch
> >};
>
> "Andrew" == Andrew Stubbs writes:
Andrew>
http://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html#composite-location-description-operations
Thanks. Adding that to the appropriate spot in the patch would be
great.
Tom
On 02/09/2020 18:49, Tom Tromey wrote:
"Andrew" == Andrew Stubbs writes:
Andrew> To be fair, the DWARF standard makes a similar assumption; the
Andrew> engineers working on LLVM and GDB, at AMD, have therefore invented
Andrew> some new DWARF operators that they plan to propose for a future
And
On 9/2/20 3:13 PM, Jonathan Wakely wrote:
Since r216679 these macros have only been defined in C++98 mode, rather
than all modes. That is permitted as a GNU extension because that header
doesn't exist in the C++ standard until C++11, so we can make it do
whatever we want for C++98. But as discuss
Since r216679 these macros have only been defined in C++98 mode, rather
than all modes. That is permitted as a GNU extension because that header
doesn't exist in the C++ standard until C++11, so we can make it do
whatever we want for C++98. But as discussed in the PR c++/60304
comments, these macro
On Linux/x86_64,
6bdbf0f37bda2587a4e82cbb956de7a159a397ae is the first bad commit
commit 6bdbf0f37bda2587a4e82cbb956de7a159a397ae
Author: Jonathan Wakely
Date: Wed Sep 2 13:27:57 2020 +0100
libstdc++: Break header cycle between and
caused
FAIL: g++.old-deja/g++.abi/cxa_vec.C -std=gnu+
> "Andrew" == Andrew Stubbs writes:
Andrew> To be fair, the DWARF standard makes a similar assumption; the
Andrew> engineers working on LLVM and GDB, at AMD, have therefore invented
Andrew> some new DWARF operators that they plan to propose for a future
Andrew> standard. Only one is relevant
On Tue, 1 Sep 2020, Jeff Law via Gcc-patches wrote:
> > With this commit:
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553109.html
> > the remaining failures should now be gone. Please let me know if
> > any persist.
> There's a related glibc build failure, but I think Joseph ack'
On 02/09/20 10:22 -0700, sunil.k.pandey wrote:
On Linux/x86_64,
6bdbf0f37bda2587a4e82cbb956de7a159a397ae is the first bad commit
commit 6bdbf0f37bda2587a4e82cbb956de7a159a397ae
Author: Jonathan Wakely
Date: Wed Sep 2 13:27:57 2020 +0100
libstdc++: Break header cycle between and
caused
On 01/09/20 3:25 pm, Jonathan Wakely wrote:
On 01/09/20 14:06 +0200, François Dumont wrote:
Hi
No chance to review this small patch ?
I did review it, and I wasn't convinced it was a good change. It only
helps a particular usage pattern, and might hurt in other cases.
I shouldn't have
On Linux/x86_64,
6bdbf0f37bda2587a4e82cbb956de7a159a397ae is the first bad commit
commit 6bdbf0f37bda2587a4e82cbb956de7a159a397ae
Author: Jonathan Wakely
Date: Wed Sep 2 13:27:57 2020 +0100
libstdc++: Break header cycle between and
caused
FAIL: g++.old-deja/g++.abi/cxa_vec.C -std=gnu+
> On Wed, Sep 2, 2020 at 8:31 AM Jose E. Marchesi via Gcc-patches
> wrote:
>>
>>
>> Hi people!
>>
>> While adding a bpf-sim.exp to dejagnu, I noticed that the flags in
>> board/cflags were included in the final compilation line _after_ the
>> flags in the test's dg-options.
>>
>> Since the test
On Wed, Sep 2, 2020 at 8:31 AM Jose E. Marchesi via Gcc-patches
wrote:
>
>
> Hi people!
>
> While adding a bpf-sim.exp to dejagnu, I noticed that the flags in
> board/cflags were included in the final compilation line _after_ the
> flags in the test's dg-options.
>
> Since the test options are mor
On 28/08/20 23:11 +0100, Jonathan Wakely wrote:
This fixes a bug with mixed signed and unsigned types, where converting
a negative value to the unsigned result type alters the value. The
solution is to obtain the absolute values of the arguments immediately
and to perform the actual GCD or LCM al
On 9/1/20 6:23 PM, Marek Polacek wrote:
This patch nails down the remaining P0960 case in PR92812:
struct A {
int ar[2];
A(): ar(1, 2) {} // doesn't work without this patch
};
Note that when the target object is not of array type, this already
works:
struct S { int x, y; };
Minor documentation fix, committed as obvious.
>From 0edc2c1a2445dffc7b839d833263c78f7cab01dc Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Wed, 2 Sep 2020 16:34:43 +0100
Subject: [PATCH] MSP430: Fix -mlarge documentation to indicate size_t is a
20-bit type
gcc/ChangeLog:
* doc
On 02/09/20 15:51 +0100, Jonathan Wakely wrote:
The spaceship operator for std::array uses memcmp when the
__is_byte trait is true, but memcmp isn't usable in
constexpr contexts. Also, memcmp should only be used for unsigned byte
types, because it gives the wrong answer for signed chars with nega
On 02/09/20 14:15 +0100, Jonathan Wakely wrote:
The and headers each include each other, which makes
building them as header-units "exciting". The header only needs
the definition of std::exception (in order to derive from it) which is
already in its own header, so just include that.
libstdc+
Hi people!
While adding a bpf-sim.exp to dejagnu, I noticed that the flags in
board/cflags were included in the final compilation line _after_ the
flags in the test's dg-options.
Since the test options are more particular than the board options, I
would expect them to be placed after any board-
During some discussion such an example as attached came up:
f() = 0.0
where 'f' is a function which returns a pointer to an array.
This gets handled as
_F.D0 => f()
_F.D0 = 0.0
However, the first line did fail with a rank error as the rank
was taken from the RHS.
Changing this to the LHS ex
The spaceship operator for std::array uses memcmp when the
__is_byte trait is true, but memcmp isn't usable in
constexpr contexts. Also, memcmp should only be used for unsigned byte
types, because it gives the wrong answer for signed chars with negative
values.
We can simply check std::is_constant
On 9/1/20 2:33 PM, Martin Liška wrote:
The last patch is a refactoring using ONE_* macros.
Thoughts?
Thanks,
Martin
There's rebassed version of the patch.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>From 5cefff607077503794a387
Please forget about the patch. It's part of 02/N v2.
Martin
On 9/1/20 4:04 PM, Jan Hubicka wrote:
The patch is about usage of MiB in memory allocation reports.
I see it much better readable than values displayed in KiB:
Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB}
{GC 19 MiB} {heap 12 MiB}
Reading the symbol table:
Mergi
On 9/1/20 2:31 PM, Martin Liška wrote:
Hey.
I've just applied to patches to glibc introducing a new mallinfo2 function.
Limitation of the current function mallinfo is usage of int type which overflows
for allocation > 2GB.
The patch adds configure detection and usage of the new one. And it prin
In the MSP430 small memory model, there is a 16-bit address space and
pointer arithmetic wraps around the address space, so any calculated
address is always within this range.
In this test, pointer arithmetic wraps when 0x1000 is added to the
address of a variable, causing the resulting address to
The and headers each include each other, which makes
building them as header-units "exciting". The header only needs
the definition of std::exception (in order to derive from it) which is
already in its own header, so just include that.
libstdc++-v3/ChangeLog:
* include/bits/stl_iterat
On Wed, Sep 2, 2020 at 2:33 AM Hongtao Liu via Gcc-patches
wrote:
>
> Hi:
> Add define_peephole2 to eliminate potential redundant conversion
> from mask to vector.
> Bootstrap is ok, regression test is ok for i386/x86-64 backend.
> Ok for trunk?
>
> gcc/ChangeLog:
> PR target/96891
>
On 9/1/20 4:50 PM, David Malcolm wrote:
Hope this is constructive
Dave
Thank you David. All of them very very useful!
There's updated version of the patch.
Martin
>From 6efbec6402a0babb0b8ccc2145fbf681e8030786 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 28 Aug 2020 10:26:13 +0200
S
On 9/2/20 12:44 PM, Jakub Jelinek wrote:
> On Wed, Sep 02, 2020 at 12:22:28PM +0200, Tom de Vries wrote:
>> And test-case passes on x86_64 with this patch (obviously, in
>> combination with trigger patch above).
>>
>> Jakub, WDYT?
>
> I guess the normal answer would be use libatomic, but it isn't
On 9/2/20 12:22 PM, Tom de Vries wrote:
Tobias, can you try on powerpc?
Testcase now compiles and runs w/o error message.
On 9/2/20 12:44 PM, Jakub Jelinek wrote:
I guess the normal answer would be use libatomic, but it isn't ported for
nvptx.
I guess at least temporarily this is ok,though
On Wed, Sep 02, 2020 at 12:22:28PM +0200, Tom de Vries wrote:
> And test-case passes on x86_64 with this patch (obviously, in
> combination with trigger patch above).
>
> Jakub, WDYT?
I guess the normal answer would be use libatomic, but it isn't ported for
nvptx.
I guess at least temporarily thi
Hi!
On Wed, Sep 02, 2020 at 11:16:00AM +0800, Kewen.Lin wrote:
> on 2020/9/1 上午3:41, Segher Boessenkool wrote:
> > On Tue, Aug 25, 2020 at 08:46:55PM +0800, Kewen.Lin wrote:
> >> 1) Currently address_cost hook on rs6000 always return zero, but at least
> >> from Power7, pre_inc/pre_dec kind instru
[ was: Re: [patch][nvptx] libgomp: Split testcase in order to XFAIL
__sync_val_compare_and_swap_16 (was: [PATCH] nvptx: Add support for
subword compare-and-swap) ]
On 9/2/20 9:56 AM, Tom de Vries wrote:
> On 9/1/20 2:58 PM, Tom de Vries wrote:
>> On 9/1/20 1:41 PM, Tobias Burnus wrote:
>>> Hi Tom,
Hi Will,
On Tue, Sep 01, 2020 at 09:00:20PM -0500, will schmidt wrote:
> This corrects an issue with the powerpc vector long long subtypes.
> As reported by SjMunroe in PR96139. When building some code with -Wall
> and attempting to print an element of a "long long vector" with a long long
> pr
On Wed, Sep 02, 2020 at 09:57:08AM +0800, Hongtao Liu via Gcc-patches wrote:
> +
> + first = XVECEXP (constant, 0, 0);
> + /* There could be some rtx like
> + (mem/u/c:V16QI (symbol_ref/u:DI ("*.LC1")))
> + but with "*.LC1" refer to V2DI constant vector. */
> + if (GET_MOD
Hi!
On Tue, Sep 01, 2020 at 07:22:57PM -0300, Alexandre Oliva wrote:
> This WIP patchlet introduces means for machines that implicitly clobber
> cc flags in asm statements, but that have machinery to output flags
> (namely x86, non-thumb arm and aarch64), to state that the asm statement
> does NOT
On Mon, Aug 31, 2020 at 2:19 PM Hongtao Liu wrote:
>
> Hi:
> This patch is to adjust testcases which failed the regression test
> when gcc is built with -march=skylake-avx512.
> Also add runtime check for AVX512 tests.
>
> gcc/testsuite/ChangeLog:
> PR target/96246
> PR target/
Hi:
Add define_peephole2 to eliminate potential redundant conversion
from mask to vector.
Bootstrap is ok, regression test is ok for i386/x86-64 backend.
Ok for trunk?
gcc/ChangeLog:
PR target/96891
* config/i386/sse.md (VI_128_256): New mode iterator.
(define_peephol
On Wed, Sep 2, 2020 at 11:26 AM luoxhu wrote:
>
> Hi,
>
> On 2020/9/1 21:07, Richard Biener wrote:
> > On Tue, Sep 1, 2020 at 10:11 AM luoxhu via Gcc-patches
> > wrote:
> >>
> >> Hi,
> >>
> >> On 2020/9/1 01:04, Segher Boessenkool wrote:
> >>> Hi!
> >>>
> >>> On Mon, Aug 31, 2020 at 04:06:47AM -0
Hi,
On 2020/9/1 21:07, Richard Biener wrote:
> On Tue, Sep 1, 2020 at 10:11 AM luoxhu via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> On 2020/9/1 01:04, Segher Boessenkool wrote:
>>> Hi!
>>>
>>> On Mon, Aug 31, 2020 at 04:06:47AM -0500, Xiong Hu Luo wrote:
vec_insert accepts 3 arguments, arg0 is in
On 9/2/20 10:18 AM, Jakub Jelinek via Gcc-patches wrote:
The standard says that excess digits from boz are truncated.
For hexadecimal or binary, the routines copy just the number of digits
that will be needed, but for octal we copy number of digits that
contain one extra bit (for 8-bit, 32-bit o
On Tue, 1 Sep 2020, Jakub Jelinek wrote:
> On Tue, Sep 01, 2020 at 01:52:21PM +0200, Richard Biener wrote:
> > OK, I'll see to do that (or fixup the RTL expansion side somehow).
> >
> > Note that clang and gcc disagree about the return value ABI for
> >
> > typedef double v1df __attribute__((vec
Hi!
The standard says that excess digits from boz are truncated.
For hexadecimal or binary, the routines copy just the number of digits
that will be needed, but for octal we copy number of digits that
contain one extra bit (for 8-bit, 32-bit or 128-bit, i.e. kind 1, 4 and 16)
or two extra bits (fo
On Wed, 2 Sep 2020 at 00:12, Martin Sebor via Gcc-patches
wrote:
>
> ILP32 failures in a test added for the new -Wstringop-overread
> option exposed an unnecessarily restrictive handling of offsets
> in ranges with an upper bound that's apparently less than
> the lower bound. I have relaxed the h
On 9/1/20 2:58 PM, Tom de Vries wrote:
> On 9/1/20 1:41 PM, Tobias Burnus wrote:
>> Hi Tom, hello all,
>>
>> it turned out that the testcase fails on PowerPC (but not x86_64)
>> as the nvptx lto complains: unresolved symbol
>> __sync_val_compare_and_swap_16
>>
>> The testcase uses int128 – and that
> BPF is an ELF-based target, so it definitely benefits from using
> elfos.h. This patch makes the target to use it, and removes
> superfluous definitions from bpf.h which are better defined in
> elfos.h.
>
> Note that BPF, despite being an ELF target, doesn't use DWARF. At
> some point it will
This patch makes the BPF backend to not provide its own implementation
of the asm_named_section hook; the default handler works perfectly
well.
2020-09-02 Jose E. Marchesi
gcc/
* config/bpf/bpf.c (bpf_asm_named_section): Delete.
(TARGET_ASM_NAMED_SECTION): Likewise.
---
61 matches
Mail list logo
