[Bug c/119893] '-Wnonnull' should not warn null pointer use in 'typeof' expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119893 --- Comment #1 from Kang-Che Sung --- (Downstream issue report: )

[Bug c/119893] New: '-Wnonnull' should not warn null pointer use in 'typeof' expression

Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- Test code: ```c __attribute__((nonnull)) \ int func(void *p); __typeof__(func((void *)0)) func2(void *p); t

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170 --- Comment #19 from Kang-Che Sung --- (In reply to Alejandro Colomar from comment #17) > > There are less compilers than programs that use it, so there will be less > points of failure if this is implemented in the compiler instead of in each

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170 --- Comment #15 from Kang-Che Sung --- (In reply to Alejandro Colomar from comment #13) > > > > Unimportant differences, I would say. > > Not really unimportant. Every time someone writes one of these in a > project, you need to make sure it'

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170 --- Comment #16 from Kang-Che Sung --- (In reply to Alejandro Colomar from comment #13) > > > > Unimportant differences, I would say. > > Not really unimportant. Every time someone writes one of these in a > project, you need to make sure it'

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170 --- Comment #12 from Kang-Che Sung --- Allow me to clarify some things. (In reply to Alejandro Colomar from comment #10)> > > The `_Widthof` > > operator working with traditional integer types is a plus but not a > > necessity. > > Here's an

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170 Kang-Che Sung changed: What|Removed |Added CC||Explorer09 at gmail dot com

[Bug other/119178] New: Optimization: (x != C) comparison can utilize (x - C) or (x ^ C) result

: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- This is an optimization opportunity that can benefit RISC-V, MIPS and other processors that don't use condition code

[Bug tree-optimization/115529] Optimization with "bit mask and compare equality" ((x & C1) == C2), ((x | C3) == C4)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115529 --- Comment #2 from Kang-Che Sung --- Since I've run into this problem again. I think it's good rephrase the issue, and provide another example code. This optimization feature request is about comparing whether a variable is in a specific range

[Bug other/118679] New: Missed optimization: inline functions, when operations can be done with smaller bit width

Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- ```c #include #include static inline uint64_t saturating_sub_u64(uint64_t a, uint64_t b) { return

[Bug other/118397] New: Missed optimization (x % (C1 * C2) / C2) vs. ((x / C2) % C1)

Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- When an expression contains modulo and division, if the modulo happens first but the divisor is a multiple of the divisor later on, the

[Bug tree-optimization/117529] Missed optimization: (y != 0 && x > (unsigned)(-1) / y) (multiplication overflow check)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117529 --- Comment #5 from Kang-Che Sung --- Sorry again. My mind wasn't cleaned up when I wrote the comment. It's (x == 0 || y == 0) and the logic is not equivalent to ((x & y) == 0).

[Bug tree-optimization/117529] Missed optimization: (y != 0 && x > (unsigned)(-1) / y) (multiplication overflow check)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117529 --- Comment #4 from Kang-Che Sung --- Oops. Correction. I mean this: ```c bool func5(unsigned long long x, unsigned long long y) { /* (x == 0 || y == 0) */ if ((x & y) == 0) return 0; unsigned long long res; return __builtin_umu

[Bug tree-optimization/117529] Missed optimization: (y != 0 && x > (unsigned)(-1) / y) (multiplication overflow check)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117529 --- Comment #3 from Kang-Che Sung --- The func4 example that Andrew Pinski provided makes me realize that this func5 should optimize to the same code: ```c bool func5(unsigned long long x, unsigned long long y) { if ((x | y) == 0) return 0;

[Bug tree-optimization/117529] New: Missed optimization: (y != 0 && x > (unsigned)(-1) / y) (multiplication overflow check)

UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- ```c #include #include bool func1(unsigned long long x, unsigned long long y) {

[Bug other/115687] New: RISC-V optimization when "lui" instructions can be merged

ty: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- ```c #include int main() { unsigned int a = 0x4010; // (0x4 << 12) + 0x10 unsigned int b = 0x4020; // (0

