https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97309
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #6 from qinzhao at gcc dot gnu.org ---
when using gcc10.2 to compile our application, we have the same compilation
error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97357
--- Comment #1 from qinzhao at gcc dot gnu.org ---
/home/qinzhao/Install/latest/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/qinzhao/Install/latest/bin/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97357
Bug ID: 97357
Summary: Unable to coalesce ssa_names which are marked as MUST
COALESCE.
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #7 from qinzhao at gcc dot gnu.org ---
as we noticed, when using gcc10.2.1 compile our application, 528 C++ modules
failed with this bug.
looks like a high priority bug to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97357
--- Comment #9 from qinzhao at gcc dot gnu.org ---
with the patch, all the C modules in our application that failed with this bug
passed without any issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97309
--- Comment #1 from qinzhao at gcc dot gnu.org ---
proposed patch:
Subject: [PATCH] PR97309--improve documentation of -fallow-store-data-races
---
gcc/doc/invoke.texi | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97309
Bug ID: 97309
Summary: Improve documentation of -fallow-store-data-races
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #3 from qinzhao at gcc dot gnu.org ---
This does not look like a bug in the new -fzero-call-used-regs implemenation.
it's more likely an existing bug in data flow analysis.
I made the following change in gcc/function.c to make the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #4 from qinzhao at gcc dot gnu.org ---
this should be a bug in the pass "stack".
if I modify the file "reg-stack.c" as following:
qinzhao@gcc10:~/Work/write_gcc/gcc$ git diff reg-stack.c
diff --git a/gcc/reg-stack.c b/gcc/reg-stack.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #5 from qinzhao at gcc dot gnu.org ---
the following patch in reg-stack.c fixed the failure:
qinzhao@gcc10:~/Work/write_gcc/gcc$ git diff reg-stack.c
diff --git a/gcc/reg-stack.c b/gcc/reg-stack.c
index 8f98bd85750..3dab843f803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680
--- Comment #1 from qinzhao at gcc dot gnu.org ---
(In reply to seurer from comment #0)
> commit d10f3e900b0377b4760a090b0f90371bcef01686
> Author: qing zhao
> Date: Fri Oct 30 20:41:38 2020 +0100
>
> If looks like the errors are all like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97699
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680
--- Comment #3 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> Err, please dg-skip the tests for ! supported targets. They also fail on
> x86_64 with -m32 btw.
x86_64 with -m32 failure should be already fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #22 from qinzhao at gcc dot gnu.org ---
proposed patch:
This change fixes a bug in the i386 backend when adding
-fzero-call-used-regs=all on a target that has no x87
registers.
When there is no x87 registers available, we should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #1 from qinzhao at gcc dot gnu.org ---
for -fzero-call-used-regs=all, when zeroing st/mm registers under x87 exit
mode, However, command line option force no 80387 mode, the following insn
generated to zero st registers is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> ;; Floating-point register constraints.
> (define_register_constraint "f"
> "TARGET_80387 || TARGET_FLOAT_RETURNS_IN_80387 ? FLOAT_REGS : NO_REGS"
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #2)
> (In reply to qinzhao from comment #1)
> > for -fzero-call-used-regs=all, when zeroing st/mm registers under x87 exit
> > mode, However, command line option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98702
Bug ID: 98702
Summary: linker failure with a very simple testing case for
gcc10
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #17 from qinzhao at gcc dot gnu.org ---
(In reply to David Malcolm from comment #15)
> where:
>
> (gdb) call inform (loc_a, "loc_a")
> In file included from
> /usr/i686-w64-mingw32/sys-root/mingw/include/minwindef.h:163,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #23 from qinzhao at gcc dot gnu.org ---
with the latest gcc11, our application can be compiled without any issue now.
thanks a lot for fixing this bug.
will this patch be added to gcc10?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99627
--- Comment #2 from qinzhao at gcc dot gnu.org ---
NOTE, this failure is on aarch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99627
--- Comment #1 from qinzhao at gcc dot gnu.org ---
Created attachment 50411
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50411=edit
testing case and script
testing case and script
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99627
Bug ID: 99627
Summary: ICE:in sel_is_loop_preheader_p, at sel-sched-ir.c:6347
with -fprofile-use -fselective-scheduling
-fsel-sched-pipelining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99332
Bug ID: 99332
Summary: ICE:inreset_sched_cycles_in_current_ebb, at
sel-sched.c:7147 with -fprofile-generate -O3
-fselective-scheduling -fselective-scheduling2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99421
--- Comment #2 from qinzhao at gcc dot gnu.org ---
Created attachment 50318
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50318=edit
tar ball to repeat the failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99421
--- Comment #4 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Liška from comment #3)
> Confirmed, reduced test-case:
>
just curious, how did you reduce the testing case with -fprofile-use? (I tried
Creduce, but failed)
another question,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99328
Bug ID: 99328
Summary: ICE: in verify_target_availability, at
sel-sched.c:1557 with -fselective-scheduling2 on
aarch64
Product: gcc
Version: 11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99421
Bug ID: 99421
Summary: ICE:in code_motion_process_successors, at
sel-sched.c:6389 on aarch64
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100053
Bug ID: 100053
Summary: tree-fre incorrectly delete a condition
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100053
--- Comment #9 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
> It would be nice if the reduced testcase could be sanitized to throw less
> diagnostics with -Wall, likewise if it were a runtime testcase.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100053
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> Created attachment 50579 [details]
> fix for the issue
>
> I am testing this patch - maybe you can test it on the original testcase you
> cannot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102269
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102273
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #2 from qinzhao at gcc dot gnu.org ---
I checked all the listed testing cases with the latest GCC + -g
-ftrivial-auto-var-init=pattern -O2
all passed without issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |qinzhao at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
Bug ID: 102317
Summary: signed integer overflow sanitizer cannot work well
with -fno-strict-overflow
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> -fno-strict-overflow maps directly to -fwrapv .
>
> If you want to use -fsanitize=signed-integer-overflow, you can just remove
> both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #5 from qinzhao at gcc dot gnu.org ---
with the latest GCC, for all the 42647 c files under gcc/testsuite, with -c -g
-O2 -Wall -ftrivial-auto-var-init=zero, there is only one failure:
/home/opc/Install/latest/bin/gcc -c -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #14 from qinzhao at gcc dot gnu.org ---
All the 3 testing cases can be resolved by adding the following patch (check
whether the type has padding before adding call to __builtin_clear_padding):
I believe that this is a safe partial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
> __builtin_clear_padding when folded emits a series of memory stores rather
> than BIT_INSERT_EXPR etc., so that wouldn't work.
> But, IMNSHO,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> Sure, you can, but just note that it is conservative and fast, it will
> return true even for types that don't have any padding.
> But for double,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #12 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> and if you have a variable that isn't addressable, you need to figure out
> what to do. I think it might be easiest not to clear anything, another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102781
Bug ID: 102781
Summary: -ftrivial-auto-var-init might not clear paddings for
long double/_Complex long double variables that have
explicit initializer
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102781
--- Comment #1 from qinzhao at gcc dot gnu.org ---
This is a placeholder to an known issue with -ftrivial-auto-var-init:
If a long double/_Complex long double auto variable has explicit initializer,
and when this variable is spilled into stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #15 from qinzhao at gcc dot gnu.org ---
A summary of this bug based on discussion and more study:
multiple issues in the current implemenation:
A. should check is_gimple_reg before adding the call to
__builtin_clear_padding;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102359
--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Confirmed. So we end with '&__closure->__this' which indeed isn't an lvalue.
>
> The issue here is that we are initializing the VAR_DECL 'this'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #8 from qinzhao at gcc dot gnu.org ---
the ICE is triggered by the following IR:
MEM[(int[0:D.1993] *)] = .DEFERRED_INIT (16, 2, 1);
which is transformed from the original IR:
(*fb.1_9) = .DEFERRED_INIT (16, 2, 1);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #12 from qinzhao at gcc dot gnu.org ---
with the following change, I can resolve the ICE:
[opc@qinzhao-ol8u3-x86 gcc]$ git diff
diff --git a/gcc/tree-ssa-ccp.c b/gcc/tree-ssa-ccp.c
index 70ce6a4d5b8d..b07026165075 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #10 from qinzhao at gcc dot gnu.org ---
commented the following transformation in tree-ssa-ccp.c:
2733 #if 0
2734 /* The heuristic of fold_builtin_alloca_with_align differs before
and
2735after inlining, so we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #9 from qinzhao at gcc dot gnu.org ---
the direct cause of the ICE is because:
MEM[(int[0:D.1993] *)] = .DEFERRED_INIT (16, 2, 1);
in the above, the fb.3 is in REG instead MEM:
8451 gcc_assert (MEM_P (result));
(gdb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #15 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #13)
> Because the variable doesn't need to be addressable.
>
> OK, so the issue is likely that we're probing the lhs with EXPAND_WRITE but
> when we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #17 from qinzhao at gcc dot gnu.org ---
> > OK, so the issue is likely that we're probing the lhs with EXPAND_WRITE but
> > when we expand the memset we end up with using expand_expr_addr_expr_1
> > with EXPAND_NORMAL.
>
> then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #18 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #13)
> We could try sth like the following which should cover this testcase and
> also hopefully doesn't break anything else.
>
> diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102587
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #25 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #22)
> Hmm, my proposed patch seems to work. I've adjusted it to not regress
> previously correctly handled cases and will test it fully.
I guess the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|FIXED |---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #28 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #21)
> Reduced testcase:
>
> int
> qy (void)
> {
> int tw = 4;
> int fb[tw];
> return fb[2];
> }
For this reduced testing case, if compiled with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #26 from qinzhao at gcc dot gnu.org ---
(In reply to qinzhao from comment #25)
> (In reply to Richard Biener from comment #22)
> > Hmm, my proposed patch seems to work. I've adjusted it to not regress
> > previously correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102359
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103206
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103038
--- Comment #6 from qinzhao at gcc dot gnu.org ---
just wondering why the ICE after my fix to PR102281. and found the reason:
Before the fix to PR102281, the IR before expansion phase is:
void test ()
{
<<< Unknown tree: offset_type >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103025
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103033
--- Comment #2 from qinzhao at gcc dot gnu.org ---
I can repeat this ICE on the gcc farm machine gcc112, which is a Powerpcle
linux machine with the latest upstream gcc (11/2/2021).
and locate the issue at:
Breakpoint 2, expand_DEFERRED_INIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103033
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102941
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #16 from qinzhao at gcc dot gnu.org ---
Created attachment 51662
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51662=edit
proposed patch to gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103127
--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #5)
> (In reply to qinzhao from comment #4)
> > with -ftrivial-auto-var-init=zero, failed at the same place.
>
> You mean without the patch from Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103127
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103127
--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > The types are OPAQUE_TYPE.
> [snip]
> > So if I understand this correctly and PR 98872 correctly. We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #18 from qinzhao at gcc dot gnu.org ---
fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
--- Comment #15 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #11)
>
> I suppose assigning TImode to a decl but not even being able to move TImode
> can be a problem elsewhere...
this might be the root issue that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
--- Comment #17 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #12)
> diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
> index 6ac3460d538..08f94b7a17a 100644
> --- a/gcc/internal-fn.c
> +++ b/gcc/internal-fn.c
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
--- Comment #8 from qinzhao at gcc dot gnu.org ---
the minimum option to repeat this failure is "-O1 -mno-strict-align".
The option "-mno-strict-align" is the one that make the difference.
For the following call to .DEFERRED_INIT:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
--- Comment #9 from qinzhao at gcc dot gnu.org ---
disable tree-ccp by adding -fno-tree-ccp cures the ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103127
--- Comment #11 from qinzhao at gcc dot gnu.org ---
Please see the details of the discussion of the patch for this bug:
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg275509.html
as a summary, we decide to exclude OPAQUE_TYPE from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
--- Comment #10 from qinzhao at gcc dot gnu.org ---
looks like that this is exactly the same issue as exposed in pr102285.
and the original fix to pr102285 just hide this inconsistent IR issue.
-mno-strict-align exposed this issue again.
So.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103720
--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
>
> Dom transformed:
> c$a$0_6 = .DEFERRED_INIT (8, 2, 0);
> _1 = .DEFERRED_INIT (8, 2, 0);
>
> into:
> c$a$0_6 = .DEFERRED_INIT (8, 2, 0);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103720
Bug ID: 103720
Summary: bogus warning from -Wuninitialized +
-ftrivial-auto-var-init + O2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586
Bug ID: 101586
Summary: ICE:in clear_padding_type, at gimple-fold.c:4783 with
call to __builtin_clear_padding for C++
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586
--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
> Reduced testcase:
> struct A { char a; };
> struct B : virtual A {};
> struct C : B {};
>
> void
> foo ()
> {
> C c;
> __builtin_clear_padding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586
--- Comment #4 from qinzhao at gcc dot gnu.org ---
I applied the attached patch and tested CPU2017 with
-ftrivial-auto-var-init=pattern, now all the corresponding C++ failures get
resolved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103720
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103720
--- Comment #3 from qinzhao at gcc dot gnu.org ---
this is fixed with the following commit in gcc12.
https://gcc.gnu.org/pipermail/gcc-cvs/2022-January/359118.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #9 from qinzhao at gcc dot gnu.org ---
having a patch in my local tree, under testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #1 from qinzhao at gcc dot gnu.org ---
Kees reported the following issue with -ftrivial-auto-var-init=pattern. the
testing case was reduced from Kernel building.
$ cat warns.i
struct vx_audio_level {
int has_monitor_level : 1;
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
Bug ID: 104550
Summary: bogus warning from -Wuninitialized +
-ftrivial-auto-var-init=pattern
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-02-15
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #10)
> I think it definitely makes sense to diagnose that we are not
> following -ftrivial-auto-init-var=X for a decl. Maybe we should
> do that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #3 from qinzhao at gcc dot gnu.org ---
the root cause for this bug is due to the new call to __builtin_clear_padding
added by -ftrivial-auto-var-init=pattern, this is treated as a use of the
uninitialized variable during early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
--- Comment #8 from qinzhao at gcc dot gnu.org ---
fixed in gcc11 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #6)
> > --- Comment #4 from Andrew Pinski ---
> > Maybe __builtin_clear_padding lowering should mark the load "MEM[(struct
> > vx_audio_level *)]" as
1 - 100 of 232 matches
Mail list logo
