[Bug tree-optimization/107541] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug tree-optimization/107541] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541 --- Comment #5 from Aldy Hernandez --- Created attachment 53841 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53841=edit untested

[Bug tree-optimization/107541] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541 --- Comment #4 from Aldy Hernandez --- This is an issue with the TRUNC_DIV_EXPR range-op entry optimizing divisions by powers of 2 into right shifts. We're right shifting the mask by the shift amount. operator_div::fold_range(): ... ...

[Bug tree-optimization/55157] Missed VRP with != 0 and multiply

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157 --- Comment #12 from Aldy Hernandez --- Created attachment 53831 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53831=edit solution improving MULT_EXPR range-ops Another solution is just improving the MULT_EXPR range-op entry. This has

[Bug tree-optimization/55157] Missed VRP with != 0 and multiply

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157 Aldy Hernandez changed: What|Removed |Added Attachment #53826|0 |1 is obsolete|

[Bug tree-optimization/55157] Missed VRP with != 0 and multiply

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157 --- Comment #10 from Aldy Hernandez --- Original TYPE_UNSIGNED patch with leading / trailing suggestions: -2.52% As attached: -3.62% Moving the code out of set_range_from_nonzero_bits back into set_nonzero_bits: -3.7%

[Bug tree-optimization/55157] Missed VRP with != 0 and multiply

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157 --- Comment #9 from Aldy Hernandez --- (In reply to Aldy Hernandez from comment #7) > (In reply to Andrew Macleod from comment #6) > > (In reply to Aldy Hernandez from comment #4) > > 3) It also seems to me that you then only need to add the

[Bug tree-optimization/55157] Missed VRP with != 0 and multiply

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157 --- Comment #8 from Aldy Hernandez --- Created attachment 53826 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53826=edit untested Here's what I tested and we're still around a 3% degradation for VRP.

[Bug tree-optimization/55157] Missed VRP with != 0 and multiply

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157 --- Comment #7 from Aldy Hernandez --- (In reply to Andrew Macleod from comment #6) > (In reply to Aldy Hernandez from comment #4) > > > > > The patch below does this, but it does have a 3% penalty for VRP (though no > > penalty to overall

[Bug tree-optimization/107342] Optimization opportunity where integer '/' corresponds to '>>'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107342 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug tree-optimization/55157] Missed VRP with != 0 and multiply

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157 --- Comment #5 from Aldy Hernandez --- (In reply to Aldy Hernandez from comment #4) > + // Reflect the mask as a simple range. For example, a mask of > + // 0xff00 could be represented as [0,0][0x100, 0x]. > + if (TYPE_UNSIGNED (type

[Bug tree-optimization/55157] Missed VRP with != 0 and multiply

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org,

[Bug tree-optimization/107490] [13 Regression] ICE in build_ge, at range-op-float.cc:283

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107490 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug tree-optimization/107490] [13 Regression] ICE in build_ge, at range-op-float.cc:283

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107490 Aldy Hernandez changed: What|Removed |Added Priority|P3 |P1 CC|

[Bug tree-optimization/107394] [13 Regression] ICE in verify_range, at value-range.cc:716 since r13-3411-gf4fda3eec408e1eb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107394 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug bootstrap/107420] [13 regression] ICE when building trunk with ieee128 after r13-3307-g8efc38347a7444

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107420 --- Comment #1 from Aldy Hernandez --- Can this be reproduced on a cross? Could you provide a preprocessed source?

[Bug tree-optimization/107394] [13 Regression] ICE in verify_range, at value-range.cc:716 since r13-3411-gf4fda3eec408e1eb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107394 Aldy Hernandez changed: What|Removed |Added Priority|P3 |P1

[Bug tree-optimization/107394] [13 Regression] ICE in verify_range, at value-range.cc:716 since r13-3411-gf4fda3eec408e1eb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107394 --- Comment #3 from Aldy Hernandez --- Created attachment 53772 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53772=edit untested

[Bug tree-optimization/107394] [13 Regression] ICE in verify_range, at value-range.cc:716 since r13-3411-gf4fda3eec408e1eb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107394 --- Comment #2 from Aldy Hernandez --- This is interesting. quux() was analyzed and a global range was set that included the possibility of +NAN, but when it was inlined into bar(), the assert making sure no NANs crept in for

