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, the
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.
* gcc.c-tort
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
> > empty TREE_TYPE, something which resolve_args and later uni
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
empty TREE_TYPE, something which resolve_args and later unify_one_argument
don't expect. And if the deduction fro
On 2021-04-21 14:22, Jakub Jelinek wrote:
On Wed, Apr 21, 2021 at 07:23:30PM +0100, Jonathan Wakely via
Gcc-patches wrote:
We should do this for gcc-11 too if an RM approves it, since acquire()
is currently broken.
Ok, but please commit it soon, we'll need to do a RC2 tomorrow or on
Friday
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.
semaphore) internally, the __atomic_notify_address_
On 4/21/21 1:30 PM, Marek Polacek wrote:
On Tue, Apr 20, 2021 at 10:40:52PM -0400, Jason Merrill wrote:
On 4/20/21 8:42 PM, Marek Polacek wrote:
Recently, we made sure that we never call value_dependent_expression_p
on an expression that isn't potential_constant_expression. That caused
this bo
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 87c753ac241f25d222d46ba1ac66ceba89d6a200
> >>> Author: H.J. Lu
> >>> Date: Fri Aug 21 09
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 87c753ac241f25d222d46ba1ac66ceba89d6a200
Author: H.J. Lu
Date: Fri Aug 21 09:42:49 2020 -0700
x86: Add target("general-regs-only") function attribute
is
Changes in this version from Version 10:
(thanks to Joseph Myers for catching these issues)
In gcc/c-family/c-cppbuiltin.c
Fixed three cases where XALLOCAVEC argument contained ...LIBGCC_...
but should have contained ...LIBGCC__...
These off by one errors managed to not fail previously due to the
Fix regressions:
FAIL: gcc.c-torture/execute/20090113-2.c -O1 (internal compiler error)
FAIL: gcc.c-torture/execute/20090113-2.c -O1 (test for excess errors)
FAIL: gcc.c-torture/execute/20090113-3.c -O1 (internal compiler error)
FAIL: gcc.c-torture/execute/20090113-3.c -O1 (test for ex
The insn has extraneous operand #3 that is aliased in RTL to operand #0
with a constraint. The operands specify a single-bit field in memory
that the machine instruction produced boths reads for the purpose of
determining whether to branch or not and either clears or sets according
to the mach
This function has never been used and it is unclear what its intended
purpose was.
gcc/
* config/vax/vax-protos.h (adjacent_operands_p): Remove
prototype.
* config/vax/vax.c (adjacent_operands_p): Remove.
---
gcc/config/vax/vax-protos.h |1
gcc/config/vax/va
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 a couple of
minor issues triggered with a flip to LRA, one causing a b
On Wed, Apr 21, 2021 at 07:23:30PM +0100, Jonathan Wakely via Gcc-patches wrote:
> We should do this for gcc-11 too if an RM approves it, since acquire()
> is currently broken.
Ok, but please commit it soon, we'll need to do a RC2 tomorrow or on Friday
and then ideally no changes at all.
Contrary to gcc/testsuite/*/gomp/, using omp_lib in libgomp is possible
and should be done – which is the proper way.
Committed as r12-52-g0c0bdcc60cfa0e87b3b9abc1460a7073b199d38a
Tobias
PS: omp_depend_kind = 2*c_intptr_t, which nowadays usually is 16,
but on 32bit systems it is usually 8.
It d
On Wed, Apr 21, 2021 at 10:09 AM Martin Sebor wrote:
>
> On 4/14/21 4:39 PM, H.J. Lu wrote:
> > commit 87c753ac241f25d222d46ba1ac66ceba89d6a200
> > Author: H.J. Lu
> > Date: Fri Aug 21 09:42:49 2020 -0700
> >
> > x86: Add target("general-regs-only") function attribute
> >
> > is incomplete
The acle/saturation.c test uses __[su]sat() and
__saturation_occurred() intrinsics but __[su]sat() are defined in
acle.h if __ARM_FEATURE_SAT true, while __saturation_occurred()
depends on __ARM_FEATURE_QBIT.
QBIT is a v5te feature, while SAT is available since v6, so the test
really needs __ARM_F
Martin Liska wrote:
gcc/config/darwin-c.c | 9 +-
gcc/config/darwin.c | 141 +
The darwin changes are OK, looks like a nice cleanup,
thanks
Iain
On 2021-04-21 11:23, Jonathan Wakely wrote:
On 21/04/21 10:10 -0700, Thomas Rodgers wrote:
[...snip...]
Please commit your patch to trunk, since that's what you had in your
original patch before I asked you to change it (causing the bug).
We should do this for gcc-11 too if an RM approves i
> On Mar 19, 2021, at 5:21 AM, Martin Liska wrote:
>
>
> gcc/ChangeLog:
>
> ...
> * config/pdp11/pdp11.c (pdp11_output_ident): Likewise.
pdp11 is ok. Thanks.
paul
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 previous implementation,
> > > that will
Martin Liška wrote:
On 4/21/21 9:50 PM, Iain Sandoe wrote:
If you could take a quick look it would be appreciated - I don’t have
much state
for the patch you applied.
The patch looks correct to me.
thanks!
Iain
On Wed, Apr 21, 2021 at 3:42 PM Martin Liška wrote:
>
> On 4/21/21 6:03 PM, David Edelsohn via Gcc-patches wrote:
> > I am requesting a freeze on non-bug fix patches to trunk.
> >
> > In the GCC 12 announcement, Jakub stated:
> >
> > "The trunk has branched for the GCC 11 release and is now open
>
> "Jakub" == Jakub Jelinek via Gcc-patches writes:
Jakub> What would be IMHO a good idea would be to use configure test for
Jakub> #include
Jakub> int t = std::thread::hardware_concurrency ();
Jakub> and in that case use that as a fallback to the previous implementation,
Jakub> that will be
On 4/21/21 9:50 PM, Iain Sandoe wrote:
> Hi,
>
> @Martin
Hello.
Sorry for the troubles I caused.
> I am not sure from the commit messages for this series whether my change
> below is complete (it is enough to make bootstrap succeed so I have
> applied it anyway).
>
> you mention TARGET_* but t
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
> >>> std::thread::hardware_concurrency where
> >>> it's used o
Hi,
@Martin
I am not sure from the commit messages for this series whether my change
below is complete (it is enough to make bootstrap succeed so I have
applied it anyway).
you mention TARGET_* but that is too general - however i386/darwin.h does
have some other ISA-specific TARGET_* settings (m
On 4/21/21 6:03 PM, David Edelsohn via Gcc-patches wrote:
> I am requesting a freeze on non-bug fix patches to trunk.
>
> In the GCC 12 announcement, Jakub stated:
>
> "The trunk has branched for the GCC 11 release and is now open
> again for general development, stage 1. Please consider not
> d
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
>>> std::thread::hardware_concurrency where
>>> it's used only if _GLIBCXX_HAS_GTHREADS is set.
>>>
>>> Does it help?
>>> Thank
On Wed, Apr 21, 2021 at 03:25:26PM -0400, David Edelsohn 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 previous implementation,
> > that will be strictly
On Wed, Apr 21, 2021 at 3:16 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
> > > std::thread::hardware_concurrency where
> > > it's used only if _GLIBCXX_HAS_GTHREADS is set.
> > >
> >
On 4/21/21 8:27 PM, Jakub Jelinek wrote:
> On Wed, Apr 21, 2021 at 08:06:26PM +0200, Martin Liška wrote:
>> On 4/21/21 7:56 PM, Jakub Jelinek wrote:
>>> On Wed, Apr 21, 2021 at 11:50:02AM -0400, David Edelsohn via Gcc-patches
>>> wrote:
This patch broke bootstrap on AIX.
std::thread
On Mon, 12 Apr 2021, 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
> empty TREE_TYPE, something which resolve_args and later unify_one_argument
> don't expect. And if the deduc
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
> > std::thread::hardware_concurrency where
> > it's used only if _GLIBCXX_HAS_GTHREADS is set.
> >
> > Does it help?
> > Thanks,
> > Martin
> >
> > gcc/ChangeLog:
> >
On Wed, Apr 21, 2021 at 08:28:56PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 21, 2021 at 08:04:18PM +0200, Martin Liška wrote:
> > Hello.
> >
> > There's a patch attempt for the problem with
> > std::thread::hardware_concurrency where
> > it's used only if _GLIBCXX_HAS_GTHREADS is set.
> >
> > D
David Edelsohn via Gcc-patches wrote:
I am requesting a freeze on non-bug fix patches to trunk.
In the GCC 12 announcement, Jakub stated:
"The trunk has branched for the GCC 11 release and is now open
again for general development, stage 1. Please consider not
disrupting it too much during t
On Wed, Apr 21, 2021 at 08:06:26PM +0200, Martin Liška wrote:
> On 4/21/21 7:56 PM, Jakub Jelinek wrote:
> > On Wed, Apr 21, 2021 at 11:50:02AM -0400, David Edelsohn via Gcc-patches
> > wrote:
> >> This patch broke bootstrap on AIX.
> >>
> >> std::thread is not provided in all instances. GCC is n
On Wed, Apr 21, 2021 at 08:04:18PM +0200, Martin Liška wrote:
> Hello.
>
> There's a patch attempt for the problem with
> std::thread::hardware_concurrency where
> it's used only if _GLIBCXX_HAS_GTHREADS is set.
>
> Does it help?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> PR bootstrap/100
On 21/04/21 10:10 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
A change was made to __atomic_semaphore::_S_do_try_acquire() to
(ideally) let the compare_exchange reload the value of __old rather than
always reloading it twice. This causes _M_acquire to spin indefinitely
if the value of __o
On Wed, 21 Apr 2021, Richard Sandiford wrote:
> which AFAICT would test preprocessing for the host rather than the target.
Ah, good point. (GCC_GLIBC_VERSION_GTE_IFELSE can be used to deal with
glibc version conditionals in a way that works, given appropriate
configure options, even when the t
Joseph Myers writes:
> On Wed, 21 Apr 2021, Andreas Schwab wrote:
>
>> On Apr 21 2021, Richard Sandiford via Gcc-patches wrote:
>>
>> > However, AArch64 postdates glibc and binutils support for
>> > .init/fini_array by some distance, so it's safe to hard-code the
>> > result to "yes" for cross co
On 4/21/21 7:56 PM, Jakub Jelinek wrote:
> On Wed, Apr 21, 2021 at 11:50:02AM -0400, David Edelsohn via Gcc-patches
> wrote:
>> This patch broke bootstrap on AIX.
>>
>> std::thread is not provided in all instances. GCC is not compiled
>> multi-threaded by default.
>>
>> error: `std::thread' has n
Hello.
There's a patch attempt for the problem with std::thread::hardware_concurrency
where
it's used only if _GLIBCXX_HAS_GTHREADS is set.
Does it help?
Thanks,
Martin
gcc/ChangeLog:
PR bootstrap/100186
* lto-wrapper.c: Use hardware_concurrency only if
_GLIBCXX_HAS_GTH
On Wed, 21 Apr 2021, Andreas Schwab wrote:
> On Apr 21 2021, Richard Sandiford via Gcc-patches wrote:
>
> > However, AArch64 postdates glibc and binutils support for
> > .init/fini_array by some distance, so it's safe to hard-code the
> > result to "yes" for cross compilers.
>
> Should there be
On Wed, Apr 21, 2021 at 11:50:02AM -0400, David Edelsohn via Gcc-patches wrote:
> This patch broke bootstrap on AIX.
>
> std::thread is not provided in all instances. GCC is not compiled
> multi-threaded by default.
>
> error: `std::thread' has not been declared.
In addition to that, I'm not re
On Linux/x86_64,
a61c4964cd71446232d62ec9b10a7d45b440dd9f is the first bad commit
commit a61c4964cd71446232d62ec9b10a7d45b440dd9f
Author: Tobias Burnus
Date: Wed Apr 21 10:58:29 2021 +0200
Fortran/OpenMP: Add 'omp depobj' and 'depend(mutexinoutset:'
caused
FAIL: libgomp.fortran/depobj-1.
On Wed, Apr 21, 2021 at 07:04:17PM +0200, Tobias Burnus wrote:
> OK for mainline and GCC 11?
Ok for 12 and 11.2 (i.e. after 11.1 GA).
> libgomp/testsuite: Fix checks for dg-excess-errors
>
> For the tests modified below, the effective target line has to be effective
> when compiling for an offlo
On Tue, Apr 20, 2021 at 10:40:52PM -0400, Jason Merrill wrote:
> On 4/20/21 8:42 PM, Marek Polacek wrote:
> > Recently, we made sure that we never call value_dependent_expression_p
> > on an expression that isn't potential_constant_expression. That caused
> > this bogus warning with a non-type tem
From: Thomas Rodgers
A change was made to __atomic_semaphore::_S_do_try_acquire() to
(ideally) let the compare_exchange reload the value of __old rather than
always reloading it twice. This causes _M_acquire to spin indefinitely
if the value of __old is already 0.
libstdc++/ChangeLog:
*
On 4/14/21 4:39 PM, H.J. Lu wrote:
commit 87c753ac241f25d222d46ba1ac66ceba89d6a200
Author: H.J. Lu
Date: Fri Aug 21 09:42:49 2020 -0700
x86: Add target("general-regs-only") function attribute
is incomplete since it is impossible to call integer intrinsics from
a function with general-re
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:
* testsuite/libgomp.c-c++-common/function-not-offloaded.c:
→ function (on purpose) not marked for off
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 implementation?
Responding only to this for now. When I said f
On 4/21/21 1:30 AM, Uros Bizjak wrote:
On Thu, Apr 15, 2021 at 12:39 AM H.J. Lu wrote:
commit 87c753ac241f25d222d46ba1ac66ceba89d6a200
Author: H.J. Lu
Date: Fri Aug 21 09:42:49 2020 -0700
x86: Add target("general-regs-only") function attribute
is incomplete since it is impossible to
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
[-Wtautological-constant-out-of-range-compare]
Patch can bootstrap on x86_64-linu
On 4/20/21 6:11 PM, Alexander Monakov wrote:
> Hello Tom,
>
> Thank you for the investigation and the detailed writeup. It was difficult for
> me to infer the internal API contracts here (and still is),
Hi Alexander,
thanks for the review.
Yep, same here.
> sorry about the
> mistake.
>
> Most
I am requesting a freeze on non-bug fix patches to trunk.
In the GCC 12 announcement, Jakub stated:
"The trunk has branched for the GCC 11 release and is now open
again for general development, stage 1. Please consider not
disrupting it too much during the RC phase of GCC 11 so it
is possible to
On 03/04/21 14:56 -0400, Philippe Blain wrote:
In order for GDB to auto-load the pretty printers, they must be installed
as "libstdc++.$ext-gdb.py", where 'libstdc++.$ext' is the name of the
object file that is loaded by GDB [1], i.e. the libstdc++ shared library.
The approach taken in libstdc++
This patch broke bootstrap on AIX.
std::thread is not provided in all instances. GCC is not compiled
multi-threaded by default.
error: `std::thread' has not been declared.
Thanks, David
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?
Thanks,
Alex
---
As discussed in the PR, we currently have two different numb
On 4/21/2021 1:28 AM, Martin Liška wrote:
Hi.
The sanity check calls toplev.finalize () in order to simulate JIT mode
in normal compilation mode.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
PR jit/98615
On 4/21/2021 5:50 AM, 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?
Thanks,
Martin
gcc/ChangeLog:
* lto-wrappe
On 4/21/2021 6:56 AM, Richard Biener wrote:
libatomic isn't built for amdgcn but reduction-16.c adds it
via -foffload=-latomic when offloading for nvptx is enabled.
The following avoids linker errors when offloading to amdgcn is enabled
as well.
Tested on x86_64-unknown-linux-gnu, OK for trunk
On Wed, Apr 21, 2021 at 12:52:39PM +0200, Jakub Jelinek wrote:
> Hi!
>
> In --enable-checking=release builds (which is the default on release
> branches), I'm getting various extra FAILs that don't appear in
> --enable-checking=yes builds.
>
> XPASS: g++.dg/cpp0x/constexpr-52830.C -std=c++14 (in
This fixes:
lto-plugin.c:642:7: warning: adding 'int' to a string does not append to the
string [-Wstring-plus-int]
Pushed as obvious,
thanks,
Martin
lto-plugin/ChangeLog:
* lto-plugin.c (exec_lto_wrapper): Make a temp variable.
---
lto-plugin/lto-plugin.c | 6 +++---
1 file changed,
On Apr 21 2021, Richard Sandiford via Gcc-patches wrote:
> However, AArch64 postdates glibc and binutils support for
> .init/fini_array by some distance, so it's safe to hard-code the
> result to "yes" for cross compilers.
Should there be an automatism for any other new architecture added?
Andre
I was wondering why the (now fixed) c-c++-common/attr-retain-[78].c
failures were showing up in the native results for aarch64-linux-gnu
but not in the posted cross results. It turns out that .init/
.fini_array support is disabled by default for cross builds,
which in turn stops those tests from r
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
+_M_try_acquire() noexcept
+{
+ for (;;
Hi, Jonathan
Thanks for the further investigation. I definitely encountered the
missing _M_try_acquire in __platform_semaphore.
Thanks, David
On Wed, Apr 21, 2021 at 8:12 AM Jonathan Wakely wrote:
>
> On 21/04/21 12:38 +0100, Jonathan Wakely wrote:
> >On 20/04/21 22:12 -0700, Thomas Rodgers wr
On 4/21/21 3:34 PM, H.J. Lu wrote:
> On Wed, Apr 21, 2021 at 3:58 AM Uros Bizjak wrote:
>>
>> On Wed, Apr 21, 2021 at 10:28 AM Martin Liska wrote:
>>>
>>>
>>> gcc/ChangeLog:
>>>
>>> * config/i386/i386-options.c (TARGET_EXPLICIT_NO_SAHF_P):
>>> Define.
>>> (SET_TARGET_NO_SA
On 2021-04-21 05:12, 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
+_M_try_acquire() noexcept
+{
+ for (;;)
+{
+
On 4/21/21 3:03 PM, Richard Biener wrote:
> On Wed, Apr 21, 2021 at 2:09 PM Uros Bizjak via Gcc-patches
> wrote:
>>
>> On Wed, Apr 21, 2021 at 10:28 AM Martin Liska wrote:
>>>
>>>
>>> gcc/ChangeLog:
>>>
>>> * config/i386/i386.h (PTA_*): Remove.
>>> (enum pta_flag): New.
>>>
On Wed, Apr 21, 2021 at 12:30 AM Uros Bizjak wrote:
>
> On Thu, Apr 15, 2021 at 12:39 AM H.J. Lu wrote:
> >
> > commit 87c753ac241f25d222d46ba1ac66ceba89d6a200
> > Author: H.J. Lu
> > Date: Fri Aug 21 09:42:49 2020 -0700
> >
> > x86: Add target("general-regs-only") function attribute
> >
>
commit 87c753ac241f25d222d46ba1ac66ceba89d6a200
Author: H.J. Lu
Date: Fri Aug 21 09:42:49 2020 -0700
x86: Add target("general-regs-only") function attribute
is incomplete since it is impossible to call integer intrinsics from
a function with general-regs-only target attribute.
1. Add gene
Move OPTION_MASK_* to i386-common.h so that they can be used in x86
backend.
* common/config/i386/i386-common.c (OPTION_MASK_*): Move to ...
* common/config/i386/i386-common.h: Here. New file.
* config/i386/i386.h: Include common/config/i386/i386-common.h.
---
gcc/common/
Add general_regs_only attribute to MWAIT intrinsics for callers with
general-regs-only target attribute.
gcc/
PR target/9974
* config/i386/mwaitintrin.h (_mm_monitor): Add general_regs_only
attribute.
(_mm_mwait): Likewise.
gcc/testsuite/
PR target/9974
I realized that
commit 87c753ac241f25d222d46ba1ac66ceba89d6a200
Author: H.J. Lu
Date: Fri Aug 21 09:42:49 2020 -0700
x86: Add target("general-regs-only") function attribute
is incomplete since it is impossible to call integer intrinsics from
a function with general-regs-only target attrib
On Wed, Apr 21, 2021 at 3:58 AM Uros Bizjak wrote:
>
> On Wed, Apr 21, 2021 at 10:28 AM Martin Liska wrote:
> >
> >
> > gcc/ChangeLog:
> >
> > * config/i386/i386-options.c (TARGET_EXPLICIT_NO_SAHF_P):
> > Define.
> > (SET_TARGET_NO_SAHF): Likewise.
> > (TARGET_EXPL
On Wed, Apr 21, 2021 at 2:10 PM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> In --enable-checking=release builds (which is the default on release
> branches), I'm getting various extra FAILs that don't appear in
> --enable-checking=yes builds.
>
> XPASS: g++.dg/cpp0x/constexpr-52830.C -std=c+
On Wed, Apr 21, 2021 at 2:09 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Wed, Apr 21, 2021 at 10:28 AM Martin Liska wrote:
> >
> >
> > gcc/ChangeLog:
> >
> > * config/i386/i386.h (PTA_*): Remove.
> > (enum pta_flag): New.
> > (DEF_PTA): Generate PTA_* values from i386.def
On 4/21/2021 2:08 AM, Martin Liška wrote:
Having c++11, we can now use a handy function called
std::thread::hardware_concurrency.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* lto-wrapper.c (cpuset_popc
On 4/21/2021 2:18 AM, Martin Liška wrote:
Hello.
The patch silents Clang warnings:
1) if (TARGET_MACHO
) ...
#if TARGET_MACHO
can be replaced with #if TARGET_MACHO
2) add_AT_vms_delta is used only if VMS_DEBUGGING_INFO is defined
3) tree.c:13454:16: warning: result of comparison of constan
libatomic isn't built for amdgcn but reduction-16.c adds it
via -foffload=-latomic when offloading for nvptx is enabled.
The following avoids linker errors when offloading to amdgcn is enabled
as well.
Tested on x86_64-unknown-linux-gnu, OK for trunk and GCC 11 branch?
Thanks.
Richard.
2021-04-2
On 4/21/2021 4:52 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
In --enable-checking=release builds (which is the default on release
branches), I'm getting various extra FAILs that don't appear in
--enable-checking=yes builds.
XPASS: g++.dg/cpp0x/constexpr-52830.C -std=c++14 (internal compile
Victor Do Nascimento via Gcc-patches writes:
> The backend pattern for storing a pair of identical values in 32 and 64-bit
> modes with the machine instruction STP was missing, and multiple instructions
> were needed to reproduce this behavior as a result of failed RTL pattern
> match in combin
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
+_M_try_acquire() noexcept
+{
+ for (;;)
+ {
+ auto __err = sem_trywait(&
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 these comments and
> bootstraps/regtests OK on aarch64-linux-gnu. OK for trunk?
OK, thanks.
On Wed, Apr 21, 2021 at 01:01:44PM +0100, Jonathan Wakely via Gcc-patches wrote:
> libstdc++-v3/ChangeLog:
>
> * include/std/latch: Replace tab characters in license text.
> * include/std/semaphore: Likewise.
>
> Tested x86_64-linux. Committed to trunk.
>
> OK for gcc-11 too?
Yes.
libstdc++-v3/ChangeLog:
* include/std/latch: Replace tab characters in license text.
* include/std/semaphore: Likewise.
Tested x86_64-linux. Committed to trunk.
OK for gcc-11 too?
commit 88202c883c07da1c03dbb1ad440f1b70189c4399
Author: Jonathan Wakely
Date: Wed Apr 21 12:59:
On Tue, 20 Apr 2021, Xionghu Luo wrote:
>
>
> On 2021/4/15 19:34, Richard Biener wrote:
> > On Thu, 15 Apr 2021, Xionghu Luo wrote:
> >
> >> Thanks,
> >>
> >> On 2021/4/14 14:41, Richard Biener wrote:
> "#538,#235,#234,#233" will all be sunk from bb 35 to bb 37 by rtl-sink,
> but it m
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?
Thanks,
Martin
gcc/ChangeLog:
* lto-wrapper.c (run_gcc): When -flto=jobserver is used, b
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 these comments and
bootstraps/regtests OK on aarch64-linux-gnu. OK for trunk?
Thanks,
Alex
>
> Alex Coplan writes:
> >
On 20/04/21 22:12 -0700, Thomas Rodgers wrote:
@@ -86,6 +88,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
}
+_GLIBCXX_ALWAYS_INLINE bool
+_M_try_acquire() noexcept
+{
+ for (;;)
+ {
+ auto __err = sem_trywait(&_M_semaphore);
+ if (__err && (errno ==
On 4/21/21 1:26 PM, Martin Liška wrote:
> On 4/21/21 12:56 PM, Jakub Jelinek wrote:
>> On Wed, Apr 21, 2021 at 12:52:42PM +0200, Martin Liška wrote:
>>> On 4/21/21 11:04 AM, Jakub Jelinek wrote:
Wouldn't it be better to be consistent with tree-pretty-print.c on this
or perhaps just call d
On 4/21/21 12:56 PM, Jakub Jelinek wrote:
> On Wed, Apr 21, 2021 at 12:52:42PM +0200, Martin Liška wrote:
>> On 4/21/21 11:04 AM, Jakub Jelinek wrote:
>>> Wouldn't it be better to be consistent with tree-pretty-print.c on this
>>> or perhaps just call dump_generic_node or whatever is used to dump
>
On Tue, Apr 20, 2021 at 05:55:46PM +0200, Andreas Schwab wrote:
> On Nov 13 2020, Nikhil Benesch via Gcc-patches wrote:
>
> > +static void
> > +demangle_const_char (struct rust_demangler *rdm)
> > +{
> > + size_t hex_len;
> > + uint64_t value;
> > +
> > + hex_len = parse_hex_nibbles (rdm, &valu
On Wed, Apr 21, 2021 at 10:28 AM Martin Liska wrote:
>
>
> gcc/ChangeLog:
>
> * config/i386/i386-options.c (TARGET_EXPLICIT_NO_SAHF_P):
> Define.
> (SET_TARGET_NO_SAHF): Likewise.
> (TARGET_EXPLICIT_PREFETCH_SSE_P): Likewise.
> (SET_TARGET_PREFETCH_SSE): Lik
On Wed, Apr 21, 2021 at 12:52:42PM +0200, Martin Liška wrote:
> On 4/21/21 11:04 AM, Jakub Jelinek wrote:
> > Wouldn't it be better to be consistent with tree-pretty-print.c on this
> > or perhaps just call dump_generic_node or whatever is used to dump
> > those e.g. for C?
>
> Yes, I'm going to i
On Wed, Apr 21, 2021 at 10:28 AM Martin Liska wrote:
>
>
> gcc/ChangeLog:
>
> * config/i386/i386-expand.c (decide_alignment): Use newly named
> macro TARGET_CPU_P.
> * config/i386/i386.c (ix86_decompose_address): Likewise.
> (ix86_address_cost): Likewise.
>
1 - 100 of 146 matches
Mail list logo