[Bug rtl-optimization/115674] New: "Checking if number is within interval" missed optimization when number is from a smaller int type

Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- ```c #include #include bool func1(uint8_t x) { uint32_t value;

[Bug tree-optimization/115529] New: Optimization with "bit mask and compare equality" ((x & C1) == C2), ((x | C3) == C4)

s: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- I thought this pattern is commonly seen, but I didn't find any issue report in

[Bug other/115525] New: Documentation: "sentinel" attribute should suggest "nullptr" instead of NULL

D Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- "sentinel" function attribute in GCC documentation: https://gcc.gnu.org/onlinedocs/gcc/C

[Bug rtl-optimization/115506] Possible but missed "cmp" instruction merging (x86 & ARM, optimization)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115506 --- Comment #3 from Kang-Che Sung --- I'm not sure if this helps, but the idea is to recognize three-way comparison as a special case. My code was originally written in this ordering: ```c if (x < c) { do_action_a(); } else if (x == c) { d

[Bug other/115506] New: Possible but missed "cmp" instruction merging (x86 & ARM, optimization)

Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- I'm not sure if the GCC developers are interested in this optimization or if this issue has b

[Bug other/115437] Wrong optimized code - GCC didn't detect a variable is modified

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115437 --- Comment #3 from Kang-Che Sung --- Now I come to realize that the C standard doesn't say that a pointer type is "compatible" with any other pointer type. So that "Foo **" type and "Bar **" type are assumed to never alias. This is troubling be

[Bug other/115437] New: Wrong optimized code - GCC didn't detect a variable is modified

ormal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- Note: I cannot tell which component this bug belongs to. Please help me update the "component" field for this bug rep

[Bug target/114490] Optimization: x86 "shl" condition codes never reused

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114490 --- Comment #7 from Kang-Che Sung --- I just come here to say that PR 114512 is the real issue that I wish to see fixed. It might be okay for me when the FLAGS of "shl" becomes unused by GCC, since other than CF (carry) and SF (sign) I don't see

[Bug middle-end/114512] New: Optimization on "test if bit N is set" pattern ((C >> x) & 1)

Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- It should be a common code pattern for "checking if bit N of a value is set" (See these web pa

[Bug target/114490] Optimization: x86 "shl" condition codes never reused

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114490 Kang-Che Sung changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED

[Bug target/114490] Optimization: x86 "shl" condition codes never reused

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114490 --- Comment #4 from Kang-Che Sung --- 1. I just read "AMD64 Architecture Programmer's Manual - Volume 3: General-Purpose and System Instructions" (https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24594.p

[Bug web/114496] New: Documentation: "Non-Bugs" page should update/mention something about -Wsign-conversion

NCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- Section 14.8 of GCC manual "Certain Changes We Don’t Want to Make" (https://gcc.gnu.org/o

[Bug target/114490] Optimization: x86 "shl" condition codes never reused

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114490 --- Comment #3 from Kang-Che Sung --- (In reply to Andrew Pinski from comment #2) > > Basically if you are shifting by 0, then the CF bit never changes from the > previous and this can't be done. > > So the comment in the backend is correct an

[Bug target/114490] New: Optimization: x86 "shl" condition codes never reused

iority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- This seems to happen with x86 target only. For the example code below, I can use the SF (sign flag) after a left shift (<<) operation, but someh

[Bug tree-optimization/89163] Missed optimization: sar and shr equivalent for non-negative numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89163 --- Comment #4 from Kang-Che Sung --- (In reply to Xi Ruoyao from comment #2) > *** Bug 114406 has been marked as a duplicate of this bug. *** I can't say bug 114406 is an exact duplicate of this one. Although my report mainly addresses right sh

[Bug middle-end/114406] New: Optimizations with ">>", div, mod and mul where operands are all positive

Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- GCC missed some optimizations on the right shift (>>), division (/) and modulo (%) operations w

[Bug tree-optimization/114341] Optimization opportunity with {mul,div} "(x & -x)" and {<<,>>} "ctz(x)"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114341 --- Comment #3 from Kang-Che Sung --- I missed one case that is more obvious: (1 << __builtin_ctz(y)) == (y & -y) Multiplication is not needed in this case, and thus (1 << __builtin_ctz(y)) can simplify to (y & -y). (I didn't think of a reason

[Bug rtl-optimization/114338] Optimizing (x & (-1 << y)) to ((x >> y) << y) or vice versa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114338 --- Comment #6 from Kang-Che Sung --- (In reply to Richard Biener from comment #5) > For canonicalization the BIT_AND variants might be preferable since they > possibly combine with other logical ops. Also more constant operands > when the numb

[Bug tree-optimization/114341] New: Optimization opportunity with {mul,div} "(x & -x)" and {<<,>>} "ctz(x)"

atus: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- This is an optimization opportunity that I'm not sure it's worth

[Bug rtl-optimization/114338] (x & (-1 << y)) should be optimized to ((x >> y) << y) or vice versa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114338 --- Comment #3 from Kang-Che Sung --- (In reply to Jakub Jelinek from comment #2) > Bet the point of this PR is to canonicalize in GIMPLE to one of the forms > (both have the same number of GIMPLE statements, so that makes it harder to > pick th

[Bug rtl-optimization/114338] New: (x & (-1 << y)) should be optimized to ((x >> y) << y) or vice versa

Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- ### Test code ```c #include unsigned int func1(unsigned int x, unsigned char count)

[Bug rtl-optimization/114087] New: RISC-V optimization on checking certain bits set ((x & mask) == val)

rmal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- It might be common in the C family of languages to check if certain bits are set in an integer with a code pat

[Bug middle-end/113680] Missed optimization: Redundant cmp/test instructions when comparing (x - y) > 0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113680 --- Comment #3 from Kang-Che Sung --- Oops. I made a typo in the test code. func4() shouldn't have that redundant brace. The corrected example: ``` void func4(int x, int y) { int diff = x - y; if (diff > 0) putchar('>'); if

[Bug middle-end/113680] Missed optimization: Redundant cmp/test instructions when comparing (x - y) > 0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113680 --- Comment #2 from Kang-Che Sung --- I forgot to mention that such optimization is unsafe for floating points (actually I knew that when I write my code). `(a - b) < 0` optimization shouldn't be performed with unsigned integers either. I reques

[Bug rtl-optimization/113680] New: Missed optimization: Redundant cmp/test instructions when comparing (x - y) > 0

MED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- Note: This issue is not limited to x86-64. I also tested it with ARM64 gcc in Compiler Explorer (ht

[Bug tree-optimization/71289] Fails to optimize unsigned mul overflow check 'A > -1 / B'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71289 Kang-Che Sung changed: What|Removed |Added CC||Explorer09 at gmail dot com --- Comment

[Bug sanitizer/62157] New: make distclean error when libsanitizer is configured not to build 'tsan'

Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc d