On 4/16/21 3:59 PM, Robin Dapp wrote:
> Hi,
>
> checking for an osc break is somewhat brittle especially with many
> passes potentially introducing new insns and moving them around.
> Therefore, only run the test with -O1 -fschedule-insns in order to limit
> the influence of other passes.
Yeah, t
Depending on whether GCC is configured using --with-mode=zarch or not,
for the 31bit target instructions are generated either for ESA or
z/Architecture. For the sake of simplicity and robustness test only for
the latter by adding manually option -mzarch.
gcc/testsuite/ChangeLog:
* gcc.ta
On 4/20/21 9:17 AM, Stefan Schulze Frielinghaus wrote:
> Depending on whether GCC is configured using --with-mode=zarch or not,
> for the 31bit target instructions are generated either for ESA or
> z/Architecture. For the sake of simplicity and robustness test only for
> the latter by adding manua
On IBM Z the aliasing stores are realized through one element vector
instructions, if no cost model for vectorization is used which is the
default according to vect.exp. Fixed by changing the number of times
the pattern must be found in the dump.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/bb
Hi Tobias,
Thanks. Commit r11-8255-g67378cd63d62bf0c69e966d1d202a1e586550a68.
By the way, I did check that there were no problems with pdt_26.f03
reported by valgrind, given the decrease in the malloc count.
Cheers
Paul
On Mon, 19 Apr 2021 at 14:08, Tobias Burnus wrote:
> Hi Paul,
>
> On 19
Pushed as obvious to master (and releases/gcc-11 branch).
Martin
gcc/ChangeLog:
* doc/invoke.texi: Document new param.
---
gcc/doc/invoke.texi | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8b70fdf580d..a1b50406048 100644
--- a/gc
> -Original Message-
> From: Richard Sandiford
> Sent: 19 April 2021 20:34
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Kyrylo Tkachov
>
> Subject: [PATCH] Adjust guality xfails for aarch64*-*-*
>
> This patch gives clean guality.exp test results for aarch64-linux-gnu
> with
On 19/04/21 12:23 -0700, Thomas Rodgers wrote:
namespace __detail
{
-using __platform_wait_t = int;
-
-constexpr auto __atomic_spin_count_1 = 16;
-constexpr auto __atomic_spin_count_2 = 12;
-
-template
- inline constexpr bool __platform_wait_uses_type
#ifdef _GLIBCXX_HAVE
FWIW, I agree with Martin. Source files with lots of tests make
finding things difficult. For example, value-range.cc has 400 lines
of tests (which I wrote ;-)). Even though these tests have proven
invaluable in finding bugs, they make navigating the source file
cumbersome.
Aldy
On Tue, Apr 20
Pushed after Jakub's confirmation. We do not coordinate major release with FSF.
Martin
---
htdocs/releasing.html | 3 ---
1 file changed, 3 deletions(-)
diff --git a/htdocs/releasing.html b/htdocs/releasing.html
index d51d6fc7..cb7bb5fe 100644
--- a/htdocs/releasing.html
+++ b/htdocs/releasing.
Pushed as obvious to master.
Martin
gcc/ada/ChangeLog:
* gnatvsn.ads: Bump Library_Version to 12.
---
gcc/ada/gnatvsn.ads | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/ada/gnatvsn.ads b/gcc/ada/gnatvsn.ads
index bbfa9f58d76..c0a77bc8c59 100644
--- a/gcc/ada/gna
It seems we bumped LTO_major_version last time 2 years ago.
Right now, the following is seen when one links a GCC 10.2.x LTO object file:
$ gcc a.o
lto1: fatal error: bytecode stream in file ‘a.o’ generated with LTO version 9.2
instead of the expected 9.0
I suggest bumping LTO_major_version fo
Hi Paul,
is there a reason why you did not apply the patch to mainline ('master')
but only to GCC 11 ('releases/gcc-11')?
While GCC 11 is okay, I had expected it to be (only) on mainline!
Tobias
On 20.04.21 10:55, Paul Richard Thomas wrote:
Hi Tobias,
Thanks. Commit r11-8255-g67378cd63d62bf0
On Tue, Apr 20, 2021 at 11:58:32AM +0200, Tobias Burnus wrote:
> is there a reason why you did not apply the patch to mainline ('master')
> but only to GCC 11 ('releases/gcc-11')?
>
> While GCC 11 is okay, I had expected it to be (only) on mainline!
r11-8255 is before the branchpoint, so is both
Answer: Because my 'git pull' somehow got stuck – and showed an old trunk.
Your patch just went in before the merge – thus it was on mainline GCC
11 and is now
on mainline GCC 12 + GCC 11 branch ...
Sorry for the confusion.
Tobias
On 20.04.21 11:58, Tobias Burnus wrote:
Hi Paul,
is there a r
On 19/04/21 22:25 -0400, Patrick Palka via Libstdc++ wrote:
This implements the wording changes of P2259R1 "Repairing input range
adaptors and counted_iterator", which resolves LWG 3283, 3289 and 3408.
The wording changes are relatively straightforward, but they require
some boilerplate to imple
On 19/04/21 22:25 -0400, Patrick Palka via Libstdc++ wrote:
This implements the wording changes of P2259R1 "Repairing input range
adaptors and counted_iterator", which resolves LWG 3283, 3289 and 3408.
The wording changes are relatively straightforward, but they require
some boilerplate to imple
On 19/04/21 15:07 +0200, Jakub Jelinek wrote:
On Fri, Apr 16, 2021 at 08:48:12PM +0200, Jakub Jelinek via Gcc-patches wrote:
Tested on powerpc64{,le}-linux now (-m32/-m64 on be) and while the first
patch works fine, the second one unfortunately doesn't on either be or le,
so more work is needed
Hi Tobias,
That was entirely accidental. I should have been more careful about
checking the timing of the merge. When I last checked the number of P1s
seemed to indicate that there was a while before it would happen.
Apologies to all.
Paul
On Tue, 20 Apr 2021 at 11:07, Tobias Burnus wrote:
>
On 19/04/21 12:23 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
This patch address jwakely's feedback from 2021-04-15.
This is a substantial rewrite of the atomic wait/notify (and timed wait
counterparts) implementation.
The previous __platform_wait looped on EINTR however this behavior i
Hi,
Consider the following omp fragment.
...
#pragma omp target
#pragma omp parallel num_threads (2)
#pragma omp task
;
...
This hangs at -O0 for nvptx.
Investigating the behaviour gives us the following trace of events:
- both threads execute GOMP_task, where they:
- deposit a task,
On 20/04/21 12:04 +0100, Jonathan Wakely wrote:
On 19/04/21 12:23 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
This patch address jwakely's feedback from 2021-04-15.
This is a substantial rewrite of the atomic wait/notify (and timed wait
counterparts) implementation.
The previous __plat
Hi All,
This is another PDT warm-up patch before tackling the real beast: PR82649.
As the contributor wrote in the PR, "The F08 standard clearly distinguishes
between type parameter definition statements and component definition
statements. See R425, R431, R435, and in particular see Note 6.7 whi
This defines the feature test macro when uselocale is available, because
the floating-point std::from_chars support currently depends on that.
Co-authored-by: Jakub Jelinek
libstdc++-v3/ChangeLog:
PR libstdc++/100146
* include/std/charconv (__cpp_lib_to_chars): Define
co
On 19/04/21 12:23 -0700, Thomas Rodgers wrote:
+ template
+ static bool
+ _S_do_spin_v(__platform_wait_t* __addr,
+ const _Up& __old, _ValFn __vfn,
+ __platform_wait_t& __val,
+ _Spin __spin = _Spin{ })
+
Add -mmwait so that the MWAIT and MONITOR intrinsics can be used with
-mgeneral-regs-only and make -msse3 to imply -mmwait.
gcc/
* config.gcc: Install mwaitintrin.h for i[34567]86-*-* and
x86_64-*-* targets.
* common/config/i386/i386-common.c (OPTION_MASK_ISA2_MWAIT_SET):
Another construct we need to look inside.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/100109
* pt.c (find_parameter_packs_r): Look into enum initializers.
gcc/testsuite/ChangeLog:
PR c++/100109
* g++.dg/cpp0x/lambda/lambda-variadic14.
On Tue, Apr 20, 2021 at 11:57 AM Martin Liška wrote:
>
> It seems we bumped LTO_major_version last time 2 years ago.
>
> Right now, the following is seen when one links a GCC 10.2.x LTO object file:
> $ gcc a.o
>
> lto1: fatal error: bytecode stream in file ‘a.o’ generated with LTO version
> 9.2
On 20/04/21 13:02 +0100, Jonathan Wakely wrote:
On 19/04/21 12:23 -0700, Thomas Rodgers wrote:
+ template
+ static bool
+ _S_do_spin_v(__platform_wait_t* __addr,
+ const _Up& __old, _ValFn __vfn,
+ __platform_wait_t& __val,
+
The test fails for targets with V4QImode support which is the case for
IBM Z.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/pr71264.c: Xfail on IBM Z due to V4QImode support.
Ok for mainline?
---
gcc/testsuite/gcc.dg/vect/pr71264.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
On 20/04/21 14:20 +0100, Jonathan Wakely wrote:
On 20/04/21 13:02 +0100, Jonathan Wakely wrote:
On 19/04/21 12:23 -0700, Thomas Rodgers wrote:
+ template
+ static bool
+ _S_do_spin_v(__platform_wait_t* __addr,
+ const _Up& __old, _ValFn __vfn,
+
On 19/04/21 12:23 -0700, Thomas Rodgers wrote:
+struct __timed_backoff_spin_policy
+{
+ __wait_clock_t::time_point _M_deadline;
+ __wait_clock_t::time_point _M_t0;
+
+ template
+ __timed_backoff_spin_policy(chrono::time_point<_Clock, _Dur>
+
On 19/04/21 12:23 -0700, Thomas Rodgers wrote:
+#if __cpp_lib_atomic_wait
+ struct __atomic_semaphore
+ {
+static constexpr ptrdiff_t _S_max = __gnu_cxx::__int_traits::__max;
+explicit __atomic_semaphore(__detail::__platform_wait_t __count) noexcept
+ : _M_counter(__count)
{
-
On Tue, 20 Apr 2021, Jonathan Wakely wrote:
> On 19/04/21 22:25 -0400, Patrick Palka via Libstdc++ wrote:
> > This implements the wording changes of P2259R1 "Repairing input range
> > adaptors and counted_iterator", which resolves LWG 3283, 3289 and 3408.
> >
> > The wording changes are relativel
With the current handling of decl alignments it is impossible to
reduce the alignment requirement as part of a variable declaration.
This change has been proposed by Richard in the PR. It fixes the
align-1.c testcase on IBM Z.
Bootstrapped on x86_64 and s390x. No regressions.
Ok for mainline?
g
On 20/04/21 12:41 +0100, Jonathan Wakely wrote:
On 20/04/21 12:04 +0100, Jonathan Wakely wrote:
On 19/04/21 12:23 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
This patch address jwakely's feedback from 2021-04-15.
This is a substantial rewrite of the atomic wait/notify (and timed wait
c
On 20/04/21 15:25 +0100, Jonathan Wakely wrote:
On 20/04/21 12:41 +0100, Jonathan Wakely wrote:
On 20/04/21 12:04 +0100, Jonathan Wakely wrote:
On 19/04/21 12:23 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
This patch address jwakely's feedback from 2021-04-15.
This is a substantial re
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, &value);
> +
> + if (hex_len == 0 || hex_len > 8)
> +{
> + rdm->errored = 1;
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), sorry about the
mistake.
Most importantly: does GCN handle this, and if yes, how? I think the solution
should be the same for config/gcn and config
There are various non-IBM CPUs with isel as well, so it is easiest if we
just don't consider that flag here (it is not needed).
2021-04-20 Segher Boessenkool
PR target/100108
* config/rs6000/rs6000.c (rs6000_machine_from_flags): Do not consider
OPTION_MASK_ISEL.
---
Com
Hi,
I'd like to ping the following, since we already have an RC.
Thanks,
On Tue, Apr 13 2021, Martin Jambor wrote:
> Hi,
>
> Martin Liška correctly observed that the newly added support for AMD
> zenver3 in GCC 11 and 10.3 is not reflected in the changes.html files.
>
> Would the following be OK
Hi Martin,
On Tue, 20 Apr 2021, Martin Jambor wrote:
> I'd like to ping the following, since we already have an RC.
sorry for not getting to this via list right away.
> > + GCC 10.3 supports AMD CPUs based on znver3 core
> > + through -march=znver3.
I believe "based on the ... core" will be b
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/
On Wed, 7 Apr 2021, Patrick McGehearty via Gcc-patches wrote:
> + macro_name = XALLOCAVEC (char, name_len
> ++ sizeof ("__LIBGCC__EXCESS_PRECISION__"));
> sprintf (macro_name, "__LIBGCC_%s_EXCESS_PRECISION__", name);
> builtin_define_with_int_v
kefile. */
#define version_string "12.0.0 20210420 (experimental)"
#define pkgversion_string "(GCC) "
/* This is the location of the online document giving instructions for
reporting bugs. If you distribute a modified version of GCC,
please configure with --with-bugurl poi
In r11-2064 I made cp_parser_enum_specifier commit to tentative parse
when seeing a '{'. That still looks like the correct thing to do, but
it caused an ICE-on-invalid as well as accepts-invalid.
When we have something sneaky like this, which is broken in multiple
ways:
template
enum struct
Hi,
I'd like to apply the attached stopgap fix for PR ada/99360 on the 11 branch,
as the real fix is really stage #1 material. This is a regression there.
Bootstrapped/regtested on x86-64/Linux, OK for the 11 branch?
2021-04-20 Eric Botcazou
Bob Duff
PR ada/99360
I have now updated the patch – and intent to commit it tomorrow, unless
there are further comments.
On 17.03.21 19:29, Jakub Jelinek wrote:
On Wed, Mar 17, 2021 at 07:19:29PM +0100, Tobias Burnus wrote:
@@ -1831,6 +1852,7 @@ show_omp_node (int level, gfc_code *c)
+case EXEC_OMP_DEPOBJ: name
On 4/20/2021 7:21 AM, Stefan Schulze Frielinghaus via Gcc-patches wrote:
The test fails for targets with V4QImode support which is the case for
IBM Z.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/pr71264.c: Xfail on IBM Z due to V4QImode support.
OK
jeff
On 4/20/2021 2:17 AM, Stefan Schulze Frielinghaus via Gcc-patches wrote:
On IBM Z the aliasing stores are realized through one element vector
instructions, if no cost model for vectorization is used which is the
default according to vect.exp. Fixed by changing the number of times
the pattern m
On 4/19/2021 1:40 AM, Jakub Jelinek via Gcc-patches wrote:
On Sun, Apr 18, 2021 at 08:11:21PM -0400, Andrew MacLeod via Gcc-patches wrote:
--- a/gcc/gimple-range-gori.cc
+++ b/gcc/gimple-range-gori.cc
@@ -29,6 +29,36 @@ along with GCC; see the file COPYING3. If not see
#include "gimple-pret
On 4/18/2021 6:10 PM, Stafford Horne via Gcc-patches wrote:
When building libgeos we get an error with:
linux-uclibc/9.3.0/crtbeginS.o: in function `__do_global_dtors_aux':
crtstuff.c:(.text+0x118): relocation truncated to fit: R_OR1K_GOT16
against symbol `__cxa_finalize' defined in
On 4/19/2021 3:21 AM, Richard Sandiford via Gcc-patches wrote:
switch_to_section warns if we try to output a retain decl in a
section without a retain flag, or if we try to output a non-retain
decl in a section with a retain flag. However, the warning only
applied if we were trying to “switch”
Hi,
This patch addresses the raised issue in the RC thread (haven't seen a
bugzilla PR for it?)
As register names are required for darwin, but not accepted by gas
unless you use `-mregnames', they have been conditionally removed on
non-darwin targets.
To avoid duplicating large blocks of almost
On Tue, Apr 20, 2021 at 05:20:39PM -0600, Jeff Law wrote:
>
> On 4/18/2021 6:10 PM, Stafford Horne via Gcc-patches wrote:
> > When building libgeos we get an error with:
> >
> > linux-uclibc/9.3.0/crtbeginS.o: in function `__do_global_dtors_aux':
> > crtstuff.c:(.text+0x118): relocation
On 4/20/2021 6:12 PM, Stafford Horne wrote:
On Tue, Apr 20, 2021 at 05:20:39PM -0600, Jeff Law wrote:
On 4/18/2021 6:10 PM, Stafford Horne via Gcc-patches wrote:
When building libgeos we get an error with:
linux-uclibc/9.3.0/crtbeginS.o: in function `__do_global_dtors_aux':
crtst
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 template parameter, something that
users don't want to see.
The problem is that in tsubst_copy_and_build/LE_EXPR 't' is
Excerpts from Iain Buclaw's message of April 21, 2021 1:35 am:
> Hi,
>
> This patch addresses the raised issue in the RC thread (haven't seen a
> bugzilla PR for it?)
>
> As register names are required for darwin, but not accepted by gas
> unless you use `-mregnames', they have been conditionally
On 4/20/21 3:33 PM, Marek Polacek wrote:
In r11-2064 I made cp_parser_enum_specifier commit to tentative parse
when seeing a '{'. That still looks like the correct thing to do, but
it caused an ICE-on-invalid as well as accepts-invalid.
When we have something sneaky like this, which is broken i
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 template parameter, something that
users don't want to see.
The problem is th
61 matches
Mail list logo
