https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #27 from Qing Zhao ---
--- Comment #26 from Siddhesh Poyarekar ---
> (In reply to Qing Zhao from comment #25)
>> If (__builtin_get_counted_by (P->FAM))
>> __builtin_get_counted_by (P->FAM) = COUNT;
>
> Do we have language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #25 from Qing Zhao ---
> --- Comment #24 from Martin Uecker ---
>
> A builtin that returns the name or an lvalue for the member would seem to be
> more useful, but then harder to ignore when there is no attribute.
You mean,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
--- Comment #8 from Qing Zhao ---
> On Feb 16, 2023, at 2:35 AM, rguenther at suse dot de
> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
>
> --- Comment #7 from rguenther at suse dot de ---
> On Wed, 15 Feb 2023, qinzhao
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #15 from Qing Zhao ---
> On Jan 25, 2023, at 11:12 AM, siddhesh at gcc dot gnu.org
> wrote:
>>
>>> The first is handled by the function just fine,
>>
>> No, even the first case is not recognized by the current
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #13 from Qing Zhao ---
> On Jan 25, 2023, at 2:32 AM, rguenther at suse dot de
> wrote:
>>
>> A little confused here:
>>when the structure with a trailing flexible-array member is a middle
>> field of
>>an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #10 from Qing Zhao ---
> --- Comment #9 from Richard Biener ---
>
> GCC handles for example
>
> struct A { char data[1]; };
> struct B { int n; struct A a; };
>
> as if the a.data[] array is a flex-array.
Okay. Then the maximum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108132
--- Comment #7 from Qing Zhao ---
> On Dec 15, 2022, at 2:33 PM, pinskia at gcc dot gnu.org
> wrote:
>
>
> There is a patch in PR 57067 even which you could try to port to a newer
> compiler version and fix up.
Okay, will check that patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270
--- Comment #4 from Qing Zhao ---
> On Jul 12, 2022, at 1:02 PM, wilco at gcc dot gnu.org
> wrote:
>
> Note that GCC could split huge .text sections automatically to allow insertion
> of linker veneers every 128MB.
Does GCC do this by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #27 from Qing Zhao ---
> On Jun 14, 2022, at 11:39 AM, siddhesh at gcc dot gnu.org
> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
>
> --- Comment #26 from Siddhesh Poyarekar ---
> (In reply to qinzhao from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891
--- Comment #8 from Qing Zhao ---
> On May 24, 2022, at 11:42 AM, arjan at linux dot intel.com
> wrote:
>
> --- Comment #7 from Arjan van de Ven ---
> from a performance angle, the xor-only sequence is not so great at all; modern
> CPUs are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539
--- Comment #9 from Qing Zhao ---
> It's a conditional uninit use which we do not warn on early by design
> (for the fear of too many false positives, that is).
Okay.
>
>> 2. the ccp optimization deletes the if (z) statement completely:
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #20 from Qing Zhao ---
> On Feb 21, 2022, at 1:56 AM, rguenth at gcc dot gnu.org
> wrote:
>>
>> my question is, is the "info" in __builtin_clear_padding() a REAL use
>> of "info"? is it correct to report the uninitialized use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #14 from Qing Zhao ---
> On Feb 17, 2022, at 1:54 AM, rguenther at suse dot de
> wrote:
>>
>> If padding clearing is exposed too late till RTL expansion, some tree
>> optimization will not be able to be applied on the expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #5 from Qing Zhao ---
> On Feb 15, 2022, at 3:38 PM, pinskia at gcc dot gnu.org
> wrote:
> Maybe __builtin_clear_padding lowering should mark the load "MEM[(struct
> vx_audio_level *)]" as not needing a warning.
>
This sound like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #27 from Qing Zhao ---
> On Feb 11, 2022, at 11:47 AM, jakub at gcc dot gnu.org
> wrote:
> But if I do:
> struct C { char a; int b; char c; long d; C () : a (42), b (42), c (42), d
> (42)
> {} };
> void bar (C *);
> void
> foo ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #23 from Qing Zhao ---
> On Feb 11, 2022, at 9:29 AM, jason at gcc dot gnu.org
> wrote:
>
> I wonder why -fauto-var-init uses builtin_clear_padding instead of just
> zero-initializing the whole object before normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
--- Comment #4 from Qing Zhao ---
>
> You should be able to simply do
>
> ../configure --target=riscv64-linux
> make all-gcc
>
> and use the built gcc/cc1 to debug such ICEs.
>
Thanks. Yes, I can repeat the ICE with this gcc even though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103127
--- Comment #9 from Qing Zhao ---
> On Nov 8, 2021, at 1:56 PM, bergner at gcc dot gnu.org
> wrote:
>
>
> So this then?
This is better, I think.
You can send a patch review request to gcc-patch alias for more comments or
approval.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #10 from Qing Zhao ---
> On Oct 11, 2021, at 3:29 PM, jakub at gcc dot gnu.org
> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
>
> --- Comment #8 from Jakub Jelinek ---
> (In reply to qinzhao from comment #7)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102683
--- Comment #5 from Qing Zhao ---
> --- Comment #4 from Richard Biener ---
> But we should avoid
> the .DEFERRED_INIT here. The GENERIC is
>
>struct C y;
> < (void) (y = n == 1 ? TARGET_EXPR : TARGET_EXPR {.c=__complex__ (3.0e+0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #16 from Qing Zhao ---
> On Oct 1, 2021, at 1:51 AM, rguenth at gcc dot gnu.org
> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
>
> --- Comment #13 from Richard Biener ---
> Because the variable doesn't need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #5 from Qing Zhao ---
> On Sep 13, 2021, at 4:45 PM, pinskia at gcc dot gnu.org
> wrote:
>
>> is it possible to make -fsanitize=signed-integer-overflow work with -fwrapv?
>
> Why would it? they conflict.
This is a feature that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #4 from Qing Zhao ---
> On Sep 10, 2021, at 5:34 PM, pinskia at gcc dot gnu.org
> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
>
> --- Comment #3 from Andrew Pinski ---
> I wonder if most of these were fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586
--- Comment #9 from Qing Zhao ---
> On Jul 23, 2021, at 10:34 AM, jakub at gcc dot gnu.org
> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586
>
> --- Comment #8 from Jakub Jelinek ---
> (In reply to Qing Zhao from comment #7)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586
--- Comment #7 from Qing Zhao ---
> On Jul 23, 2021, at 10:10 AM, jakub at gcc dot gnu.org
> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586
>
> --- Comment #6 from Jakub Jelinek ---
> It is related to the weird FIELD_DECLs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99421
--- Comment #8 from Qing Zhao ---
> On Mar 8, 2021, at 11:58 AM, marxin at gcc dot gnu.org
> wrote:
>
> Sure. I used C-Vise:
> https://github.com/marxin/cvise
>From my understanding, cvise is similar as creduce, but faster.
So, I am still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680
--- Comment #10 from Qing Zhao ---
> but it will still fail on all targets but x86_64 (and now powerpc). Qinzhao,
> what's the list of targets this is supported?
I believe that the targets that currently support this feature are:
x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #21 from Qing Zhao ---
> --- Comment #19 from Jakub Jelinek ---
> And, actually the function.c change is probably unnecessary, because the
> if (!crtl->abi->clobbers_full_reg_p (regno))
>continue;
> if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #20 from Qing Zhao ---
> On Nov 4, 2020, at 11:48 AM, jakub at gcc dot gnu.org
> wrote:
>
> --- Comment #18 from Jakub Jelinek ---
> --- gcc/function.c.jj 2020-10-31 17:41:19.756740009 +0100
> +++ gcc/function.c 2020-11-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #17 from Qing Zhao ---
> On Nov 4, 2020, at 10:08 AM, ubizjak at gmail dot com
> wrote:
>>
>> I used the following in middle end to exclude fixed registers from being
>> zeroed:
>> if (fixed_regs[regno])
>>continue;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #13 from Qing Zhao ---
> On Nov 4, 2020, at 10:04 AM, jakub at gcc dot gnu.org
> wrote:
> --- Comment #11 from Jakub Jelinek ---
> I think you should do:
> --- gcc/function.c 2020-10-31 17:41:19.756740009 +0100
> +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #10 from Qing Zhao ---
> On Nov 4, 2020, at 9:45 AM, ubizjak at gmail dot com
> wrote:
>> fixed registers should already be excluded from zeroing.
>> are ST registers considered FIXED registers when -mno-80387 is specified?
>
>
32 matches
Mail list logo