[Bug middle-end/107355] [13 Regression] ICE: in lower_bound, at value-range.h:350 with -fsanitize=float-cast-overflow since r13-3231-g706d8583706475fb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107355 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug middle-end/107355] [13 Regression] ICE: in lower_bound, at value-range.h:350 with -fsanitize=float-cast-overflow since r13-3231-g706d8583706475fb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107355 --- Comment #4 from Aldy Hernandez --- fixed

[Bug middle-end/107355] [13 Regression] ICE: in lower_bound, at value-range.h:350 with -fsanitize=float-cast-overflow since r13-3231-g706d8583706475fb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107355 --- Comment #2 from Aldy Hernandez --- Created attachment 53768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53768=edit untested

[Bug tree-optimization/107365] ICE in verify_range, at value-range.cc:726

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107365 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug tree-optimization/107365] ICE in verify_range, at value-range.cc:726

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107365 --- Comment #2 from Aldy Hernandez --- Created attachment 53761 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53761=edit untested

[Bug tree-optimization/107365] ICE in verify_range, at value-range.cc:726

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107365 --- Comment #1 from Aldy Hernandez --- Ok, this is getting ridiculous. I'm tired of these weird finite-math-only combinations in Vax and rx-elf. I think we should just test -ffinite-math-only and -fno-finite-math-only in the self tests for

[Bug tree-optimization/107342] Optimization opportunity where integer '/' corresponds to '>>'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107342 Aldy Hernandez changed: What|Removed |Added Attachment #53749|0 |1 is obsolete|

[Bug tree-optimization/107342] Optimization opportunity where integer '/' corresponds to '>>'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107342 --- Comment #2 from Aldy Hernandez --- Created attachment 53749 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53749=edit untested patch I'm sure somebody smarter could handle other shift amounts that are not powers of 2, but this seems

[Bug tree-optimization/107342] Optimization opportunity where integer '/' corresponds to '>>'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107342 Aldy Hernandez changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED

[Bug tree-optimization/107312] [13 Regression] ICE in verify_range, at value-range.cc:1172, called from range_true_and_false since r13-3193-g8b6bcedc88d54415

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107312 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug tree-optimization/107312] [13 Regression] ICE in verify_range, at value-range.cc:1172, called from range_true_and_false since r13-3193-g8b6bcedc88d54415

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107312 --- Comment #3 from Aldy Hernandez --- Created attachment 53730 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53730=edit patch in testing

[Bug tree-optimization/107312] [13 Regression] ICE in verify_range, at value-range.cc:1172, called from range_true_and_false since r13-3193-g8b6bcedc88d54415

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107312 Aldy Hernandez changed: What|Removed |Added CC||amacleod at redhat dot com ---

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299 --- Comment #7 from Aldy Hernandez --- It looks like the 0.0 with the wrong type is there quite early in the pipeline. At least by einline (after SSA and CFG have been built) we have: (gdb) p debug(gs) c_92 = __builtin_copysignf128 (0.0,

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299 --- Comment #6 from Aldy Hernandez --- Created attachment 53718 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53718=edit preprocessed testcase

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299 --- Comment #4 from Aldy Hernandez --- (In reply to Aldy Hernandez from comment #3) > We are failing while trying to fold: > > c_92 = __builtin_copysignf128 (0.0, c_80(D)); > > The problem is that c_92 is TFtype but 0.0 is _Float128. TFtype

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299 Aldy Hernandez changed: What|Removed |Added Ever confirmed|0 |1 CC|

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299 --- Comment #1 from Aldy Hernandez --- I can't reproduce on gcc135.fsffrance.org with default parameters on a bootstrap. Is there a way to reproduce this on said machine? Or could you provide a .i file that could be used with a cross?

[Bug tree-optimization/107293] Wrong code at -Os on x86_64-linux-gnu since r13-2876-g2460f7cdef7ef9c9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107293 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug tree-optimization/107293] Wrong code at -Os on x86_64-linux-gnu since r13-2876-g2460f7cdef7ef9c9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107293 --- Comment #2 from Aldy Hernandez --- Created attachment 53717 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53717=edit patch in testing

