https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #21 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:de67f943b858099b40f73632a51e66147ec79c9b
commit r12-7012-gde67f943b858099b40f73632a51e66147ec79c9b
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #20 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #19)
> Created attachment 52329 [details]
> gcc12-pr104334.patch
>
> Patch doing ?h_range and related comparisons in widest_int.
Looks like a good app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #19 from Jakub Jelinek ---
Created attachment 52329
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52329&action=edit
gcc12-pr104334.patch
Patch doing ?h_range and related comparisons in widest_int.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #18 from Jakub Jelinek ---
I think to_widest only works with INTEGER_CSTs, to do the comparisons (or have
?h_range be widest_int), we'd need to use widest_int::from I think.
Anyway, with the above patch I've built so far stage2 cc1p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #17 from rguenther at suse dot de ---
On Wed, 2 Feb 2022, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
>
> Jakub Jelinek changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #16 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #13)
> So, I think one way is to punt on these small precision types, like:
> --- range-op.cc.jj1 2022-01-13 22:29:15.345831749 +0100
> +++ range-op.cc 2022-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #14 from Martin Liška ---
I can just confirm that using tree-vrp.o from stage1 fixes the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #13 from Jakub Jelinek ---
So, I think one way is to punt on these small precision types, like:
--- range-op.cc.jj1 2022-01-13 22:29:15.345831749 +0100
+++ range-op.cc 2022-02-02 13:44:05.813637820 +0100
@@ -148,11 +148,13 @@ ran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
Martin Liška changed:
What|Removed |Added
Summary|[12 Regression] Ranger/dom |[12 Regression] Ranger/dom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #11 from Jakub Jelinek ---
> And another question is, the 2, 3, 4 cases handling seems like an
> optimization, > so wi_fold at line 192 should give the right answer, but it
> doesn't.
Actually no, I misunderstood, with -O0 or non-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #10 from rguenther at suse dot de ---
On Wed, 2 Feb 2022, rsandifo at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
>
> --- Comment #9 from rsandifo at gcc dot gnu.org
> ---
> (In reply to Jakub Jel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #9 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #7)
> The difference might be in:
> 1938/* Optimize comparisons with constants. */
> 1939if (STATIC_CONSTANT_P (yi.len == 1 && yi.val[0] >= 0))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #8 from Jakub Jelinek ---
Now verified, in the LTO case both wi::gt_p/wi::gtu_p and wi::lt_p/wi::ltu_p
are inlined and do:
0x0191600e
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
Jakub Jelinek changed:
What|Removed |Added
CC||mrs at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #6 from Jakub Jelinek ---
So, in the debugger the difference is in the range_operator::wi_fold_in_parts
function (with:
enum class A { A0, A1, A2, A3 };
int x;
void baz ();
struct B {
unsigned b : 2;
A
foo () const
{
r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #5 from Andrew Pinski ---
If there is a way to test adding -fno-ipa-modref to the bootstrap. That or
-fno-tree-vectorize. I suspect it is one of those two since those were the
areas that changed the most for the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
Martin Liška changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #4 from Mart
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Last reconfi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
Andrew Pinski changed:
What|Removed |Added
Keywords||lto, wrong-code
Severity|norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #1 from Jakub Jelinek ---
Also tried
../configure --enable-bootstrap --enable-languages=c,c++
--enable-checking=release --disable-multilib --with-tune=generic
build, but there it doesn't reproduce in either of stage1 or stage2 (stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
Jakub Jelinek changed:
What|Removed |Added
Summary|Ranger/dom miscompilation |[12 Regression] Ranger/dom
23 matches
Mail list logo
