Kewen:
On 6/23/24 19:41, Kewen.Lin wrote:
> Hi,
>
> on 2024/6/22 00:15, Carl Love wrote:
>> GCC maintainers:
>>
>> version 2, update the dg options per the feedback. Retested the patch on
>> Power 10 with no regressions.
>>
>> This patch updates th
wen Lin wrote:
>>> Joseph pointed out "floating types should have their mode,
>>> not a poorly defined precision value" in the discussion[1],
>>> as he and Richi suggested, the existing macros
>>> {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE will be replaced with a
>&
GCC maintainers:
version 3, rebased on current mainline tree. Version 2 of the patch was out of
sync. Retested the patch on
Power 10 with no regressions.
version 2, update the dg options per the feedback. Retested the patch on Power
10 with no regressions.
This patch updates the dg options
Hi Kewen,
Sorry for not answering earlier - yes, this sounds good to me :) thanks
for taking care of that.
Best,
Arthur
On 6/21/24 12:36, Kewen.Lin wrote:
Hi Arthur,
on 2024/6/21 18:17, Arthur Cohen wrote:
Hi,
Sorry about the delay in my answer! The patch looks good to me :) Will you
-gimple, verify-control-flow and the likes.
--
This patch adds prime path coverage to gcc/gcov. It is a bit rough in a few
places, but I think all the main components are there and ready for some
feedback while I keep working on the details. First, a quick
introduction to path coverage, before I
Make gcov aware which edges are the true/false to more accurately
reconstruct the CFG. There are plenty of bits left in arc_info and it
opens up for richer reporting.
gcc/ChangeLog:
* gcov-io.h (GCOV_ARC_TRUE): New.
(GCOV_ARC_FALSE): New.
* gcov.cc (struct arc_info): Add
Without key terms like "masking" and "MC/DC" it is not at all obvious
what --conditions actually reports on, and there is no easy path for the
user to figure out. By at least including the two key terms MC/DC and
masking users have something to search for.
gcc/ChangeLog:
* gcov.cc
gcc/ChangeLog:
* doc/gcov.texi: Add MC/DC section.
---
gcc/doc/gcov.texi | 72 +++
1 file changed, 72 insertions(+)
diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index dc79bccb8cf..a9221738cce 100644
--- a/gcc/doc/gcov.texi
+++
The value vec objects are destroyed on exit, but release still needs to
be called explicitly.
gcc/ChangeLog:
* tree-profile.cc (find_conditions): Release vectors before
return.
---
gcc/tree-profile.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/tree-profile.cc
Hi All,
It looks like I forgot to check in the C++ frontend if a condition exist for the
loop being adorned with novector. This causes a segfault because cond isn't
expected to be null.
This fixes it by issuing the same kind of diagnostics we issue for the other
pragmas.
Bootstrapped Regtested
Add the --include and --exclude flags to gcov to control what functions
to report on. This is meant to make gcov more practical as an when
writing test suites or performing other coverage experiments, which
tends to focus on a few functions at the time. This really shines in
combination with the
on 2024/6/21 18:36, Kewen.Lin wrote:
> Hi Arthur,
>
> on 2024/6/21 18:17, Arthur Cohen wrote:
>> Hi,
>>
>> Sorry about the delay in my answer! The patch looks good to me :) Will you
>> push it as part of your patchset?
>>
>
> Thanks for the revie
comments
> >> below about part 6:
> >>
> >> If the TARGET_DLLIMPORT_DECL_ATTRIBUTES condition can be dropped, the
> >> series is OK from my POV with that change and with the changes above.
> >> Please get sign-off from an x86 maintainer too though.
> >
> > Thank you for the review and su
; Richard Biener
Subject: [PATCH v2 1/2] [APX CFCMOV] Support APX CFCMOV in if_convert pass
APX CFCMOV feature implements conditionally faulting which means
that all memory faults are suppressed when the condition code
evaluates to false and load or store a memory operand. Now we
could load
: RE: [PATCH v2] Vect: Support truncate after .SAT_SUB pattern in zip
> -Original Message-
> From: Li, Pan2
> Sent: Tuesday, June 25, 2024 7:06 AM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.
Ping. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
Peter
On 6/18/24 5:59 PM, Peter Bergner wrote:
> Updated patch. This passed bootstrap and regtesting on powerpc64le-linux
> with no regressions. Ok for trunk?
>
> Changes from v1:
> 1
> -Original Message-
> From: Li, Pan2
> Sent: Tuesday, June 25, 2024 7:06 AM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com;
> jeffreya...@gmail.com; pins...@gmail.com
> Subject: RE: [PA
vectorized code if a is limited to char unsigned. Of
course we can do that based on this patch.
Pan
-Original Message-
From: Tamar Christina
Sent: Tuesday, June 25, 2024 12:01 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail
for memory leaks.
Thanks Jeff. I just realized I wrote "varible" rather than "volatile" -
ah well.
Trivially fixable with a follow-up patch.
See patch 4 - write_custom_types loops through the custom_types linked
list, and removes and frees the head until it's empty.
On 6/17/24 6:17 PM, Mark Harmstone wrote:
Translates DW_TAG_structure_type DIEs into LF_STRUCTURE symbols, and
DW_TAG_class_type DIEs into LF_CLASS symbols.
gcc/
* dwarf2codeview.cc
(struct codeview_type): Add is_fwd_ref member.
(struct
This fixes most, but not all of the testsuite fallout from the
late-combine patch. Specifically in the vector space we're often able
to eliminate a broadcast of an scalar element across a vector. That
eliminates the vsetvl related to the broadcast, but more importantly
from the testsuite
Ping.
On Mon, Jun 10, 2024 at 07:19:19AM +0200, Stefan Schulze Frielinghaus wrote:
> Ping.
>
> On Fri, May 24, 2024 at 11:13:12AM +0200, Stefan Schulze Frielinghaus wrote:
> > This implements hard register constraints for inline asm. A hard register
> > constraint is of the form {regname} where
The problem here is even though we pass std namespace to lookup_template_class
as the context, it will look at the current scope for the name too.
The fix is to lookup the qualified name first and then use that
for lookup_template_class.
This is how std::initializer_list is handled in listify.
On Mon, Jun 24, 2024 at 7:35 PM Andrew Pinski wrote:
>
> On Mon, Jun 24, 2024 at 7:20 PM Andrew MacLeod wrote:
> >
> >
> > On 6/22/24 09:15, Richard Biener wrote:
> > > On Fri, Jun 21, 2024 at 3:02 PM Andrew MacLeod
> > > wrote:
> > >>
> -Original Message-
> From: Li, Pan2
> Sent: Tuesday, June 25, 2024 3:25 AM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com;
> jeffreya...@gmail.com; pins...@gmail.com
> Subject: RE: [PA
Hi,
This is the current version.
I haven't made any major changes to the original code, I think it will have
less impact on your code. And I think the current API is sufficient to support
the mode selection you mentioned, if you have any concerns you can mention
them. I can tweak it further.
Thanks for taking a look!
Things have changed after I posted this patch and LLVM doesn't support
this option now, so I think we don't need this patch any more.
Please see this PR and its references:
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/62.
On 2024/6/25 2:17, Palmer Dabbelt
Kewen:
On 6/18/24 20:03, Kewen.Lin wrote:
> Hi Carl,
>
> on 2024/6/14 03:40, Carl Love wrote:
>> GCC maintainers:
>>
>> Per the comments on patch 0004 from version 3, the removal of
>> The built-in __builtin_vsx_xvcvdpuxds_uns and __builtin_vsx_xvcvspuxws was
wrote "varible" rather than "volatile" - ah well.
See patch 4 - write_custom_types loops through the custom_types linked list,
and removes and frees the head until it's empty.
Mark
On Mon, Jun 24, 2024 at 7:20 PM Andrew MacLeod wrote:
>
>
> On 6/22/24 09:15, Richard Biener wrote:
> > On Fri, Jun 21, 2024 at 3:02 PM Andrew MacLeod wrote:
> >> This patch adds
> >>
> >> --param=vrp-block-limit=N
> >>
> >> Wh
5, 2024 4:00 AM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com;
jeffreya...@gmail.com; pins...@gmail.com
Subject: RE: [PATCH v2] Vect: Support truncate after .SAT_SUB pattern in zip
Hi,
> -Original Message-
> Fr
On 6/22/24 09:15, Richard Biener wrote:
On Fri, Jun 21, 2024 at 3:02 PM Andrew MacLeod wrote:
This patch adds
--param=vrp-block-limit=N
When the basic block counter for a function exceeded 'N' , VRP is
invoked with the new fast_vrp algorithm instead. This algorithm uses a
lot less
On 6/17/24 14:17, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
In r13-272 we hardened the *_PACK_EXPANSION and *_ARGUMENT_PACK macros.
That trips up here because make_pack_expansion returns error_mark_node
and we access that with
On 6/18/24 10:31, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13?
Makes sense to me, though probably the [meta.unary.prop] table should be
adjusted in the same way. Jonathan, what do you think?
-- >8 --
Here we started to ICE with r13-25: in
On 6/18/24 10:58, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
Since r13-3299, build_dynamic_cast_1 calls pushdecl which calls
duplicate_decls and that in this testcase emits the "conflicting
declaration" error and returns error_mark_node, so
> -Original Message-
> From: Tamar Christina
> Sent: Monday, June 24, 2024 10:12 PM
> To: Richard Biener ; Hu, Lin1
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao ;
> ubiz...@gmail.com
> Subject: RE: [PATCH 1/3 v3] vect: generate suitable convert insn for int ->
On 6/24/24 21:00, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >8 --
The capture proxy handling in finish_decltype_type added in r14-5330
was stripping the reference type of a capture proxy's captured variable,
which is desirable
On 6/24/24 21:00, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk? This fixes PR115358 whose testcase used a constexpr static
array variable, but it seems the general issue is not specific to
constexpr as illustrated by the below testcase.
On 6/18/24 20:03, Kewen.Lin wrote:
> Hi Carl,
>
> on 2024/6/14 03:40, Carl Love wrote:
>>
>> GCC maintainers:
>>
>> As noted the removal of __builtin_vsx_xvcvdpuxds_uns and
>> __builtin_vsx_xvcvspuxws was moved to patch 2 in the seris. The patch has
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk? This fixes PR115358 whose testcase used a constexpr static
array variable, but it seems the general issue is not specific to
constexpr as illustrated by the below testcase. Note that Clang
currently rejects the
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >8 --
The capture proxy handling in finish_decltype_type added in r14-5330
was stripping the reference type of a capture proxy's captured variable,
which is desirable for a by-value capture, but not for a
> + m = targetm.c.mode_for_floating_type (TI_FLOAT_TYPE);
> > > + size = GET_MODE_PRECISION (m).to_constant ();
> > > break;
> > > case GCC_JIT_TYPE_DOUBLE:
> > > - size = DOUBLE_TYPE_SIZE;
> > > + m = targetm.c.mod
In r14-5118-gc5db4d8ba5f3de I added a mechanism to automatically add
documentation URLs to quoted strings in diagnostics.
In r14-6920-g9e49746da303b8 I added a mechanism to generate URLs for
mentions of command-line options in quoted strings in diagnostics.
This patch does a similar thing
; Date: Sat Nov 4 14:39:19 2023 +0100
>
> C: Error message for incorrect use of static in array declarations.
Please use "[PATCH] c: ..." for C patches.
> Add an explicit error messages when c99's static is
> used without a size expression in an array declarator.
/rvv/base/setmem-2.c: New tests
* gcc.target/riscv/rvv/base/setmem-3.c: New tests
So I've updated this patch to work on the trunk and run it through
pre-commit CI. Results are clean and I've pushed this to the trunk.
Thanks for your patience.
jeff
Hi,
> -Original Message-
> From: pan2...@intel.com
> Sent: Monday, June 24, 2024 2:55 PM
> To: gcc-patches@gcc.gnu.org
> Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com;
> jeffreya...@gmail.com; pins...@gmail.com; Pan Li
> Subject: [PA
I didn't see this before. Sigh.
On Tue, Jan 02, 2024 at 09:47:11AM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Tue, Oct 24, 2023 at 07:49:10PM +0100, Richard Sandiford wrote:
> >> This patch adds a combine pass that runs la
On Jun 24, 2024, "Richard Earnshaw (lists)" wrote:
> A signed shift right on a 16-bit vector element by 15 would still
> yield -1
Yeah. Indeed, ISTM that we *could* have retained the clamping
transformation for *signed* shifts, since the clamping would only make a
difference in case of
.
Signed-off-by: Patrick O'Neill
---
Tested using rv64gcv_ztso/rv64id but relying on precommit to run the targets
there.
Beyond testing Ztso/Zalrsc this is also helpful for the Zabha patch I'm
working on. We can continue to test the atomic subword emulation
routines without specifing a -march
0 10:46, HAO CHEN GUI 写道:
>> Hi,
>> The builtin isinf is not folded at front end if the corresponding optab
>> exists. It causes the range evaluation failed on the targets which has
>> optab_isinf. For instance, range-sincos.c will fail on the targets which
>> has opt
On 6/24/24 09:11, David Faust wrote:
Ping.
Richard: I changed the option name as you asked but forgot to CC you on
the updated patch. Is the new option OK?
Indu: You had some minor comments on the prior version which I have
addressed, not sure whether you meant the rest of the patch was OK
On Fri, 22 Dec 2023 01:23:13 PST (-0800), wangpengcheng...@bytedance.com wrote:
These two options are negative alias of -m[no-]strict-align.
This matches LLVM implmentation.
gcc/ChangeLog:
* config/riscv/riscv.opt: Add option alias.
gcc/testsuite/ChangeLog:
*
.
Signed-off-by: Patrick O'Neill
---
Tested using rv64gcv_ztso/rv64id but relying on precommit to run the targets
there.
Beyond testing Ztso/Zalrsc this is also helpful for the Zabha patch I'm
working on. We can continue to test the atomic subword emulation
routines without specifing a -march
0 10:46, HAO CHEN GUI 写道:
>> Hi,
>> This patch adds the range op for builtin isfinite.
>>
>> Compared to previous version, the main change is to set the range to
>> 1 if it's finite number otherwise to 0.
>> https://gcc.gnu.org/pipermail/gcc-patches
On 24/06/2024 12:35, Alexandre Oliva wrote:
> On Jun 21, 2024, Christophe Lyon wrote:
>
>>> How about mentioning Christophe's simplification in the commit log?
>
>> For the avoidance of doubt: it's OK for me (but you don't need to
>> mention my name in fact ;-)
>
> Needing or not, I added it
rnal data structures.
>
> With the structural change in the prior patches, in particular the
> guarantee that CTF will always be fully emitted before any BTF
> translation occurs, there is no longer anything preventing generation
> of both CTF and BTF at the same time. This patch changes o
Ping.
Richard: I changed the option name as you asked but forgot to CC you on
the updated patch. Is the new option OK?
Indu: You had some minor comments on the prior version which I have
addressed, not sure whether you meant the rest of the patch was OK or
not, or if you had a chance to review
represent, once some optimization
like combine does some changes basing on it, it would cause
the unexpected consequence. The newly constructed test case
pr106069-1.c is a typical example for this issue.
So this patch is to fix the wrong RTL pattern, ensure the
associated RTL patterns becom
> -Original Message-
> From: Richard Biener
> Sent: Thursday, June 20, 2024 8:55 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; bin.ch...@linux.alibaba.com
> Subject: RE: [PATCH][ivopts]: perform affine fold on unsigned addressing modes
> known not t
On Jun 21, 2024, Christophe Lyon wrote:
>> How about mentioning Christophe's simplification in the commit log?
> For the avoidance of doubt: it's OK for me (but you don't need to
> mention my name in fact ;-)
Needing or not, I added it ;-)
>> > be accepted. (int16_t)32768 >> (int16_t)16 must
> -Original Message-
> From: Richard Biener
> Sent: Monday, June 24, 2024 1:34 PM
> To: Hu, Lin1
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao ;
> ubiz...@gmail.com
> Subject: RE: [PATCH 1/3 v3] vect: generate suitable convert insn for int ->
> int, float
&
SUB
} while (--n);
}
It will have gimple before vect pass, it cannot hit any pattern of
SAT_SUB and then cannot vectorize to SAT_SUB.
_2 = a_11 - b_12(D);
iftmp.0_13 = (short unsigned int) _2;
_18 = a_11 >= b_12(D);
iftmp.0_5 = _18 ? iftmp.0_13 : 0;
This patch would like to improve the pattern
> -Original Message-
> From: Richard Biener
> Sent: Thursday, June 20, 2024 8:49 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; bin.ch...@linux.alibaba.com
> Subject: RE: [PATCH][ivopts]: use affine_tree when comparing IVs during
> candidate
ds[reduc_index].length ())
> >> +{
> >> + /* For lane-reducing op covered by single-lane slp node, the input
> >> +vectype of the reduction PHI determines copies of vectorized
> >> def-use
> >> +cycles, which might be more th
On Thu, 20 Jun 2024, Hu, Lin1 wrote:
> > >else if (ret_elt_bits > arg_elt_bits)
> > > modifier = WIDEN;
> > >
> > > + if (supportable_convert_operation (code, ret_type, arg_type, ))
> > > +{
> > > + g = gimple_build_assign (lhs, code1, arg);
> > > + gsi_replace (gsi, g,
KNOWN_LOCATION", and so it gives up on the warning.
>
> Root cause is that the edge in question is created by gimple_split_edge
> within the loop optimizer, and gimple_split_edge creates the new edge
> with UNKNOWN_LOCATION.
>
> This patch tweaks gimple_split_edge to copy
24-May/650405.html
>
> This patch fixes PR tree-optimization/113673, a P2 ice-on-valid regression
> caused by load merging of (ptr[0]<<8)+ptr[1] when -ftrapv has been
> specified. When the operator is | or ^ this is safe, but for addition
> of signed integer types, a trap may be gene
On Mon, Jun 24, 2024 at 1:34 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Mon, Jun 24, 2024 at 10:03 AM Richard Sandiford
> > wrote:
> >>
> >> Richard Biener writes:
> >> > On Sat, Jun 22, 2024 at 6:50 PM Richard Sandiford
> >> >> The traditional (and IMO correct) way to
The following prevents SLP CSE to create new cycles which happened
because of a 1:1 permute node being present where its child was then
CSEd to the permute node. Fixed by making a node only available to
CSE to after recursing.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Richard Biener writes:
> On Mon, Jun 24, 2024 at 10:03 AM Richard Sandiford
> wrote:
>>
>> Richard Biener writes:
>> > On Sat, Jun 22, 2024 at 6:50 PM Richard Sandiford
>> >> The traditional (and IMO correct) way to handle this is to make the
>> >> pattern reserve the temporary registers that
nsible way to achieve what the patch does?
Yeah, it conflicts somewhat with the existing -finline-limit[-=] flags,
so possibly another name (-finline-as=O3?) is needed.
Richard.
> Signed-off-by: Rama Malladi
> ---
> gcc/common.opt | 5 +
> gcc/doc/invoke.texi | 18 ++
On Mon, Jun 24, 2024 at 10:03 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Sat, Jun 22, 2024 at 6:50 PM Richard Sandiford
> >> The traditional (and IMO correct) way to handle this is to make the
> >> pattern reserve the temporary registers that it needs, using
> >>
From: Rama Malladi
Signed-off-by: Rama Malladi
---
gcc/common.opt | 5 +
gcc/doc/invoke.texi | 18 +-
gcc/opts.cc | 17 -
3 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/gcc/common.opt b/gcc/common.opt
index
This patch tries to address the issue in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115413 .
It does so by adding another pass devirtualize-typeid which does the same thing
as the value range propagation pass, except
* in the true branch of a conditional of the form `typeid (a) == typeid (b
On 6/23/24 16:40, Pali Rohár wrote:
Add missing msvcr40* and msvcrtd* cases to CPP_SPEC and
document missing _UCRT macro and msvcr71* case.
Fixes commit 453cb585f0f8673a5d69d1b420ffd4b3f53aca00.
Thanks, pushed to master branch.
Hi Dave,
May I ask if you still have some concerns on this patch with some
replies to your previous questions?
BR,
Kewen
on 2024/6/14 10:16, Kewen.Lin wrote:
> Hi David,
>
> on 2024/6/13 21:44, David Malcolm wrote:
>> On Sun, 2024-06-02 at 22:01 -0500, Kewen Lin wrote:
>>
s intended to represent, once some optimization
like combine does some changes basing on it, it would cause
the unexpected consequence. The newly constructed test case
pr106069-2.c is a typical example for this issue on element type
short.
So this patch is to fix the wrong RTL pattern, ensure the
asso
Richard Biener writes:
> On Sat, Jun 22, 2024 at 6:50 PM Richard Sandiford
>> The traditional (and IMO correct) way to handle this is to make the
>> pattern reserve the temporary registers that it needs, using match_scratches.
>> rs6000 has many examples of this. E.g.:
>>
>>
On Jun 24 2024, Mikael Morin wrote:
> tree-pretty-print.cc's op_symbol_code handles them as:
>
> case TRUTH_AND_EXPR:
> case TRUTH_ANDIF_EXPR:
> return "&&";
>
> so no, I don't think they are differentiated.
Only because C does not have a TRUTH_AND_EXPR operator.
--
Andreas
with the tests that
> they are better aligned with.
>
> This patch is dependent on the two patches to update the dg arguments for
> test files altivec-1-runnable.c and altivec-2-runnable.c being accepted and
> committed before this patch.
>
> The patch has been tested on Power 10 with no
Le 23/06/2024 à 22:58, Harald Anlauf a écrit :
Dear all,
the attached patch fixes issues exhibited by the testcase in comment#19 of
PR55978.
First, when passing an allocatable optional dummy array to an optional dummy,
we need to prevent accessing the data component of the array when
Hi Carl,
on 2024/6/22 00:15, Carl Love wrote:
> GCC maintainers:
>
> version 4: Additional dg option updates per the feedback. Retested the
> patch on Power 10, no regressions.
>
> version 3: Updated per the feedback from Peter, Kewen and Segher. Note,
> Peter sugges
Hi
Still no time ?
Thanks
On 06/06/2024 19:02, François Dumont wrote:
No chance ?
On 22/05/2024 06:50, François Dumont wrote:
Ping ?
On 13/05/2024 06:33, François Dumont wrote:
libstdc++: [_Hashtable] Fix some implementation inconsistencies
Get rid of the different usages of the
Hi,
on 2024/6/22 00:15, Carl Love wrote:
> GCC maintainers:
>
> version 2, update the dg options per the feedback. Retested the patch on
> Power 10 with no regressions.
>
> This patch updates the dg options.
>
> The patch has been tested on Power 10 with no regressi
On 6/17/24 6:17 PM, Mark Harmstone wrote:
Translates DW_TAG_enumeration_type DIEs into LF_ENUM symbols.
gcc/
* dwarf2codeview.cc (MAX_FIELDLIST_SIZE): Define.
(struct codeview_integer): New structure.
(struct codeview_subtype): Likewise
On 6/17/24 6:17 PM, Mark Harmstone wrote:
Translate DW_TAG_const_type and DW_TAG_volatile_type DIEs into
LF_MODIFIER symbols.
gcc/
* dwarf2codeview.cc
(struct codeview_custom_type): Add lf_modifier to union.
(write_cv_padding, write_lf_modifier):
On 6/17/24 6:17 PM, Mark Harmstone wrote:
Translates DW_TAG_pointer_type DIEs into LF_POINTER symbols, which get
output into the .debug$T section.
gcc/
* dwarf2codeview.cc (FIRST_TYPE): Define.
(struct codeview_custom_type): New structure.
On 6/17/24 6:17 PM, Mark Harmstone wrote:
gcc/
* dwarf2codeview.cc (get_type_num): Handle typedefs.
Thanks. I've pushed this to the trunk.
jeff
.
Thanks. I've pushed this patch to the trunk.
jeff
On 6/17/24 6:17 PM, Mark Harmstone wrote:
Parse the DW_TAG_variable DIEs, and outputs S_GDATA32 (for global variables)
and S_LDATA32 (static global variables) symbols into the .debug$S section.
gcc/
* dwarf2codeview.cc (S_LDATA32, S_GDATA32): Define.
(struct
> I think the check for TYPE_UNSIGNED should be of TREE_TYPE (@0) rather
> than type here.
Changed
> Or maybe you need `types_match (type, TREE_TYPE (@0))` too.
And use tree_nop_conversion_p (type, TREE_TYPE (@0)) and add view_convert to
rshift.
Bootstrapped and regtested on
Dear all,
the attached patch fixes issues exhibited by the testcase in comment#19 of
PR55978.
First, when passing an allocatable optional dummy array to an optional dummy,
we need to prevent accessing the data component of the array when the argument
is not present, and pass a null pointer
ing this optimization.
The code snippet mentioned above is also included in this patch as a new Zicond
testcase.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_expand_conditional_move): Add a
CONST0_RTX check.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zicond-ice-3.c:
This adds an explicit error message for [static] and [static*]
(the same as clang has) instead of the generic "error: expected
expression before ']' token", which is not entirely accurate.
For function definitions the subsequent error "[*] can not be
used outside function prototype scope" is
Add missing msvcr40* and msvcrtd* cases to CPP_SPEC and
document missing _UCRT macro and msvcr71* case.
Fixes commit 453cb585f0f8673a5d69d1b420ffd4b3f53aca00.
gcc/
* config/i386/mingw-w64.h (CPP_SPEC): Add missing -mcrtdll=
cases: msvcr40*, msvcrtd*.
* config/mingw/mingw32.h
be transformed as:
>> +
>> + vector<4> int sum_v0 = { 0, 0, 0, 0 };
>> + vector<4> int sum_v1 = { 0, 0, 0, 0 };
>> + vector<4> int sum_v2 = { 0, 0, 0, 0 };
>> + vector<4> int sum_v3 = { 0, 0, 0, 0 };
c: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com;
jeffreya...@gmail.com; rdapp@gmail.com
Subject: Re: [PATCH v1] Ifcvt: Add cond tree reconcile for truncated .SAT_SUB
On Fri, Jun 21, 2024 at 4:45 PM Li, Pan2 wrote:
>
> Thanks Richard for suggestion, tried
The compare_repeat_factors comparator fails qsort checking eventually
because it uses rf2->rank - rf1->rank to compare unsigned numbers
which causes issues for ranks that interpret negative as signed.
Fixed by re-writing the obvious way. I've also fixed the count
comparison which suffers from
This should fix the test failures introduced by the fix for PR115157.
Tested on x86_64 and also tested with -m32.
Fix test errors introduced with fix for PR115157.
Fix tests introduced when fixing PR115157 that assume
sizeof(enum)==sizeof(int)
by adding the flag
The following makes sure to always CSE when there's SLP_TREE_SCALAR_STMTS
as otherwise a chain of two-operator node operations can result in
exponential behavior of the CSE process as likely seen when building
510.parest on aarch64.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
901 - 1000 of 246018 matches
Mail list logo
