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
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
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)));
>
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.
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,
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
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:
> >
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
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_
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
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
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.
>
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
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-
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!
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
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:
>
>> 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
On Mon, Aug 31, 2020 at 10:06 AM Feng Xue OS via Gcc-patches
wrote:
>
> This patch is to fix a bug that cost that is used to evaluate clone candidate
> becomes negative due to integer overflow.
OK.
Richard.
> Feng
> ---
> 2020-08-31 Feng Xue
>
> gcc/
> PR tree-optimization/96806
>
On Mon, Aug 24, 2020 at 3:03 PM Hongtao Liu wrote:
>
> Hi:
> This patch is to fix a typo in my last patch [1].
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551982.html
>
> Bootstrap is ok, gcc regression test hosted on CLX for i386/x86-64
> backend is ok.
> Ok for trunk?
>
>
On Mon, Jun 15, 2020 at 10:23 AM Eric Botcazou wrote:
>
> > The patch probably fixes only part of the issues with SRA and rev-storage.
>
> Well, this issue (coming from a bypass in SRA) is the first issue uncovered
> with rev-storage in SRA for years.
>
> > I see in build_ref_for_model:
> >
> >
> The patch probably fixes only part of the issues with SRA and rev-storage.
Well, this issue (coming from a bypass in SRA) is the first issue uncovered
with rev-storage in SRA for years.
> I see in build_ref_for_model:
>
> /* The flag will be set on the record type. */
> REF_REVER
On Thu, Jun 11, 2020 at 5:24 PM Eric Botcazou wrote:
>
> > I am not very good at reasoning about reverse storage order stuff but
> > can it ever happen that this reverse is not the same as racc->reverse?
> >
> > In order for that to happen, we'd have to have an assignment (folded
> > memcpy?) betw
> I am not very good at reasoning about reverse storage order stuff but
> can it ever happen that this reverse is not the same as racc->reverse?
>
> In order for that to happen, we'd have to have an assignment (folded
> memcpy?) between two aggregates in the original code that, at the same
> offse
Hi,
On Thu, Jun 11 2020, Eric Botcazou wrote:
> Hi,
>
> this fixes an issue with reverse storage order in SRA, which is caught by the
> built-in verifier:
>
> ===GNAT BUG DETECTED==+
> | 11.0.0 20200610 (experimental) (x86_64-suse-linux) GCC err
On Mon, 2020-03-23 at 16:32 +0100, Andrea Corallo wrote:
> Hi all,
>
> I'd like to submit this for PR94144.
>
> The patch prevent 'simplify_logical_relational_operation' to generate
> insn with a float only operator with non float operands.
>
>
> In the PR the following
>
> (ior:SI (gt:SI (reg
On Fri, Jan 17, 2020 at 03:11:40PM +0100, Jakub Jelinek wrote:
> On Fri, Jan 17, 2020 at 09:07:01AM -0500, Jason Merrill wrote:
> > On 12/30/19 3:51 PM, Kerem Kat wrote:
> > > +/* { dg-message "expected" "expected" { target *-*-* } .3 } */
> >
> > Dejagnu doesn't like this:
> >
> > ERROR: c-c++-c
On Fri, Jan 17, 2020 at 09:07:01AM -0500, Jason Merrill wrote:
> On 12/30/19 3:51 PM, Kerem Kat wrote:
> > +/* { dg-message "expected" "expected" { target *-*-* } .3 } */
>
> Dejagnu doesn't like this:
>
> ERROR: c-c++-common/pr92833-4.c -std=c++98: expected integer but got ".3"
> for " dg-messa
On 12/30/19 3:51 PM, Kerem Kat wrote:
+/* { dg-message "expected" "expected" { target *-*-* } .3 } */
Dejagnu doesn't like this:
ERROR: c-c++-common/pr92833-4.c -std=c++98: expected integer but got
".3" for " dg-message 4 "expected" "expected" { target *-*-* } .3 "
Jason
Thank you for reviewing and committing it.
Kerem
On Fri, Jan 17, 2020 at 1:04 AM Jeff Law wrote:
> On Thu, 2020-01-16 at 23:43 +, Joseph Myers wrote:
> > Thanks, patch committed.
> Beat me to it :-) I spun it yesterday, but didn't get around to
> committing it.
> jeff
>
>
On Thu, 2020-01-16 at 23:43 +, Joseph Myers wrote:
> Thanks, patch committed.
Beat me to it :-) I spun it yesterday, but didn't get around to
committing it.
jeff
Thanks, patch committed.
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, 2019-12-11 at 00:23 +0100, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because gimple_call_alloc_size doesn't
> always
> return a sizetype typed INTEGER_CST, which the callers rely on
> (compare
> those converted to wide_int with other wide_ints with the sizetype
> precisio
On Tue, 2019-12-10 at 21:40 +0100, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on the newly added asserts.
> Some comments hint that maybe it is fine if CODE_LABEL additions
> don't
> trigger df recomputations, but even if it is not ok,
> regstat_bb_compute_calls_crossed doesn't loo
On Mon, Dec 9, 2019 at 1:23 PM Eric Botcazou wrote:
>
> Hi,
>
> this is a regression present on the mainline and 9 branch: the compiler gives
> an ICE for the attached Ada testcase on the following assertion:
>
> if (DECL_P (ref))
> {
> /* We shouldn't have true variables h
> On the following testcase we ICE on i686-linux (32-bit), because we store
> (first 96-bit, then 72-bit) structure into the first part of a 2x 96-bit
> complex long double, and for 96-bit floats there is no corresponding
> integral mode that covers it and we ICE when op0 is not in MEM (it is a
> R
On Thu, Dec 5, 2019 at 9:21 AM Jakub Jelinek wrote:
>
> Hi!
>
> The huge LTO testcase in the PR ICEs, because in a function
> where optimize_function_for_speed_p (cfun) and when targetting
> -march=i686 optab_handler (movstrict_optab, E_QImode) is
> CODE_FOR_movstrictqi, but when the *movstrictqi
On 29.11.19 15:46, Richard Sandiford wrote:
> Thanks for doing this, looks good to me FWIW. I was seeing the same
> failure for SVE but hadn't found time to look at it.
Thank you all for the review. Committed as r278853.
Frederik
"Harwath, Frederik" writes:
> Hi Jakub,
>
> On 29.11.19 14:41, Jakub Jelinek wrote:
>
>> s/use/Use/
>>
>> [...]
>>
>> s/. /. /
>
> Right, thanks. Does that look ok for inclusion in trunk now?
>
> Best regards,
> Frederik
>
>
> 2019-11-29 Frederik Harwath
>
> gcc/
> * gimple-match-head.
Hi Jakub,
On 29.11.19 14:41, Jakub Jelinek wrote:
> s/use/Use/
>
> [...]
>
> s/. /. /
Right, thanks. Does that look ok for inclusion in trunk now?
Best regards,
Frederik
2019-11-29 Frederik Harwath
gcc/
* gimple-match-head.c (maybe_resimplify_conditional_op): Use
generic_
On Fri, Nov 29, 2019 at 02:38:34PM +0100, Harwath, Frederik wrote:
> 2019-11-29 Frederik Harwath
>
> gcc/
> * gimple-match-head.c (maybe_resimplify_conditional_op): use
s/use/Use/
> generic_expr_could_trap_p to check if the condition of COND_EXPR or
> VEC_COND_EXPR can trap.
On Thu, 28 Nov 2019, Jakub Jelinek wrote:
> Hi!
>
> The various routines propagate to the caller whether
> if (check_and_optimize_stmt (&gsi, &cleanup_eh, evrp.get_vr_values ()))
> gsi_next (&gsi);
> should do gsi_next or not (return false if e.g. gsi_remove is done, thus
> gsi is a
On Sat, Nov 23, 2019 at 2:09 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase ICEs, because ix86_md_asm_adjust emits an invalid
> insn that isn't matched. setcc_qi output is nonimmediate_operand and so is
> fine, but the problem is if we decide to do a ZERO_EXTEND, because
> zero_extend
On Wed, 20 Nov 2019, Jakub Jelinek wrote:
> Hi!
>
> I agree that we shouldn't have made __builtin_stack_{save,restore} public,
> but I'd fear it is too late to remove it now (and replace by internal fn),
> I'd think some code might use it to control when e.g. alloca will be
> released. As the co
On Wed, 20 Nov 2019, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase we ICE on i686-linux (32-bit), because we store
> (first 96-bit, then 72-bit) structure into the first part of a 2x 96-bit
> complex long double, and for 96-bit floats there is no corresponding
> integral mode that cove
On 11/19/19 4:42 PM, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase we ICE on i686-linux (32-bit), because we store
> (first 96-bit, then 72-bit) structure into the first part of a 2x 96-bit
> complex long double, and for 96-bit floats there is no corresponding
> integral mode that cover
On 11/19/19 4:58 PM, Jakub Jelinek wrote:
> Hi!
>
> I agree that we shouldn't have made __builtin_stack_{save,restore} public,
> but I'd fear it is too late to remove it now (and replace by internal fn),
> I'd think some code might use it to control when e.g. alloca will be
> released. As the com
On Mon, 11 Nov 2019, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on aarch64-linux. The problem is that maxbound
> is POLY_INT_CST, eltsize is INTEGER_CST, but int_const_binop for
> TRUNC_DIV_EXPR returns NULL_TREE as it can't simplify it to something
> usable and we later try to M
On November 9, 2019 1:07:18 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>On the following testcase we ICE, because gimple_resimplify3 is called
>on a CONSTRUCTOR with 3 elements, which is fine, but it calls
>fold_ternary
>which works only on expression codes with TREE_CODE_LENGTH of 3.
>
>Fixed thu
On 9/24/19 5:57 PM, Jeff Law wrote:
> Sure, and IMHO moving tests like this should be something that can be
> done without explicit ACKs.
Ok, next time I'll not ask for a confirmation ;)
Thanks,
Martin
>
> jeff
On 9/24/19 4:34 AM, Martin Liška wrote:
> On 9/24/19 11:14 AM, Thomas Schwinge wrote:
>> Hi!
>>
>> Curious: even if you found the issue on a s390x target, shouldn't this
>> (presumably generic?) test case live in a generic place instead of
>> 'gcc.target/s390/'?
>
> Sure, that's logical and I've j
On 9/24/19 11:14 AM, Thomas Schwinge wrote:
> Hi!
>
> Curious: even if you found the issue on a s390x target, shouldn't this
> (presumably generic?) test case live in a generic place instead of
> 'gcc.target/s390/'?
Sure, that's logical and I've just tested that locally on x86_64-linux-gnu.
Read
Hi!
Curious: even if you found the issue on a s390x target, shouldn't this
(presumably generic?) test case live in a generic place instead of
'gcc.target/s390/'?
Grüße
Thomas
On 2019-06-27T11:21:33+0200, Martin Liška wrote:
> This is quite an obvious changes I've noticed during fuzzing
> of
On Fri, 6 Sep 2019, Jakub Jelinek wrote:
> Hi!
>
> On Thu, Sep 05, 2019 at 08:40:35PM +0200, Bernhard Reutner-Fischer wrote:
> > >@@ -2771,6 +2771,11 @@ load_register_parameters (struct arg_dat
> > > poly_int64 size = 0;
> > > HOST_WIDE_INT const_size = 0;
> > > rtx_insn *before_arg =
Hi!
On Thu, Sep 05, 2019 at 08:40:35PM +0200, Bernhard Reutner-Fischer wrote:
> >@@ -2771,6 +2771,11 @@ load_register_parameters (struct arg_dat
> > poly_int64 size = 0;
> > HOST_WIDE_INT const_size = 0;
> > rtx_insn *before_arg = get_last_insn ();
> >+ tree type = TREE_TYPE
On Thu, 5 Sep 2019, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on most targets. The problem is that
> initialize_argument_information properly considers the type of the first
> field in this case for how the aggregate should be passed, but then
> load_register_parameters uses the
On July 20, 2019 8:45:38 AM GMT+02:00, Jakub Jelinek wrote:
>On Fri, Jul 19, 2019 at 04:41:06PM +0200, Uros Bizjak wrote:
>> As suggested by Jakub in the PR, add missing vector one_cmpl2
>to
>> mmx.md. A generic fix is in the works by Jakub.
>
>Yes, here it is. Bootstrapped/regtested on x86_64-li
On Thu, Jun 27, 2019 at 11:21 AM Martin Liška wrote:
>
> Hi.
>
> This is quite an obvious changes I've noticed during fuzzing
> of s390x target compiler.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
OK.
Richard.
> Thanks,
> Martin
>
> gcc
On Thu, 30 May 2019, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on the trunk, because both gsi_split_seq_after
> and gsi_insert_seq_after have assertions that the split is not after
> gsi_end_p iterator or insertion is not after such an iterator.
>
> My understanding of Alex' cha
On Mon, May 27, 2019 at 10:32 AM Eric Botcazou wrote:
>
> The function simply doesn't handle the new location expression opcodes coming
> from DebugFission (https://gcc.gnu.org/wiki/DebugFission). Fixed by making it
> handle them like DW_OP_addr and DW_OP_const*.
>
> OK for mainline and the activ
On 3/14/19 7:47 PM, Martin Sebor wrote:
> To copy type attributes from struct A, the copy attribute (new
> in GCC 9) accepts a pointer argument such as (struct A*)0, but
> it isn't prepared for anything much more complicated than that.
> So for example when it's passed something like (struct A*)(0,
On 3/19/19 12:42 PM, Jeff Law wrote:
On 3/14/19 7:47 PM, Martin Sebor wrote:
To copy type attributes from struct A, the copy attribute (new
in GCC 9) accepts a pointer argument such as (struct A*)0, but
it isn't prepared for anything much more complicated than that.
So for example when it's pass
On 3/14/19 7:47 PM, Martin Sebor wrote:
> To copy type attributes from struct A, the copy attribute (new
> in GCC 9) accepts a pointer argument such as (struct A*)0, but
> it isn't prepared for anything much more complicated than that.
> So for example when it's passed something like (struct A*)(0,
On March 11, 2019 11:32:38 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>All other expand_builtin* calls in builtins.c return NULL or return
>const0_rtx or return without ICEing when arg validation fails, but
>these
>two and as the testcases show, it can happen on invalid (at runtime)
>testcases. Fi
On March 5, 2019 4:18:13 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>When adding this warning years ago, I forgot to verify number of
>arguments.
>
>Fixed thusly, bootstrapped/regtested on powerpc64{,le}-linux, ok for
>trunk?
OK.
Richard.
>2019-03-05 Jakub Jelinek
>
> PR middle-end/89
On 2/20/19 3:32 PM, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase we ICE in simplify_gen_subreg, when result has
> BLKmode and we want to convert it to some complex mode (e.g. DCmode or
> in theory XCmode or TCmode too).
> Such SUBREGs are invalid, but BLKmode can only live in memory an
On Thu, 14 Feb 2019, Jakub Jelinek wrote:
> Hi!
>
> We ICE on the following testcase, because while we save optimize,
> and optimize_{size,debug} vars during option saving/restoring, we don't save
> optimize_fast, and because of that end up with optimize 0 optimize_fast 1
> which the option handl
1 - 100 of 443 matches
Mail list logo
