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
>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
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?
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
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
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
> > >
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
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
> 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
> 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
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
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
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
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
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:
-
[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 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/
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 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 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
> 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
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 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,
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
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.
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
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
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
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
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
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 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_
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]
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
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
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
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
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
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 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
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 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 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 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
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 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
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 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
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 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 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 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
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 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 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 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 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: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 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 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 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 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 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 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 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
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 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_
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.
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
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/
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
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
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++
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
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
>
>
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
79 matches
Mail list logo
