Force_operand issues an ICE when input
is (subreg:DI (us_truncate:V8QI)), it's probably because it's an
invalid rtx, So refine backend patterns for that.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
gcc/ChangeLog:
PR target/117318
* config/i386/s
On 7/28/24 4:41 PM, Mark Harmstone wrote:
Empty structs result in empty LF_FIELDLIST types, which are valid, but
we weren't accounting for this and assuming they had to contain
subtypes.
gcc/
* dwarf2codeview.cc (get_type_num_struct): Fix NULL pointer dereference.
OK
jeff
Empty structs result in empty LF_FIELDLIST types, which are valid, but
we weren't accounting for this and assuming they had to contain
subtypes.
gcc/
* dwarf2codeview.cc (get_type_num_struct): Fix NULL pointer dereference.
---
gcc/dwarf2codeview.cc | 7 +--
1 file changed, 5 insertion
On Wed, Jun 19, 2024 at 07:32:28PM +0200, Jakub Jelinek wrote:
> Ok, I've tried that, but that doesn't work, it ICEs on the
> pr114574-2.c testcase.
The following works on quick testing of dg.exp=pr11[45]*.c
but haven't bootstrapped/regtested it yet.
2024-06-19 Jakub Jelinek
Martin
On Wed, Jun 19, 2024 at 09:26:00AM +0200, Martin Uecker wrote:
> Ok. Then should it, instead of
>
> TYPE_CANONICAL (x)
> = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x));
>
> be
>
> tree c = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x));
> TYPE_CANONICAL (x) = TREE
On Wed, Jun 19, 2024 at 09:36:40AM +0200, Richard Biener wrote:
> > TYPE_CANONICAL (x)
> > = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x));
>
> That looks indeed weird. What are the constraints on 't' for
> c_update_type_canonical? If it is TYPE_STRUCTURAL_EQUALITY_P
> the ab
On Wed, Jun 19, 2024 at 09:26:00AM +0200, Martin Uecker wrote:
> Ok. Then should it, instead of
>
> TYPE_CANONICAL (x)
> = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x));
>
> be
>
> tree c = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x));
> TYPE_CANONICAL (x) = TREE
On Wed, 19 Jun 2024, Martin Uecker wrote:
> Am Mittwoch, dem 19.06.2024 um 08:57 +0200 schrieb Richard Biener:
> > On Wed, 19 Jun 2024, Martin Uecker wrote:
> >
> > > Am Mittwoch, dem 19.06.2024 um 08:04 +0200 schrieb Richard Biener:
> > > >
> > > > > Am 18.06.2024 um 20:18 schrieb Martin Uecker
Am Mittwoch, dem 19.06.2024 um 08:57 +0200 schrieb Richard Biener:
> On Wed, 19 Jun 2024, Martin Uecker wrote:
>
> > Am Mittwoch, dem 19.06.2024 um 08:04 +0200 schrieb Richard Biener:
> > >
> > > > Am 18.06.2024 um 20:18 schrieb Martin Uecker :
> > > >
> > > > Am Dienstag, dem 18.06.2024 um 17:
On Wed, 19 Jun 2024, Jakub Jelinek wrote:
> On Wed, Jun 19, 2024 at 08:04:55AM +0200, Richard Biener wrote:
> > >> Note a canonical type should always be unqualified (for
> > >> classical qualifiers, not address space or atomic qualification)
> > >
> > > The logic in build_qualified_type is the s
On Wed, 19 Jun 2024, Martin Uecker wrote:
> Am Mittwoch, dem 19.06.2024 um 08:04 +0200 schrieb Richard Biener:
> >
> > > Am 18.06.2024 um 20:18 schrieb Martin Uecker :
> > >
> > > Am Dienstag, dem 18.06.2024 um 17:27 +0200 schrieb Richard Biener:
> > > >
> > > > > > Am 18.06.2024 um 17:20 schr
Am Mittwoch, dem 19.06.2024 um 08:29 +0200 schrieb Jakub Jelinek:
> On Wed, Jun 19, 2024 at 08:04:55AM +0200, Richard Biener wrote:
> > > > Note a canonical type should always be unqualified (for
> > > > classical qualifiers, not address space or atomic qualification)
> > >
> > > The logic in buil
Am Mittwoch, dem 19.06.2024 um 08:04 +0200 schrieb Richard Biener:
>
> > Am 18.06.2024 um 20:18 schrieb Martin Uecker :
> >
> > Am Dienstag, dem 18.06.2024 um 17:27 +0200 schrieb Richard Biener:
> > >
> > > > > Am 18.06.2024 um 17:20 schrieb Martin Uecker :
> > > >
> > > >
> > > > As discuss
On Wed, Jun 19, 2024 at 08:04:55AM +0200, Richard Biener wrote:
> >> Note a canonical type should always be unqualified (for
> >> classical qualifiers, not address space or atomic qualification)
> >
> > The logic in build_qualified_type is the same as in this patch,
> > it constructs TYPE_CANONICA
> Am 18.06.2024 um 20:18 schrieb Martin Uecker :
>
> Am Dienstag, dem 18.06.2024 um 17:27 +0200 schrieb Richard Biener:
>>
Am 18.06.2024 um 17:20 schrieb Martin Uecker :
>>>
>>>
>>> As discussed this replaces the use of check_qualified_type with
>>> a simple check for qualifiers as su
Am Dienstag, dem 18.06.2024 um 17:27 +0200 schrieb Richard Biener:
>
> > Am 18.06.2024 um 17:20 schrieb Martin Uecker :
> >
> >
> > As discussed this replaces the use of check_qualified_type with
> > a simple check for qualifiers as suggested by Jakub in
> > c_update_type_canonical.
>
> Note a
> Am 18.06.2024 um 17:20 schrieb Martin Uecker :
>
>
> As discussed this replaces the use of check_qualified_type with
> a simple check for qualifiers as suggested by Jakub in
> c_update_type_canonical.
Note a canonical type should always be unqualified (for classical qualifiers,
not addres
As discussed this replaces the use of check_qualified_type with
a simple check for qualifiers as suggested by Jakub in
c_update_type_canonical.
Martin
Bootstrapped and regression tested on x86_64.
C23: Fix ICE related to incomplete structures [PR114930,PR115502].
The fix for PR1
On Tue, Jun 11, 2024 at 01:36:35PM +0800, liuhongt wrote:
> In theory, const_wide_int can also be handle with extra check for each
> components of the HOST_WIDE_INT array, and the check is need for both
> shift and bit_and operands.
> I assume the optimization opportnunity is rare, so the patch ju
In theory, const_wide_int can also be handle with extra check for each
components of the HOST_WIDE_INT array, and the check is need for both
shift and bit_and operands.
I assume the optimization opportnunity is rare, so the patch just add
extra check to make sure GET_MODE_INNER (mode) can fix into
On Tue, 2 Apr 2024, Martin Uecker wrote:
> Fix ICE with -g and -std=c23 related to incomplete types [PR114361]
>
> We did not copy TYPE_CANONICAL to the incomplete variants when
> completing a structure.
>
> PR c/114361
>
> gcc/c/
> * c-decl.c (finish_struct): Set TY
I did not copy TYPE_CANONICAL to incomplete variants
when they are completed.
Bootstrapped and regession tested on x86_64
Fix ICE with -g and -std=c23 related to incomplete types [PR114361]
We did not copy TYPE_CANONICAL to the incomplete variants when
completing a structure.
On Sat, 20 Jan 2024, Martin Uecker wrote:
> C23: Fix ICE for composite type for structs with unsigned bitfields [PR113492]
>
> This patch fixes a bug when forming a composite type from structs that
> contain an unsigned bitfield declared with int while using
> -funsigned-bitfields.
> In such
C23: Fix ICE for composite type for structs with unsigned bitfields [PR113492]
This patch fixes a bug when forming a composite type from structs that
contain an unsigned bitfield declared with int while using -funsigned-bitfields.
In such structs the unsigned integer type was not compatible
The new added splitter will generate
(insn 58 56 59 2 (set (reg:V4HI 20 xmm0 [129])
(vec_duplicate:V4HI (reg:HI 22 xmm2 [123]))) "testcase.c":16:21 -1
But we only have
(define_insn "*vec_dupv4hi"
[(set (match_operand:V4HI 0 "register_operand" "=y,Yw")
(vec_duplicate:V4HI
We have to clear the visited flag on stmts.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-slp.cc (vect_slp_region): Also clear visited flag when
we skipped an instance due to -fdbg-cnt.
---
gcc/tree-vect-slp.cc | 9 ++---
1 file changed, 6 insertion
On Tue, Nov 14, 2023 at 1:56 AM liuhongt wrote:
>
> if (TREE_CODE (init_expr) == INTEGER_CST)
> init_expr = fold_convert (TREE_TYPE (vectype), init_expr);
> else
> gcc_assert (tree_nop_conversion_p (TREE_TYPE (vectype),
>TREE_TYPE (init_expr)));
>
if (TREE_CODE (init_expr) == INTEGER_CST)
init_expr = fold_convert (TREE_TYPE (vectype), init_expr);
else
gcc_assert (tree_nop_conversion_p (TREE_TYPE (vectype),
TREE_TYPE (init_expr)));
and init_expr is a 24 bit integer type while vectype has 32bi
On Mon, Aug 7, 2023 at 4:54 PM liuhongt wrote:
>
> /var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/generated/matmul_i1.c:
> In function ‘matmul_i1_avx512f’:
> /var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/generated/matmul_i1.
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/generated/matmul_i1.c:
In function ‘matmul_i1_avx512f’:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/generated/matmul_i1.c:1781:1:
internal compiler error: RTL check: expected
Committed, thanks Richard.
Lili.
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, May 31, 2023 3:22 PM
> To: Cui, Lili
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Fix ICE in rewrite_expr_tree_parallel
>
> On Wed, May 31, 2023 at
On Wed, May 31, 2023 at 3:35 AM Cui, Lili wrote:
>
> Hi,
>
> This patch is to fix ICE in rewrite_expr_tree_parallel.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110038
>
> Bootstrapped and regtested. Ok for trunk?
OK.
> Regards
> Lili.
>
> 1. Limit the value of tree-reassoc-width to IntegerRa
Hi,
This patch is to fix ICE in rewrite_expr_tree_parallel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110038
Bootstrapped and regtested. Ok for trunk?
Regards
Lili.
1. Limit the value of tree-reassoc-width to IntegerRange(0, 256).
2. Add width limit in rewrite_expr_tree_parallel.
gcc/Change
Here is a fix for PR105660.
Bootstrapped and regression tested on x86-64.
Fix ICE related to implicit access attributes for VLA arguments [PR105660]
When constructing the specifier string when merging an access attribute
that encodes information about VLA arguments, the string
Hi,
On Thu, Jun 23 2022, Xionghu Luo via Gcc-patches wrote:
> There is a corner case for speculative multiple targets, that if speculative
> edges are streamed to different ltrans units, and then edges are expanded
> in one ltrans unit but the speculative property is not cleared by
> resolve_specu
On Thu, Jul 14, 2022 at 10:20 AM Eric Botcazou via Gcc-patches
wrote:
>
> Hi,
>
> you can build a view conversion between pretty much anything in Ada including
> between types with different sizes, although the compiler warns in this case
> and gigi pads the smaller type to end up with the same si
Hi,
you can build a view conversion between pretty much anything in Ada including
between types with different sizes, although the compiler warns in this case
and gigi pads the smaller type to end up with the same size.
The attached testcase triggers an ICE at -O or above for one of them:
FAIL:
There is a corner case for speculative multiple targets, that if speculative
edges are streamed to different ltrans units, and then edges are expanded
in one ltrans unit but the speculative property is not cleared by
resolve_speculation in other ltrans unit finally cause ICE. This patch
fixes this
On Wed, Jun 15, 2022 at 12:49 AM liuhongt wrote:
>
> (In reply to Uroš Bizjak from comment #1)
> > Instruction does not accept memory operand for operand 3:
> >
> > (define_insn_and_split
> > "*_blendv_ltint"
> > [(set (match_operand: 0 "register_operand" "=Yr,*x,x")
> > (unspec:
> >
(In reply to Uroš Bizjak from comment #1)
> Instruction does not accept memory operand for operand 3:
>
> (define_insn_and_split
> "*_blendv_ltint"
> [(set (match_operand: 0 "register_operand" "=Yr,*x,x")
> (unspec:
> [(match_operand: 1 "register_operand" "0,0,x")
> (match_
On Wed, Mar 23, 2022 at 7:04 AM liuhongt wrote:
>
> In validate_subreg, both (subreg:V2HF (reg:SI) 0)
> and (subreg:V8HF (reg:V2HF) 0) are valid, but not
> for (subreg:V8HF (reg:SI) 0) which causes ICE.
>
> Ideally it should be handled in validate_subreg to support
> subreg for all modes available
On Wed, Mar 23, 2022 at 2:05 PM liuhongt via Gcc-patches
wrote:
>
> In validate_subreg, both (subreg:V2HF (reg:SI) 0)
> and (subreg:V8HF (reg:V2HF) 0) are valid, but not
> for (subreg:V8HF (reg:SI) 0) which causes ICE.
>
> Ideally it should be handled in validate_subreg to support
> subreg for all
In validate_subreg, both (subreg:V2HF (reg:SI) 0)
and (subreg:V8HF (reg:V2HF) 0) are valid, but not
for (subreg:V8HF (reg:SI) 0) which causes ICE.
Ideally it should be handled in validate_subreg to support
subreg for all modes available in TARGET_CAN_CHANGE_MODE_CLASS, but
that would be too risky
On 2021/12/29 03:33, Jan Hubicka wrote:
>> -/* Proportion second loop's bb counts except those dominated by false
>> - branch to avoid drop 1s down. */
>> -basic_block bbi_copy = get_bb_copy (false_edge->dest);
>> -bbs2 = get_loop_body (loop2);
>> -for (j = 0; j < loop2->n
> - /* Proportion second loop's bb counts except those dominated by false
> -branch to avoid drop 1s down. */
> - basic_block bbi_copy = get_bb_copy (false_edge->dest);
> - bbs2 = get_loop_body (loop2);
> - for (j = 0; j < loop2->num_nodes; j++)
> - if (bbs2[j] == loo
On 12/21/2021 7:19 PM, Xionghu Luo wrote:
no-guess-branch-probability option requires profile_count with initialized_p
guard. Also merge the missed part of r12-6086 of factor out function to
avoid duplicate code.
gcc/ChangeLog:
PR 103793
* tree-ssa-loop-split.c (fix_loop_bb_
no-guess-branch-probability option requires profile_count with initialized_p
guard. Also merge the missed part of r12-6086 of factor out function to
avoid duplicate code.
gcc/ChangeLog:
PR 103793
* tree-ssa-loop-split.c (fix_loop_bb_probability): New function.
(split_loop
On Fri, Oct 1, 2021 at 10:30 AM Eric Botcazou wrote:
>
> > OK though I wonder if you could get away with using
> > built_function_type (void_type_node, NULL_TREE); aka
> > a non-prototype void f().
>
> See below.
>
> > Did you track down what changed the requirement?
>
> The new function-abi.cc mo
> OK though I wonder if you could get away with using
> built_function_type (void_type_node, NULL_TREE); aka
> a non-prototype void f().
See below.
> Did you track down what changed the requirement?
The new function-abi.cc module, so I'd rather have a correct prototype.
--
Eric Botcazou
On Fri, Oct 1, 2021 at 10:17 AM Eric Botcazou via Gcc-patches
wrote:
>
> Hi,
>
> this is a regression present on mainline, 11 and 10 branches: on bare-metal
> platforms, the Ada compiler emulates stack checking (it is required by the
> language and tested by ACATS) in the runtime via the stack_che
Hi,
this is a regression present on mainline, 11 and 10 branches: on bare-metal
platforms, the Ada compiler emulates stack checking (it is required by the
language and tested by ACATS) in the runtime via the stack_check_libfunc hook
of the RTL middle-end. Calls to the function are generated as
Am Montag, den 16.08.2021, 06:49 +0200 schrieb Martin Uecker:
> Am Montag, den 16.08.2021, 00:30 -0400 schrieb Jason Merrill:
> > On 8/1/21 1:36 PM, Uecker, Martin wrote:
> > > Here is an attempt to fix some old and annoying bugs related
> > > to VLAs and statement expressions. In particulary, this
Am Montag, den 16.08.2021, 00:30 -0400 schrieb Jason Merrill:
> On 8/1/21 1:36 PM, Uecker, Martin wrote:
> >
> > Here is an attempt to fix some old and annoying bugs related
> > to VLAs and statement expressions. In particulary, this seems
> > to fix the issues with variably-modified types which a
On 8/1/21 1:36 PM, Uecker, Martin wrote:
Here is an attempt to fix some old and annoying bugs related
to VLAs and statement expressions. In particulary, this seems
to fix the issues with variably-modified types which are
returned from statement expressions (which works on clang),
but there are
> Yes, it breaks Ada. I already found this out in the meanwhile.
OK, thanks for checking.
> My understanding of this is that this is for referring
> to some field of an outer struct which is then used in the
> size expression, e.g. something like this (using
> C syntax):
>
> struct foo {
> int
Am Montag, den 09.08.2021, 15:52 +0200 schrieb Eric Botcazou:
> > I think the patch makes sense but the comment says
> >
> > Java requires that we elaborated nodes in source order. That
> > means we must gimplify the inner expression followed by each
> > of
> > the indices, in o
> I think the patch makes sense but the comment says
>
> Java requires that we elaborated nodes in source order. That
> means we must gimplify the inner expression followed by each of
> the indices, in order. But we can't gimplify the inner
> expression until we deal with any
Am Montag, den 02.08.2021, 16:19 +0200 schrieb Martin Uecker:
>
> Am Montag, den 02.08.2021, 16:05 +0200 schrieb Martin Uecker:
> > > On Sun, Aug 1, 2021 at 7:37 PM Uecker, Martin
> > > wrote:
> > > >
> > > > Here is an attempt to fix some old and annoying bugs related
> > > > to VLAs and statem
Am Montag, den 02.08.2021, 16:05 +0200 schrieb Martin Uecker:
> > On Sun, Aug 1, 2021 at 7:37 PM Uecker, Martin
> > wrote:
> > >
> > >
> > > Here is an attempt to fix some old and annoying bugs related
> > > to VLAs and statement expressions. In particulary, this seems
> > > to fix the issues
On Tue, Aug 3, 2021 at 9:31 PM Martin Uecker wrote:
>
> Am Dienstag, den 03.08.2021, 11:26 +0200 schrieb Richard Biener:
> > On Tue, Aug 3, 2021 at 10:28 AM Martin Uecker wrote:
>
>
> >
> > Does the same issue arise with writing the testcases as
> >
> > ({ ... }) + i;
> >
> > ? How can we fix i
> On Sun, Aug 1, 2021 at 7:37 PM Uecker, Martin
> wrote:
> >
> >
> >
> > Here is an attempt to fix some old and annoying bugs related
> > to VLAs and statement expressions. In particulary, this seems
> > to fix the issues with variably-modified types which are
> > returned from statement expressio
Am Dienstag, den 03.08.2021, 11:26 +0200 schrieb Richard Biener:
> On Tue, Aug 3, 2021 at 10:28 AM Martin Uecker wrote:
>
> Does the same issue arise with writing the testcases as
>
> ({ ... }) + i;
>
> ? How can we fix it then if you also need to support
>
> i + ({ ...});
>
> ?
Here, t
Am Dienstag, den 03.08.2021, 11:26 +0200 schrieb Richard Biener:
> On Tue, Aug 3, 2021 at 10:28 AM Martin Uecker
> wrote:
> >
> > Hi
> > Am Dienstag, den 03.08.2021, 10:10 +0200 schrieb Richard Biener:
> > > On Tue, Aug 3, 2021 at 7:32 AM Martin Uecker
> > > wrote:
> > > >
> > > > (resending
On Tue, Aug 3, 2021 at 10:28 AM Martin Uecker wrote:
>
>
> Hi
> Am Dienstag, den 03.08.2021, 10:10 +0200 schrieb Richard Biener:
> > On Tue, Aug 3, 2021 at 7:32 AM Martin Uecker wrote:
> > >
> > >
> > > (resending from a different account, as emails seem to do not
> > > go out from my other accou
Hi
Am Dienstag, den 03.08.2021, 10:10 +0200 schrieb Richard Biener:
> On Tue, Aug 3, 2021 at 7:32 AM Martin Uecker wrote:
> >
> >
> > (resending from a different account, as emails seem to do not
> > go out from my other account at this time)
> >
> > Am Montag, den 02.08.2021, 16:05 +0200 sc
On Tue, Aug 3, 2021 at 7:32 AM Martin Uecker wrote:
>
>
>
> (resending from a different account, as emails seem to do not
> go out from my other account at this time)
>
> Am Montag, den 02.08.2021, 16:05 +0200 schrieb Martin Uecker:
> > > On Sun, Aug 1, 2021 at 7:37 PM Uecker, Martin
> > > wrote:
(resending from a different account, as emails seem to do not
go out from my other account at this time)
Am Montag, den 02.08.2021, 16:05 +0200 schrieb Martin Uecker:
> > On Sun, Aug 1, 2021 at 7:37 PM Uecker, Martin
> > wrote:
> > >
> > >
> > > Here is an attempt to fix some old and annoyin
On Sun, Aug 1, 2021 at 7:37 PM Uecker, Martin
wrote:
>
>
>
> Here is an attempt to fix some old and annoying bugs related
> to VLAs and statement expressions. In particulary, this seems
> to fix the issues with variably-modified types which are
> returned from statement expressions (which works on
Here is an attempt to fix some old and annoying bugs related
to VLAs and statement expressions. In particulary, this seems
to fix the issues with variably-modified types which are
returned from statement expressions (which works on clang),
but there are still bugs remaining related to structs
wit
On Fri, May 21, 2021 at 4:41 AM Hongtao Liu wrote:
>
> On Thu, May 20, 2021 at 4:30 PM Richard Biener
> wrote:
> >
> > On Thu, May 20, 2021 at 10:15 AM Hongtao Liu wrote:
> > >
> > > On Thu, May 20, 2021 at 4:06 PM Richard Biener
> > > wrote:
> > > >
> > > > On Thu, May 20, 2021 at 8:54 AM Hong
On Thu, May 20, 2021 at 4:30 PM Richard Biener
wrote:
>
> On Thu, May 20, 2021 at 10:15 AM Hongtao Liu wrote:
> >
> > On Thu, May 20, 2021 at 4:06 PM Richard Biener
> > wrote:
> > >
> > > On Thu, May 20, 2021 at 8:54 AM Hongtao Liu wrote:
> > > >
> > > > Hi:
> > > > In folding target-specific
On Thu, May 20, 2021 at 10:15 AM Hongtao Liu wrote:
>
> On Thu, May 20, 2021 at 4:06 PM Richard Biener
> wrote:
> >
> > On Thu, May 20, 2021 at 8:54 AM Hongtao Liu wrote:
> > >
> > > Hi:
> > > In folding target-specific builtin, when lhs is NULL, create a
> > > temporary variable for it.
> > >
On Thu, May 20, 2021 at 4:06 PM Richard Biener
wrote:
>
> On Thu, May 20, 2021 at 8:54 AM Hongtao Liu wrote:
> >
> > Hi:
> > In folding target-specific builtin, when lhs is NULL, create a
> > temporary variable for it.
> > Bootstrapped and regtested on x86_64-linux-gnu{-m32,}
>
> I would sugg
On Thu, May 20, 2021 at 10:06:36AM +0200, Richard Biener wrote:
> On Thu, May 20, 2021 at 8:54 AM Hongtao Liu wrote:
> >
> > Hi:
> > In folding target-specific builtin, when lhs is NULL, create a
> > temporary variable for it.
> > Bootstrapped and regtested on x86_64-linux-gnu{-m32,}
>
> I wo
On Thu, May 20, 2021 at 8:54 AM Hongtao Liu wrote:
>
> Hi:
> In folding target-specific builtin, when lhs is NULL, create a
> temporary variable for it.
> Bootstrapped and regtested on x86_64-linux-gnu{-m32,}
I would suggest to drop the stmt or leave it unfolded instead.
Note dropping would m
doesn't exist.
gcc/testsuite/ChangeLog:
PR target/100660
* gcc.target/i386/pr100660.c: New test.
--
BR,
Hongtao
From b32791645429e3e25c46f56e2b81ffab7863afde Mon Sep 17 00:00:00 2001
From: liuhongt
Date: Thu, 20 May 2021 09:59:36 +0800
Subject: [PATCH] Fix ICE when lhs is
On Wed, 12 May 2021 at 10:24, Richard Biener wrote:
>
> On Wed, 12 May 2021, Bernd Edlinger wrote:
>
> > Hi,
> >
> > this fixes another regression from my previous patch.
> >
> >
> > Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> > Is it OK for trunk?
>
> OK.
>
> Richard.
>
Hi,
As the new
On Wed, 12 May 2021, Bernd Edlinger wrote:
> Hi,
>
> this fixes another regression from my previous patch.
>
>
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
OK.
Richard.
>
> Thanks
> Bernd.
>
] Fix ICE in output_rnglists, at dwarf2out.c:12294
In this testcase the compile unit consists of a single
text section with a single embedded DECL_IGNORED_P function.
So we have a kind of multi-range text section here.
To avoid an ICE in output_rnglists we need to make sure
that
On 3/14/2021 8:03 AM, Iain Buclaw via Gcc-patches wrote:
Excerpts from Iain Sandoe's message of March 13, 2021 6:09 pm:
Hi Iain,
Iain Buclaw via Gcc-patches wrote:
This patch fixes an ICE caused by emutls routines generating a weak,
non-public symbol for storing the initializer of a weak T
Excerpts from Iain Sandoe's message of March 13, 2021 6:09 pm:
> Hi Iain,
>
> Iain Buclaw via Gcc-patches wrote:
>
>> This patch fixes an ICE caused by emutls routines generating a weak,
>> non-public symbol for storing the initializer of a weak TLS variable.
>>
>> In get_emutls_init_templ_addr,
Hi Iain,
Iain Buclaw via Gcc-patches wrote:
This patch fixes an ICE caused by emutls routines generating a weak,
non-public symbol for storing the initializer of a weak TLS variable.
In get_emutls_init_templ_addr, only declarations that were DECL_ONE_ONLY
would get a public initializer symbol
Hi,
This patch fixes an ICE caused by emutls routines generating a weak,
non-public symbol for storing the initializer of a weak TLS variable.
In get_emutls_init_templ_addr, only declarations that were DECL_ONE_ONLY
would get a public initializer symbol, ignoring variables that were
declared with
On Sat, Feb 20, 2021 at 11:49 AM Martin Liška wrote:
>
> After g:1a2a7096e5e20d736c6138179470b21aa5a74864 we forbid inlining
> for a VLA types. What we miss is setting inline_forbidden_reason
> variable.
>
> Fixes:
>
> ./xgcc -B. -O3 -c
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr99122-
After g:1a2a7096e5e20d736c6138179470b21aa5a74864 we forbid inlining
for a VLA types. What we miss is setting inline_forbidden_reason
variable.
Fixes:
./xgcc -B. -O3 -c /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr99122-2.c
-Winline
during GIMPLE pass: local-fnsummary
/home/marxin/Progra
On 12/23/20 6:18 PM, Martin Sebor wrote:
Thanks for looking into it! I'm actually just testing the very same
fix. It's taken me a while to come up with a non-LTO test case but
below is what I've got.
All right. You were faster, anyway thank you for the fix.
Martin
On 12/23/20 10:07 AM, Martin Liška wrote:
Hello.
I'm not fully familiar with code in warn_dealloc_offset, but I guess
the following can work.
Martin, what do you think?
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks for looking into it!
Hello.
I'm not fully familiar with code in warn_dealloc_offset, but I guess
the following can work.
Martin, what do you think?
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
PR tree-optimization/98160
On Thu, 15 Oct 2020, Jeff Law wrote:
>
> On 10/15/20 3:49 AM, Richard Biener wrote:
> > This fixes the case where the insertion iterator for the live stmt
> > is the end of a BB by adjusting the dominance query to the definition
> > of the def we're substituting.
> >
> > Bootstrapped and tested o
On 10/15/20 3:49 AM, Richard Biener wrote:
> This fixes the case where the insertion iterator for the live stmt
> is the end of a BB by adjusting the dominance query to the definition
> of the def we're substituting.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
>
> 2020-10-15
This fixes the case where the insertion iterator for the live stmt
is the end of a BB by adjusting the dominance query to the definition
of the def we're substituting.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2020-10-15 Richard Biener
* tree-vect-loop.c (vectorizab
This fixes a vector CTOR insertion issue when we try to insert after
a PHI node.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
2020-10-09 Richard Biener
* tree-vect-slp.c (vect_create_constant_vectors): Properly insert
after PHIs.
* gcc.dg/vect/bb-slp-phis-
On Mon, Sep 21, 2020 at 12:53 PM Martin Liška wrote:
>
> With SVE we can end up with:
> switch (POLY_INT_CST [2, 2]) [INV], case 2: [INV], case
> 4: [INV]>
> which is fine to expand and we can remove the assert.
>
> Ready to be installed?
OK.
Richard.
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
With SVE we can end up with:
switch (POLY_INT_CST [2, 2]) [INV], case 2: [INV], case 4:
[INV]>
which is fine to expand and we can remove the assert.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
PR tree-optimization/96915
* tree-switch-conversion.c (switch_conversion:
>> Hi,
>>
>> On Mon, Aug 31 2020, Feng Xue OS wrote:
>> > This patch is to fix a bug that cost that is used to evaluate clone
>> > candidate
>> > becomes negative due to integer overflow.
>> >
>> > Feng
>> > ---
>> > 2020-08-31 Feng Xue
>> >
>> > gcc/
>> > PR tree-optimization/96806
>>
> Hi,
>
> On Mon, Aug 31 2020, Feng Xue OS wrote:
> > This patch is to fix a bug that cost that is used to evaluate clone
> > candidate
> > becomes negative due to integer overflow.
> >
> > Feng
> > ---
> > 2020-08-31 Feng Xue
> >
> > gcc/
> > PR tree-optimization/96806
>
> the compon
>>> the component is "ipa," please change that when you commit the patch.
>> Mistake has been made, I'v pushed it. Is there a way to correct it? git push
>> --force?
>
> There is. You need to wait until tomorrow (after the commit message
> gets copied to gcc/ChangeLog by a script) and then push a
Hi,
On Mon, Aug 31 2020, Feng Xue OS wrote:
>>> gcc/
>>> PR tree-optimization/96806
>
>> the component is "ipa," please change that when you commit the patch.
> Mistake has been made, I'v pushed it. Is there a way to correct it? git push
> --force?
There is. You need to wait until tomor
>> gcc/
>> PR tree-optimization/96806
> the component is "ipa," please change that when you commit the patch.
Mistake has been made, I'v pushed it. Is there a way to correct it? git push
--force?
Thanks,
Feng
Hi,
On Mon, Aug 31 2020, Feng Xue OS wrote:
> This patch is to fix a bug that cost that is used to evaluate clone candidate
> becomes negative due to integer overflow.
>
> Feng
> ---
> 2020-08-31 Feng Xue
>
> gcc/
> PR tree-optimization/96806
the component is "ipa," please change that
1 - 100 of 977 matches
Mail list logo