[Bug tree-optimization/107286] gcc/value-range.cc:4027: range_tests_floats: FAIL: ASSERT_TRUE ((real_isinf (_bound (), true)))

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107286 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug tree-optimization/107195] [13 Regression] wrong code with "-O1 -fno-tree-ccp" on x86_64-linux-gnu since r13-3090-gdf4c584c567263fd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107195 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug tree-optimization/107195] [13 Regression] wrong code with "-O1 -fno-tree-ccp" on x86_64-linux-gnu since r13-3090-gdf4c584c567263fd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107195 --- Comment #6 from Aldy Hernandez --- Created attachment 53687 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53687=edit untested patch

[Bug tree-optimization/107195] [13 Regression] wrong code with "-O1 -fno-tree-ccp" on x86_64-linux-gnu since r13-3090-gdf4c584c567263fd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107195 Aldy Hernandez changed: What|Removed |Added CC||amacleod at redhat dot com ---

[Bug tree-optimization/107195] [13 Regression] wrong code with "-O1 -fno-tree-ccp" on x86_64-linux-gnu since r13-3090-gdf4c584c567263fd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107195 --- Comment #4 from Aldy Hernandez --- *** Bug 107194 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/107194] [13 Regression] wrong code at -O1 on x86_64-linux-gnu since r13-3090-gdf4c584c567263fd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107194 Aldy Hernandez changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW

[Bug tree-optimization/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172 --- Comment #3 from Aldy Hernandez --- (In reply to Martin Liška from comment #2) > Started with r13-1268-g8c99e307b20c502e. Disabling DOM with -fno-tree-dominator-opts still causes the crash, so it's not this patch that caused the problem.

[Bug tree-optimization/107170] [13 Regression] ICE on valid code: in as_a, at value-range.h:381

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107170 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug c/107170] ICE on valid code: in as_a, at value-range.h:381

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107170 --- Comment #1 from Aldy Hernandez --- Created attachment 53672 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53672=edit untested patch

[Bug c/107170] ICE on valid code: in as_a, at value-range.h:381

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107170 Aldy Hernandez changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org

[Bug tree-optimization/107052] Range of __builtin_popcount can be improved with nonzerobits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107052 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug tree-optimization/107130] [13 Regression] wrong code with -Os -fno-tree-ccp -fno-tree-forwprop -fno-tree-fre since r13-2900-g001c60ccfeaf9a48

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107130 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug tree-optimization/107130] [13 Regression] wrong code with -Os -fno-tree-ccp -fno-tree-forwprop -fno-tree-fre since r13-2900-g001c60ccfeaf9a48

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107130 --- Comment #5 from Aldy Hernandez --- Created attachment 53656 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53656=edit untested patch

[Bug tree-optimization/107130] [13 Regression] wrong code with -Os -fno-tree-ccp -fno-tree-forwprop -fno-tree-fre since r13-2900-g001c60ccfeaf9a48

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107130 Aldy Hernandez changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org ---

[Bug tree-optimization/107053] ones bits is not tracked and popcount is not tracked

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107053 Aldy Hernandez changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug tree-optimization/107052] Range of __builtin_popcount can be improved with nonzerobits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107052 --- Comment #5 from Aldy Hernandez --- Created attachment 53633 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53633=edit patch in testing This might do it.

[Bug tree-optimization/107052] Range of __builtin_popcount can be improved with nonzerobits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107052 --- Comment #4 from Aldy Hernandez --- (In reply to Andrew Pinski from comment #3) > (In reply to Aldy Hernandez from comment #2) > > Don't you mean the only values for popcount are 0-2? I mean, there are only > > two bits that could be 1 with

[Bug tree-optimization/107052] Range of __builtin_popcount can be improved with nonzerobits

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107052 Aldy Hernandez changed: What|Removed |Added Last reconfirmed||2022-09-27 CC|

[Bug tree-optimization/107053] ones bits is not tracked and popcount is not tracked

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107053 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

[Bug tree-optimization/107043] range information not used in popcount

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107043 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment

[Bug testsuite/107046] [13 Regression] Recent FP range work causing inf-2 to be miscompiled on rx-elf

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107046 --- Comment #4 from Aldy Hernandez --- (In reply to Richard Biener from comment #3) > Ah, probably the > > void test(double f, double i) > { > ... > if (i != __builtin_inf()) > abort (); > > int main() > { > test (34.0,

