git commit g:11c13111ac64a035d6c4ea6c118eff4ece7a9d9b
gcc-descr r15-43-g11c13111ac64a0
power9 BE
Linux 6.7.12-powerpc64 ppc64
GNU Make 4.3
DejaGnu:
DejaGnu version 1.6.3
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Mon Apr 29 04:15:22 UTC 2024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
--- Comment #3 from Hongtao Liu ---
Created attachment 58066
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58066=edit
reproduced testcase
gfortran -O2 -march=x86-64-v4 -fvect-cost-model=cheap.
git commit g:11c13111ac64a035d6c4ea6c118eff4ece7a9d9b
gcc-descr r15-43-g11c13111ac64a0
power9
Linux 5.15.0-97-generic ppc64le
GNU Make 4.3
DejaGnu:
DejaGnu version 1.6.2
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Mon Apr 29 04:03:36 UTC 2024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Hi, Han.
GCC 14 is branch out. You can commit it to trunk (GCC 15).
juzhe.zh...@rivai.ai
From: demin.han
Date: 2024-04-02 16:30
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li; jeffreyalaw; rdapp.gcc
Subject: [PATCH v2] RISC-V: Refine the condition for add additional vars in RVV
cost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114884
Bug ID: 114884
Summary: GCC rejects valid deduction using deduction guide
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
--- Comment #2 from Hongtao Liu ---
(In reply to Andrew Pinski from comment #1)
> Can you reduce the fortran code down for the ICE? It should not be hard, you
> can use delta even.
Let me try.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
--- Comment #1 from Andrew Pinski ---
Can you reduce the fortran code down for the ICE? It should not be hard, you
can use delta even.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
Andrew Pinski changed:
What|Removed |Added
Summary|521.wrf_r ICE with -O2 |[14 Regression] 521.wrf_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
Bug ID: 114883
Summary: 521.wrf_r ICE with -O2 -march=sapphirerapids
-fvect-cost-model=cheap
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
--- Comment #33 from Andrew Pinski ---
(In reply to Paul Eggert from comment #32)
> Created attachment 58065 [details]
> Run "gunzip t.i.gz; gcc -O2 -S -Wclobbered t.i" to reproduce the false
> positives
>
> I ran into this bug today when
git commit g:01207cb496ad21e17e14176e827dcfc847279cd6
gcc-descr r12-10401-g01207cb496ad21
power9 IEEE128
Linux 6.9.0-0.rc3.30.fc41.ppc64le ppc64le
GNU Make 4.4.1
DejaGnu:
DejaGnu version 1.6.3
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Mon Apr 29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
Paul Eggert changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
--- Comment #32
git commit g:cb3d253abe35ba5c7ab0991f15ea35892a2d9c8d
gcc-descr r13-8657-gcb3d253abe35ba
power9 BE
Linux 6.7.12-powerpc64 ppc64
GNU Make 4.3
DejaGnu:
DejaGnu version 1.6.3
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Mon Apr 29 03:00:29 UTC 2024
OK for trunk, and my understanding is that flag isn't really used in
code gen yet, so it's not necessary to port to GCC 14 branch?
On Mon, Apr 29, 2024 at 7:05 AM Christoph Müllner
wrote:
>
> The extension parsing table entries for a range of Zic* extensions
> does not match the mask definition
https://gcc.gnu.org/g:11c13111ac64a035d6c4ea6c118eff4ece7a9d9b
commit r15-43-g11c13111ac64a035d6c4ea6c118eff4ece7a9d9b
Author: Jie Mei
Date: Sun Apr 28 16:57:31 2024 +0800
MIPS: Add MIN/MAX.fmt instructions support for MIPS R6
This patch adds the smin/smax RTL mode for the
git commit g:cb3d253abe35ba5c7ab0991f15ea35892a2d9c8d
gcc-descr r13-8657-gcb3d253abe35ba
power8
Linux 5.4.0-177-generic ppc64le
GNU Make 4.2.1
DejaGnu:
DejaGnu version 1.6.2
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Mon Apr 29 02:26:04 UTC 2024
I will apply this patch.
While we still have a problem about
```
float max(float a, float b) { return a>=b?a:b; }
```
If it is compiled with `-ffinite-math-only -fsigned-zeros -O2
-mips32r6 -mabi=32`,
`max.s` can be used.
The max.fmt/min.fmt of MIPSr6 can process +0/-0 correctly.
git commit g:12c03bdb5865ff5f4ffd007401c6f5a3737540ca
gcc-descr r11-11398-g12c03bdb5865ff
power9
Linux 5.15.0-97-generic ppc64le
GNU Make 4.3
DejaGnu:
DejaGnu version 1.6.2
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Mon Apr 29 02:55:20 UTC 2024
LAST_UPDATED: Sun Apr 28 17:05:09 UTC 2024 (revision r15-24-g507f3ce34c5)
=== acats tests ===
FAIL: cb1010a
=== acats Summary ===
# of expected passes2327
# of unexpected failures1
Native configuration is s390x-ibm-linux-gnu arch14
Xi Ruoyao 于2024年3月26日周二 18:10写道：
>
> On Tue, 2024-03-26 at 11:15 +0800, YunQiang Su wrote:
>
> /* snip */
>
> > With -ffinite-math-only -fno-signed-zeros, it does work with
> > x >= y ? x : y
> > while without `-ffinite-math-only -fno-signed-zeros`, it cannot.
> > @Xi Ruoyao Is it expected by
# From https://ci.linaro.org/job/tcwg_gcc_check--master-arm-build/2036/:
LAST_UPDATED: 2024-04-29T03:09:29+00:00 (master revision
gcc-15-42-gdeb69bfbb00) armv8l-unknown-linux-gnueabihf
Native configuration is armv8l-unknown-linux-gnueabihf
=== libatomic tests ===
Running
git commit g:cb3d253abe35ba5c7ab0991f15ea35892a2d9c8d
gcc-descr r13-8657-gcb3d253abe35ba
power9 IEEE128
Linux 6.9.0-0.rc3.30.fc41.ppc64le ppc64le
GNU Make 4.4.1
DejaGnu:
DejaGnu version 1.6.3
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Mon Apr 29
Jeff Law 于2024年1月3日周三 01:00写道：
>
>
>
> On 1/1/24 09:48, YunQiang Su wrote:
> > When building multilib libraries, CC/CXX etc are set with an option
> > -B*/lib/, instead of -B/lib/.
> > This will make some trouble in some case, for example building
> > cross toolchain based on Debian's cross
git commit g:deb69bfbb000339fbef316916cf6c46156c6af1b
gcc-descr r15-42-gdeb69bfbb00033
power9
Linux 5.15.0-97-generic ppc64le
GNU Make 4.3
DejaGnu:
DejaGnu version 1.6.2
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Mon Apr 29 01:24:26 UTC 2024
git commit g:deb69bfbb000339fbef316916cf6c46156c6af1b
gcc-descr r15-42-gdeb69bfbb00033
power9 BE
Linux 6.7.12-powerpc64 ppc64
GNU Make 4.3
DejaGnu:
DejaGnu version 1.6.3
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Mon Apr 29 01:27:38 UTC 2024
git commit g:deb69bfbb000339fbef316916cf6c46156c6af1b
gcc-descr r15-42-gdeb69bfbb00033
power8
Linux 5.4.0-177-generic ppc64le
GNU Make 4.2.1
DejaGnu:
DejaGnu version 1.6.2
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Mon Apr 29 00:24:12 UTC 2024
90
# of unexpected successes 20
# of expected failures 1619
# of unsupported tests 4251
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 15.0.0 20240428
(experimental) [remotes/origin/HEAD r15-41-gd71308d5a6] (GCC)
=== gfortran tests ===
Regressions on master at commit r15-41 vs commit r15-25 on Linux/x86_64
New failures:
FAIL: libgomp.c++/../libgomp.c-c++-common/for-3.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/for-5.c execution test
New passes:
FAIL: libgomp.c/../libgomp.c-c++-common/for-11.c execution test
FAIL:
# From https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/1914/:
LAST_UPDATED: 2024-04-29T00:52:41+00:00 (master revision
gcc-15-42-gdeb69bfbb00) aarch64-unknown-linux-gnu
Native configuration is aarch64-unknown-linux-gnu
=== libatomic tests ===
Running target
git commit g:01207cb496ad21e17e14176e827dcfc847279cd6
gcc-descr r12-10401-g01207cb496ad21
power9 BE
Linux 6.7.12-powerpc64 ppc64
GNU Make 4.3
DejaGnu:
DejaGnu version 1.6.3
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Mon Apr 29 00:22:25 UTC 2024
git commit g:01207cb496ad21e17e14176e827dcfc847279cd6
gcc-descr r12-10401-g01207cb496ad21
power9
Linux 5.15.0-97-generic ppc64le
GNU Make 4.3
DejaGnu:
DejaGnu version 1.6.2
Expect version 5.45.4
Tcl version 8.6
64-bit
LAST_UPDATED: Mon Apr 29 00:22:18 UTC 2024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107060
--- Comment #10 from Paul Eggert ---
Created attachment 58064
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58064=edit
"gunzip u.i" then "gcc -O2 -S -fanalyzer u.i" to see how much memory GCC uses
I'm having more trouble with this when
-linux-gnu/bin/aarch64-linux-gnu-gcc
version 15.0.0 20240428 (experimental) [master revision
gcc-15-41-gd71308d5a68] (GCC)
Host is x86_64-pc-linux-gnu
=== gfortran tests ===
Running target qemu
FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O0 execution
outputs-23 exe savetmp named2-2: outputs.ld1_args
FAIL: outputs-24 exe savetmp named2-3: outputs.ld1_args
FAIL: outputs-25 exe savetmp named2-4: outputs.ld1_args
FAIL: outputs-294 lto sing unnamed-3: a.ld1_args
FAIL: outputs-294 lto sing unnamed-3: a.ld_args
=== gcc Summary ===
# of expe
150371
# of unexpected failures176
# of unexpected successes 33
# of expected failures 985
# of unresolved testcases 2
# of unsupported tests 3770
/home/gccbuild/build/nightly/build-gcc-11/gcc/xgcc version 11.4.1 20240428
[releases/gcc-1
Signed-off-by: Peter Damianov
---
Fixes these warnings:
../../gcc/gcc/../libgcc/libgcov-util.c: In function 'void tag_counters(unsigned
int, int)':
../../gcc/gcc/../libgcc/libgcov-util.c:214:59: warning: 'void* calloc(size_t,
size_t)' sizes specified with 'sizeof' in the earlier argument and
29 Apr 2024 12:16:26 am Peter Damianov :
This commit adds a new option to the driver that truncates one file
after
linking.
Tested likeso:
$ gcc hello.c -c
$ du -h hello.o
4.0K hello.o
$ gcc hello.o -truncate hello.o
$ ./a.out
Hello world
$ du -h hello.o
$ 0 hello.o
$ gcc hello.o
This commit changes the Makefiles generated by lto-wrapper to no longer use
the "mv" and "touch" shell commands. These don't exist on Windows, so when the
Makefile attempts to call them, it results in errors like:
The system cannot find the file specified.
This problem only manifested when
This commit adds a new option to the driver that truncates one file after
linking.
Tested likeso:
$ gcc hello.c -c
$ du -h hello.o
4.0K hello.o
$ gcc hello.o -truncate hello.o
$ ./a.out
Hello world
$ du -h hello.o
$ 0 hello.o
$ gcc hello.o -truncate
gcc: error: missing filename after
The extension parsing table entries for a range of Zic* extensions
does not match the mask definition in riscv.opt.
This results in broken TARGET_ZIC* macros, because the values of
riscv_zi_subext and riscv_zicmo_subext are set wrong.
This patch fixes this by moving Zic64b into riscv_zicmo_subext
s147360
# of unexpected failures38
# of unexpected successes 4
# of expected failures 916
# of unresolved testcases 2
# of unsupported tests 2773
/home/gccbuild/build/nightly/build-gcc-11/gcc/xgcc version 11.4.1 20240428
[releases/gcc-11
5035
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 15.0.0 20240428
(experimental) [remotes/origin/HEAD r15-41-gd71308d5a6] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test
XPASS: gfortra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827
--- Comment #10 from Neil Carlson ---
Thanks Harald for hunting this down!
I've tested your patch on master with -fsanitize=address against my library
that turned up these errors and it all looks good now. Is it possible to back
port this to
Snapshot gcc-15-20240428 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/15-20240428/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 15 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Regressions on master at commit r15-25 vs commit r15-22 on Linux/x86_64
New failures:
FAIL: libgomp.c/../libgomp.c-c++-common/for-11.c execution test
FAIL: libgomp.c++/../libgomp.c-c++-common/for-5.c execution test
New passes:
tor/vec-scalar-cmp-1.c scan-assembler
ne:\\n[^:]*\\twfcdb\\t%v[0-9]*,%v[0-9]*\\n\\t[^:]+\\tlocghine\\t%r2,1
=== gcc Summary for unix/-m64 ===
# of expected passes180905
# of unexpected failures173
# of unexpected successes 17
# of expected failures
scan-assembler-times padd 5
FAIL: gcc.target/i386/vect-reduc-1.c scan-assembler-times psrl 2
FAIL: gcc.target/i386/xorsign.c scan-tree-dump-times vect "vectorized 2 loops" 1
=== gcc Summary ===
# of expected passes 196227
# of unexpected failures229
# of u
179467
# of unexpected failures106
# of unexpected successes 20
# of expected failures 1619
# of unsupported tests 4249
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 15.0.0 20240428
(experimental) [remotes/origin/HEAD r15-41-gd71308d5a68] (G
Hi All,
Could this be looked at quickly? The timing of this regression is more than
a little embarrassing on the eve of the 14.1 release. The testcase and the
comment in gfc_trans_class_init_assign explain what this problem is all
about and how the patch fixes it.
OK for 15-branch and
5241
# of unsupported tests 23201
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xg++ version 15.0.0 20240428
(experimental) [master r15-41-gd71308d5a6] (GCC)
=== gcc tests ===
Running target unix/-m32
XPASS: gcc.dg/guality/example.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
Paul Thomas changed:
What|Removed |Added
Attachment #58054|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114581
--- Comment #1 from Ian Lance Taylor ---
The behavior is different under gdb because gdb resends the signal. The
program then sees it with an si_code field of SI_USER, which causes it to act
differently.
90
# of unexpected successes 20
# of expected failures 1619
# of unsupported tests 4251
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 15.0.0 20240428
(experimental) [remotes/origin/HEAD r15-24-g507f3ce34c] (GCC)
=== gfortran tests ===
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114882
Bug ID: 114882
Summary: Two -fanalyzer false positives after realloc grows
buffer
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
cases 1
# of unsupported tests 9466
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-gcc
version 15.0.0 20240428 (experimental) [master revision
gcc-15-14-g83bc41e8364] (GCC)
Host is x86_64-pc-linux-gnu
=== g++ tests ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Attachment #58048|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
Nicolas Boulenguez changed:
What|Removed |Added
Attachment #58028|0 |1
is obsolete|
5035
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 15.0.0 20240428
(experimental) [remotes/origin/HEAD r15-25-g942a9cf2a9] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test
XPASS: gfortra
The polymorphic Value_Range object takes a tree type at construction
so it can determine what type of range to use (currently irange or
frange). It seems a few of the types are slightly off. This isn't a
problem now, because IPA only cares about integers and pointers, which
can both live in an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52357
--- Comment #8 from Ian Lance Taylor ---
This is a register allocator problem, not a Go problem. I've opened
https://gcc.gnu.org/PR114881. It's an updated version of
https://gcc.gnu.org/PR53125.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114881
Bug ID: 114881
Summary: Very slow compilation on SPARC
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
scan-assembler-times padd 5
FAIL: gcc.target/i386/vect-reduc-1.c scan-assembler-times psrl 2
FAIL: gcc.target/i386/xorsign.c scan-tree-dump-times vect "vectorized 2 loops" 1
=== gcc Summary ===
# of expected passes 196227
# of unexpected failures229
# of u
Dear contributor, our automatic CI has detected problems related to your
patch(es). Please find some details below. If you have any questions, please
follow up on linaro-toolch...@lists.linaro.org mailing list, Libera's
#linaro-tcwg channel, or ping your favourite Linaro toolchain developer
179467
# of unexpected failures106
# of unexpected successes 20
# of expected failures 1619
# of unsupported tests 4249
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 15.0.0 20240428
(experimental) [remotes/origin/HEAD r15-25-g942a9cf2a95] (G
5241
# of unsupported tests 23201
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xg++ version 15.0.0 20240428
(experimental) [master r15-25-g942a9cf2a9] (GCC)
=== gcc tests ===
Running target unix/-m32
XPASS: gcc.dg/guality/example.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114880
Bug ID: 114880
Summary: analyzer: False positive Wanalyzer-fd-use-after-close
when open returns the same fd
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
In this cycle, we will be contributing ranges for pointers (prange),
to disambiguate pointers from integers in a range. Initially they
will behave exactly as they do now, with just two integer end points
and a bitmask, but eventually we will track points-to info in a less
hacky manner than what
As per the documentation, irange_bitmask must have the unknown bits in
the mask set to 0 in the value field. Even though we say we must have
normalized value/mask bits, we don't enforce it, opting to normalize
on the fly in union and intersect. Avoiding this lazy enforcing as
well as the extra
Conditional operators are always boolean, regardless of their
operands. Getting the type wrong is not currently a problem, but will
be when prange's can no longer store an integer.
gcc/ChangeLog:
* vr-values.cc (simplify_using_ranges::fold_cond_with_ops): Remove
type from
There are some irange uses that should be Value_Range, because they
can be either integers or pointers. This will become a problem when
prange comes live.
gcc/ChangeLog:
* tree-ssa-loop-split.cc (split_at_bb_p): Make int_range a Value_Range.
* tree-ssa-strlen.cc (get_range):
/mve-vshr.c scan-assembler-times
vshl.u[0-9]+tq[0-9]+, q[0-9]+ 3
=== gcc Summary ===
# of expected passes160486
# of unexpected failures268
# of expected failures 1016
# of unresolved testcases 1
# of unsupported tests 9379
/home/tcwg-buildslave
Remove legacy range_zero and range_nonzero as they return by value,
which make it not work in a separate irange and prange world. Also,
we already have set_zero and set_nonzero methods in vrange.
gcc/ChangeLog:
* range-op-ptr.cc (pointer_plus_operator::wi_fold): Use method
range
Accept a vrange, as this will be used for either integers or pointers.
gcc/ChangeLog:
* value-range.h (range_includes_zero_p): Accept vrange.
---
gcc/value-range.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/gcc/value-range.h b/gcc/value-range.h
index
Explicitly make vrange an abstract class. This involves fleshing out
the unsupported_range overrides which we were inheriting by default
from vrange.
gcc/ChangeLog:
* value-range.cc (unsupported_range::accept): Move down.
(vrange::contains_p): Rename to...
In preparation for prange, make get_legacy_range take a generic
vrange, not just an irange.
gcc/ChangeLog:
* value-range.cc (get_legacy_range): Make static and add another
version of get_legacy_range that takes a vrange.
* value-range.h (class irange): Remove unnecessary
Make range_includes_zero_p take an argument instead of a pointer for
consistency in the range-op code.
gcc/ChangeLog:
* gimple-range-op.cc (cfn_clz::fold_range): Change
range_includes_zero_p argument to a reference.
(cfn_ctz::fold_range): Same.
* range-op.cc
Move some code out of the irange pretty printers so it can be shared
with pointers.
gcc/ChangeLog:
* value-range-pretty-print.cc (print_int_bound): New.
(print_irange_bitmasks): New.
(vrange_printer::print_irange_bound): Remove.
We have a sanity check in the irange storage code to make sure that
reading back a cache entry we have just written to yields exactly the
same range. There's no need to do this only for integers. This patch
moves the code to a more generic place.
However, doing so tickles a latent bug in the
Richi mentioned in PR113476 that it would be cleaner to move the
destructor from int_range to the base class. Although this isn't
strictly necessary, as there are no users, it is good to future proof
things, and the overall impact is miniscule.
gcc/ChangeLog:
* value-range.h
prange will also have bitmasks, so it will need to use get_bitmask_from_range.
gcc/ChangeLog:
* value-range.cc (get_bitmask_from_range): Move out of irange class.
(irange::get_bitmask): Call function instead of internal method.
* value-range.h (class irange): Remove
This patch adds vrange::lbound() and vrange::ubound() that return
trees. These can be used in generic code that is type agnostic, and
avoids special casing for pointers and integers in places where we
handle both. It also cleans up a wart in the Value_Range class.
gcc/ChangeLog:
*
Any range can theoretically have a bitmask of set bits. This patch
moves the bitmask accessors to the base class. This cleans up some
users in IPA*, and will provide a cleaner interface when prange is in
place.
gcc/ChangeLog:
* ipa-cp.cc (propagate_bits_across_jump_function): Access
Now that we have a vrange storage class to save ranges in long-term
memory, there is no need for GTY markers for any of the vrange
classes, since they should never live in GC.
gcc/ChangeLog:
* value-range-storage.h: Remove friends.
* value-range.cc (gt_ggc_mx): Remove.
Fix some Value_Range's that we know ahead of time will be only
integers. This avoids using the polymorphic Value_Range unnecessarily
gcc/ChangeLog:
* gimple-ssa-warn-access.cc (check_nul_terminated_array): Make
Value_Range an int_range.
(memmodel_to_uhwi): Same
*
https://gcc.gnu.org/g:d71308d5a681de00ea291136c162e5b46c7c
commit r15-41-gd71308d5a681de00ea291136c162e5b46c7c
Author: Aldy Hernandez
Date: Tue Apr 23 10:12:56 2024 +0200
Callers of irange_bitmask must normalize value/mask pairs.
As per the documentation, irange_bitmask
https://gcc.gnu.org/g:3b9abfd2df5fe720798aab1e21b4a11876607561
commit r15-40-g3b9abfd2df5fe720798aab1e21b4a11876607561
Author: Aldy Hernandez
Date: Wed Mar 20 05:51:55 2024 +0100
Remove range_zero and range_nonzero.
Remove legacy range_zero and range_nonzero as they return by
https://gcc.gnu.org/g:df6a1bc59a355c9fee10d29f54c9dca81612afb6
commit r15-39-gdf6a1bc59a355c9fee10d29f54c9dca81612afb6
Author: Aldy Hernandez
Date: Tue Mar 19 20:26:27 2024 +0100
Move print_irange_* out of vrange_printer class.
Move some code out of the irange pretty printers so
https://gcc.gnu.org/g:c284f8d2d16ce9c29defce3329419ccc54605ad4
commit r15-37-gc284f8d2d16ce9c29defce3329419ccc54605ad4
Author: Aldy Hernandez
Date: Tue Mar 19 18:22:08 2024 +0100
Make some integer specific ranges generic Value_Range's.
There are some irange uses that should be
https://gcc.gnu.org/g:b102633be7d0b763d106b0a883679bb1497ca17c
commit r15-38-gb102633be7d0b763d106b0a883679bb1497ca17c
Author: Aldy Hernandez
Date: Tue Mar 19 18:29:21 2024 +0100
Accept any vrange in range_includes_zero_p.
Accept a vrange, as this will be used for either integers
https://gcc.gnu.org/g:2caf7a50a6a9de80d2767d82b8cdb69d63469aaf
commit r15-36-g2caf7a50a6a9de80d2767d82b8cdb69d63469aaf
Author: Aldy Hernandez
Date: Tue Mar 19 18:04:55 2024 +0100
Move get_bitmask_from_range out of irange class.
prange will also have bitmasks, so it will need to
https://gcc.gnu.org/g:92f74ee21218cab08d7bb7769004a65e8a291fa3
commit r15-34-g92f74ee21218cab08d7bb7769004a65e8a291fa3
Author: Aldy Hernandez
Date: Tue Mar 19 16:35:41 2024 +0100
Verify that reading back from vrange_storage doesn't drop bits.
We have a sanity check in the irange
https://gcc.gnu.org/g:9a2f0d152d98dd55efc9accd07ea507b929c3516
commit r15-35-g9a2f0d152d98dd55efc9accd07ea507b929c3516
Author: Aldy Hernandez
Date: Tue Mar 19 17:17:53 2024 +0100
Accept a vrange in get_legacy_range.
In preparation for prange, make get_legacy_range take a generic
https://gcc.gnu.org/g:d883fc7d00ed6bf5ee151de4fd3e05431582bd5f
commit r15-33-gd883fc7d00ed6bf5ee151de4fd3e05431582bd5f
Author: Aldy Hernandez
Date: Tue Mar 19 16:33:47 2024 +0100
Change range_includes_zero_p argument to a reference.
Make range_includes_zero_p take an argument
https://gcc.gnu.org/g:039e88b1aea5723221e8b0b926c35afb2f96a8a9
commit r15-32-g039e88b1aea5723221e8b0b926c35afb2f96a8a9
Author: Aldy Hernandez
Date: Wed Feb 7 11:27:29 2024 +0100
Make fold_cond_with_ops use a boolean type for range_true/range_false.
Conditional operators are
https://gcc.gnu.org/g:eeef1f69c5e77ecf13fdcf44df5bcf592a9993e6
commit r15-31-geeef1f69c5e77ecf13fdcf44df5bcf592a9993e6
Author: Aldy Hernandez
Date: Wed Feb 21 09:34:29 2024 +0100
Remove GTY support for vrange and derived classes.
Now that we have a vrange storage class to save
https://gcc.gnu.org/g:ba1a8e8eed963c0253c6e5550c8bccc264c5d469
commit r15-29-gba1a8e8eed963c0253c6e5550c8bccc264c5d469
Author: Aldy Hernandez
Date: Mon Apr 22 13:34:48 2024 +0200
Add tree versions of lower and upper bounds to vrange.
This patch adds vrange::lbound() and
https://gcc.gnu.org/g:fd4cf7a092bb2ce21c0d8246c17c0b7f82de440c
commit r15-30-gfd4cf7a092bb2ce21c0d8246c17c0b7f82de440c
Author: Aldy Hernandez
Date: Thu Feb 22 09:18:46 2024 +0100
Move bitmask routines to vrange base class.
Any range can theoretically have a bitmask of set bits.
https://gcc.gnu.org/g:a46564e4876c9a863d9897d72963cc4f03689adc
commit r15-28-ga46564e4876c9a863d9897d72963cc4f03689adc
Author: Aldy Hernandez
Date: Mon Apr 22 13:29:39 2024 +0200
Make some Value_Range's explicitly integer.
Fix some Value_Range's that we know ahead of time will be
https://gcc.gnu.org/g:a78dfb0fc83606e9b83b76575deb7e43300254fa
commit r15-27-ga78dfb0fc83606e9b83b76575deb7e43300254fa
Author: Aldy Hernandez
Date: Wed Feb 21 09:33:19 2024 +0100
Add a virtual vrange destructor.
Richi mentioned in PR113476 that it would be cleaner to move the
1 - 100 of 206 matches
Mail list logo
