On Wed, Oct 20, 2021 at 7:31 AM dianhong.xu--- via Gcc-patches
wrote:
>
> From: dianhong xu
>
> Add -muse-unaligned-vector-move option to emit unaligned vector move
> instaructions.
Why would you ever want to have such option?! Should the documentation
at least read "emit unaligned vector moves
On Wed, Oct 20, 2021 at 9:02 AM Richard Biener
wrote:
>
> On Wed, Oct 20, 2021 at 7:31 AM dianhong.xu--- via Gcc-patches
> wrote:
> >
> > From: dianhong xu
> >
> > Add -muse-unaligned-vector-move option to emit unaligned vector move
> > instaructions.
>
> Why would you ever want to have such opt
On Tue, 19 Oct 2021 at 19:58, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > Hi,
> > The attached patch emits a more verbose diagnostic for target attribute that
> > is an architecture extension needing a leading '+'.
> >
> > For the following test,
> > void calculate(void) __attrib
On 10/20/21 01:23, H.J. Lu wrote:
Add libffi/ to ignored_prefixes for syncing with libffi upstream:
Sure, please push it.
Martin
The removal of --param=max-fsm-thread-length is causing code
explosion. I thought that --param=max-fsm-thread-path-insns was a
better gague for path profitability than raw BB length, but it turns
out that we don't take into account PHIs when estimating the number of
statements.
In this PR, we hav
Tested on x86-64 Linux.
gcc/ChangeLog:
* tree-ssa-threadbackward.c
(back_threader_registry::back_threader_registry):
Remove.
(back_threader_registry::register_path): Remove m_threaded_paths.
---
gcc/tree-ssa-threadbackward.c | 11 +--
1 file changed, 1 insertion(
Hi!
If GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC is not defined, the intent was to
treat the split of the structure between first cacheline (64 bytes)
as mostly write-once, use afterwards and second cacheline as rw just
as an optimization. But as has been reported, with vectorization enabled
at -O2 it ca
Thanks for the comments.
> And does it even work?
It works, I checked it in the test case, and when using this option, it can
emit an unaligned vector move.
>I fail to see adjustments to memory operands of
SSE/AVX instructions that have to be aligned
I changed all vector move in "get_ssemov" witho
Thanks for the comments.
>Why would you ever want to have such option?!
I need to ask @H. J. Lu for help to answer this question. He knows more
about the background. I may not explain it clearly.
>Should the documentation
at least read "emit unaligned vector moves even for aligned storage or when
On Wed, Oct 20, 2021 at 9:48 AM Xu Dianhong wrote:
>
> Thanks for the comments.
>
> > And does it even work?
> It works, I checked it in the test case, and when using this option, it can
> emit an unaligned vector move.
> >I fail to see adjustments to memory operands of
> SSE/AVX instructions tha
Hi,
I have been playing around with making Kewen's partial vector changes
workable with s390:
We have a vll instruction that can be passed the highest byte to load.
The rather unfortunate consequence of this is that a length of zero
cannot be specified. The partial vector framework, however
Hello.
Sometimes, one needs a more complex replacement in source files and
an editor can be a weak tool. That has happened to me in the recent
time and so I made the replacement in Python.
The script provides simple API:
- handle_file_p - return True if you want to touch the file
- modify_line -
On Wed, 20 Oct 2021 at 06:48, Tim Song wrote:
>
> On Tue, Oct 19, 2021 at 9:05 AM Jonathan Wakely via Gcc-patches
> wrote:
> >
> > +constexpr bool
> > +test_copy_elision()
> > +{
> > + return true;
> > +}
> > +
> > +static_assert( test_copy_elision() );
> > +
>
> This isn't much of a test :)
The
This is a regression present on the mainline in the form of a -fcompare-debug
failure at -O3 on a compiler-generated testcase. Fixed by disregarding a
debug statement in the last position of a basic block to reset the current
location for the outgoing edges.
Bootstrapped/regtested on x86-64/Li
This addresses PR ada/100486, which is the bootstrap failure of GCC 11 for 32-
bit Windows in the MSYS setup. The PR shows that we cannot rely on exception
propagation being operational during the bootstrap, at least on the 11 branch,
so fix this by removing the problematic raise statement.
Tes
On Oct 18, 2021, Richard Biener wrote:
> Yes, it is (just having had a quick look most of the functions in the
> pass lack function-level comments).
Oh my, I'm so sorry, please accept my apologies. I stepped away from
this patch for a few weeks, and when I got back to it, I did not realize
it w
On 10/19/21 12:53, Richard Biener wrote:
Meh ... :/
Well, move the target override hook call down (try to shuffle things
so diagnostics happen after but
"inits" happen before).
Not so easy. There are direct usages of the hooks
(influences dwarf2out_as_loc_support and dwarf2out_as_locview_suppo
Hi,
This patch disables gimple folding for float or double vec_min/max when
fast-math is not set. It makes vec_min/max conform with the guide.
Bootstrapped and tested on powerpc64le-linux with no regressions. Is this okay
for trunk? Any recommendations? Thanks a lot.
I refined the patch acc
Robin Dapp via Gcc-patches writes:
> Hi,
>
> I have been playing around with making Kewen's partial vector changes
> workable with s390:
>
> We have a vll instruction that can be passed the highest byte to load.
> The rather unfortunate consequence of this is that a length of zero
> cannot be s
On 19/10/21 17:47 +0100, Jonathan Wakely wrote:
The ISA-3.0 instruction set includes DARN ("deliver a random number")
which can be used similar to the existing support for RDRAND and RDSEED.
libstdc++-v3/ChangeLog:
* src/c++11/random.cc (USE_DARN): Define.
(__ppc_darn): New func
On Wed, Oct 20, 2021 at 1:00 AM Jeff Law wrote:
>
>
>
> On 10/18/2021 8:03 AM, Aldy Hernandez wrote:
> >
> >
> > On 10/18/21 3:41 PM, Aldy Hernandez wrote:
> >
> >> I've been experimenting with reducing the total number of threading
> >> passes, and I'd like to see if there's consensus/stomach for
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572555.html
BR,
Kewen
>
on 2021/6/11 下午9:16, Kewen.Lin via Gcc-patches wrote:
> Hi Segher,
>
> Thanks for the review!
>
> on 2021/6/10 上午4:17, Segher Boessenkool wrote:
>> Hi!
>>
>> O
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580358.html
BR,
Kewen
> on 2021/9/28 下午4:16, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> This patch follows the discussions here[1][2], where Segher
>> pointed out the existing way to guard the extra penalized
>> c
Hi,
Gentle ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578552.html
One related patch [1] is ready to commit, whose test cases rely on
this patch if no changes are applied to them.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579658.html
BR,
Kewen
Prathamesh Kulkarni writes:
> On Tue, 19 Oct 2021 at 19:58, Richard Sandiford
> wrote:
>>
>> Prathamesh Kulkarni writes:
>> > Hi,
>> > The attached patch emits a more verbose diagnostic for target attribute
>> > that
>> > is an architecture extension needing a leading '+'.
>> >
>> > For the fol
Hi,
As the discussions and the testing result under the main thread, this
patch would be safe.
Ping for this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580357.html
BR,
Kewen
on 2021/9/28 下午4:13, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As the discussion in PR102347, currently
On 27/09/2021 12:54, Richard Biener via Gcc-patches wrote:
On Mon, 27 Sep 2021, Jirui Wu wrote:
Hi all,
I now use the type based on the specification of the intrinsic
instead of type based on formal argument.
I use signed Int vector types because the outputs of the neon builtins
that I am low
On 19/10/2021 00:22, Joseph Myers wrote:
On Fri, 15 Oct 2021, Richard Biener via Gcc-patches wrote:
On Fri, Sep 24, 2021 at 2:59 PM Jirui Wu via Gcc-patches
wrote:
Hi,
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577846.html
The patch is attached as text for ease of use. Is
On Wed, 20 Oct 2021, Andre Vieira (lists) wrote:
> On 27/09/2021 12:54, Richard Biener via Gcc-patches wrote:
> > On Mon, 27 Sep 2021, Jirui Wu wrote:
> >
> >> Hi all,
> >>
> >> I now use the type based on the specification of the intrinsic
> >> instead of type based on formal argument.
> >>
> >>
On Wed, 20 Oct 2021, Andre Vieira (lists) wrote:
>
> On 19/10/2021 00:22, Joseph Myers wrote:
> > On Fri, 15 Oct 2021, Richard Biener via Gcc-patches wrote:
> >
> >> On Fri, Sep 24, 2021 at 2:59 PM Jirui Wu via Gcc-patches
> >> wrote:
> >>> Hi,
> >>>
> >>> Ping: https://gcc.gnu.org/pipermail/gcc
These are some random obvious cleanups to the threading dumps, since
it seems I'm not the only one looking at dumps these days.
The "just threaded" debugging message is redundant since there's
already an equivalent "Registering jump thread" message.
The "about to thread" message is actually confu
Tested on x86-64 Linux.
gcc/ChangeLog:
* tree-ssa-threadbackward.c (back_threader::~back_threader): Remove.
---
gcc/tree-ssa-threadbackward.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/gcc/tree-ssa-threadbackward.c b/gcc/tree-ssa-threadbackward.c
index 96422a1390e..d94e3b962
Sometimes we can solve a candidate path without having to recurse
further back. This can mostly happen in fully resolving mode, because
we can ask the ranger what the range on entry to the path is, but
there's no reason this can't always apply. This one-liner removes
the fully-resolving restricti
Many thanks for your explanation. I got the meaning of operands.
The "addpd b(%rip), %xmm0" instruction needs "b(%rip)" aligned otherwise
it will rise a "Real-Address Mode Exceptions".
I haven't considered this situation "b(%rip)" has an address dependence of
"a(%rip)" before. I think this situati
On 18.10.21 09:52, Jakub Jelinek wrote:
On Mon, Oct 18, 2021 at 09:22:51AM +0200, Tobias Burnus wrote:
This patch updates the OMP_PLACES description for the recent
OpenMP 5.1 changes.
I actually wonder when/whether the spec reference
should be updated to OpenMP 5.1 or an additional
reference to
On Wed, Oct 20, 2021 at 12:40 PM Xu Dianhong wrote:
>
> Many thanks for your explanation. I got the meaning of operands.
> The "addpd b(%rip), %xmm0" instruction needs "b(%rip)" aligned otherwise it
> will rise a "Real-Address Mode Exceptions".
> I haven't considered this situation "b(%rip)" has
Wilco Dijkstra writes:
> Hi Richard,
>
>> The problem is that you're effectively asking for these values to be
>> taken on faith without providing any analysis and without describing
>> how you arrived at the new numbers. Did you try other values too?
>> If so, how did they compare with the numbe
Hi,
On Tue, Oct 19, 2021 at 11:03 AM liuhongt via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> updated patch:
> 1. Add documents in doc/sourcebuild.texi (Effective-Target Keywords).
> 2. Reduce -novec.c testcases to contain only new failed parted which
> is caused by O2 vectorization.
>
This avoids running into the assert in compute_distributive_range when
starting the analysis with operations in a trapping type.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-10-20 Richard Biener
PR tree-optimization/102853
* tree-data-ref.c (split_constant
On 9/16/21 12:00, Martin Liška wrote:
As preparation for a new global object that will encapsulate
asm_out_file, we would need to live with a macro that will
define asm_out_file as casm->out_file and thus the name
can't be used in function arguments.
I've built all cross compilers with the chang
On Tue, 19 Oct 2021 at 16:55, Richard Biener wrote:
>
> On Tue, 19 Oct 2021, Prathamesh Kulkarni wrote:
>
> > On Tue, 19 Oct 2021 at 13:02, Richard Biener
> > wrote:
> > >
> > > On Tue, Oct 19, 2021 at 9:03 AM Prathamesh Kulkarni via Gcc-patches
> > > wrote:
> > > >
> > > > On Mon, 18 Oct 2021
On Wed, Oct 20, 2021 at 1:58 PM Martin Liška wrote:
>
> On 9/16/21 12:00, Martin Liška wrote:
> > As preparation for a new global object that will encapsulate
> > asm_out_file, we would need to live with a macro that will
> > define asm_out_file as casm->out_file and thus the name
> > can't be use
The documentation on asm statements suggests asm is always a GNU
extension, but it's been part of ISO C++ since the first standard.
The documentation of -fno-asm is wrong for C++ as it states that it only
affects typeof, but actually it affects typeof and asm (despite asm
being part of ISO C++).
On 10/20/21 09:15, Martin Liška wrote:
On 10/20/21 01:23, H.J. Lu wrote:
Add libffi/ to ignored_prefixes for syncing with libffi upstream:
Sure, please push it.
Martin
Hello H.J.
Note the server hook is updated after you installed the patch.
Martin
Hi Jakub,
this version adjusts the patch to let sections/parallel sections also use
strictly-structured blocks, making it more towards 5.2.
Because of this change, some of the testcases using the sections-construct need
a bit of adjustment too, since "block; end block" at the start of the constru
On 10/20/21 5:27 AM, Aldy Hernandez wrote:
On Wed, Oct 20, 2021 at 1:00 AM Jeff Law wrote:
On 10/18/2021 8:03 AM, Aldy Hernandez wrote:
On 10/18/21 3:41 PM, Aldy Hernandez wrote:
I've been experimenting with reducing the total number of threading
passes, and I'd like to see if there's con
The code that threads incoming paths to a PHI is duplicating what we
do generically in find_paths_to_names. This shortcoming is actually
one of the reasons we aren't threading all possible paths into a PHI.
For example, we give up after finding one threadable path, but some
PHIs have multiple thre
On Mon, Oct 18, 2021 at 06:17:20PM +0200, Marcel Vollweiler wrote:
> @@ -14255,6 +14257,16 @@ c_parser_omp_clause_use_device_addr (c_parser
> *parser, tree list)
> list);
> }
>
> +/* OpenMP 5.1:
> + has_device_addr ( variable-list ) */
> +
> +static tree
>
* LOCAL_PATCHES: New file.
---
libffi/LOCAL_PATCHES | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 libffi/LOCAL_PATCHES
diff --git a/libffi/LOCAL_PATCHES b/libffi/LOCAL_PATCHES
new file mode 100644
index 000..a377c28ce8d
--- /dev/null
+++ b/libffi/LOCAL_PATCHES
@@ -0,
When --enable-cet is used to configure GCC, enable Intel CET in libffi.
* Makefile.am (AM_CFLAGS): Add $(CET_FLAGS).
(AM_CCASFLAGS): Likewise.
* configure.ac (CET_FLAGS): Add GCC_CET_FLAGS and AC_SUBST.
* Makefile.in: Regenerate.
* aclocal.m4: Likewise.
On Wed, 20 Oct 2021, Prathamesh Kulkarni wrote:
> On Tue, 19 Oct 2021 at 16:55, Richard Biener wrote:
> >
> > On Tue, 19 Oct 2021, Prathamesh Kulkarni wrote:
> >
> > > On Tue, 19 Oct 2021 at 13:02, Richard Biener
> > > wrote:
> > > >
> > > > On Tue, Oct 19, 2021 at 9:03 AM Prathamesh Kulkarni v
On Wed, Oct 20, 2021 at 5:30 AM Martin Liška wrote:
>
> On 10/20/21 09:15, Martin Liška wrote:
> > On 10/20/21 01:23, H.J. Lu wrote:
> >> Add libffi/ to ignored_prefixes for syncing with libffi upstream:
> >
> > Sure, please push it.
> >
> > Martin
>
> Hello H.J.
>
> Note the server hook is update
On 20/10/21 10:12 +0100, Jonathan Wakely wrote:
On 19/10/21 17:47 +0100, Jonathan Wakely wrote:
The ISA-3.0 instruction set includes DARN ("deliver a random number")
which can be used similar to the existing support for RDRAND and RDSEED.
libstdc++-v3/ChangeLog:
* src/c++11/random.cc (
On Wed, Oct 20, 2021 at 2:32 PM Andrew MacLeod wrote:
>
> On 10/20/21 5:27 AM, Aldy Hernandez wrote:
> Oh? the float stuff isn't range related, just relations? you can
> certainly register those and query/fold them
See? I knew you'd get a bright idea. No. There's no time in this release
On Wed, Oct 20, 2021 at 4:18 AM Richard Biener
wrote:
>
> On Wed, Oct 20, 2021 at 12:40 PM Xu Dianhong wrote:
> >
> > Many thanks for your explanation. I got the meaning of operands.
> > The "addpd b(%rip), %xmm0" instruction needs "b(%rip)" aligned otherwise it
> > will rise a "Real-Address Mod
This maps -ftrapv to -fsanitize=signed-integer-overflow
-fsanitize-undefined-trap-on-error, effectively removing
flag_trapv (or rather making it always false).
This has implications on language support - while -ftrapv
was formerly universally available the mapping restricts it
to the C family of f
On 15/10/2021 09:48, Richard Biener wrote:
On Tue, 12 Oct 2021, Andre Vieira (lists) wrote:
Hi Richi,
I think this is what you meant, I now hide all the unrolling cost calculations
in the existing target hooks for costs. I did need to adjust 'finish_cost' to
take the loop_vinfo so the target's
Hi all,
Looking at calls.c:initialize_argument_information, I spotted some dead
code that seems to have been left behind from when MPX support was
removed.
This patch removes that code as well as the associated target hooks
(which appear to be unused).
Bootstrapped and regtested on aarch64-linux
On 10/20/21 4:28 AM, Aldy Hernandez via Gcc-patches wrote:
Sometimes we can solve a candidate path without having to recurse
further back. This can mostly happen in fully resolving mode, because
we can ask the ranger what the range on entry to the path is, but
there's no reason this can't always
ping
From: Wilco Dijkstra
Sent: 02 June 2021 11:21
To: GCC Patches
Cc: Kyrylo Tkachov ; Richard Sandiford
Subject: [PATCH] AArch64: Improve address rematerialization costs
Hi,
Given the large improvements from better register allocation of GOT accesses,
I decided to generalize it to get la
ping
From: Wilco Dijkstra
Sent: 04 June 2021 14:44
To: Richard Sandiford
Cc: Kyrylo Tkachov ; GCC Patches
Subject: [PATCH v3] AArch64: Improve GOT addressing
Hi Richard,
This merges the v1 and v2 patches and removes the spurious MEM from
ldr_got_small_si/di. This has been rebased after [1]
On Wed, Oct 20, 2021 at 4:35 PM Martin Sebor wrote:
> I appreciate the heads up. I'm happy that the threader has
> improved. I'm obviously not pleased that it has led to regressions
> in warnings but I understand that in some cases they might be due
> to limitations in the warning code. I thin
Hi,
In GCC, there are many utility routines for reporting error, warning, or
information, for example:
warning (0, "weak declaration of %q+D not supported", decl);
warning_at (stmtloc, OPT_Wmaybe_uninitialized, "%qE may be used
uninitialized", ptr));
inform (loc, "in a call to %qT declared wit
On Wed, 2021-10-20 09:43:42 +0200, Aldy Hernandez via Gcc-patches
wrote:
> The removal of --param=max-fsm-thread-length is causing code
> explosion. I thought that --param=max-fsm-thread-path-insns was a
> better gague for path profitability than raw BB length, but it turns
> out that we don't t
On Wed, Oct 20, 2021 at 08:30:34PM +0800, Chung-Lin Tang wrote:
> 2021-10-20 Chung-Lin Tang
>
> gcc/fortran/ChangeLog:
>
> * decl.c (gfc_match_end): Add COMP_OMP_STRICTLY_STRUCTURED_BLOCK case
> together with COMP_BLOCK.
> * parse.c (parse_omp_structured_block): Change return
Hi!
On Wed, Oct 20, 2021 at 05:04:56PM +0800, HAO CHEN GUI wrote:
> This patch disables gimple folding for float or double vec_min/max when
> fast-math is not set. It makes vec_min/max conform with the guide.
>
> Bootstrapped and tested on powerpc64le-linux with no regressions. Is this
> okay f
> On Oct 18, 2021, at 2:26 PM, Qing Zhao via Gcc-patches
> wrote:
>
> Hi, Jakub,
>
> This is the 2nd version of the patch based on your comment.
>
> Bootstrapped on both x86 and aarch64. Regression testings are ongoing.
The regression testing was done. Looks good.
Okay for committing?
Tha
On 10/7/21 4:14 PM, Siddhesh Poyarekar wrote:
Handle either static sizes in function parameters or hints provided by
__attribute__ ((access (...))) to compute sizes for objects.
It's been my hope to eventually teach __builtin_object_size about
attribute access but implementing it in the new bui
On October 20, 2021 3:19:28 PM GMT+02:00, "H.J. Lu" wrote:
>On Wed, Oct 20, 2021 at 4:18 AM Richard Biener
> wrote:
>>
>> On Wed, Oct 20, 2021 at 12:40 PM Xu Dianhong wrote:
>> >
>> > Many thanks for your explanation. I got the meaning of operands.
>> > The "addpd b(%rip), %xmm0" instruction need
Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and branches
after a while?
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (viewable_range): Adjust as per
LWG 3481.
* testsuite/std/ranges/adaptors/all.cc (test07): New test.
---
libstdc++-v3/include/bits/
Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and branches
after a while?
libstdc++-v3/ChangeLog:
* include/std/ranges (join_view::__iter_cat::_S_iter_cat): Adjust
criteria for returning bidirectional_iterator_tag as per LWG3535.
(join_view::_Iterator::_S_ite
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and branches?
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (common_iterator::__arrow_proxy):
Make fully constexpr.
(common_iterator::__postfix_proxy): Likewise.
---
libstdc++-v3/include/bits/stl_iterator.
On 10/20/21 22:26, Martin Sebor wrote:
On 10/7/21 4:14 PM, Siddhesh Poyarekar wrote:
Handle either static sizes in function parameters or hints provided by
__attribute__ ((access (...))) to compute sizes for objects.
It's been my hope to eventually teach __builtin_object_size about
attribute a
On 10/20/2021 6:28 AM, Jonathan Wakely via Gcc-patches wrote:
The documentation on asm statements suggests asm is always a GNU
extension, but it's been part of ISO C++ since the first standard.
The documentation of -fno-asm is wrong for C++ as it states that it only
affects typeof, but actual
On 10/20/2021 3:27 AM, Aldy Hernandez wrote:
On Wed, Oct 20, 2021 at 1:00 AM Jeff Law wrote:
On 10/18/2021 8:03 AM, Aldy Hernandez wrote:
On 10/18/21 3:41 PM, Aldy Hernandez wrote:
I've been experimenting with reducing the total number of threading
passes, and I'd like to see if there'
On Wed, Oct 20, 2021 at 03:49:09PM +, Qing Zhao via Gcc-patches wrote:
> Hi,
>
> In GCC, there are many utility routines for reporting error, warning, or
> information, for example:
>
> warning (0, "weak declaration of %q+D not supported", decl);
> warning_at (stmtloc, OPT_Wmaybe_uninitializ
On 10/20/2021 6:37 AM, Aldy Hernandez wrote:
The code that threads incoming paths to a PHI is duplicating what we
do generically in find_paths_to_names. This shortcoming is actually
one of the reasons we aren't threading all possible paths into a PHI.
For example, we give up after finding one
Thanks. I'm going to wait until/if you approve the previous patch in
the series before I commit:
[PATCH] Try to resolve paths in threader without looking further back.
..because otherwise I'll have to test again and twiddle tests in a
different order.
Aldy
On Wed, Oct 20, 2021 at 8:04 PM Jeff
Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and 11 after
a while?
libstdc++-v3/ChangeLog:
* include/std/ranges (lazy_split_view::base): Add forward_range
constraint as per LWG 3591.
(lazy_split_view::begin, lazy_split_view::end): Also check
simplene
On Wed, Oct 20, 2021 at 9:58 AM Richard Biener
wrote:
>
> On October 20, 2021 3:19:28 PM GMT+02:00, "H.J. Lu"
> wrote:
> >On Wed, Oct 20, 2021 at 4:18 AM Richard Biener
> > wrote:
> >>
> >> On Wed, Oct 20, 2021 at 12:40 PM Xu Dianhong wrote:
> >> >
> >> > Many thanks for your explanation. I got
On Wed, 20 Oct 2021 at 18:10, Martin Liška wrote:
> On 10/20/21 18:59, Jonathan Wakely via Gcc wrote:
> > On Wed, 20 Oct 2021 at 17:40, Joseph Myers wrote:
> >
> >> On Wed, 20 Oct 2021, Jonathan Wakely via Gcc wrote:
> >>
> >>> https://gcc.gnu.org/install/ says:
> >>>
> >>> "There are also some ol
On Wed, 20 Oct 2021 at 19:17, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and 11 after
> a while?
Yes for both, thanks.
On Wed, 20 Oct 2021 at 18:44, Jeff Law wrote:
> On 10/20/2021 6:28 AM, Jonathan Wakely via Gcc-patches wrote:
> > The documentation on asm statements suggests asm is always a GNU
> > extension, but it's been part of ISO C++ since the first standard.
> >
> > The documentation of -fno-asm is wrong fo
On Wed, 20 Oct 2021 at 18:01, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and branches
> after a while?
Yes for all.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_base.h (viewable_range): Adjust as per
> LWG 3481.
> * testsu
On Wed, 20 Oct 2021 at 18:03, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and branches
> after a while?
Yes for all.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (join_view::__iter_cat::_S_iter_cat): Adjust
> criteri
On Wed, 20 Oct 2021 at 18:04, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and branches?
I thought I'd already done this one, maybe I have it in a local Git stash.
OK for all branches, thanks.
>
> libstdc++-v3/ChangeLog:
>
> * include
On Tue, Oct 19, 2021 at 1:41 AM Thomas Koenig wrote:
>
> Hi Eric,
>
> > Hi, I have updated this patch and tested it with more languages now; I
> > can now confirm that it works with ada, d, and fortran now. The only
> > languages that remain untested now are go (since I'm building on
> > darwin an
On Wed, 20 Oct 2021 at 09:42, Jonathan Wakely wrote:
>
> On Wed, 20 Oct 2021 at 06:48, Tim Song wrote:
> >
> > On Tue, Oct 19, 2021 at 9:05 AM Jonathan Wakely via Gcc-patches
> > wrote:
> > >
> > > +constexpr bool
> > > +test_copy_elision()
> > > +{
> > > + return true;
> > > +}
> > > +
> > > +st
Hi, Marek,
Thanks a lot for the information.
Really helpful.
Qing
> On Oct 20, 2021, at 12:57 PM, Marek Polacek wrote:
>
> On Wed, Oct 20, 2021 at 03:49:09PM +, Qing Zhao via Gcc-patches wrote:
>> Hi,
>>
>> In GCC, there are many utility routines for reporting error, warning, or
>> inf
In case of a checked type conversion, correctly update Typ to match the
expression being validated and call Analyze_And_Resolve on the modified
expression.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* checks.adb (Insert_Valid_Check): in case of checked type
conver
It is common that a quantified expression takes the form of a
conjunction or disjunction. In such a case, it is expected that all
conjuncts/ disjuncts reference the quantified variable. Not doing so can
be either the symptom of an error, or of a non-optimal expression, as
that sub-expression could
Cleanup and remove some unused system specs and references to same.
These are specs that set Frontend_Exceptions, which is no longer
used in GNAT.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* Makefile.rtl: Remove references to system-vxworks-ppc.ads
and system-vxw
This removes an unreachable case in a nested predicate function as well
as trims down a verbose condition. No functional changes.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_eval.ads (Check_Non_Static_Context): Update documentation.
* sem_eval.adb (In_Any_In
Testing for Convention_Intrinsic is not the proper way in order to spot
intrinsic subprograms, calling the predicate Is_Intrinsic_Subprogram is.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* gcc-interface/decl.c (gnat_to_gnu_entity) :
Replace test on Convention_Int
This exposes the newly added support for type-generic GCC atomic builtins
to the user through the System.Atomic_Primitives package, where a generic
version of the existing routines is added. This also uses this support
in the implementation of the System.Atomic_Operations packages.
Tested on x86_
A temporary workaround needed by GNATprove after cleaning up the
handling of AST fields with universal integers.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_spark.adb (Expand_SPARK_N_Attribute_Reference): Guard
against equality of an uninitialized RM_Size fie
When corresponding parameter subtypes or result subtypes denote
different declarations between the declaration and body of a subprogram,
but those are fully conforming, a warning will be issued indicating that
the subtypes come from different declarations. In the case of anonymous
access subtypes,
Use No_Uint to indicate "unknown" or "not yet known" for various fields
whose type is Uint, instead of using Uint_0. Otherwise Uint_0 could be
ambiguous -- it could also mean "value is known, and is zero". This
patch does not fix all bugs in this area, but fixes most of them, and
adds assertions th
Distance of a variant in the enclosing type declaration is never
negative. Code cleanup related to fix for boxes in record delta
aggregates; semantics is unaffected.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_aggr.adb (Variant_Depth): Refine type from Integer to
This patch corrects issues in the compiler whereby default initializing
a protected type component of an access type containing controlled parts
with an allocator causes a crash at compile-time at the point of an
object declaration of such protected type.
Tested on x86_64-pc-linux-gnu, committed o
1 - 100 of 135 matches
Mail list logo