[Bug tree-optimization/107046] [13 Regression] Recent FP range work causing inf-2 to be miscompiled on rx-elf

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107046 --- Comment #1 from Aldy Hernandez --- The target seems to set flag_finite_math_only. We are much more aggressive at folding comparisons involving infinities with this flag. config/rx/rx.cc: /* Alert the user if they are changing the

[Bug tree-optimization/107009] [13 Regression] massive unnecessary code blowup in vectorizer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug tree-optimization/107009] [13 Regression] massive unnecessary code blowup in vectorizer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009 --- Comment #7 from Aldy Hernandez --- Created attachment 53622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53622=edit DOM patch in testing to calculate ranges for all ranges involving unreachable edges

[Bug tree-optimization/107009] [13 Regression] massive unnecessary code blowup in vectorizer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009 --- Comment #6 from Aldy Hernandez --- Created attachment 53621 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53621=edit bitwise and op1_range patch in testing

[Bug tree-optimization/107009] [13 Regression] massive unnecessary code blowup in vectorizer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009 --- Comment #5 from Aldy Hernandez --- There are two things needed to fix this regression. First, we need an op1_range entry for bitwise-and, so that the 2->4 edge range has the correct nonzero bits for n_12. [local count: 118111600]:

[Bug tree-optimization/107009] [13 Regression] massive unnecessary code blowup in vectorizer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009 --- Comment #4 from Aldy Hernandez --- (In reply to Richard Biener from comment #3) > # RANGE [irange] size_t [1, +INF] > size_t n_12(D) = n; > > the nonzero bits info on 'n' is gone. DOM2 used to produce that and > CCP3 elides the

[Bug tree-optimization/107009] [13 Regression] massive unnecessary code blowup in vectorizer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009 --- Comment #2 from Aldy Hernandez --- (In reply to Marek Polacek from comment #1) > Looks like it was caused by r13-1268-g8c99e307b20c50: > > commit 8c99e307b20c502e55c425897fb3884ba8f05882 > Author: Aldy Hernandez > Date: Sat Jun 25

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967 --- Comment #12 from Aldy Hernandez --- (In reply to Richard Biener from comment #11) > Btw, > > static inline bool > finite_operands_p (const frange , const frange ) > { > return flag_finite_math_only || (!op1.maybe_isnan () &&

[Bug tree-optimization/106970] [13 Regression] ICE in verify_range, at value-range.cc:702 since r13-2713-g917461478d3bb733

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106970 --- Comment #8 from Aldy Hernandez --- abulafia:~/bld/t/gcc$ cat a.c int script_obj_as_number_obj, script_obj_as_number_obj_0_0; double script_obj_as_number() { if (script_obj_as_number_obj) return script_obj_as_number_obj_0_0; return

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967 --- Comment #10 from Aldy Hernandez --- *** Bug 106970 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/106970] [13 Regression] ICE in verify_range, at value-range.cc:702 since r13-2713-g917461478d3bb733

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106970 Aldy Hernandez changed: What|Removed |Added Resolution|WORKSFORME |DUPLICATE --- Comment #6 from Aldy

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967 --- Comment #9 from Aldy Hernandez --- Created attachment 53596 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53596=edit another patch in testing This one may be needed as well.

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967 --- Comment #8 from Aldy Hernandez --- Created attachment 53595 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53595=edit patch in testing This was painful. I had audit all the relational code to make sure we're handling NANs before

[Bug tree-optimization/106970] [13 Regression] ICE in verify_range, at value-range.cc:702 since r13-2713-g917461478d3bb733

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106970 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967 --- Comment #6 from Aldy Hernandez --- > > finite_operands_p() must be adjusted for the case where there is a NAN in > the source...but still.. is PRE supposed to be adding NANs? What i meant to say here was the users of finite operands p

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967 --- Comment #5 from Aldy Hernandez --- Does that mean we can assume the incoming edge from BB9 as unreachable?

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967 Aldy Hernandez changed: What|Removed |Added CC||rguenth at gcc dot gnu.org ---

[Bug tree-optimization/106970] [13 Regression] ICE in verify_range, at value-range.cc:702 since r13-2713-g917461478d3bb733

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106970 --- Comment #2 from Aldy Hernandez --- Works on mainline. I can add a testcase though.

