https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #22 from Khem Raj ---
(In reply to Jakub Jelinek from comment #20)
> How could these changes result in
> ../harfbuzz-6.0.0/src/hb-map.hh:295:5: error: no match for ‘operator|’
> (operand types are ‘hb_filter_iter_t unsigned int,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #21 from Jakub Jelinek ---
Seems it is r13-5684-g59e0376f607805ef9b67fd7b0a4a3084ab3571a5 aka PR107461
change. So, please file a separate bugreport, it has nothing to do with this
PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #20 from Jakub Jelinek ---
How could these changes result in
../harfbuzz-6.0.0/src/hb-map.hh:295:5: error: no match for ‘operator|’ (operand
types are ‘hb_filter_iter_t::item_t>, bool (hb_hashmap_t::item_t::*)() const, const&, 0>’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
Khem Raj changed:
What|Removed |Added
CC||raj.khem at gmail dot com
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #17 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e753080ab8abd4021381699bc7e857f5b4a083c4
commit r13-5698-ge753080ab8abd4021381699bc7e857f5b4a083c4
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #16 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:10bd26d6efe88a8cf03a6a325351bc470a910cab
commit r13-5695-g10bd26d6efe88a8cf03a6a325351bc470a910cab
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #15 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #14)
> Created attachment 54405 [details]
> gcc13-pr108647.patch
>
> Here is what I'm about to test momentarily, though I must say I don't
> understand those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #13 from Aldy Hernandez ---
Created attachment 54404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54404=edit
frange changes
These are the analogous changes to range-op-float.cc.
Patch in testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #12 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #7)
> So
> --- gcc/range-op.cc.jj2023-02-03 10:51:40.699003658 +0100
> +++ gcc/range-op.cc 2023-02-03 16:04:39.264159294 +0100
> @@ -642,7 +642,8 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #11 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Andrew Macleod from comment #9)
> > (In reply to Jakub Jelinek from comment #8)
> > > Unfortunately that would mean for the non-equality cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #10 from Jakub Jelinek ---
(In reply to Andrew Macleod from comment #9)
> (In reply to Jakub Jelinek from comment #8)
> > Unfortunately that would mean for the non-equality cases that if
> > lhs.undefined_p () we don't return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #8)
> Unfortunately that would mean for the non-equality cases that if
> lhs.undefined_p () we don't return undefined but false (aka VARYING).
> Another option is to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #8 from Jakub Jelinek ---
Unfortunately that would mean for the non-equality cases that if
lhs.undefined_p () we don't return undefined but false (aka VARYING).
Another option is to add those if (op?.undefined_p ()) return false; to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #7 from Jakub Jelinek ---
So
--- gcc/range-op.cc.jj 2023-02-03 10:51:40.699003658 +0100
+++ gcc/range-op.cc 2023-02-03 16:04:39.264159294 +0100
@@ -642,7 +642,8 @@ operator_equal::op1_range (irange , tr
case BRS_FALSE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #6 from Andrew Macleod ---
This is the first release that we process relations in GORI. Up until recently
it was fairly ad-hoc what got passed in as a relation trio to the op?_range
routines. A couple of days ago I fleshed it out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #5 from Aldy Hernandez ---
> Perhaps just adding if (op2.undefined_p ()) return false; above most of the
> switch (get_bool_state (r, lhs, type)) lines (in methods that refer to op2;
> and similarly for op1) for the comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #4 from Jakub Jelinek ---
Perhaps just adding if (op2.undefined_p ()) return false; above most of the
switch (get_bool_state (r, lhs, type)) lines (in methods that refer to op2; and
similarly for op1) for the comparison operators.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
21 matches
Mail list logo
