https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88400
--- Comment #5 from hhj ---
(In reply to Richard Biener from comment #2)
> Please provide a testcase to reproduce the issue. Also note that GCC 6 is
> no longer supported. This sounds like an issue in the libsanitizer
> interceptor
> to me, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88400
--- Comment #4 from hhj ---
(In reply to Andrew Pinski from comment #3)
> Also this seems like it is an upstream issue too.
This is how we handle it.
When the parent's sched_priority isn't sam as the children's
1 If the parent's sched_priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88400
hhj changed:
What|Removed |Added
CC||He.Hongjun at zte dot com.cn
--- Comment #1 from
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: He.Hongjun at zte dot com.cn
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87023
--- Comment #2 from hhj ---
(In reply to Joseph S. Myers from comment #1)
> This is not a bug. The comment on c_fully_fold_internal explains its
> semantics, which only ever involve clearing *MAYBE_CONST_OPERANDS and
> *MAYBE_CONST_ITSELF (point
erity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: He.Hongjun at zte dot com.cn
Target Milestone: ---
in c_fully_fold_internal, C_MAYBE_CONST_EXPR's initial value is false. later,
using add operations, it's