[Bug tree-optimization/68097] We should track ranges for floating-point values too

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 --- Comment #8 from Aldy Hernandez --- (In reply to Richard Biener from comment #7) > Yes, I think fixed in that we can now record info on FP SSA names. There > are other bugs for specific things. > > What's not fixed is that we still recurse

[Bug c++/106654] [C++23] P1774 - Portable assumptions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654 --- Comment #11 from Aldy Hernandez --- (In reply to Jason Merrill from comment #10) > > But wait a minute, is calling a non-const function from [[assume]] even > > allowed? > > Yep, that's the tricky part. Of course, as functions get more

[Bug c++/106654] [C++23] P1774 - Portable assumptions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654 --- Comment #9 from Aldy Hernandez --- (In reply to Jason Merrill from comment #8) > (In reply to Aldy Hernandez from comment #7) > > Silly question, why can't you expand the [[assume]] construct into: > > > > if (x > 5) > >

[Bug tree-optimization/68097] We should track ranges for floating-point values too

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment

[Bug c++/106654] [C++23] P1774 - Portable assumptions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654 --- Comment #7 from Aldy Hernandez --- You could provide an API to access the different relations that hold in either the outline function, or the .IFN_ASSUME construct. Then ranger could use that API to access and record the different

[Bug tree-optimization/106936] [13 Regression] ICE in get_value_range, at value-query.cc:170 since r13-1815-g8b8103dcd2624936

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106936 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug tree-optimization/106936] [13 Regression] ICE in get_value_range, at value-query.cc:170 since r13-1815-g8b8103dcd2624936

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106936 --- Comment #2 from Aldy Hernandez --- This assert was put here to make sure that the legacy get_value_range() wasn't being called on stuff that legacy couldn't handle (floats, etc), because the result would ultimately be copied into a

[Bug tree-optimization/106867] [13 Regression] ICE in set, at value-range.cc:372

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106867 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug middle-end/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug middle-end/106824] [13 Regression] ICE in set_nan, at value-range.cc:283 since r13-2266-g8bb1df032cc080b7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED

[Bug middle-end/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831 --- Comment #8 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #7) > I guess disabling them at least for now could be fine. > If somebody involved with dfp wants to extend it for dfp, it can be done > incrementally. > > BTW,

[Bug middle-end/106824] [13 Regression] ICE in set_nan, at value-range.cc:283 since r13-2266-g8bb1df032cc080b7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824 --- Comment #11 from Aldy Hernandez --- Created attachment 53539 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53539=edit untested patch

[Bug target/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831 --- Comment #6 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #5) > BTW, I admit I don't know much about decimal{32,64,128}, but > https://en.wikipedia.org/wiki/Decimal32_floating-point_format > says: > Because the significand

[Bug c++/106824] [13 Regression] ICE in set_nan, at value-range.cc:283 since r13-2266-g8bb1df032cc080b7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824 Aldy Hernandez changed: What|Removed |Added CC||amacleod at redhat dot com

[Bug target/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831 Aldy Hernandez changed: What|Removed |Added Last reconfirmed||2022-09-05

[Bug target/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831 --- Comment #2 from Aldy Hernandez --- And yes, I've started testing mpfr now for my frange patches.

[Bug target/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/106824] ice in set_nan, at value-range.cc:283

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/106824] ice in set_nan, at value-range.cc:283

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824 --- Comment #4 from Aldy Hernandez --- Yeah, that's all me. I can't reproduce on x86-64, but there's been a couple patches in this area over the weekend. Could you double check again on an updated trunk?

[Bug other/106814] [13 regression] r13-2266-g8bb1df032cc080 breaks some mpfr tests

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106814 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED

[Bug middle-end/106819] [13 Regression] NaN != NaN comparisons return false at -O2 since r13-2338

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106819 --- Comment #11 from Aldy Hernandez --- I'll just fix union and implement copysign folding and leave it at that.

[Bug middle-end/106819] [13 Regression] NaN != NaN comparisons return false at -O2 since r13-2338

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106819 --- Comment #10 from Aldy Hernandez --- Got it. Less work for me :-). Thanks for the explanation.

<    1   2   3   4   5   6   7   8   >