Hi:
If the second operand of __builtin_shuffle is const vector 0, and with
specific mask, it can be optimized to movq/vmovps.
.i.e.
foo128:
- vxorps %xmm1, %xmm1, %xmm1
- vmovlhps%xmm1, %xmm0, %xmm0
+ vmovq %xmm0, %xmm0
foo256:
- vxorps %xmm1, %xmm1, %xmm1
On 4/22/21 4:55 AM, Martin Liška wrote:
There's an updated version of the patch, Jonathan noticed correctly
the comment related to assert was not correct.
Subject: [PATCH] Use STATIC_ASSERT for OVL_OP_MAX.
Subject line needs "c++:"
Please also include the rationale from your first message
As requested at the end of Stage 4, this patch changes the debugging
format for AIX configuration of GCC to "DWARF2". This is in
preparation for removing stabs debugging support from GCC.
The rs6000 configuration files remain somewhat intertwined with the
stabs debugging support, but the
On Thu, 22 Apr 2021 14:28:24 -0600
Martin Sebor via Gcc-patches wrote:
> > enum E { e = 5 };
> > struct A { E e: 3; };
> >
> > constexpr int number_of_bits ()
> > {
> > A a = { };
> > a.e = (E)-1;
> > return 32 - __builtin_clz(a.e);
> > }
> >
>
> I had the same thought about
On Fri, Apr 09, 2021 at 05:09:07PM -0400, Michael Meissner wrote:
> Fix logic error in 32-bit trampolines, PR target/98952.
>
> The test in the PowerPC 32-bit trampoline support is backwards. It aborts
> if the trampoline size is greater than the expected size. It should abort
> when the
On Mon, Apr 12, 2021 at 05:02:38PM -0500, will schmidt wrote:
> On Fri, 2021-04-09 at 17:09 -0400, Michael Meissner wrote:
> > - li r8,trampoline_size /* verify that the trampoline is big
> > enough */
> > - cmpwcr1,r8,r4
> > + cmpwi cr1,r4,trampoline_size /* verify that
Hi,
this patch adds changesentry for IPA/LTO and FDO.
Honza
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 6f58cfe8..bba16ead 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -170,6 +170,37 @@ a work-in-progress.
use -g together with
On 4/22/21 11:34 AM, Patrick Palka wrote:
As described in detail in comment #4 of this PR, when tentatively
parsing a construct that can either be a type or an expression, if
during the type parse we encounter an unexpected template placeholder,
we need to simulate an error rather than issue a
On 4/22/21 10:49 AM, Patrick Palka wrote:
This implements the wording changes of CWG2374, which clarifies the
wording of P0138 to forbid e.g. direct-list-initialization of a scoped
enumeration from a different scoped enumeration.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
For op_by_pieces operations between two areas of memory on non-strict
alignment target, add -foverlap-op-by-pieces=[off|on|max-memset] to
generate overlapping operations to minimize number of operations if it
is not a stack push which must not overlap.
When operating on LENGTH bytes of memory,
Add TARGET_PREFER_OVERLAP_OP_BY_PIECES for Alder Lake and Intel core
processoes with AVX2 to enable -foverlap-op-by-pieces by default.
gcc/
PR middl-end/90773
* config/i386/i386-options.c (ix86_option_override_internal):
Enable -foverlap-op-by-pieces by default for
For op_by_pieces operations between two areas of memory on non-strict
alignment target, add -foverlap-op-by-pieces=[off|on|max-memset] to
generate overlapping operations to minimize number of operations if it
is not a stack push which must not overlap.
When operating on LENGTH bytes of memory,
Now with the correct patch attached ...
Sorry for the confusion!
---
Dear Fortranners,
we need to check the arguments to the affected GNU intrinsic extensions
properly, and - as pointed out in the PR by Tobias - we need to allow
function references that have a data pointer result. Also the
Dear Fortranners,
we need to check the arguments to the affected GNU intrinsic extensions
properly, and - as pointed out in the PR by Tobias - we need to allow
function references that have a data pointer result. Also the argument
names of the character arguments of the subroutine versions
On 4/22/21 9:41 AM, Jonathan Wakely wrote:
On Thu, 22 Apr 2021 at 15:59, Martin Sebor wrote:
On 4/22/21 2:52 AM, Jonathan Wakely wrote:
On Thu, 22 Apr 2021, 08:47 Martin Liška, wrote:
On 4/21/21 6:11 PM, Martin Sebor wrote:
> On 4/21/21 2:15 AM, Martin Liška wrote:
>>
Dear Fortranners,
while analyzing a different PR (PR100154), Tobias pointed out that the
target of a pointer from the evaluation of function-reference is allowed
to be used in a variable definition context and thus as an actual
argument to a function or subroutine.
This seems to be a more
From: Bernhard Reutner-Fischer
gcc/ChangeLog:
* config/i386/x86-tune-sched-bd.c (dispatch_group): Commentary
typo fix.
---
gcc/config/i386/x86-tune-sched-bd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/i386/x86-tune-sched-bd.c
On April 22, 2021 9:09:28 PM GMT+02:00, Michael Meissner
wrote:
>On Wed, Apr 21, 2021 at 10:10:07AM +0200, Tobias Burnus wrote:
>> On 20.04.21 08:58, Richard Biener via Fortran wrote:
>> >On Mon, Apr 19, 2021 at 9:40 PM Michael Meissner via Fortran
>> > wrote:
>> Is there any reason to not only
On Wed, Apr 21, 2021 at 10:10:07AM +0200, Tobias Burnus wrote:
> On 20.04.21 08:58, Richard Biener via Fortran wrote:
> >On Mon, Apr 19, 2021 at 9:40 PM Michael Meissner via Fortran
> > wrote:
> Is there any reason to not only send the email to fortran@ _and_
> gcc-patches@ but sending it to 13
We correctly diagnose the invalid access since r11-1350.
gcc/testsuite/ChangeLog:
PR c++/16617
* g++.dg/template/access36.C: New test.
---
gcc/testsuite/g++.dg/template/access36.C | 25
1 file changed, 25 insertions(+)
create mode 100644
We correctly accept this testcase since r11-1638.
gcc/testsuite/ChangeLog:
PR c++/84689
* g++.dg/cpp0x/sfinae67.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/sfinae67.C | 20
1 file changed, 20 insertions(+)
create mode 100644
Hi All!
Proposed patch to:
PR82376 - Duplicate function call using -fcheck=pointer
Patch tested only on x86_64-pc-linux-gnu.
Evaluate function result and then pass a pointer, instead of a reference
to the function itself, thus avoiding multiple evaluations of the function.
Thank you very
The test was added in r11-6687-gbdd1b1f55529da00b867ef05a53a08fbfc3d1c2e
(PR93340)
but placed into the wrong directly. Fixed by moving to gfortran.dg/
in commit r12-68-gac456fd981db6b0c2f7ee1ab0d17d36087a74dc2 after
confirming that the tests work.
Tobias
-
Mentor Graphics
Martin Liška writes:
> Hey.
>
> I/O buffering in gcov seems duplicite to what modern C library can provide.
> The patch is a simplification and can provide easier interface for system
> that don't have a filesystem and would like using GCOV.
>
> I'm going to install the patch after 11.1 if there
The __cond_wait_until_impl function takes a steady_clock timeout, but
then sometimes tries to compare it to a time from the system_clock,
which won't compile. Additionally, that function gets called with
system_clock timeouts, which also won't compile. This makes the function
accept timeouts for
On Thu, 22 Apr 2021 at 15:59, Martin Sebor wrote:
>
> On 4/22/21 2:52 AM, Jonathan Wakely wrote:
> > On Thu, 22 Apr 2021, 08:47 Martin Liška, wrote:
> >
> > On 4/21/21 6:11 PM, Martin Sebor wrote:
> > > On 4/21/21 2:15 AM, Martin Liška wrote:
> > >> Hello.
> > >>
> > >>
On Thu, Apr 22, 2021 at 09:26:47AM -0600, Jeff Law via Gcc-patches wrote:
> > * g++.dg/template/nontype29.C: Fix typos and missing comments.
> > * gcc.dg/Warray-bounds-64.c: Likewise.
> > * gcc.dg/Warray-parameter.c: Likewise.
> > * gcc.dg/Wstring-compare.c: Likewise.
> > *
As described in detail in comment #4 of this PR, when tentatively
parsing a construct that can either be a type or an expression, if
during the type parse we encounter an unexpected template placeholder,
we need to simulate an error rather than issue a real error because the
subsequent expression
On 4/22/2021 6:23 AM, Martin Liška wrote:
Hello.
The patch fixes various typos.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
PR testsuite/100159
PR testsuite/100192
gcc/ChangeLog:
* builtins.c
This fixes a linker error on AIX:
FAIL: 30_threads/semaphore/try_acquire_posix.cc (test for excess errors)
Excess errors:
ld: 0711-317 ERROR: Undefined symbol: .__atomic_fetch_add_8
ld: 0711-317 ERROR: Undefined symbol: .__atomic_load_8
ld: 0711-317 ERROR: Undefined symbol: .__atomic_fetch_sub_8
Prior to C++20 it should be ill-formed to use std::make_shared with an
array type (and we don't support the C++20 feature to make it valid yet
anyway).
libstdc++-v3/ChangeLog:
PR libstdc++/99006
* include/bits/shared_ptr.h (allocate_shared): Assert that _Tp
is not an
libstdc++-v3/ChangeLog:
* config/os/gnu-linux/os_defines.h: Fix type in comment.
Tested powerpc64le-linux. Committed to trunk.
commit 19aa9bc9897955817622574e62b53b24ae0837e9
Author: Jonathan Wakely
Date: Thu Apr 22 15:48:29 2021
libstdc++: Fix typo in comment
On 4/22/21 2:52 AM, Jonathan Wakely wrote:
On Thu, 22 Apr 2021, 08:47 Martin Liška, wrote:
On 4/21/21 6:11 PM, Martin Sebor wrote:
> On 4/21/21 2:15 AM, Martin Liška wrote:
>> Hello.
>>
>> It's addressing the following Clang warning:
>> cp/lex.c:170:45: warning:
This implements the wording changes of CWG2374, which clarifies the
wording of P0138 to forbid e.g. direct-list-initialization of a scoped
enumeration from a different scoped enumeration.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
On 4/22/21 3:59 PM, Richard Biener wrote:
> For system.h please keep it working for C code (not sure if we use
> a C compiler anywhere).
All right. I've just did --enable-languages=all and all is fine.
So there's likely no C usage of it.
Martin
On 2021-04-22 02:23, Jonathan Wakely wrote:
On 21/04/21 18:29 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
NOTE - This patch also needs to be backported to gcc-11 in order for
semaphore release() to work correctly on non-futex platforms.
Tested sparc-sun-solaris2.11
For types that
On 4/22/21 4:00 PM, Richard Biener wrote:
> For the dg-bogus did you check the emitted diagnostic not tested for
> doesn't have the same misspelling?
I did. I'm going to push it.
Martin
2021-04-22 Uroš Bizjak
gcc/
PR target/100119
* config/i386/i386-expand.c (ix86_expand_convert_uns_sidf_sse):
Remove the sign with FE_DOWNWARD, where x - x = -0.0.
gcc/testsuite/
PR target/100119
* gcc.target/i386/pr100119.c: New test.
Bootstrapped and regression tested
Wrong PR # in subject.
On Thu, Apr 22, 2021 at 7:11 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> gcc on ia32 miscompiles various atomics involving floating point,
> unfortunately I'm afraid it is too late to fix that for 11.1 and
> as I'm quite lost on it, it might take a while for 12 too
On 4/22/21 2:47 PM, Richard Biener wrote:
> On Thu, Apr 22, 2021 at 2:21 PM Martin Liška wrote:
>>
>> On 4/22/21 1:19 PM, Richard Biener wrote:
>>> On Thu, Apr 22, 2021 at 11:02 AM Martin Liška wrote:
On 4/22/21 10:04 AM, Richard Biener wrote:
> On Wed, Apr 21, 2021 at 3:08 PM
On Thu, Apr 22, 2021 at 3:50 PM Martin Liška wrote:
>
> Hello.
>
> The patch fixes various typos.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
For the dg-bogus did you check the emitted diagnostic not tested for
doesn't have the same
On Thu, Apr 22, 2021 at 3:52 PM Martin Liška wrote:
>
> Right now, we require a C++11 compiler, so the check is not needed any
> longer.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed once GCC 11.1 is released?
For system.h please keep it
> On Apr 21, 2021, at 5:32 PM, Maciej W. Rozycki wrote:
>
> ...
> OTOH switching to LRA regresses code generation seriously, by making the
> indexed and indirect VAX address modes severely underutilised, so while
> with these changes in place the backend can be switched to LRA with just a
On Wed, 21 Apr 2021, Patrick Palka wrote:
> On Wed, 21 Apr 2021, Jason Merrill wrote:
>
> > On 4/12/21 1:20 PM, Patrick Palka wrote:
> > > Here we're crashing during deduction for a template placeholder from a
> > > dependent initializer because one of the initializer's elements has an
> > >
The test requires an FPU, so use -march=armv7-a+fp -mfpu=auto instead
of -march=armv7-a.
We also remove dg-require-effective-target arm_fp_ok, but keep
dg-add-options arm_fp: this enables the test to pass on arm-eabi
configured with default cpu/fpu/mode.
dg-require-effective-target arm_fp_ok
On 22/04/21 14:42 +0200, Jakub Jelinek wrote:
Hi!
gcc on ia32 miscompiles various atomics involving floating point,
unfortunately I'm afraid it is too late to fix that for 11.1 and
as I'm quite lost on it, it might take a while for 12 too
(disabling all the 8 peephole2s would be easiest, but
On Thu, Apr 22, 2021 at 2:52 PM Richard Biener
wrote:
>
> On Thu, Apr 22, 2021 at 2:22 PM Jakub Jelinek wrote:
> >
> > On Thu, Apr 22, 2021 at 01:23:20PM +0200, Richard Biener via Gcc-patches
> > wrote:
> > > > The question is if the pragma GCC target right now behaves incrementally
> > > > or
On Thu, Apr 22, 2021 at 2:22 PM Jakub Jelinek wrote:
>
> On Thu, Apr 22, 2021 at 01:23:20PM +0200, Richard Biener via Gcc-patches
> wrote:
> > > The question is if the pragma GCC target right now behaves incrementally
> > > or not, whether
> > > #pragma GCC target("avx2")
> > > adds -mavx2 to
On Thu, Apr 22, 2021 at 2:21 PM Martin Liška wrote:
>
> On 4/22/21 1:19 PM, Richard Biener wrote:
> > On Thu, Apr 22, 2021 at 11:02 AM Martin Liška wrote:
> >>
> >> On 4/22/21 10:04 AM, Richard Biener wrote:
> >>> On Wed, Apr 21, 2021 at 3:08 PM Martin Liška wrote:
>
> When
Hi!
gcc on ia32 miscompiles various atomics involving floating point,
unfortunately I'm afraid it is too late to fix that for 11.1 and
as I'm quite lost on it, it might take a while for 12 too
(disabling all the 8 peephole2s would be easiest, but then we'd
run into optimization regressions).
On Thu, Apr 22, 2021 at 01:27:40PM +0100, Jonathan Wakely wrote:
> I'm just finishing testing this on various targets and will push to
> trunk. I'd like to backport it to gcc-11 too, to fix PR100179.
Ok for 11.1.
> commit 50070d8602a07160cece5890899929e9f210244d
> Author: Jonathan Wakely
>
On 21/04/21 15:30 +0100, Jonathan Wakely wrote:
On 21/04/21 13:12 +0100, Jonathan Wakely wrote:
On 21/04/21 12:38 +0100, Jonathan Wakely wrote:
On 20/04/21 22:12 -0700, Thomas Rodgers wrote:
@@ -86,6 +88,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
}
+_GLIBCXX_ALWAYS_INLINE bool
+
Right now, we require a C++11 compiler, so the check is not needed any
longer.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed once GCC 11.1 is released?
Thanks,
Martin
gcc/analyzer/ChangeLog:
* program-state.cc (program_state::operator=):
Hello.
The patch fixes various typos.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
PR testsuite/100159
PR testsuite/100192
gcc/ChangeLog:
* builtins.c (expand_builtin): Fix typos and missing comments.
On Thu, Apr 22, 2021 at 01:23:20PM +0200, Richard Biener via Gcc-patches wrote:
> > The question is if the pragma GCC target right now behaves incrementally
> > or not, whether
> > #pragma GCC target("avx2")
> > adds -mavx2 to options if it was missing before and nothing otherwise, or if
> > it
On 4/22/21 1:19 PM, Richard Biener wrote:
> On Thu, Apr 22, 2021 at 11:02 AM Martin Liška wrote:
>>
>> On 4/22/21 10:04 AM, Richard Biener wrote:
>>> On Wed, Apr 21, 2021 at 3:08 PM Martin Liška wrote:
When -flto=jobserver is used and we cannot detect job server, then we can
still
On Thu, Apr 22, 2021 at 1:58 PM H.J. Lu wrote:
>
> On Thu, Apr 22, 2021 at 4:23 AM Richard Biener
> wrote:
> >
> > On Thu, Apr 22, 2021 at 12:30 PM Jakub Jelinek via Gcc-patches
> > wrote:
> > >
> > > On Wed, Apr 21, 2021 at 06:01:07PM -0700, H.J. Lu via Gcc-patches wrote:
> > > > How about
On Thu, Apr 22, 2021 at 4:23 AM Richard Biener
wrote:
>
> On Thu, Apr 22, 2021 at 12:30 PM Jakub Jelinek via Gcc-patches
> wrote:
> >
> > On Wed, Apr 21, 2021 at 06:01:07PM -0700, H.J. Lu via Gcc-patches wrote:
> > > How about this?
> > >
> > > @item general_regs_only
> > > @cindex
On 12/17/20 5:46 PM, Tom de Vries wrote:
> On 10/15/20 5:05 PM, Tom de Vries wrote:
>> On 10/2/20 3:21 PM, Tom de Vries wrote:
>>> Hi,
>>>
>>> Consider the test-case libgomp.c/pr81778.c added in this commit, with
>>> this core loop (note: CANARY_SIZE set to 0 for simplicity):
>>> ...
>>> int s =
Hi YiFei.
This is OK for both trunk and GCC 10.
Thanks for the fix!
[I see you don't have a copyright transfer contract in place. I believe
this change, and also the patch in 2/2, are small/trivial enough to not
require one, but if you plan to do more contributions in the future we
will
Christophe Lyon via Gcc-patches writes:
> On Wed, 21 Apr 2021 at 14:05, Richard Sandiford via Gcc-patches
> wrote:
>>
>> Alex Coplan writes:
>> > Hi Richard,
>> >
>> > On 15/04/2021 18:45, Richard Sandiford wrote:
>> >> Looks good in general, but like you say, it's GCC 12 material.
>> >
>> >
On Thu, Apr 22, 2021 at 12:30 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Wed, Apr 21, 2021 at 06:01:07PM -0700, H.J. Lu via Gcc-patches wrote:
> > How about this?
> >
> > @item general_regs_only
> > @cindex @code{general_regs_only} function attribute, x86
> > The @code{general_regs_only}
On Thu, Apr 22, 2021 at 11:02 AM Martin Liška wrote:
>
> On 4/22/21 10:04 AM, Richard Biener wrote:
> > On Wed, Apr 21, 2021 at 3:08 PM Martin Liška wrote:
> >>
> >> When -flto=jobserver is used and we cannot detect job server, then we can
> >> still fallbackto -flto=N mode.
> >>
> >> Patch can
Alex Coplan writes:
> Hi,
>
> Here is a backport of my fix for PR99216. The only change w.r.t the
> original patch is a bump of lto-streamer.h:LTO_minor_version.
>
> Bootstrapped and regtested on aarch64-linux-gnu, no issues.
>
> OK for GCC 10 branch?
OK, thanks.
Richard
> As discussed in the
On 4/21/21 7:02 PM, Alexander Monakov wrote:
> On Wed, 21 Apr 2021, Tom de Vries wrote:
>
>>> I don't think implementing futex_wait is possible on nvptx.
>>>
>>
>> Well, I gave it a try, attached below. Can you explain why you think
>> it's not possible, or pinpoint a problem in the
On Thu, Apr 22, 2021 at 12:05 PM Hongtao Liu wrote:
>
> Hi:
> Bootstrapped and regtested on x86-64_iinux-gnu{-m32,}.
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/100093
> * config/i386/i386-options.c (ix86_option_override_internal):
> Clear
Prior to this, a BSS declaration such as:
int foo;
static int bar;
Generates:
.global foo
.local foo
.comm foo,4,4
.local bar
.comm bar,4,4
Creating symbols:
b foo
0004 b bar
Both symbols are local. However, libbpf
Libbpf does not treat paddings after functions well. If function
symbols does not cover a whole text section, it will emit error
similar to:
libbpf: sec '.text': failed to find program symbol at offset 56
Each instruction in BPF is a multiple of 8 bytes, so align the
functions to 8 bytes,
Hi:
Bootstrapped and regtested on x86-64_iinux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR target/100093
* config/i386/i386-options.c (ix86_option_override_internal):
Clear MASK_AVX256_SPLIT_UNALIGNED_LOAD/STORE in x_target_flags
when
On 21/04/21 18:29 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
NOTE - This patch also needs to be backported to gcc-11 in order for
semaphore release() to work correctly on non-futex platforms.
Tested sparc-sun-solaris2.11
For types that track whether or not there extant waiters (e.g.
The test did fail when the virtual memory already had a hard limit !=
unlimited.
Committed as r12-57-gfaf7d413a3f3337be1a3ac5cdf33e0e3b87b426e
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer:
On 4/22/21 10:04 AM, Richard Biener wrote:
> On Wed, Apr 21, 2021 at 3:08 PM Martin Liška wrote:
>>
>> When -flto=jobserver is used and we cannot detect job server, then we can
>> still fallbackto -flto=N mode.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>>
On Wed, Apr 21, 2021 at 06:01:07PM -0700, H.J. Lu via Gcc-patches wrote:
> How about this?
>
> @item general_regs_only
> @cindex @code{general_regs_only} function attribute, x86
> The @code{general_regs_only} function attribute informs the compiler
> that the function uses only general purpose
There's an updated version of the patch, Jonathan noticed correctly
the comment related to assert was not correct.
Martin
>From e035fd0549ea17ab4f8d71488f577fd1e4077fd9 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 12 Mar 2021 14:32:07 +0100
Subject: [PATCH] Use STATIC_ASSERT for
On Thu, 22 Apr 2021, 08:47 Martin Liška, wrote:
> On 4/21/21 6:11 PM, Martin Sebor wrote:
> > On 4/21/21 2:15 AM, Martin Liška wrote:
> >> Hello.
> >>
> >> It's addressing the following Clang warning:
> >> cp/lex.c:170:45: warning: result of comparison of constant 64 with
> expression of type
On Thu, Apr 22, 2021 at 4:29 AM Thomas Rodgers
wrote:
>
> From: Thomas Rodgers
>
> NOTE - This patch also needs to be backported to gcc-11 in order for
> semaphore release() to work correctly on non-futex platforms.
>
> Tested sparc-sun-solaris2.11
>
> For types that track whether or not there
On Thu, Apr 22, 2021 at 3:01 AM H.J. Lu wrote:
>
> On Wed, Apr 21, 2021 at 4:24 PM Martin Sebor wrote:
> >
> > On 4/21/21 2:58 PM, H.J. Lu wrote:
> > > On Wed, Apr 21, 2021 at 10:09 AM Martin Sebor wrote:
> > >>
> > >> On 4/14/21 4:39 PM, H.J. Lu wrote:
> > >>> commit
On Thu, Apr 22, 2021 at 1:22 AM Maciej W. Rozycki wrote:
>
> Hi,
>
> According to the plan discussed in the context of the recent switch to
> MODE_CC of the VAX backend I have been looking into switching the backend
> to LRA as well.
>
> It has turned out quite straightforward itself, with just
On Wed, Apr 21, 2021 at 3:08 PM Martin Liška wrote:
>
> When -flto=jobserver is used and we cannot detect job server, then we can
> still fallbackto -flto=N mode.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
I think this behavior needs to
On Wed, 21 Apr 2021, Tobias Burnus wrote:
> This was brought up by Richard when testing libgomp with the GCC 11
> distribution
> compiler, which has both nvptx and gcn enabled – but no offloading device was
> available.
>
> This lead to fails for:
> *
On 4/21/21 6:11 PM, Martin Sebor wrote:
> On 4/21/21 2:15 AM, Martin Liška wrote:
>> Hello.
>>
>> It's addressing the following Clang warning:
>> cp/lex.c:170:45: warning: result of comparison of constant 64 with
>> expression of type 'enum ovl_op_code' is always true
>>
On Wed, 21 Apr 2021 at 14:05, Richard Sandiford via Gcc-patches
wrote:
>
> Alex Coplan writes:
> > Hi Richard,
> >
> > On 15/04/2021 18:45, Richard Sandiford wrote:
> >> Looks good in general, but like you say, it's GCC 12 material.
> >
> > Thanks for the review. The attached patch addresses
On 4/21/21 10:16 PM, Jakub Jelinek wrote:
> On Wed, Apr 21, 2021 at 08:53:54PM +0100, Jonathan Wakely wrote:
What would be IMHO a good idea would be to use configure test for
#include
int t = std::thread::hardware_concurrency ();
and in that case use that as a fallback to the
> Anyway, that's why we have a C++ ISO standard and so
> std::thread::hardware_concurrency function implementation can (and likely
> should) handle all this. Or?
This is a compiler though, i.e. quite low level in the software stack, so the
implementation must be conservative and thus fancy C++
On 4/21/21 9:53 PM, Jonathan Wakely wrote:
> On Wed, 21 Apr 2021 at 20:41, Martin Liška wrote:
>>
>> On 4/21/21 9:15 PM, Jakub Jelinek wrote:
>>> On Wed, Apr 21, 2021 at 08:28:55PM +0200, Jakub Jelinek via Gcc-patches
>>> wrote:
> There's a patch attempt for the problem with
>
> This patch broke bootstrap on AIX.
>
> std::thread is not provided in all instances. GCC is not compiled
> multi-threaded by default.
Right, this will very likely break on Windows too.
--
Eric Botcazou
arm.h has had this error message since 1997, and was never updated to
take softfp into account. Anyway, it seems it was useful long ago, but
it is no longer needed since option parsing has been improved:
-mfloat-abi is handled via arm.opt and updates the var_float_abi
variable. So, the last
On Thu, 22 Apr 2021, Bernd Edlinger wrote:
> Aehm,
>
> forgot to mention,
>
> tested on arm-none-eabi (arm-sim target)
> is it OK for trunk?
OK next week (when RC2 looks good).
Thanks,
Richard.
>
> Thanks
> Bernd.
>
> On 4/22/21 8:37 AM, Bernd Edlinger wrote:
> > As the test case shows,
Aehm,
forgot to mention,
tested on arm-none-eabi (arm-sim target)
is it OK for trunk?
Thanks
Bernd.
On 4/22/21 8:37 AM, Bernd Edlinger wrote:
> As the test case shows, the outer mode may have a higher alignment
> requirement than the inner mode here.
>
> 2021-04-22 Bernd Edlinger
>
>
As the test case shows, the outer mode may have a higher alignment
requirement than the inner mode here.
2021-04-22 Bernd Edlinger
PR target/100106
* gimplify-rtx.c (simplify_context::simplify_subreg): Check the
memory alignment for the outer mode.
*
90 matches
Mail list logo
