On Tue, Dec 5, 2023 at 7:50 PM Marek Polacek wrote:
>
> Tested with .../configure --target=c6x-uclinux [...] && make all-gcc,
> ok for trunk?
OK
> -- >8 --
> Currently, cross-compiling with --target=c6x-uclinux (and several other)
> fails due to:
>
> ../../src/gcc/config/linux.h:221:45: error:
On Wed, 6 Dec 2023, Tamar Christina wrote:
> Hi All,
>
> While waiting for reviews I've continued to run more test.
> In this case this was one found running 32-bit systems.
>
> While we calculate the right latch count for the epilog,
> the vectorizer overrides SCEV and so unrolling goes wrong.
Hi,
Following up the discussion of V2 patches in
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639368.html,
this patch series add early clobber for all TImode NDD alternatives
to avoid any potential overlapping between dest register and src
register/memory. Also use get_attr_isa (insn) =
From: Kong Lingling
For *one_cmplsi2_2_zext, it will be splitted to xor, so its NDD form will be
added together with xor NDD support.
gcc/ChangeLog:
* config/i386/i386.md (one_cmpl2): Add new constraints for NDD
and adjust output template.
(*one_cmpl2_1): Likewise.
From: Kong Lingling
APX NDD provides an extra destination register operand for several gpr
related legacy insns, so a new alternative can be adopted to operand1
with "r" constraint.
This first patch supports NDD for add instruction, and keeps to use lea
when all operands are registers since lea
NDD uses evex prefix, so when segment prefix is also applied, the instruction
could excceed its 15byte limit, especially adding immediates. This could happen
when "e" constraint accepts any UNSPEC_TPOFF/UNSPEC_NTPOFF constant and it will
add the offset to segment register, which will be encoded usi
From: Kong Lingling
Similar to AND insn, two splitters need to be adjusted to prevent
misoptimizaiton for NDD OR/XOR.
Also adjust *one_cmplsi2_2_zext and its corresponding splitter that will
generate xor insn.
gcc/ChangeLog:
* config/i386/i386.md (3): Add new alternative for NDD
From: Kong Lingling
Legacy adc patterns are commonly adopted to TImode add, when extending TImode
add to NDD version, operands[0] and operands[1] can be different, so extra move
should be emitted if those patterns have optimization when adding const0_rtx.
For TImode insn, there could be register
From: Kong Lingling
Similar to *add3_doubleword, operands[1] may not equal to operands[0] so
extra move and earlyclobber are required.
gcc/ChangeLog:
* config/i386/i386.md (*sub3_doubleword): Add new alternative for
NDD, adopt '&' modifier to NDD dest and emit move when operands
From: Kong Lingling
gcc/ChangeLog:
* config/i386/i386-expand.cc (ix86_expand_unary_operator): Add use_ndd
parameter and adjust for NDD.
* config/i386/i386-protos.h: Add use_ndd parameter for
ix86_unary_operator_ok and ix86_expand_unary_operator.
* config/i
From: Kong Lingling
For NDD form AND insn, there are three splitter fixes after extending legacy
patterns.
1. APX NDD does not support high QImode registers like ah, bh, ch, dh, so for
some optimization splitters that generates highpart zero_extract for QImode
need to be prohibited under NDD pat
gcc/ChangeLog:
* config/i386/i386.md (*movcc_noc): Extend with new constraints
to support NDD.
(*movsicc_noc_zext): Likewise.
(*movsicc_noc_zext_1): Likewise.
(*movqicc_noc): Likewise.
gcc/testsuite/ChangeLog:
* gcc.target/i386/apx-ndd-cmov.c: New
For shld/shrd insns, the old pattern use match_dup 0 as its shift src and use
+r*m as its constraint. To support NDD we added new define_insns to handle NDD
form pattern with extra input and dest operand to be fixed in register.
gcc/ChangeLog:
* config/i386/i386.md (x86_64_shld_ndd): New
From: Kong Lingling
gcc/ChangeLog:
* config/i386/i386.md: (addsi_1_zext): Add new alternatives for
NDD and adjust output templates.
(*add_2): Likewise.
(*addsi_2_zext): Likewise.
(*add_3): Likewise.
(*addsi_3_zext): Likewise.
(*adddi_4): Li
For left shift, there is an optimization TARGET_DOUBLE_WITH_ADD that shl
1 can be optimized to add. As NDD form of add requires src operand to
be register since NDD cannot take 2 memory src, we currently just keep
using NDD form shift instead of add.
The optimization TARGET_SHIFT1 will try to remo
Similar to LSHIFT, rshift do not need to omit $1 for NDD form.
gcc/ChangeLog:
* config/i386/i386.md (ashr3_cvt): Extend with new
alternatives to support NDD, and adjust output templates.
(*ashr3_1): Likewise for SI/DI mode.
(*lshr3_1): Likewise.
(*si3_1_zex
From: Kong Lingling
gcc/ChangeLog:
* config/i386/i386-expand.cc (ix86_fixup_binary_operands_no_copy):
Add use_ndd parameter and parse it.
* config/i386/i386-protos.h (ix86_fixup_binary_operands_no_copy):
Change define.
* config/i386/i386.md (sub3): Add new
For TImode shifts, they are splitted by splitter functions, which assume
operands[0] and operands[1] to be the same. For the NDD alternative the
assumption may not be true so add split functions for NDD to emit the NDD
form instructions, and omit the handling of !64bit target split.
Although the N
gcc/ChangeLog:
* config/i386/i386.md (*3_1): Extend with a new
alternative to support NDD for SI/DI rotate, and adjust output
template.
(*si3_1_zext): Likewise.
(*3_1): Likewise for QI/HI modes.
(rcrsi2): Likewise, and use nonimmediate_operand for op
Hi,
SImode in float register is supported on P7 above. It causes "fctiw"
can't be generated on old 32-bit processors as the output operand of
fctiw insn is an SImode in float/double register. This patch fixes the
problem by adding one expand and one insn pattern for fctiw. The output
of new patte
On Wed, 6 Dec 2023, Tamar Christina wrote:
> Hi All,
>
> While waiting for reviews I found this case where both loop exit needs to go
> to
> epilogue loop, but there was an IV related variable that was used in the
> scalar
> iteration as well.
>
> vect_update_ivs_after_vectorizer then blew the
Hi,
The "fctid" is supported on 64-bit Power processors and powerpc 476. It
need a guard to check it. The patch fixes the issue.
Compared with last version,
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/638859.html
the main change is to define TARGET_FCTID to POWERPC64 or PPC476. Als
On Mon, 6 Nov 2023, Tamar Christina wrote:
> Hi All,
>
> This sets LOOP_VINFO_EARLY_BREAKS and does some misc changes so the other
> patches are self contained.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
>
在 2023/12/6 下午3:04, Jiahao Xu 写道:
LoongArch V1.1 adds support for approximate instructions, which are utilized
along with additional
Newton-Raphson steps implement single precision floating-point division, square
root and reciprocal
square root operations for better throughput.
The patches a
On Mon, 6 Nov 2023, Tamar Christina wrote:
> Hi All,
>
> This finishes wiring that didn't fit in any of the other patches.
> Essentially just adding related changes so peeling for early break works.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?
>
> Than
Hi,
CC'd Thomas.
FYI the newly added file libgcc/strub.c of this patch (aka commit
r14-6201-gf0a90c7d7333fc )
causes that nvptx does not bootstrap, failing with:
./gcc/as -v -o strub.o strub.s
Verifying sm_30 code with sm_50 code generation.
ptxas -c -o /dev/null strub.o --gpu-name sm_50 -O0
On Wed, 6 Dec 2023 at 02:21, Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu. Are the library test changes OK?
Sure, they seem fine.
> A reduced
> example of the issue is at https://godbolt.org/z/cPxrcnKjG
>
> -- 8< --
>
> Looks like we implemented option 1 (skip the object parameter) for C
> > Hi All,
> >
> > While waiting for reviews I found this case where both loop exit needs to
> > go to
> > epilogue loop, but there was an IV related variable that was used in the
> > scalar
> > iteration as well.
> >
> > vect_update_ivs_after_vectorizer then blew the value away and replaced it
On Wed, Dec 06, 2023 at 07:33:21AM +, waffl3x wrote:
> Here is the next version, it feels very close to finished. As before, I
> haven't ran a bootstrap or the full testsuite yet but I did run the
> explicit-obj tests which completed as expected.
>
> There's a few test cases that still need to
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, December 6, 2023 8:18 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH 13/21]middle-end: Update loop form analysis to support
> early
> break
>
> On Mon, 6 Nov 2023, Ta
> -Original Message-
> From: Tamar Christina
> Sent: Wednesday, December 6, 2023 8:48 AM
> To: Richard Biener
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: RE: [PATCH]middle-end: Fix peeled vect loop IV values.
>
> > > Hi All,
> > >
> > > While waiting for reviews
According to spec, fmv.h checks if the input operands are correctly
NaN-boxed. If not, the input value is treated as an n-bit canonical NaN.
This patch fixs the issue that operands returned by soft-fp16 libgcc
(i.e., __truncdfhf2) was not correctly NaN-boxed.
*gcc/ChangeLog:*
* config/riscv/ri
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, December 6, 2023 8:32 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH 12/21]middle-end: Add remaining changes to peeling and
> vectorizer to support early breaks
>
> On
On Wed, 6 Dec 2023, Tamar Christina wrote:
> > > Hi All,
> > >
> > > While waiting for reviews I found this case where both loop exit needs to
> > > go to
> > > epilogue loop, but there was an IV related variable that was used in the
> > > scalar
> > > iteration as well.
> > >
> > > vect_update_
On Wed, 6 Dec 2023, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Wednesday, December 6, 2023 8:18 AM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> > Subject: Re: [PATCH 13/21]middle-end: Update loop form analysis
Hi,
The issue mentioned in PR112525 would be able to be handled by
updating dse.cc to treat arg_pointer_rtx similarly with frame_pointer_rtx.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271#c10 also mentioned
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, December 6, 2023 9:15 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: RE: [PATCH 13/21]middle-end: Update loop form analysis to support
> early
> break
>
> On Wed, 6 Dec 2023, Ta
On Wed, 6 Dec 2023, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Wednesday, December 6, 2023 8:32 AM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> > Subject: Re: [PATCH 12/21]middle-end: Add remaining changes to
On Wednesday, December 6th, 2023 at 1:48 AM, Jakub Jelinek
wrote:
>
>
> On Wed, Dec 06, 2023 at 07:33:21AM +, waffl3x wrote:
>
> > Here is the next version, it feels very close to finished. As before, I
> > haven't ran a bootstrap or the full testsuite yet but I did run the
> > exp
On Wed, 6 Dec 2023, Tamar Christina wrote:
> > > > is the exit edge you are looking for without iterating over all loop
> > > > exits.
> > > >
> > > > > + gimple *tmp_vec_stmt = vec_stmt;
> > > > > + tree tmp_vec_lhs = vec_lhs;
> > > > > + tree tmp_bitstart = b
On Wed, 6 Dec 2023, Tamar Christina wrote:
> > > > +
> > > > + tree truth_type = truth_type_for (vectype_op); machine_mode mode =
> > > > + TYPE_MODE (truth_type); int ncopies;
> > > > +
> >
> > more line break issues ... (also below, check yourself)
> >
> > shouldn't STMT_VINFO_VECTYPE alrea
Hi,
Update the patch to fix problems in the test case:
- add "-details" option to the dump command
- add dg-require and target filters to avoid potential failures on platforms
that don't support vectorization.
Thanks,
-Hao
gcc/ChangeLog:
PR tree-optimization/112774
* tree-pre
On Wed, 6 Dec 2023, Tamar Christina wrote:
> > > > + && LOOP_VINFO_LOOP_IV_COND (loop_vinfo) != cond)
> > > > + *relevant = vect_used_in_scope;
> >
> > but why not simply mark all gconds as vect_used_in_scope?
> >
>
> We break outer-loop vectorization since doing so would pull the
Hi!
When libgcc is being built in --disable-tls configuration or on
a target without native TLS support, one gets annoying warnings:
../../../../libgcc/emutls.c:61:7: warning: conflicting types for built-in
function ‘__emutls_get_address’; expected ‘void *(void *)’
[-Wbuiltin-declaration-mismatc
> On Nov 30, 2023, Jan Hubicka wrote:
>
> >> + if (VAR_P (replaced))
> >> + varpool_node::create_alias (sym_node->decl, replacement);
> >> + else
> >> + cgraph_node::create_alias (sym_node->decl, replacement);
>
> Unfortunately, this change didn't work. Several of the C++ tests
> re
Hi,
I am sorry for sending this late. I think the ipa changes are generally
fine. There are few things which was not clear to me.
> for gcc/ChangeLog
>
> * Makefile.in (OBJS): Add ipa-strub.o.
> (GTFILES): Add ipa-strub.cc.
> * builtins.def (BUILT_IN_STACK_ADDRESS): New.
>
On Wed, 6 Dec 2023, Jakub Jelinek wrote:
> Hi!
>
> When libgcc is being built in --disable-tls configuration or on
> a target without native TLS support, one gets annoying warnings:
> ../../../../libgcc/emutls.c:61:7: warning: conflicting types for built-in
> function ?__emutls_get_address?; exp
Follow up to this, bootstrapped and tested with no regressions.
On Wednesday, December 6th, 2023 at 12:33 AM, waffl3x
wrote:
>
>
> Here is the next version, it feels very close to finished. As before, I
> haven't ran a bootstrap or the full testsuite yet but I did run the
> explicit-obj test
Hi Alexandre!
On 2023-12-06T09:36:33+0100, Tobias Burnus wrote:
> FYI the newly added file libgcc/strub.c of this patch (aka commit
> r14-6201-gf0a90c7d7333fc )
> causes that nvptx does not bootstrap, failing with:
('s%bootstrap%build'.)
> ./gcc/as -v -o strub.o strub.s
> Verifying sm_30 code
Hi Julian,
LGTM, except for:
* The 'target exit data' handling - comments below - looks a bit
fishy/inconsistent.
I intent to have a closer look with more code context, but maybe you
should have a look at it as well.
BTW: Fortran deep-mapping is not yet on mainline. Are you aware of
changes or
On Tue, 5 Dec 2023 at 06:18, Marek Polacek wrote:
>
> On Mon, Dec 04, 2023 at 04:49:29PM -0500, Jason Merrill wrote:
> > On 12/4/23 15:23, Marek Polacek wrote:
> > > +/* FN is not a consteval function, but may become one. Remember to
> > > + escalate it after all pending templates have been ins
On Wed, Dec 6, 2023 at 10:46 AM Hao Liu OS wrote:
>
> Hi,
>
> Update the patch to fix problems in the test case:
> - add "-details" option to the dump command
> - add dg-require and target filters to avoid potential failures on platforms
> that don't support vectorization.
Interesting simple t
On Mon, 20 Nov 2023 at 15:28, Florian Weimer wrote:
>
> The change to build_conditional_expr drops the downgrade
> from a pedwarn to warning for builtins for C99 and later
> language dialects. It remains a warning in C89 mode (not
> a permerror), as the -std=gnu89 -fno-permissive test shows.
Hi F
On Wed, Dec 6, 2023 at 9:08 AM Hongyu Wang wrote:
>
> Hi,
>
> Following up the discussion of V2 patches in
> https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639368.html,
> this patch series add early clobber for all TImode NDD alternatives
> to avoid any potential overlapping between dest
* Yang Yujie:
> From: Yang Yujie
> Subject: [PATCH] testsuite: Adjust for the new permerror
> -Wincompatible-pointer-types
> To: gcc-patches@gcc.gnu.org
> Cc: r...@cebitec.uni-bielefeld.de, mikest...@comcast.net, fwei...@redhat.com,
> Yang Yujie
> Date: Wed, 6 Dec 2023 10:29:31 +0800 (9 hours
* Prathamesh Kulkarni:
> On Mon, 20 Nov 2023 at 15:28, Florian Weimer wrote:
>>
>> The change to build_conditional_expr drops the downgrade
>> from a pedwarn to warning for builtins for C99 and later
>> language dialects. It remains a warning in C89 mode (not
>> a permerror), as the -std=gnu89 -
On Mon, Sep 18, 2023 at 11:26:49PM +0200, Martin Uecker via Gcc-patches wrote:
> Add option Walloc-size that warns about allocations that have
> insufficient storage for the target type of the pointer the
> storage is assigned to.
>
> PR c/71219
> gcc:
> * doc/invoke.texi: Document -Wa
Hi Alexandre!
On 2023-12-06T02:28:42-0300, Alexandre Oliva wrote:
> libsupc++: try cxa_thread_atexit_impl at runtime
>
> g++.dg/tls/thread_local-order2.C fails when the toolchain is built for
> a platform that lacks __cxa_thread_atexit_impl, even if the program is
> built and run using that toolc
On Wed, 2023-12-06 at 13:24 +0100, Jakub Jelinek wrote:
> I wonder if this part isn't too pedantic or more of a code style.
> Some packages fail to build with this with -Werror because they do
> struct S *p = calloc (sizeof (struct S), 1);
> or similar. It is true that calloc arguments are docum
This series adds support for function multiversioning on aarch64.
Patches 1-3 are already approved, with just one minor change from the previous
version of patch 1 suggested by Richard Sandiford.
Patches 4-5 are updated based on Richard's reviews. The only major change is
replacing the EXPANDED_
This is added to enable function multiversioning, but can also be used
directly. The interface is chosen to match that used in LLVM's
compiler-rt, to facilitate cross-compiler compatibility.
The content of the patch is derived almost entirely from Pavel's prior
contributions to compiler-rt/lib/bu
This patch changes the handling of mutual exclusions involving the
target and target_clones attributes to use the generic attribute
exclusion lists. Additionally, the duplicate handling for the
always_inline and noinline attribute exclusion is removed.
The only change in functionality is the choi
Change the handling of some attribute mutual exclusions to use the
generic attribute exclusion lists, and fix some asymmetric exclusions by
adding the exclusions for always_inline after noinline or target_clones.
Aside from the new always_inline exclusions, the only change is
functionality is the
This patch adds support for the "target_version" attribute to the middle
end and the C++ frontend, which will be used to implement function
multiversioning in the aarch64 backend.
On targets that don't use the "target" attribute for multiversioning,
there is no conflict between the "target" and "t
This adds initial support for function multiversioning on aarch64 using
the target_version and target_clones attributes. This loosely follows
the Beta specification in the ACLE [1], although with some differences
that still need to be resolved (possibly as follow-up patches).
Existing function mu
On Wed, Dec 06, 2023 at 08:31:12PM +0800, Xi Ruoyao wrote:
> On Wed, 2023-12-06 at 13:24 +0100, Jakub Jelinek wrote:
> > I wonder if this part isn't too pedantic or more of a code style.
> > Some packages fail to build with this with -Werror because they do
> > struct S *p = calloc (sizeof (struc
As PR112855 mentioned, the VSETVL PASS insert vsetvli in unexpected location.
Due to 2 reasons:
1. incorrect transparant computation LCM data. We need to check VL operand defs
and uses.
2. incorrect fusion of unrelated edge which is the edge never reach the vsetvl
expression.
PR target/
Am Mittwoch, dem 06.12.2023 um 13:57 +0100 schrieb Jakub Jelinek:
> On Wed, Dec 06, 2023 at 08:31:12PM +0800, Xi Ruoyao wrote:
> > On Wed, 2023-12-06 at 13:24 +0100, Jakub Jelinek wrote:
> > > I wonder if this part isn't too pedantic or more of a code style.
> > > Some packages fail to build with t
Am Mittwoch, dem 06.12.2023 um 14:34 +0100 schrieb Martin Uecker:
> Am Mittwoch, dem 06.12.2023 um 13:57 +0100 schrieb Jakub Jelinek:
> > On Wed, Dec 06, 2023 at 08:31:12PM +0800, Xi Ruoyao wrote:
> > > On Wed, 2023-12-06 at 13:24 +0100, Jakub Jelinek wrote:
> > > > I wonder if this part isn't too
This is an RTL pass that detects store forwarding from stores to larger loads
(load pairs).
This optimization is SPEC2017-driven and was found to be beneficial for some
benchmarks,
through testing on ampere1/ampere1a machines.
For example, it can transform cases like
str d5, [sp, #320]
fmul d
On Wed, 6 Dec 2023 at 12:30, Thomas Schwinge wrote:
>
> Hi Alexandre!
>
> On 2023-12-06T02:28:42-0300, Alexandre Oliva wrote:
> > libsupc++: try cxa_thread_atexit_impl at runtime
> >
> > g++.dg/tls/thread_local-order2.C fails when the toolchain is built for
> > a platform that lacks __cxa_thread_
On 12/6/23 01:02, waffl3x wrote:
On Tuesday, December 5th, 2023 at 9:36 PM, Jason Merrill
wrote:
On 12/5/23 23:23, waffl3x wrote:
Does CWG2834 effect this weird edge case?
2834 affects all partial ordering with explicit object member functions;
Both in relation to each other, and to iobj
LGTM.
+ /* Don't perform earliest fusion on unrelated edge. */
+ if (bitmap_count_bits (e) != 1)
+ continue;
This could still use a comment why e is "unrelated" in that case
(no v2 needed).
Regards
Robin
On Tue, Dec 05, 2023 at 11:01:20AM -0500, Jason Merrill wrote:
> > And there is another thing I wonder about: with -Wno-attributes= we are
> > supposed to ignore the attributes altogether, but we are actually still
> > warning about them when we emit these generic warnings about ignoring
> > all at
On Wed, Dec 06, 2023 at 02:34:10PM +0100, Martin Uecker wrote:
> > Further I think
> > "size less than or equal to the size requested"
> > is quite ambiguous in the calloc case, isn't the size requested in the
> > calloc case actually nmemb * size rather than just size?
>
> This is unclear but it
As PR112855 mentioned, the VSETVL PASS insert vsetvli in unexpected location.
Due to 2 reasons:
1. incorrect transparant computation LCM data. We need to check VL operand defs
and uses.
2. incorrect fusion of unrelated edge which is the edge never reach the vsetvl
expression.
PR target/
Attached a new patch with these changes.
On Mon, 4 Dec 2023 at 12:15, Jonathan Wakely wrote:
> On Sat, 2 Dec 2023 at 21:24, Costas Argyris wrote:
> >
> > Use std::vector instead of malloc'd pointer
> > to get automatic freeing of memory.
>
> You can't include there. Instead you need to define
>
Any comments on this approach?
-- >8 --
This makes constexpr std::vector (mostly) work in Debug Mode. All safe
iterator instrumentation and checking is disabled during constant
evaluation, because it requires mutex locks and calls to non-inline
functions defined in libstdc++.so. It should be OK t
On 2023-12-06 09:21, Jakub Jelinek wrote:
On Wed, Dec 06, 2023 at 02:34:10PM +0100, Martin Uecker wrote:
Further I think
"size less than or equal to the size requested"
is quite ambiguous in the calloc case, isn't the size requested in the
calloc case actually nmemb * size rather than just size?
On Wed, Dec 6, 2023 at 2:48 PM Manos Anagnostakis
wrote:
>
> This is an RTL pass that detects store forwarding from stores to larger loads
> (load pairs).
>
> This optimization is SPEC2017-driven and was found to be beneficial for some
> benchmarks,
> through testing on ampere1/ampere1a machines
On Wed, Dec 06, 2023 at 05:09:21PM +0530, Prathamesh Kulkarni wrote:
> On Tue, 5 Dec 2023 at 06:18, Marek Polacek wrote:
> >
> > On Mon, Dec 04, 2023 at 04:49:29PM -0500, Jason Merrill wrote:
> > > On 12/4/23 15:23, Marek Polacek wrote:
> > > > +/* FN is not a consteval function, but may become on
Tested on x86_64-pc-linux-gnu with --enable-languages=c,c++ and
additional -Wformat to CXXFLAGS.
-- >8 --
Fix testsuite when compiling with -Wformat. Use nonnull arguments so
that -Wformat does not cause extraneous output to be reported as an
error.
FAIL: tr1/8_c_compatibility/cinttypes/function
On Wed, Dec 06, 2023 at 02:29:25PM +, Costas Argyris wrote:
> Attached a new patch with these changes.
>
> On Mon, 4 Dec 2023 at 12:15, Jonathan Wakely wrote:
>
> > On Sat, 2 Dec 2023 at 21:24, Costas Argyris wrote:
> > >
> > > Use std::vector instead of malloc'd pointer
> > > to get automat
On Wed, 6 Dec 2023 at 13:53, Jonathan Wakely wrote:
>
> On Wed, 6 Dec 2023 at 12:30, Thomas Schwinge wrote:
> >
> > Hi Alexandre!
> >
> > On 2023-12-06T02:28:42-0300, Alexandre Oliva wrote:
> > > libsupc++: try cxa_thread_atexit_impl at runtime
> > >
> > > g++.dg/tls/thread_local-order2.C fails
On Wed, Dec 06, 2023 at 09:30:32AM -0500, Siddhesh Poyarekar wrote:
> > We have the -Wmemset-transposed-args warning, couldn't we
> > have a similar one for calloc, and perhaps do it solely in
> > the case where one uses sizeof of the type used in the cast
> > pointer?
> > So warn for
> > (struct S
On 2023-12-06 09:41, Jakub Jelinek wrote:
On Wed, Dec 06, 2023 at 09:30:32AM -0500, Siddhesh Poyarekar wrote:
We have the -Wmemset-transposed-args warning, couldn't we
have a similar one for calloc, and perhaps do it solely in
the case where one uses sizeof of the type used in the cast
pointer?
Am Mittwoch, dem 06.12.2023 um 15:21 +0100 schrieb Jakub Jelinek:
> On Wed, Dec 06, 2023 at 02:34:10PM +0100, Martin Uecker wrote:
> > > Further I think
> > > "size less than or equal to the size requested"
> > > is quite ambiguous in the calloc case, isn't the size requested in the
> > > calloc ca
On Wed, Dec 06, 2023 at 03:56:10PM +0100, Martin Uecker wrote:
> > That would be my preference because then the allocation size is
> > correct and it is purely a style warning.
> > It doesn't follow how the warning is described:
> > "Warn about calls to allocation functions decorated with attribute
Am Mittwoch, dem 06.12.2023 um 16:01 +0100 schrieb Jakub Jelinek:
> On Wed, Dec 06, 2023 at 03:56:10PM +0100, Martin Uecker wrote:
> > > That would be my preference because then the allocation size is
> > > correct and it is purely a style warning.
> > > It doesn't follow how the warning is describ
Hi Richard,
thanks for the useful comments.
On Wed, Dec 6, 2023 at 4:32 PM Richard Biener
wrote:
> On Wed, Dec 6, 2023 at 2:48 PM Manos Anagnostakis
> wrote:
> >
> > This is an RTL pass that detects store forwarding from stores to larger
> loads (load pairs).
> >
> > This optimization is SPEC2
Just an update on this issue.
Finally, I resolved this issue with the following solution:
For the source code (portion):
"
struct annotated {
size_t foo;
char array[] __attribute__((counted_by (foo)));
};
p2->array[8] = 0;
“
C FE will generate the following: (*.005t.original)
*(.ACCESS_WI
Tested on hppa-unknown-linux-gnu. Committed to trunk.
Dave
---
Fix c-c++-common/fhardened-[12].c test fails on hppa
The -fstack-protector and -fstack-protector-strong options are
not supported on hppa since the stack grows up.
2023-12-06 John David Anglin
gcc/testsuite/ChangeLog:
Tested on x86_64-pc-linux-gnu with --enable-languages=c,c++
-- >8 --
Handle '#pragma GCC optimize' earlier as the __OPTIMIZE__ macro may need
to be defined as well for certain usages.
This is a follow-up to r14-4967-g8697d3a1. Also add more tests for the
'#pragma GCC target' case with auto-vecto
Dear All,
This patch was rescued from my ill-fated and long winded attempt to provide
a fix-up for function selector references, where the function is parsed
after the procedure containing the associate/select type construct (PRs
89645 and 99065). The fix-ups broke down completely once these const
On Tue, 05 Dec 2023 16:39:06 PST (-0800), e...@rivosinc.com wrote:
Ran the test case at 122e7b4f9d0c2d54d865272463a1d812002d0a5c where the xfail
That's the original port submission, I'm actually kind of surprised it
still builds/works at all.
was introduced. The test did pass at that hash a
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, November 28, 2023 5:56 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH 17/21]AArch64: Add implementation for vector cbranch for
> Ad
Sorry, I only just spotted this while looking at something else.
On 23/05/2023 15:41, Christophe Lyon via Gcc-patches wrote:
Glibc defines int32_t as 'int' while newlib defines it as 'long int'.
Although these correspond to the same size, g++ complains when using the
GDB makes use of the libiberty function buildargv for splitting the
inferior (program being debugged) argument string in the case where
the inferior is not being started under a shell.
I have recently been working to improve this area of GDB, and have
tracked done some of the unexpected behaviour
Thank you, Tobias, for approving the v3 patch series with minor changes.
https://patchwork.sourceware.org/project/gcc/list/?series=27815&state=%2A&archive=both
These patches are what I've actually committed. Besides the requested
changes there were one or two bug fixes and minor tweaks, but othe
The NVPTX low latency memory is not accessible outside the team that allocates
it, and therefore should be unavailable for allocators with the access trait
"all". This change means that the omp_low_lat_mem_alloc predefined
allocator no longer works (but omp_cgroup_mem_alloc still does).
libgomp/
1 - 100 of 194 matches
Mail list logo
