Committed, thanks Robin.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Robin Dapp via Gcc-patches
Sent: Thursday, August 24, 2023 6:23 PM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: rdapp@gmail.com; kito.ch...@gmail.com; kito.ch...@sifive.com;
jeffreya...@gmail.com
Subjec
This adds dump on the full result of the match-and-simplify
for phiopt and specifically to know if we are rejecting something
due to being in early phi-opt.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (gimple_simplify_phiopt):
Somehow when I was testing the new testcase, it was working but
when I re-ran the full testsuite it was not. Anyways the issue
was just a simple space before the `}` for dg-options directive.
Committed as obvious.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/phi-opt-34.c: Fix dg-options di
On 8/25/23 19:37, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
1) When saying that a conversion is erroneous because it would use
an explicit constructor, it might be nice to show where exactly
the explicit constructor is located. For example, with
On 8/25/2023 11:53 AM, Jeff Law via Gcc-patches wrote:
On 8/24/23 15:19, Edwin Lu wrote:
Related Discussion:
https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/
This patch updates the sync instructions to ensure that no insn is left
without a type attribut
* MAINTAINERS: Add myself
Signed-off-by: Edwin Lu
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4e706df6522..da2817a547c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -541,6 +541,7 @@ Gabor Loki
Man
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
1) When saying that a conversion is erroneous because it would use
an explicit constructor, it might be nice to show where exactly
the explicit constructor is located. For example, with this patch:
[...]
explicit.C:4:12: note
On Thu, Aug 24, 2023 at 11:47 PM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches
> wrote:
> >
> > Now that MIN/MAX can sometimes be transformed into BIT_AND/BIT_IOR,
> > we should allow BIT_AND and BIT_IOR in the early phiopt.
> > Also we pr
Spurred by Jivan's patch and a desire for cleaner testresults, I went
ahead and make the stack_save_restore tests independent of the precise
stack size by using a regexp.
Pushed to the trunk.
Jeffcommit e1f096a3cc96c71907cfbc7b8baf67a3d863cb6d
Author: Jeff Law
Date: Fri Aug 25 16:34:17 2023
I thought I had already fixed this, but clearly if I did, I didn't
include it in any upstream commits.
With -Og the optimizers are hindered in various ways and this prevents
using zicond. So skip this test with -Og (it was already being skipped
at -O0).
Pushed to the trunk.
Jeff
commit 3c
On 8/25/23 6:20 AM, Kewen.Lin wrote:
> Assuming the current PCREL_SUPPORTED_BY_OS unchanged, when
> PCREL_SUPPORTED_BY_OS is true, all its required conditions are
> satisfied, it should be safe. while PCREL_SUPPORTED_BY_OS is
> false, it means the given subtarget doesn't support it, or one
> or mo
On 8/13/23 23:50, Jin Ma wrote:
This patch adds the 'Zfa' extension for riscv, which is based on:
https://github.com/riscv/riscv-isa-manual/commits/zfb
The binutils-gdb for 'Zfa' extension:
https://sourceware.org/pipermail/binutils/2023-April/127060.html
What needs special explanation is:
1,
On 8/14/23 06:51, Jin Ma wrote:
This code is great and completely different from the way I implemented it.
I'm not sure which one is better, but my idea is that the fli instruction
corresponds to three tables (HF, SF and DF), all of which represent
specific values. the library in gcc's real.
Hi!
This paper voted in as DR makes some multi-character literals ill-formed.
'abcd' stays valid, but e.g. 'á' is newly invalid in UTF-8 exec charset
while valid e.g. in ISO-8859-1, because it is a single character which needs
2 bytes to be encoded.
The following patch does that by checking (only
After more investigations, it seems like the fault was on our side as
we were calling `gcc_jit_type_get_restrict` on types that weren't
pointers.
I added a check for that in `gcc_jit_type_get_restrict` directly as well.
We will continue our investigation to be sure we didn't miss anything.
Le mar
Hello-
This is adding a testcase for a PR that was already incidentally fixed. OK
to commit please? Thanks...
-Lewis
-- >8 --
The PR was fixed by r12-5454. Since the fix was somewhat incidental,
although related, add a testcase from PR90400 too before closing it out.
gcc/testsuite/ChangeLog:
Hi!
The following patch implements
CWG 2406 - [[fallthrough]] attribute and iteration statements
The genericization of some loops leaves nothing at all or just a label
after a body of a loop, so if the loop is later followed by
case or default label in a switch, the fallthrough statement isn't
dia
On 8/13/23 23:32, Tsukasa OI via Gcc-patches wrote:
From: Tsukasa OI
This commit adds support for the 'Zfa' extension containing additional
floating point instructions, version 0.1 (stable and approved).
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_implied_in
On Fri, 2023-08-25 at 14:48 +0200, Benjamin Priour wrote:
> Hi David,
>
> Thanks for the review.
>
> On Fri, Aug 25, 2023 at 2:12 AM David Malcolm
> wrote:
>
> > > From: benjamin priour
> > >
> > > Hi,
> > >
> > > Below the first batch of a serie of patches to transition
> > > the analyzer t
ee with 201 annotations[1] added. Things work as expected. :)
-Kees
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=devel/next-20230825/counted_by
--
Kees Cook
OpenMP 5.0 removed the restriction that multiple collapsed loops must
be perfectly nested, allowing "intervening code" (including nested
BLOCKs) before or after each nested loop. In GCC this code is moved
into the inner loop body by the respective front ends.
In the Fortran front end, most of the
gcc/testsuite/ChangeLog
* c-c++-common/gomp/imperfect-attributes.c: New.
* c-c++-common/gomp/imperfect-badloops.c: New.
* c-c++-common/gomp/imperfect-blocks.c: New.
* c-c++-common/gomp/imperfect-extension.c: New.
* c-c++-common/gomp/imperfect-gotos.c: New.
OpenMP 5.0 removed the restriction that multiple collapsed loops must
be perfectly nested, allowing "intervening code" (including nested
BLOCKs) before or after each nested loop. In GCC this code is moved
into the inner loop body by the respective front ends.
This patch changes the C front end to
libgomp/ChangeLog
* libgomp.texi (OpenMP 5.0): Imperfectly-nested loops are done.
---
libgomp/libgomp.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 5c91163893f..4aad8cc52f4 100644
--- a/libgomp/libgomp.texi
+++ b
OpenMP 5.0 removed the restriction that multiple collapsed loops must
be perfectly nested, allowing "intervening code" (including nested
BLOCKs) before or after each nested loop. In GCC this code is moved
into the inner loop body by the respective front ends.
This patch changes the C++ front end
In order to detect invalid jumps in and out of intervening code in
imperfectly-nested loops, the front ends need to insert some sort of
marker to identify the structured block sequences that they push into
the inner body of the loop. The error checking happens in the
diagnose_omp_blocks pass, betw
V2 of these patches were previously approved with a few small changes
requested. For the archives, here is the version I've pushed.
Parts 1 and 2 are unchanged since V2. In part 3 (C++) I had to fix a
merge problem by hand. In parts 4 and 5, I hacked up a couple tests
as requested by Jakub. Pa
Hoist want_to_gcse_p () calls rtx_cost () to compute max distance for
hoist candidates. For a simple const (say 6 which needs seperate insn "LI 6")
backend currently returns 0, causing Hoist to bail and elide GCSE.
Note that constants requiring more than 1 insns to setup were working
fine since ri
On 8/24/23 15:19, Edwin Lu wrote:
Related Discussion:
https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/
This patch updates the sync instructions to ensure that no insn is left
without a type attribute. Updates a total of 6 insns to have type "atomic"
Te
On 8/24/23 23:16, Vineet Gupta wrote:
Hoist want_to_gcse_p () calls rtx_cost () to compute max distance for
hoist candidates. For a simple const (say 6 which needs seperate insn "LI 6")
backend currently returns 0, causing Hoist to bail and elide GCSE.
Note that constants requiring more than
On 8/24/23 09:45, Jivan Hakobyan via Gcc-patches wrote:
Subject:
RISC-V: Fix stack_save_restore_1/2 test cases
From:
Jivan Hakobyan via Gcc-patches
Date:
8/24/23, 09:45
To:
GCC Patches , Jeff Law
This patch fixes failing stack_save_restore_1/2 test cases.
After 6619b3d4c15c commit size of
In PR 106677, I noticed that on the trunk we were producing:
```
_25 = SR.116_117 == 0;
_27 = (unsigned char) _25;
_32 = _27 | SR.116_117;
```
>From `SR.115_117 != 0 ? SR.115_117 : 1`
Rather than:
```
_119 = MAX_EXPR <1, SR.115_117>;
```
Or (rather)
```
_119 = SR.115_117 | 1;
```
Due to t
On Fri, Aug 25, 2023 at 11:11 AM Andrew Pinski wrote:
>
> On Thu, Aug 24, 2023 at 11:39 PM Richard Biener via Gcc-patches
> wrote:
> >
> > On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches
> > wrote:
> > >
> > > In PR 106677, I noticed that on the trunk we were producing:
> > > ```
>
This syncs the libgomp.texi implementation status to the webpage,
i.e. adding a few new items + marking some as 'supported'.
It also fixes a couple of bugs and adds links providing more details
for two items (a PR link as in libgomp.texi and a section in the manual).
Comments? Suggestions? If no
On Thu, Aug 24, 2023 at 11:39 PM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches
> wrote:
> >
> > In PR 106677, I noticed that on the trunk we were producing:
> > ```
> > _25 = SR.116_117 == 0;
> > _27 = (unsigned char) _25;
> > _32 =
On Fri, 25 Aug 2023, Marek Polacek via Gcc-patches wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
LGTM
>
> -- >8 --
>
> This CWG clarifies that designated initializer support direct-initialization.
> Just be careful what Note 2 in [dcl.init.aggr]/4.2 says: "If the
> init
Tested on x86_64-pc-linux-gnu, does this look OK for trunk? This
reduces calls to is_rvalue_constant_expression from
cp_parser_constant_expression by 10% for stdc++.h.
-- >8 --
As a follow-up to Marek's r14-3088-ga263152643bbec, this patch makes
us avoid passing an effectively dummy non_constant
On Fri, Aug 25, 2023 at 12:33:31PM -0400, Patrick Palka via Gcc-patches wrote:
> Boostrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?
Very nice. LGTM.
> -- >8 --
>
> This replaces manual memory management via conversion_obstack_alloc(0)
> and obstack_free with the r
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This CWG clarifies that designated initializer support direct-initialization.
Just be careful what Note 2 in [dcl.init.aggr]/4.2 says: "If the
initialization is by designated-initializer-clause, its form determines
whether copy
Boostrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
This replaces manual memory management via conversion_obstack_alloc(0)
and obstack_free with the recently added conversion_obstack_sentinel,
and also uses the latter in build_user_type_conversion and
build_ope
On Fri, 25 Aug 2023, FX Coudert via Gcc-patches wrote:
> Hi,
>
> Thanks Joseph for the review.
>
> > The driver changes are OK.
> >
> > I think the new configure options and the new -nodefaultrpaths compiler
> > option need documenting
>
> Doc patch was added, and okay’ed by Iain.
I see docu
This moves the pattern `(X & ~Y) | (~X & Y)` to use bitwise_inverted_equal_p
so we can simplify earlier the case where X and Y are defined by comparisons.
We were able to optimize to (!X)^(!Y) in the end due to the pattern added in
r14-3110-g7fb65f102851248bafa0815 and the older pattern r13-4620-g4
Use the counted_by attribute information in bound sanitizer.
gcc/c-family/ChangeLog:
PR C/108896
* c-ubsan.cc (ubsan_instrument_bounds): Use counted_by attribute
information.
gcc/testsuite/ChangeLog:
PR C/108896
* gcc.dg/ubsan/flex-array-counted-by-bounds
Use the counted_by atribute info in builtin object size to compute the
subobject size for flexible array members.
gcc/ChangeLog:
PR C/108896
* tree-object-size.cc (addr_object_size): Use the counted_by
attribute info.
* tree.cc (component_ref_has_counted_by_p): New
This is the 3rd version of the patch, per our discussion based on the
review comments for the 1st and 2nd version, the major changes in this
version are:
***Against 1st version:
1. change the name "element_count" to "counted_by";
2. change the parameter for the attribute from a STRING to an
Identi
Provide a new counted_by attribute to flexible array member field.
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the flexible array
member of a structure. It indicates that the number of the
elements of the array is given by the field named "COUNT" in the
On Fri, 25 Aug 2023, Richard Biener via Gcc-patches wrote:
>
> The following adds the capability to have fold-const.cc matched
> patterns visible in -folding dumps. There's two choices,
> a portable one replacing return stmts like
>
> - return fold_build1 (tcode, ctype, fold_convert (ctyp
The following adds the capability to have fold-const.cc matched
patterns visible in -folding dumps. There's two choices,
a portable one replacing return stmts like
- return fold_build1 (tcode, ctype, fold_convert (ctype, t1));
+ DRET (fold_build1 (tcode, ctype, fold_convert (ctype,
Hi David,
Thanks for the review.
On Fri, Aug 25, 2023 at 2:12 AM David Malcolm wrote:
> > From: benjamin priour
> >
> > Hi,
> >
> > Below the first batch of a serie of patches to transition
> > the analyzer testsuite from gcc.dg/analyzer to c-c++-common/analyzer.
> > I do not know how long thi
Hi Jeff,
> You might also peek at the RTL gcse/pre code which is also LCM based and
> has the same class of problems.
I found a similar approach to take care of this in gcse.cc/pre_edge_insert with
some comments as below.
/* We can't insert anything on an abnormal and
critical edge, s
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-3481-g99a3fcb8ff0bf2.
gcc/analyzer/ChangeLog:
* access-diagram.cc (class string_region_spatial_item): Remove
assumption that the string is written to the start of the cluster.
gcc/testsuite/Chang
The following fixes a mistake with SLP dependence checking. When
checking whether we can hoist loads to the first load place we
special-case stores of the same instance considering them sunk
to the last store place. But we fail to consider that stores from
other SLP instances are sunk in a simila
on 2023/8/25 11:20, Peter Bergner wrote:
> On 8/24/23 12:56 AM, Kewen.Lin wrote:
>> By looking into the uses of function rs6000_pcrel_p, I think we can
>> just replace it with TARGET_PCREL. Previously we don't require PCREL
>> unset for any unsupported target/OS, so we need rs6000_pcrel_p() to
>>
This refactors things, separating load and store handing, adjusting
comments to reflect reality and removing some dead code.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
This is in preparation for a fix for PR37.
* tree-vect-data-refs.cc (vect_slp_analyze_store_depend
v1 -> v2:
1. Modify description information
Since the SLT instruction does not distinguish between 64-bit operations and
32-bit
operations under the 64-bit LoongArch architecture, if the operand of slt is
SImode,
the sign extension of the operand needs to be displayed.
But similar to t
On 25.08.23 10:26, Uros Bizjak via Gcc-patches wrote:
gcc/fortran/ChangeLog:
* match.cc (gfc_match_equivalence): Rename TRUE/FALSE to true/false.
* module.cc (check_access): Ditto.
* primary.cc (match_real_constant): Ditto.
* trans-array.cc (gfc_trans_allocate_array_storage):
gcc/fortran/ChangeLog:
* match.cc (gfc_match_equivalence): Rename TRUE/FALSE to true/false.
* module.cc (check_access): Ditto.
* primary.cc (match_real_constant): Ditto.
* trans-array.cc (gfc_trans_allocate_array_storage): Ditto.
(get_array_ctor_strlen): Ditto.
* trans-comm
gcc/c-family/ChangeLog:
* c-format.cc (read_any_format_width):
Rename TRUE/FALSE to true/false.
gcc/ChangeLog:
* caller-save.cc (new_saved_hard_reg):
Rename TRUE/FALSE to true/false.
(setup_save_areas): Ditto.
* gcc.cc (set_collect_gcc_options): Ditto.
(driver::build_
Hi Vineet.
Do you mind sending your patches inline using git send-email or some such ?
Never thought about that, what is the purpose of sending it in that way?
Of course, if it is more convenient for the community then I will send
through git.
On Fri, Aug 25, 2023 at 9:12 AM Vineet Gupta wro
vect_dissolve_slp_only_groups currently only expects loads, for stores
we have to make sure to mark the dissolved "groups" strided.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
PR tree-optimization/36
* tree-vect-loop.cc (vect_dissolve_slp_only_groups): For
Hi,
This patch refactors the codes of expand_cond_len_{unop,binop,ternop}.
Introduces a new unified function expand_cond_len_op to do the main thing.
The expand_cond_len_{unop,binop,ternop} functions only care about how
to pass the operands to the intrinsic patterns.
Best,
Lehua
gcc/ChangeLog:
On Thu, Aug 24, 2023 at 11:37 PM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Aug 24, 2023 at 9:16 PM Andrew Pinski via Gcc-patches
> wrote:
> >
> > Even though this is handled by other code inside both VRP and CCP,
> > sometimes we want to optimize this outside of VRP and CCP.
> > An exampl
Hi Robin,
There is one issue with this patch and the next few patches, the mask
policy for the generated vsetvl should be mu, which is currently done
wrong. I'm going to clear the expand_cond_len* functions before sending
the next version of these patches. Then these patches can directly use
When working on LLVM, I found this problem
https://github.com/llvm/llvm-project/issues/64974.
Maybe it's time for us to reconsider the way of getting GOT address
for PIC code.
1.Background[1]:
All of the accessing of global variables and normal function calls
needs help from GOT.
So normally, the
64 matches
Mail list logo