public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/104334] New: Ranger/dom miscompilation
@ 2022-02-01 20:35 jakub at gcc dot gnu.org
2022-02-01 20:35 ` [Bug tree-optimization/104334] [12 Regression] " jakub at gcc dot gnu.org
` (22 more replies)
0 siblings, 23 replies; 24+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-01 20:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
Bug ID: 104334
Summary: Ranger/dom miscompilation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
enum class A { A0, A1, A2, A3 };
int x;
__attribute__((noipa)) void
baz ()
{
x = 1;
}
struct B {
unsigned b : 2;
A
foo () const
{
return static_cast<A> (b);
}
__attribute__((noinline)) void
bar ()
{
if (foo () == A::A2 || foo () == A::A3)
baz ();
}
};
int
main ()
{
B c;
c.b = 2;
c.bar ();
if (x != 1)
__builtin_abort ();
return 0;
}
is miscompiled on x86_64-linux with -O2 --param logical-op-non-short-circuit=0
and on powerpc64le-linux and s390x-linux with just -O2.
Strangely, I can't reproduce it with cross-compilers or -O0 built cc1plus or
even cc1plus bootstrapped my usual way:
../configure --enable-languages=default,ada,obj-c++,lto,go,d
--enable-checking=yes,rtl,extra --enable-libstdcxx-backtrace=yes
but can reproduce it in:
./configure --enable-bootstrap --enable-languages=c,c++
--enable-checking=release --disable-multilib --with-tune=generic
--with-build-config=bootstrap-lto --enable-link-serialization=1
(but there only in second and third stages, stage1-gcc still doesn't miscompile
it).
thread2 dump is still identical between non-miscompiled and miscompiled cases,
we have there:
<unnamed-unsigned:2> _5;
<unnamed-unsigned:2> _7;
<bb 2> [local count: 1073741823]:
_5 = MEM[(const struct B *)this_3(D)].b;
_7 = _5 + 2;
if (_7 <= 1)
(frankly weird to do the addition and comparison in unsigned:2 type, but it is
what reassoc comes up with. Furthermore, for unsigned:2 type, test for value
in [2,3] range can be done with just
_5 >= 2 and doesn't need to do the addition).
The difference is in dom3 dump (-fdump-tree-all-alias-details):
@@ -66,11 +66,11 @@ LKUP STMT _5 = MEM[(const struct B *)thi
extract_range_from_stmt visiting:
_7 = _5 + 2;
Intersecting
- <unnamed-unsigned:2> VARYING
+ <unnamed-unsigned:2> [1, +INF]
and
<unnamed-unsigned:2> VARYING
to
- <unnamed-unsigned:2> VARYING
+ <unnamed-unsigned:2> [1, +INF]
Optimizing statement _7 = _5 + 2;
LKUP STMT _7 = _5 plus_expr 2
2>>> STMT _7 = _5 plus_expr 2
@@ -79,7 +79,7 @@ Optimizing statement if (_7 <= 1)
Visiting conditional with predicate: if (_7 <= 1)
With known ranges
- _7: <unnamed-unsigned:2> VARYING
+ _7: <unnamed-unsigned:2> [1, +INF]
Predicate evaluates to: DON'T KNOW
LKUP STMT _7 le_expr 1
@@ -94,9 +94,9 @@ Adding assert for _5 from _5 + 2 <= 1
Intersecting
<unnamed-unsigned:2> [0, 1] EQUIVALENCES: { _7 } (1 elements)
and
- <unnamed-unsigned:2> VARYING
+ <unnamed-unsigned:2> [1, +INF]
to
- <unnamed-unsigned:2> [0, 1] EQUIVALENCES: { _7 } (1 elements)
+ <unnamed-unsigned:2> [1, 1] EQUIVALENCES: { _7 } (1 elements)
Intersecting
<unnamed-unsigned:2> [2, +INF] EQUIVALENCES: { _5 } (1 elements)
and
@@ -104,12 +104,12 @@ and
to
<unnamed-unsigned:2> [2, +INF] EQUIVALENCES: { _5 } (1 elements)
Intersecting
- <unnamed-unsigned:2> VARYING
+ <unnamed-unsigned:2> [1, +INF]
and
- <unnamed-unsigned:2> [0, 1]
+ <unnamed-unsigned:2> [1, 1]
to
- <unnamed-unsigned:2> [0, 1]
-pushing new range for _7: <unnamed-unsigned:2> [0, 1] EQUIVALENCES: { _7 } (1
elements)
+ <unnamed-unsigned:2> [1, 1]
+pushing new range for _7: <unnamed-unsigned:2> [1, 1] EQUIVALENCES: { _7 } (1
elements)
Intersecting
<unnamed-unsigned:2> VARYING
and
@@ -123,7 +123,7 @@ Optimizing statement baz ();
<<<< STMT 0 = _7 gt_expr 1
<<<< STMT 1 = _7 le_expr 1
popping range for _5, restoring <unnamed-unsigned:2> VARYING
-popping range for _7, restoring <unnamed-unsigned:2> VARYING
+popping range for _7, restoring <unnamed-unsigned:2> [1, +INF]
Optimizing block #4
@@ -144,6 +144,7 @@ void B::bar (struct B * const this)
<bb 2> [local count: 1073741823]:
_5 = MEM[(const struct B *)this_3(D)].b;
+ # RANGE [1, 3]
_7 = _5 + 2;
if (_7 <= 1)
goto <bb 3>; [20.24%]
and the bogus # RANGE in the last hunk is what is the problem, both _5 and _7
have actually VARYING range (aka [0, 3]).
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
@ 2022-02-01 20:35 ` jakub at gcc dot gnu.org
2022-02-01 20:48 ` jakub at gcc dot gnu.org
` (21 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-01 20:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Ranger/dom miscompilation |[12 Regression] Ranger/dom
| |miscompilation
Priority|P3 |P1
Target Milestone|--- |12.0
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
2022-02-01 20:35 ` [Bug tree-optimization/104334] [12 Regression] " jakub at gcc dot gnu.org
@ 2022-02-01 20:48 ` jakub at gcc dot gnu.org
2022-02-02 1:27 ` pinskia at gcc dot gnu.org
` (20 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-01 20:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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 (stage3
still building).
So most probably LTO bootstrap is the trigger :(.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
2022-02-01 20:35 ` [Bug tree-optimization/104334] [12 Regression] " jakub at gcc dot gnu.org
2022-02-01 20:48 ` jakub at gcc dot gnu.org
@ 2022-02-02 1:27 ` pinskia at gcc dot gnu.org
2022-02-02 10:18 ` marxin at gcc dot gnu.org
` (19 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-02-02 1:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |lto, wrong-code
Severity|normal |blocker
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>So most probably LTO bootstrap is the trigger :(.
Maybe you could throw some "#pragma GCC optimize" in some files to figure out
which file has the function that is being miscompiled. Maybe then narrow it
down using the optimize attribute?
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (2 preceding siblings ...)
2022-02-02 1:27 ` pinskia at gcc dot gnu.org
@ 2022-02-02 10:18 ` marxin at gcc dot gnu.org
2022-02-02 10:19 ` marxin at gcc dot gnu.org
` (18 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-02-02 10:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |marxin at gcc dot gnu.org
Last reconfirmed| |2022-02-02
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
I can confirm the same behavior: the non-bootstrapped compiler is fine and
openSUSE gcc12 package built with lto/PGO reproduces that.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (3 preceding siblings ...)
2022-02-02 10:18 ` marxin at gcc dot gnu.org
@ 2022-02-02 10:19 ` marxin at gcc dot gnu.org
2022-02-02 10:29 ` pinskia at gcc dot gnu.org
` (17 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-02-02 10:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |needs-bisection
--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
I can try bisecting that. Do we speak about a possible miscompilation?
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (4 preceding siblings ...)
2022-02-02 10:19 ` marxin at gcc dot gnu.org
@ 2022-02-02 10:29 ` pinskia at gcc dot gnu.org
2022-02-02 10:37 ` jakub at gcc dot gnu.org
` (16 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-02-02 10:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (5 preceding siblings ...)
2022-02-02 10:29 ` pinskia at gcc dot gnu.org
@ 2022-02-02 10:37 ` jakub at gcc dot gnu.org
2022-02-02 12:06 ` jakub at gcc dot gnu.org
` (15 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-02 10:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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
{
return static_cast<A> (b);
}
void bar ();
};
void
B::bar ()
{
if (foo () == A::A2 || foo () == A::A3)
baz ();
}
the first one).
type is unsigned:2, lh_lb 0, lh_ub -1 (aka 3), rh_lb and rh_ub -2 (aka 2).
lh_range is -1 (aka 3), rh_range is 0, ov_{l,r}h is OVF_NONE.
In the non-LTO case, we do wi_fold on line 176
171 // Otherise check for 2, 3, or 4 values in the LH range and split
them up.
172 // The RH side has been checked, so no recursion needed.
173 else if (wi::gt_p (lh_range, 0, sign) && wi::lt_p (lh_range, 4, sign)
174 && ov_lh == wi::OVF_NONE)
175 {
176 wi_fold (r, type, lh_lb, lh_lb, rh_lb, rh_ub);
while in the LTO case on line 192.
The wi::lt_p (rh_range, 4, sign) and wi::lt_p (lh_range, 4, sign) calls
look highly suspicious, 4 is not representable in unsigned:2.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (6 preceding siblings ...)
2022-02-02 10:37 ` jakub at gcc dot gnu.org
@ 2022-02-02 12:06 ` jakub at gcc dot gnu.org
2022-02-02 12:13 ` jakub at gcc dot gnu.org
` (14 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-02 12:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mrs at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org,
| |rsandifo at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The difference might be in:
1938 /* Optimize comparisons with constants. */
1939 if (STATIC_CONSTANT_P (yi.len == 1 && yi.val[0] >= 0))
1940 return xi.len == 1 && xi.to_uhwi () < (unsigned HOST_WIDE_INT)
yi.val[0];
1941 if (STATIC_CONSTANT_P (xi.len == 1 && xi.val[0] >= 0))
1942 return yi.len != 1 || yi.to_uhwi () > (unsigned HOST_WIDE_INT)
xi.val[0];
1943 /* Optimize the case of two HWIs. The HWIs are implicitly
sign-extended
1944 for precisions greater than HOST_BITS_WIDE_INT, but sign-extending
both
1945 values does not change the result. */
1946 if (__builtin_expect (xi.len + yi.len == 2, true))
1947 {
1948 unsigned HOST_WIDE_INT xl = xi.to_uhwi ();
1949 unsigned HOST_WIDE_INT yl = yi.to_uhwi ();
1950 return xl < yl;
1951 }
Perhaps with LTO STATIC_CONSTANT_P (yi.len && iy.val[0] >= 0) is true while
without LTO it is false.
I'll verify that. Though, xi.len == 1, xi.to_uhwi () is 3, yi.val[0] is 4 and
yi.to_uhwi () is 0.
So I think if STATIC_CONSTANT_P is true, it will return 3 < 4, while if it is
false, it will return 3 < 0.
Now, the question is, do we consider those wi::lt_p (x, 4, sign) calls invalid
if 4 is not representable in type,
or does the STATIC_CONSTANT_P case need to also check precision, or mask
Xi.val[0]?
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (7 preceding siblings ...)
2022-02-02 12:06 ` jakub at gcc dot gnu.org
@ 2022-02-02 12:13 ` jakub at gcc dot gnu.org
2022-02-02 12:26 ` rsandifo at gcc dot gnu.org
` (13 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-02 12:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Now verified, in the LTO case both wi::gt_p/wi::gtu_p and wi::lt_p/wi::ltu_p
are inlined and do:
0x000000000191600e
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_+750>:
test %rdx,%rdx
0x0000000001916011
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_+753>:
je 0x1915edc
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_+444>
0x0000000001916017
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_+759>:
cmp $0x3,%rdx
0x000000000191601b
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_+763>:
ja 0x1915edc <_ZNK14range_operator
so that looks like lh_range.val[0] != 0 && lh_range.val[0] <= 3U, so I'm pretty
sure that is the STATIC_CONSTANT_P case.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (8 preceding siblings ...)
2022-02-02 12:13 ` jakub at gcc dot gnu.org
@ 2022-02-02 12:26 ` rsandifo at gcc dot gnu.org
2022-02-02 12:30 ` rguenther at suse dot de
` (12 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2022-02-02 12:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #9 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> The difference might be in:
> 1938 /* Optimize comparisons with constants. */
> 1939 if (STATIC_CONSTANT_P (yi.len == 1 && yi.val[0] >= 0))
> 1940 return xi.len == 1 && xi.to_uhwi () < (unsigned HOST_WIDE_INT)
> yi.val[0];
> 1941 if (STATIC_CONSTANT_P (xi.len == 1 && xi.val[0] >= 0))
> 1942 return yi.len != 1 || yi.to_uhwi () > (unsigned HOST_WIDE_INT)
> xi.val[0];
> 1943 /* Optimize the case of two HWIs. The HWIs are implicitly
> sign-extended
> 1944 for precisions greater than HOST_BITS_WIDE_INT, but sign-extending
> both
> 1945 values does not change the result. */
> 1946 if (__builtin_expect (xi.len + yi.len == 2, true))
> 1947 {
> 1948 unsigned HOST_WIDE_INT xl = xi.to_uhwi ();
> 1949 unsigned HOST_WIDE_INT yl = yi.to_uhwi ();
> 1950 return xl < yl;
> 1951 }
> Perhaps with LTO STATIC_CONSTANT_P (yi.len && iy.val[0] >= 0) is true while
> without LTO it is false.
> I'll verify that. Though, xi.len == 1, xi.to_uhwi () is 3, yi.val[0] is 4
> and yi.to_uhwi () is 0.
> So I think if STATIC_CONSTANT_P is true, it will return 3 < 4, while if it
> is false, it will return 3 < 0.
>
> Now, the question is, do we consider those wi::lt_p (x, 4, sign) calls
> invalid if 4 is not representable in type,
> or does the STATIC_CONSTANT_P case need to also check precision, or mask
> Xi.val[0]?
At the moment I think they're invalid. If we want to change that,
and have the value be implicitly truncated, we should probably do
it by setting primitive_int_traits::is_sign_extended to false.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (9 preceding siblings ...)
2022-02-02 12:26 ` rsandifo at gcc dot gnu.org
@ 2022-02-02 12:30 ` rguenther at suse dot de
2022-02-02 12:31 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: rguenther at suse dot de @ 2022-02-02 12:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #10 from rguenther at suse dot de <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 <rsandifo at gcc dot gnu.org> ---
> (In reply to Jakub Jelinek from comment #7)
> > The difference might be in:
> > 1938 /* Optimize comparisons with constants. */
> > 1939 if (STATIC_CONSTANT_P (yi.len == 1 && yi.val[0] >= 0))
> > 1940 return xi.len == 1 && xi.to_uhwi () < (unsigned HOST_WIDE_INT)
> > yi.val[0];
> > 1941 if (STATIC_CONSTANT_P (xi.len == 1 && xi.val[0] >= 0))
> > 1942 return yi.len != 1 || yi.to_uhwi () > (unsigned HOST_WIDE_INT)
> > xi.val[0];
> > 1943 /* Optimize the case of two HWIs. The HWIs are implicitly
> > sign-extended
> > 1944 for precisions greater than HOST_BITS_WIDE_INT, but sign-extending
> > both
> > 1945 values does not change the result. */
> > 1946 if (__builtin_expect (xi.len + yi.len == 2, true))
> > 1947 {
> > 1948 unsigned HOST_WIDE_INT xl = xi.to_uhwi ();
> > 1949 unsigned HOST_WIDE_INT yl = yi.to_uhwi ();
> > 1950 return xl < yl;
> > 1951 }
> > Perhaps with LTO STATIC_CONSTANT_P (yi.len && iy.val[0] >= 0) is true while
> > without LTO it is false.
> > I'll verify that. Though, xi.len == 1, xi.to_uhwi () is 3, yi.val[0] is 4
> > and yi.to_uhwi () is 0.
> > So I think if STATIC_CONSTANT_P is true, it will return 3 < 4, while if it
> > is false, it will return 3 < 0.
> >
> > Now, the question is, do we consider those wi::lt_p (x, 4, sign) calls
> > invalid if 4 is not representable in type,
> > or does the STATIC_CONSTANT_P case need to also check precision, or mask
> > Xi.val[0]?
> At the moment I think they're invalid. If we want to change that,
> and have the value be implicitly truncated, we should probably do
> it by setting primitive_int_traits::is_sign_extended to false.
I also think they are invalid. I guess primitive_int_traits
always produce "widest_ints", but I don't know whether we can
reasonably reject the wi:lt_p (x, 4, sign) calls in favor of
requiring wi::lt_p (wi::to_widest (x), 4, sign) at compile-time ...
I don't think we want to silenlty truncate the literal '4', instead
if we really want, we could ICE with checking enabled ...
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (10 preceding siblings ...)
2022-02-02 12:30 ` rguenther at suse dot de
@ 2022-02-02 12:31 ` jakub at gcc dot gnu.org
2022-02-02 12:38 ` [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e marxin at gcc dot gnu.org
` (10 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-02 12:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> 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-LTO, it is the wi_fold call,
while with LTO it is the
178 wi_fold (r, type, lh_lb, lh_lb, rh_lb, rh_ub);
179 if (wi::gt_p (lh_range, 1, sign))
180 {
181 wi_fold (tmp, type, lh_lb + 1, lh_lb + 1, rh_lb, rh_ub);
182 r.union_ (tmp);
183 if (wi::eq_p (lh_range, 3))
184 {
(gdb)
185 wi_fold (tmp, type, lh_lb + 2, lh_lb + 2, rh_lb, rh_ub);
186 r.union_ (tmp);
187 }
188 }
189 wi_fold (tmp, type, lh_ub, lh_ub, rh_lb, rh_ub);
190 r.union_ (tmp);
optimization. And that one doesn't work too well, because
wi::eq_p (lh_range, 3) is false:
xi.is_sign_extended is true, yi.is_sign_extended is true
lh_range.val[0] is -1, and yi.val[0] is 3, so it isn't equal.
That is because we haven't sign-extended 3.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (11 preceding siblings ...)
2022-02-02 12:31 ` jakub at gcc dot gnu.org
@ 2022-02-02 12:38 ` marxin at gcc dot gnu.org
2022-02-02 12:46 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-02-02 12:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[12 Regression] Ranger/dom |[12 Regression] Ranger/dom
|miscompilation |miscompilation since
| |r12-4694-gcb153222404e2e
--- Comment #12 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r12-4694-gcb153222404e2e.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (12 preceding siblings ...)
2022-02-02 12:38 ` [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e marxin at gcc dot gnu.org
@ 2022-02-02 12:46 ` jakub at gcc dot gnu.org
2022-02-02 12:51 ` marxin at gcc dot gnu.org
` (8 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-02 12:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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 @@ range_operator::wi_fold_in_parts (irange
int_range_max tmp;
wide_int rh_range = wi::sub (rh_ub, rh_lb, TYPE_SIGN (type), &ov_rh);
wide_int lh_range = wi::sub (lh_ub, lh_lb, TYPE_SIGN (type), &ov_lh);
- signop sign = TYPE_SIGN (type);;
+ signop sign = TYPE_SIGN (type);
// If there are 2, 3, or 4 values in the RH range, do them separately.
// Call wi_fold_in_parts to check the RH side.
- if (wi::gt_p (rh_range, 0, sign) && wi::lt_p (rh_range, 4, sign)
- && ov_rh == wi::OVF_NONE)
+ if (wi::min_precision (4, sign) <= wi::get_precision (rh_range)
+ && ov_rh == wi::OVF_NONE
+ && wi::gt_p (rh_range, 0, sign)
+ && wi::lt_p (rh_range, 4, sign))
{
wi_fold_in_parts (r, type, lh_lb, lh_ub, rh_lb, rh_lb);
if (wi::gt_p (rh_range, 1, sign))
@@ -170,8 +172,10 @@ range_operator::wi_fold_in_parts (irange
}
// Otherise check for 2, 3, or 4 values in the LH range and split them up.
// The RH side has been checked, so no recursion needed.
- else if (wi::gt_p (lh_range, 0, sign) && wi::lt_p (lh_range, 4, sign)
- && ov_lh == wi::OVF_NONE)
+ else if (wi::min_precision (4, sign) <= wi::get_precision (lh_range)
+ && ov_lh == wi::OVF_NONE
+ && wi::gt_p (lh_range, 0, sign)
+ && wi::lt_p (lh_range, 4, sign))
{
wi_fold (r, type, lh_lb, lh_lb, rh_lb, rh_ub);
if (wi::gt_p (lh_range, 1, sign))
i.e. only optimize if 4 is representable in the given wide_int.
The other option is to be extra careful.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (13 preceding siblings ...)
2022-02-02 12:46 ` jakub at gcc dot gnu.org
@ 2022-02-02 12:51 ` marxin at gcc dot gnu.org
2022-02-02 13:39 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-02-02 12:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #14 from Martin Liška <marxin at gcc dot gnu.org> ---
I can just confirm that using tree-vrp.o from stage1 fixes the issue.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (14 preceding siblings ...)
2022-02-02 12:51 ` marxin at gcc dot gnu.org
@ 2022-02-02 13:39 ` jakub at gcc dot gnu.org
2022-02-02 13:50 ` amacleod at redhat dot com
` (6 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-02 13:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52328
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52328&action=edit
gcc12-pr104334.patch
Better untested fix.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (15 preceding siblings ...)
2022-02-02 13:39 ` jakub at gcc dot gnu.org
@ 2022-02-02 13:50 ` amacleod at redhat dot com
2022-02-02 13:56 ` rguenther at suse dot de
` (5 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: amacleod at redhat dot com @ 2022-02-02 13:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #16 from Andrew Macleod <amacleod at redhat dot com> ---
(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-02-02 13:44:05.813637820 +0100
> @@ -148,11 +148,13 @@ range_operator::wi_fold_in_parts (irange
> int_range_max tmp;
> wide_int rh_range = wi::sub (rh_ub, rh_lb, TYPE_SIGN (type), &ov_rh);
> wide_int lh_range = wi::sub (lh_ub, lh_lb, TYPE_SIGN (type), &ov_lh);
> - signop sign = TYPE_SIGN (type);;
> + signop sign = TYPE_SIGN (type);
> // If there are 2, 3, or 4 values in the RH range, do them separately.
> // Call wi_fold_in_parts to check the RH side.
> - if (wi::gt_p (rh_range, 0, sign) && wi::lt_p (rh_range, 4, sign)
> - && ov_rh == wi::OVF_NONE)
> + if (wi::min_precision (4, sign) <= wi::get_precision (rh_range)
> + && ov_rh == wi::OVF_NONE
> + && wi::gt_p (rh_range, 0, sign)
> + && wi::lt_p (rh_range, 4, sign))
> {
> wi_fold_in_parts (r, type, lh_lb, lh_ub, rh_lb, rh_lb);
> if (wi::gt_p (rh_range, 1, sign))
> @@ -170,8 +172,10 @@ range_operator::wi_fold_in_parts (irange
> }
> // Otherise check for 2, 3, or 4 values in the LH range and split them up.
> // The RH side has been checked, so no recursion needed.
> - else if (wi::gt_p (lh_range, 0, sign) && wi::lt_p (lh_range, 4, sign)
> - && ov_lh == wi::OVF_NONE)
> + else if (wi::min_precision (4, sign) <= wi::get_precision (lh_range)
> + && ov_lh == wi::OVF_NONE
> + && wi::gt_p (lh_range, 0, sign)
> + && wi::lt_p (lh_range, 4, sign))
> {
> wi_fold (r, type, lh_lb, lh_lb, rh_lb, rh_ub);
> if (wi::gt_p (lh_range, 1, sign))
> i.e. only optimize if 4 is representable in the given wide_int.
> The other option is to be extra careful.
yes, I think if the precision is small, simply don't try to break it up. We
special case 1 bit all over the place for this reason.
Like you did, or simply this way. Either amounts to the same thing and wi_fold
get called on the range.
diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 19bdf30911a..a88fb7b8932 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -149,6 +149,11 @@ range_operator::wi_fold_in_parts (irange &r, tree type,
wide_int rh_range = wi::sub (rh_ub, rh_lb, TYPE_SIGN (type), &ov_rh);
wide_int lh_range = wi::sub (lh_ub, lh_lb, TYPE_SIGN (type), &ov_lh);
signop sign = TYPE_SIGN (type);;
+
+ // If precision of the type is too small, don't bother trying to split it
up.
+ if (TYPE_PRECISION (type) <= 3)
+ wi_fold (r, type, lh_lb, lh_ub, rh_lb, rh_ub);
+ else
// If there are 2, 3, or 4 values in the RH range, do them separately.
// Call wi_fold_in_parts to check the RH side.
if (wi::gt_p (rh_range, 0, sign) && wi::lt_p (rh_range, 4, sign)
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (16 preceding siblings ...)
2022-02-02 13:50 ` amacleod at redhat dot com
@ 2022-02-02 13:56 ` rguenther at suse dot de
2022-02-02 14:00 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: rguenther at suse dot de @ 2022-02-02 13:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #17 from rguenther at suse dot de <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 <jakub at gcc dot gnu.org> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Status|NEW |ASSIGNED
> Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
>
> --- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Created attachment 52328
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52328&action=edit
> gcc12-pr104334.patch
>
> Better untested fix.
unconditional using wi::to_widest for the compares might also work?
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (17 preceding siblings ...)
2022-02-02 13:56 ` rguenther at suse dot de
@ 2022-02-02 14:00 ` jakub at gcc dot gnu.org
2022-02-02 14:12 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-02 14:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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 cc1plus and that no
longer miscompiles the testcase.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (18 preceding siblings ...)
2022-02-02 14:00 ` jakub at gcc dot gnu.org
@ 2022-02-02 14:12 ` jakub at gcc dot gnu.org
2022-02-02 15:07 ` rsandifo at gcc dot gnu.org
` (2 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-02 14:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (19 preceding siblings ...)
2022-02-02 14:12 ` jakub at gcc dot gnu.org
@ 2022-02-02 15:07 ` rsandifo at gcc dot gnu.org
2022-02-03 8:46 ` cvs-commit at gcc dot gnu.org
2022-02-03 8:46 ` jakub at gcc dot gnu.org
22 siblings, 0 replies; 24+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2022-02-02 15:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #20 from rsandifo at gcc dot gnu.org <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 approach to me FWIW. You can use infix
operators instead of lts_p etc. for widest_ints, since widest_ints
always have enough bits for the sign.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (20 preceding siblings ...)
2022-02-02 15:07 ` rsandifo at gcc dot gnu.org
@ 2022-02-03 8:46 ` cvs-commit at gcc dot gnu.org
2022-02-03 8:46 ` jakub at gcc dot gnu.org
22 siblings, 0 replies; 24+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-02-03 8:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:de67f943b858099b40f73632a51e66147ec79c9b
commit r12-7012-gde67f943b858099b40f73632a51e66147ec79c9b
Author: Jakub Jelinek <jakub@redhat.com>
Date: Thu Feb 3 09:45:16 2022 +0100
ranger: Fix up wi_fold_in_parts for small precision types [PR104334]
The wide-int.h templates expect that when an int/long etc. operand is used
it will be sign-extended based on the types precision.
wi_fold_in_parts passes 3 such non-zero constants to wi::lt_p, wi::gt_p
and wi::eq_p - 1, 3 and 4, which means it was doing weird things if either
some of 1, 3 or 4 weren't representable in type, or if type was unsigned 3
bit
type 4 should be written as -4.
The following patch promotes the subtraction operands to widest_int and
uses that as the type for ?h_range variables and compares them as such.
We don't need the overflow handling because there is never an overflow.
2022-02-02 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/104334
* range-op.cc (range_operator::wi_fold_in_parts): Change lh_range
and rh_range type to widest_int and subtract in widest_int. Remove
ov_rh, ov_lh and sign vars, always perform comparisons as signed
and use >, < and == operators for it.
* g++.dg/opt/pr104334.C: New test.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
` (21 preceding siblings ...)
2022-02-03 8:46 ` cvs-commit at gcc dot gnu.org
@ 2022-02-03 8:46 ` jakub at gcc dot gnu.org
22 siblings, 0 replies; 24+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-03 8:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2022-02-03 8:46 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-01 20:35 [Bug tree-optimization/104334] New: Ranger/dom miscompilation jakub at gcc dot gnu.org
2022-02-01 20:35 ` [Bug tree-optimization/104334] [12 Regression] " jakub at gcc dot gnu.org
2022-02-01 20:48 ` jakub at gcc dot gnu.org
2022-02-02 1:27 ` pinskia at gcc dot gnu.org
2022-02-02 10:18 ` marxin at gcc dot gnu.org
2022-02-02 10:19 ` marxin at gcc dot gnu.org
2022-02-02 10:29 ` pinskia at gcc dot gnu.org
2022-02-02 10:37 ` jakub at gcc dot gnu.org
2022-02-02 12:06 ` jakub at gcc dot gnu.org
2022-02-02 12:13 ` jakub at gcc dot gnu.org
2022-02-02 12:26 ` rsandifo at gcc dot gnu.org
2022-02-02 12:30 ` rguenther at suse dot de
2022-02-02 12:31 ` jakub at gcc dot gnu.org
2022-02-02 12:38 ` [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e marxin at gcc dot gnu.org
2022-02-02 12:46 ` jakub at gcc dot gnu.org
2022-02-02 12:51 ` marxin at gcc dot gnu.org
2022-02-02 13:39 ` jakub at gcc dot gnu.org
2022-02-02 13:50 ` amacleod at redhat dot com
2022-02-02 13:56 ` rguenther at suse dot de
2022-02-02 14:00 ` jakub at gcc dot gnu.org
2022-02-02 14:12 ` jakub at gcc dot gnu.org
2022-02-02 15:07 ` rsandifo at gcc dot gnu.org
2022-02-03 8:46 ` cvs-commit at gcc dot gnu.org
2022-02-03 8:46 ` jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).