On Wed, Apr 14, 2021 at 3:30 AM Hongtao Liu wrote:
>
> On Tue, Apr 13, 2021 at 6:38 PM Uros Bizjak wrote:
> >
> > On Tue, Apr 13, 2021 at 12:18 PM Hongtao Liu wrote:
> > >
> > > Hi:
> > > As described in PR, we introduced tigerlake string in driver-i386.c
> > > by r9-8652 w/o support -march/tu
On Wed, Apr 14, 2021 at 4:07 PM Jose E. Marchesi via Gcc-patches
wrote:
>
> This patch introduces a dwarf_debuginfo_p predicate that abstracts and
> replaces complex checks on write_symbols.
OK once stage1 opens (can be pushed independently of the rest).
Richard.
> 2021-04-14 Indu Bhagat
>
>
Thanks,
On 2021/4/14 14:41, Richard Biener wrote:
>> "#538,#235,#234,#233" will all be sunk from bb 35 to bb 37 by rtl-sink,
>> but it moves #538 first, then #235, there is strong dependency here. It
>> seemsdoesn't like the LCM framework that could solve all and do the
>> delete-insert in one ite
Here we ICE when compiling this code in C++20, because we're trying to
slam a 'typename' after the ->. The cp_parser_template_id call just
before the spot I'm changing parsed A::template A as a BASELINK
that contains a constructor, but make_typename_type crashes on that.
My fix is the same as c++
commit 87c753ac241f25d222d46ba1ac66ceba89d6a200
Author: H.J. Lu
Date: Fri Aug 21 09:42:49 2020 -0700
x86: Add target("general-regs-only") function attribute
is incomplete since it is impossible to call integer intrinsics from
a function with general-regs-only target attribute.
1. Add gene
I realized that
commit 87c753ac241f25d222d46ba1ac66ceba89d6a200
Author: H.J. Lu
Date: Fri Aug 21 09:42:49 2020 -0700
x86: Add target("general-regs-only") function attribute
is incomplete since it is impossible to call integer intrinsics from
a function with general-regs-only target attrib
Move OPTION_MASK_* to i386-common.h so that they can be used in x86
backend.
* common/config/i386/i386-common.c (OPTION_MASK_*): Move to ...
* common/config/i386/i386-common.h: Here. New file.
* config/i386/i386.h: Include common/config/i386/i386-common.h.
---
gcc/common/
AIX uses a compiler-managed TOC for global data, including TLS symbols.
The GCC TOC implementation manages the TOC entries through the
constant pool.
TLS symbols sometimes require a function call to obtain the TLS base
pointer. The arguments to the TLS call can conflict with argum
On Wed, Apr 14, 2021 at 02:15:47PM -0500, Segher Boessenkool wrote:
> On Wed, Apr 14, 2021 at 03:09:13PM -0400, Michael Meissner wrote:
> > On Tue, Apr 13, 2021 at 05:19:12PM -0500, Segher Boessenkool wrote:
> > > > * config/rs6000/rs6.h (FLOAT128_MIN_MAX_FPMASK_P): New
> > > > macro.
On Wed, Apr 14, 2021 at 02:38:47PM -0500, Segher Boessenkool wrote:
> On Fri, Apr 09, 2021 at 10:43:58AM -0400, Michael Meissner wrote:
> > (Fv mode attribute): Add KFmode and TFmode.
> > (movcc_fpmask): Replace
> > movcc_p9. Add IEEE 128-bit fp support.
> > (movcc_
Richard Sandiford writes:
> Jakub Jelinek writes:
>> On Wed, Apr 14, 2021 at 05:31:23PM +0100, Richard Sandiford wrote:
>>> > +(define_split
>>> > + [(set (match_operand:GPI 0 "register_operand")
>>> > + (LOGICAL:GPI
>>> > + (and:GPI (ashift:GPI (match_operand:GPI 1 "register_operand")
>>> > +
On 4/14/2021 9:32 AM, Richard Sandiford via Gcc-patches wrote:
types are distinct from GNU vector types in at least
their mangling. However, there used to be nothing explicit in the
VECTOR_TYPE itself to indicate the difference: we simply treated them
as distinct TYPE_MAIN_VARIANTs. This cau
On 4/14/2021 9:36 AM, Richard Sandiford via Gcc-patches wrote:
types are distinct from GNU vector types in at least
their mangling. However, there used to be nothing explicit in the
VECTOR_TYPE itself to indicate the difference: we simply treated them
as distinct TYPE_MAIN_VARIANTs. This cau
On Wed, 14 Apr 2021, Richard Sandiford via Gcc-patches wrote:
> gcc/
> PR c/98852
> * attribs.h (affects_type_identity_attributes): Declare.
> * attribs.c (remove_attributes_matching): New function.
> (affects_type_identity_attributes): Likewise.
>
> gcc/c/
> PR c/98
On 14 April 2021 21:01:15 CEST, Segher Boessenkool
wrote:
>> > > --- /dev/null
>> > > +++ b/gcc/testsuite/gcc.target/powerpc/float128-cmove.c
>> > > @@ -0,0 +1,93 @@
>> > > +/* { dg-do compile } */
>> > > +/* { dg-require-effective-target ppc_float128_hw } */
>> > > +/* { dg-require-effective-ta
On 4/14/2021 11:13 AM, Stefan Schulze Frielinghaus via Gcc-patches wrote:
Regarding test gcc.dg/pr93210.c, on different targets GIMPLE code may
slightly differ which is why the scan-tree-dump-times directive may
fail. For example, for a RETURN_EXPR on x86_64 we have
return 0x11100f0e0d0c0a
On Wed, Apr 14, 2021 at 02:47:59PM -0500, Segher Boessenkool wrote:
> On Wed, Apr 14, 2021 at 09:45:35PM +0200, Jakub Jelinek wrote:
> > On Wed, Apr 14, 2021 at 02:42:54PM -0500, Segher Boessenkool wrote:
> > > > provably doesn't (that is from the splitter I wrote for the non-hard
> > > > regs),
>
On Wed, Apr 14, 2021 at 09:45:35PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 14, 2021 at 02:42:54PM -0500, Segher Boessenkool wrote:
> > > provably doesn't (that is from the splitter I wrote for the non-hard
> > > regs),
> > > nor
> > > [(set (match_operand:GPI 0 "register_operand")
> > >
On Wed, Apr 14, 2021 at 09:25:46PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 14, 2021 at 01:47:04PM -0500, Segher Boessenkool wrote:
> > > and I must say I don't know if make_more_copies was meant to
> > > split insn 2 into (set (reg:QI pseudo) (reg:QI 0 x0)) and
> > > (set (reg/v:SI 96) (zero_exte
On Wed, Apr 14, 2021 at 02:42:54PM -0500, Segher Boessenkool wrote:
> > provably doesn't (that is from the splitter I wrote for the non-hard regs),
> > nor
> > [(set (match_operand:GPI 0 "register_operand")
> > (LOGICAL:GPI
> > (and:GPI (ashift:GPI (match_operand:GPI 1 "register
On Wed, Apr 14, 2021 at 09:20:35PM +0200, Jakub Jelinek wrote:
> The question is what to write in the splitter pattern so that
> they would match.
> [(set (match_operand:GPI 0 "register_operand")
> (LOGICAL:GPI
> (and:GPI (ashift:GPI (match_operator:GPI 4 "subreg_lowpart_operato
On Wed, Apr 14, 2021 at 09:20:33PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 14, 2021 at 01:47:04PM -0500, Segher Boessenkool wrote:
> > A subreg:QI of the match_dup should match fine. You can use a subreg
> > wherever GCC tries to match a reg.
> >
> > > match_dup means insn-recog.c calls rtx_equ
On Fri, Apr 09, 2021 at 10:43:58AM -0400, Michael Meissner wrote:
> (Fv mode attribute): Add KFmode and TFmode.
> (movcc_fpmask): Replace
> movcc_p9. Add IEEE 128-bit fp support.
> (movcc_invert_fpmask): Replace
> movcc_invert_p9. Add IEEE 128-bit fp
>
On Wed, Apr 14, 2021 at 01:47:04PM -0500, Segher Boessenkool wrote:
> > and I must say I don't know if make_more_copies was meant to
> > split insn 2 into (set (reg:QI pseudo) (reg:QI 0 x0)) and
> > (set (reg/v:SI 96) (zero_extend:SI (reg:QI pseudo)))
> > or not.
>
> It makes
>
> (set (reg:QI new
On Wed, Apr 14, 2021 at 01:47:04PM -0500, Segher Boessenkool wrote:
> A subreg:QI of the match_dup should match fine. You can use a subreg
> wherever GCC tries to match a reg.
>
> > match_dup means insn-recog.c calls rtx_equal_p and that returns false if the
> > mode is not the same.
>
> Yes, bu
Hi!
The requires clause parsing has code to suggest users wrapping
non-primary expressions in (), so if it e.g. parses a primary expression
and sees it is followed by ++, --, ., ( or -> among other things it
will try to reparse it as assignment expression or what and if that works
suggests wrappin
On Wed, Apr 14, 2021 at 03:09:13PM -0400, Michael Meissner wrote:
> On Tue, Apr 13, 2021 at 05:19:12PM -0500, Segher Boessenkool wrote:
> > > * config/rs6000/rs6.h (FLOAT128_MIN_MAX_FPMASK_P): New macro.
> >
> > As said in the other mail, don't do the macro; just write its expansion
> > in t
Hi!
The following testcase ICEs in tsubst_decomp_names because the assumptions
that the structured binding artificial var is followed in DECL_CHAIN by
the corresponding structured binding vars is violated.
I've tracked it to extract_locals* which is done for the constexpr
IF_STMT. extract_locals_
On Tue, Apr 13, 2021 at 05:19:12PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Apr 09, 2021 at 10:42:50AM -0400, Michael Meissner wrote:
> > Since then the patch seems to have gone into a limbo state.
>
> Patches I cannot immediately handle take time, and if they aren't
> pinged, they can
Richard Biener writes:
> On April 14, 2021 5:10:26 PM GMT+02:00, Richard Sandiford via Gcc-patches
> wrote:
>>Looking at PR99929 showed that we weren't dumping enough information
>>about variable-length CONST_VECTORs. Something like:
>>
>> (const_vector:VNx4SI [(const_int 1) (const_int 0)])
>>
On Fri, Apr 09, 2021 at 09:20:32PM +0200, Bernhard Reutner-Fischer wrote:
> On Fri, 09 Apr 2021 11:54:59 -0500
> will schmidt via Gcc-patches wrote:
> > > + enum rtx_code cond = reverse_condition_maybe_unordered (GET_CODE
> > > (old_cmp));
>
> I think you can drop the enum keyword.
You can in
My patch for PR93085 didn't consider that a default template argument can
also make a template dependent.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/100078
PR c++/93085
* pt.c (uses_outer_template_parms): Also look at default
template
On April 14, 2021 5:10:26 PM GMT+02:00, Richard Sandiford via Gcc-patches
wrote:
>Looking at PR99929 showed that we weren't dumping enough information
>about variable-length CONST_VECTORs. Something like:
>
> (const_vector:VNx4SI [(const_int 1) (const_int 0)])
>
>could be either:
>
>(a) 1, 0, 1
On April 14, 2021 5:13:23 PM GMT+02:00, Richard Sandiford via Gcc-patches
wrote:
>PR99929 is one of those “how did we get away with this for so long”
>bugs: the equality routines weren't checking whether two
>variable-length
>CONST_VECTORs had the same encoding. This meant that:
>
> { 1, 0, 0,
On Wed, Apr 14, 2021 at 08:01:11PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 14, 2021 at 12:46:43PM -0500, Segher Boessenkool wrote:
> > The REGNO checks work fine for pseudos as well. But, why does it do
> > this at all, instead of using match_dup? That should be clearer.
>
> Because with the h
On Wed, Apr 14, 2021 at 06:55:56PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > The REGNO checks work fine for pseudos as well. But, why does it do
> > this at all, instead of using match_dup? That should be clearer.
>
> The register is appearing in two different modes: GPI
On Wed, Apr 14, 2021 at 12:46:43PM -0500, Segher Boessenkool wrote:
> The REGNO checks work fine for pseudos as well. But, why does it do
> this at all, instead of using match_dup? That should be clearer.
Because with the hard regs it has different modes, so match_dup
wouldn't work.
We are talk
Segher Boessenkool writes:
> On Wed, Apr 14, 2021 at 05:31:23PM +0100, Richard Sandiford wrote:
>> Jakub Jelinek writes:
>> > +(define_split
>> > + [(set (match_operand:GPI 0 "register_operand")
>> > + (LOGICAL:GPI
>> > +(and:GPI (ashift:GPI (match_operand:GPI 1 "register_operand")
>> > +
On Wed, Apr 14, 2021 at 06:42:33PM +0100, Richard Sandiford wrote:
> Otherwise this looks good apart from the open question about whether
> we should be doing complex combinations involving hard regs. Let's see
> what Segher says about that side.
It works find with pseudos as well, but then you n
On Wed, Apr 14, 2021 at 10:49:42AM -0600, Martin Sebor via Gcc-patches wrote:
> Apparently the IL GCC emits on some targets (arm and aarach64 with
> mabi=ilp32, and powerpc64 to name the three where the failures have
> been pointed out) isn't handled by the uninit pass and so it doesn't
> issue the
N2253 allowed referring to non-static data members without an object in
unevaluated operands like that of sizeof, but in a constant-expression
context like an array bound or template argument within such an unevaluated
operand we do actually need a value, so that permission cannot apply.
Tested x8
Hi!
On Wed, Apr 14, 2021 at 05:31:23PM +0100, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > +(define_split
> > + [(set (match_operand:GPI 0 "register_operand")
> > + (LOGICAL:GPI
> > + (and:GPI (ashift:GPI (match_operand:GPI 1 "register_operand")
> > + (matc
Jakub Jelinek writes:
> On Wed, Apr 14, 2021 at 05:31:23PM +0100, Richard Sandiford wrote:
>> > +(define_split
>> > + [(set (match_operand:GPI 0 "register_operand")
>> > + (LOGICAL:GPI
>> > +(and:GPI (ashift:GPI (match_operand:GPI 1 "register_operand")
>> > + (match_o
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100066
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64.
commit f99f64f69db49ce6343d79a39eab28dcc6b91865
Author: Vladimir N. Makarov
Date: Wed Apr 14 13:21:40 2021 -0400
[PR100066]
On Wed, Apr 14, 2021 at 05:31:23PM +0100, Richard Sandiford wrote:
> > +(define_split
> > + [(set (match_operand:GPI 0 "register_operand")
> > + (LOGICAL:GPI
> > + (and:GPI (ashift:GPI (match_operand:GPI 1 "register_operand")
> > + (match_operand:QI 2 "aarch64_shift_
Regarding test gcc.dg/pr93210.c, on different targets GIMPLE code may
slightly differ which is why the scan-tree-dump-times directive may
fail. For example, for a RETURN_EXPR on x86_64 we have
return 0x11100f0e0d0c0a090807060504030201;
whereas on IBM Z the first operand is a RESULT_DECL like
On 4/14/21 2:11 AM, Christophe Lyon wrote:
On Tue, 13 Apr 2021 at 21:50, Martin Sebor via Gcc-patches
wrote:
The issue has been fixed so r11-8161 just adds the test case:
https://gcc.gnu.org/g:8084ab15a3e300e3b2c537e56e0f3a1b00778aec
Hi,
This new test fails on arm (and aarch64 with -ma
Jakub Jelinek writes:
> Hi!
>
> Before combiner added 2 to 2 combinations, the following testcase functions
> have been all compiled into 2 instructions, zero/sign extensions or and
> followed by orr with lsl, e.g. for the first function
> Trying 7 -> 8:
> 7: r96:SI=r94:SI<<0xb
> 8: r95:SI
types are distinct from GNU vector types in at least
their mangling. However, there used to be nothing explicit in the
VECTOR_TYPE itself to indicate the difference: we simply treated them
as distinct TYPE_MAIN_VARIANTs. This caused problems like the ones
reported in PR95726.
The fix for that P
types are distinct from GNU vector types in at least
their mangling. However, there used to be nothing explicit in the
VECTOR_TYPE itself to indicate the difference: we simply treated them
as distinct TYPE_MAIN_VARIANTs. This caused problems like the ones
reported in PR95726.
The fix for that P
PR99246 is about a case in which we failed to handle a CONST_VECTOR
with NELTS_PER_PATTERN==2, i.e. a vector with a “foreground” sequence
of N vectors followed by a repeating “background” sequence of N vectors.
At the moment, it's difficult to produce these vectors directly,
but I'm hoping that fo
PR99929 is one of those “how did we get away with this for so long”
bugs: the equality routines weren't checking whether two variable-length
CONST_VECTORs had the same encoding. This meant that:
{ 1, 0, 0, 0, 0, 0, ... }
would appear to be equal to:
{ 1, 0, 1, 0, 1, 0, ... }
since both a
Looking at PR99929 showed that we weren't dumping enough information
about variable-length CONST_VECTORs. Something like:
(const_vector:VNx4SI [(const_int 1) (const_int 0)])
could be either:
(a) 1, 0, 1, 0, repeating
(b) 1 followed by all zeros
This patch adds more information to the dumps.
This fixes the error checking for two of the vector builtins which
accept irregular (e.g. non-contigiuous) ranges of values.
Regression tested on s390x (--with-arch=arch13).
Applied to mainline. Needs to go into 9 and 10 branch as well.
gcc/ChangeLog:
* config/s390/s390-builtins.def (O_M
On Tue, Apr 13, 2021 at 8:51 AM Martin Sebor wrote:
>
> On 4/12/21 7:03 PM, H.J. Lu wrote:
> > On Mon, Apr 12, 2021 at 4:55 PM Martin Sebor wrote:
> >>
> >> On 4/12/21 3:53 PM, H.J. Lu via Gcc-patches wrote:
> >>> On Mon, Apr 12, 2021 at 2:21 AM Richard Biener
> >>> wrote:
>
> On Sat,
On 11.04.21 09:05, Paul Richard Thomas wrote:
Tobias noticed a major technical fault with the resubmission below: I
forgot to attach the patch :-(
LGTM. Plus as remarked in the first review: 'trans-expr_c' typo needs to
be fixed (ChangeLog).
Tobias
Please find it attached this time.
Paul
> On 05/04/2021 21:43 Iain Buclaw wrote:
>
>
> Hi,
>
> This patch adds TARGET_D_REGISTER_OS_TARGET_INFO as a new D front-end
> target hook, implementing `__traits(getTargetInfo, "objectFormat")' for
> all targets that have D support files.
>
> This trait was added earlier in the front-end as
This removes update_call_from_tree in favor of
gimplify_and_update_call_from_tree, removing some code duplication
and simplifying the API use. Some users of update_call_from_tree
have been transitioned to replace_call_with_value and the API
and its dependences have been moved to gimple-fold.h.
Th
This commit adds a new testsuite for the CTF debug format.
2021-04-14 Indu Bhagat
David Faust
gcc/testsuite/
* lib/gcc-dg.exp (gcc-dg-frontend-supports-ctf): New procedure.
(gcc-dg-debug-runtest): Add -gctf support.
* gcc.dg/debug/btf/btf-1.c: New test.
This patch changes the BPF GCC backend in order to use the DWARF debug
hooks and therefore enables the user to generate BTF debugging
information with -gbtf. Generating BTF is crucial when compiling BPF
programs, since the CO-RE (compile-once, run-everwhere) mechanism
used by the kernel BPF loader
This commit documents the new command line options introduced by the
CTF and BTF debug formats.
2021-04-14 Indu Bhagat
* doc/invoke.texi: Document the CTF and BTF debug info options.
---
gcc/doc/invoke.texi | 20
1 file changed, 20 insertions(+)
diff --git a/gcc/
[Changes from V5:
- Rebased to today's master.
- New preparatory patch: factorize some code in
gcc-dg-debug-runtest into a new procedure. This is used by the
CTF testsuite.
- Expose get_AT_file and related data structures in dwarf2int.
- Move the call to ctf_debug_finalize into dwarf2out_finis
This patch introduces a dwarf2int.h header, to be used by code that
needs access to the internal DIE structures and their attributes.
The following functions which were previously defined as static in
dwarf2out.c are now non-static, and extern prototypes for them have
been added to dwarf2int.h:
-
This patch introduces a dwarf_debuginfo_p predicate that abstracts and
replaces complex checks on write_symbols.
2021-04-14 Indu Bhagat
gcc/ChangeLog
* flags.h (dwarf_debuginfo_p): New function declaration.
* opts.c (dwarf_debuginfo_p): New function definition.
* confi
Move some functionality into a procedure of its own. This is only so that when
the patch for ctf comes along, the gcc-dg-debug-runtest procedure looks bit
more uniform.
gcc/testsuite/ChangeLog:
* lib/gcc-dg.exp (gcc-dg-target-supports-debug-format): New procedure.
---
gcc/testsuite/lib/g
Hi,
This patch removes the setting of all target-specific global.params
flags from the D front-end. Now that all dependencies on these flags
have been removed, there's no need to test and set them.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.
Reg
Hi,
This patch moves the call to the newly introduced set_linkage_for_decl
in the D front-end from d_finish_decl to declare_extern_var.
This both prevents against it being called twice for declarations that
are defined, and fixes an issue where variables defined in the
compilation get one kind of
> On 05/04/2021 21:43 Iain Buclaw wrote:
>
>
> Hi,
>
> This patch adds TARGET_D_REGISTER_CPU_TARGET_INFO as a new D front-end
> target hook, implementing `__traits(getTargetInfo, "floatAbi")' for all
> targets that have D support files.
>
> This trait was added earlier in the front-end as a
> On 05/04/2021 21:43 Iain Buclaw wrote:
>
>
> Hi,
>
> This patch adds TARGET_D_HAS_STDCALL_CONVENTION as a new D front-end
> target hook. It replaces the use of the D front-end `is64bit' parameter
> in determining whether to insert the "stdcall" function attribute.
>
> It is also used to de
This avoids use of valid_gimple_rhs_p and instead gimplifies to
such a RHS, avoiding more SSA copies being generated by IVOPTs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, queued for stage1
2021-04-14 Richard Biener
* tree-ssa-loop-ivopts.c (rewrite_use_nonlinear_expr): Avoid
This adjusts GIMPLE verification with respect to the VEC_COND_EXPR
changes forcing a split out condition.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-04-14 Richard Biener
* tree-cfg.c (verify_gimple_assign_ternary): Verify that
VEC_COND_EXPRs have a gimpl
On Wed, Apr 07, 2021 at 03:53:26PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Mar 29, 2021 at 11:16:55AM +0200, Jakub Jelinek wrote:
> > > Looks good to me. Richard E knows this code better than I do though,
> > > so I think he should have the final say. He's currently on holiday
> > >
If the compiler is configured with --with-fpu= (or invoked
with, say, -mfpu=neon), then specifying -mcpu=neoverse-n1 can lead to
an unexpected warning: cc1: warning: switch ‘-mcpu=neoverse-n1’
conflicts with ‘-march=armv8.2-a’ switch
The fix for this is to correctly remove all the feature bits r
Hi!
As can be seen under valgrind, the testcase didn't bind in the last part
the fortran pointers properly to the c pointers.
Tested on x86_64-linux, committed to trunk.
2021-04-14 Jakub Jelinek
PR testsuite/100071
* testsuite/libgomp.fortran/alloc-1.F90: Call c_f_pointer aft
On Tue, 13 Apr 2021 at 21:50, Martin Sebor via Gcc-patches
wrote:
>
> The issue has been fixed so r11-8161 just adds the test case:
>https://gcc.gnu.org/g:8084ab15a3e300e3b2c537e56e0f3a1b00778aec
>
Hi,
This new test fails on arm (and aarch64 with -mabi=ilp32):
XFAIL: gcc.dg/pr86058.c pr?
>From b1774ab1c8aad82b7a5d975ef90c6d3f633780ee Mon Sep 17 00:00:00 2001
From: expnkx
Date: Wed, 14 Apr 2021 03:14:28 -0400
Subject: [PATCH] Fix intrinsics mm_malloc.h in freestanding [PR100057]
C does not have stdlib.h and C++ cstdint in freestanding does not malloc
either. This leads
to fail of
>From b1774ab1c8aad82b7a5d975ef90c6d3f633780ee Mon Sep 17 00:00:00 2001
From: expnkx
Date: Wed, 14 Apr 2021 03:14:28 -0400
Subject: [PATCH] Fix intrinsics mm_malloc.h in freestanding [PR100057]
C does not have stdlib.h and C++ cstdint in freestanding does not malloc
either. This leads
to fail of
>From b1774ab1c8aad82b7a5d975ef90c6d3f633780ee Mon Sep 17 00:00:00 2001
From: expnkx
Date: Wed, 14 Apr 2021 03:14:28 -0400
Subject: [PATCH] Fix intrinsics mm_malloc.h in freestanding [PR100057]
C does not have stdlib.h and C++ cstdint in freestanding does not malloc
either. This leads
to fail of
Hi!
Before combiner added 2 to 2 combinations, the following testcase functions
have been all compiled into 2 instructions, zero/sign extensions or and
followed by orr with lsl, e.g. for the first function
Trying 7 -> 8:
7: r96:SI=r94:SI<<0xb
8: r95:SI=r96:SI|r94:SI
REG_DEAD r96:SI
79 matches
Mail list logo
