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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
>
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?
>>>
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
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.
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
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.
> >
> >
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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.
>
>
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
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
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
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
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:
*
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
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
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?
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
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
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.
>>>
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
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.
---
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
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.
> >
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
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
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
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
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.
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
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
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 =
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,
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
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
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,
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
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, );
>
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):
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
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.
>
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 compiler error)
FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++14
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 install patch that does:
+ if (DECL_NAME (t))
+
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.
> * wide-int-bitmask.h (WIDE_INT_BITMASK_FROM_NTH): New macro.
> *
1 - 100 of 143 matches
Mail list logo
