[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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119893 Bug ID: 119893 Summary: '-Wnonnull' should not warn null pointer use in 'typeof' expression Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal

[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 --- Comment

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119178 Bug ID: 119178 Summary: Optimization: (x != C) comparison can utilize (x - C) or (x ^ C) result Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: norm

[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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118679 Bug ID: 118679 Summary: Missed optimization: inline functions, when operations can be done with smaller bit width Product: gcc Version: 14.2.0 Status: UNCONFIRMED

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118397 Bug ID: 118397 Summary: Missed optimization (x % (C1 * C2) / C2) vs. ((x / C2) % C1) Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal

[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)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117529 Bug ID: 117529 Summary: Missed optimization: (y != 0 && x > (unsigned)(-1) / y) (multiplication overflow check) Product: gcc Version: 14.1.0 Status: UNCONFIRMED

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115687 Bug ID: 115687 Summary: RISC-V optimization when "lui" instructions can be merged Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal P

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115674 Bug ID: 115674 Summary: "Checking if number is within interval" missed optimization when number is from a smaller int type Product: gcc Version: 14.1.0 Status: UNCONFIRM

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115529 Bug ID: 115529 Summary: Optimization with "bit mask and compare equality" ((x & C1) == C2), ((x | C3) == C4) Product: gcc Version: 14.1.0 Status: UNCONFIRMED S

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115525 Bug ID: 115525 Summary: Documentation: "sentinel" attribute should suggest "nullptr" instead of NULL Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity:

[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)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115506 Bug ID: 115506 Summary: Possible but missed "cmp" instruction merging (x86 & ARM, optimization) Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: norm

[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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115437 Bug ID: 115437 Summary: Wrong optimized code - GCC didn't detect a variable is modified Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal

[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)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114512 Bug ID: 114512 Summary: Optimization on "test if bit N is set" pattern ((C >> x) & 1) Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal

[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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114496 Bug ID: 114496 Summary: Documentation: "Non-Bugs" page should update/mention something about -Wsign-conversion Product: gcc Version: 13.2.0 Status: UNCONFIRMED

[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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114490 Bug ID: 114490 Summary: Optimization: x86 "shl" condition codes never reused Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Comp

[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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114406 Bug ID: 114406 Summary: Optimizations with ">>", div, mod and mul where operands are all positive Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: no

[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)"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114341 Bug ID: 114341 Summary: Optimization opportunity with {mul,div} "(x & -x)" and {<<,>>} "ctz(x)" Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: norm

[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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114338 Bug ID: 114338 Summary: (x & (-1 << y)) should be optimized to ((x >> y) << y) or vice versa Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114087 Bug ID: 114087 Summary: RISC-V optimization on checking certain bits set ((x & mask) == val) Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal

[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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113680 Bug ID: 113680 Summary: Missed optimization: Redundant cmp/test instructions when comparing (x - y) > 0 Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severi