https://gcc.gnu.org/g:1b91818e47119863f827b19ae4c6c91af3962cd6
commit r12-10406-g1b91818e47119863f827b19ae4c6c91af3962cd6
Author: Jeevitha
Date: Sun Apr 28 23:38:41 2024 -0500
rs6000: Don't ICE when compiling the __builtin_vsx_splat_2di [PR113950]
When we expand the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113950
--- Comment #6 from GCC Commits ---
The releases/gcc-12 branch has been updated by jeevitha :
https://gcc.gnu.org/g:1b91818e47119863f827b19ae4c6c91af3962cd6
commit r12-10406-g1b91818e47119863f827b19ae4c6c91af3962cd6
Author: Jeevitha
Date:
git commit g:020133c0fd06f2ee682fb0bca6ce7a4a01c52a23
gcc-descr r12-10405-g020133c0fd06f2
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: Wed May 1 04:26:03 UTC 2024
git commit g:72001c4cfb066ad3ceecb53ba0cd3a7cb7d0b936
gcc-descr r13-8666-g72001c4cfb066a
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: Wed May 1 04:12:42 UTC 2024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863
--- Comment #7 from Leo Carreon ---
I'm assuming the fix is for all floating point types not just double.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> here is a reduced testcase:
> Note ` -O1 -fno-tree-fre -fno-tree-forwprop -fno-tree-ccp
> -fno-tree-dominator-opts`
This testcase is broken in GCC 13 for
# From
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_v8a_hard_eabi-build/412/:
LAST_UPDATED: 2024-05-01T04:47:00+00:00 (master revision
gcc-15-83-g610415bb7dd) arm-eabi
{-mthumb/-march=armv8-a+simd/-mfpu=auto/-mfloat-abi=hard}
Target is arm-unknown-eabi
Host is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
--- Comment #4 from Andrew Pinski ---
here is a reduced testcase:
```
[[gnu::noipa]]
int f(int b)
{
int tt1 = ~b;
int t = 1 & tt1;
int e = -t;
int tt = e >= -1;
if (tt) return 0;
__builtin_trap();
}
int main()
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
Bug 98940 depends on bug 107688, which changed state.
Bug 107688 Summary: [C++23] P2615 - Meaningful exports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107688
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107688
Nathaniel Shead changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/g:79420dd344145819677b3f975bb305a778fcaf91
commit r15-84-g79420dd344145819677b3f975bb305a778fcaf91
Author: Nathaniel Shead
Date: Mon Mar 4 23:58:30 2024 +1100
c++: Implement P2615 'Meaningful Exports' [PR107688]
This clarifies which kinds of declarations may
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107688
--- Comment #2 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:79420dd344145819677b3f975bb305a778fcaf91
commit r15-84-g79420dd344145819677b3f975bb305a778fcaf91
Author: Nathaniel Shead
Date:
Regressions on master at commit r15-82 vs commit r15-70 on Linux/x86_64
New failures:
New passes:
FAIL: libgomp.c/examples-4/teams-4.c execution test
FAIL: libgomp.c++/../libgomp.c-c++-common/for-11.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/for-11.c execution test
FAIL:
On 4/30/24 10:34, Stefan Schulze Frielinghaus wrote:
> Starting with r14-2047-gd0e891406b16dc we see through subregs which
> means for f10 in risbg-ll-2.c we do not end up with rosbg_si_noshift but
> rather rosbg_di_noshift which materializes in slightly different start
> index. This saves us an
On 4/30/24 10:32, Stefan Schulze Frielinghaus wrote:
> Starting with r12-2731-g96146e61cd7aee we do not generate code like
>
> _5 = (unsigned int) c_2(D);
> i_6 = _5 << 8;
> _7 = _5 << 20;
> i_8 = i_6 | _7;
>
> anymore but instead
>
> _5 = (unsigned int) c_2(D);
> _3 = _5 * 1048832;
>
> which
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk (and
later 14.2)? I don't think making it a GTY root is necessary but I felt
perhaps better to be safe than sorry.
Potentially another approach would be to use DECL_UID instead like how
entity_map does; would that be preferable?
--
git commit g:72001c4cfb066ad3ceecb53ba0cd3a7cb7d0b936
gcc-descr r13-8666-g72001c4cfb066a
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: Wed May 1 03:11:08 UTC 2024
git commit g:020133c0fd06f2ee682fb0bca6ce7a4a01c52a23
gcc-descr r12-10405-g020133c0fd06f2
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: Wed May 1 03:12:07 UTC 2024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630
--- Comment #7 from Patrick Palka ---
The following seems to minimally fix it:
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index c35e70b8cb8..57ccaec5ebd 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -6798,7 +6798,7 @@
git commit g:610415bb7ddc5626ec301ca20833e78696978601
gcc-descr r15-83-g610415bb7ddc56
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: Wed May 1
On Tue, Apr 30, 2024 at 8:54 PM Jeff Law wrote:
>
>
> In doing some preparation work for using zbkb's pack instructions for
> constant synthesis I figured it would be wise to get a sense of how well
> our constant synthesis is actually working and address any clear issues.
>
> So the first
git commit g:754b14b98946894240ddc62e96d497194353bfe0
gcc-descr r11-11409-g754b14b9894689
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: Wed May 1 02:36:05 UTC 2024
LAST_UPDATED: Tue Apr 30 17:04:59 UTC 2024 (revision r15-77-g1ff71f71a13)
=== acats tests ===
FAIL: cb1010a
=== acats Summary ===
# of expected passes2327
# of unexpected failures1
Native configuration is s390x-ibm-linux-gnu arch14
This adds a few more of what is currently done in phiopt's value_replacement
to match. I noticed this when I was hooking up phiopt's value_replacement
code to use match and disabling the old code. But this can be done
independently from the hooking up phiopt's value_replacement as phiopt
is
git commit g:610415bb7ddc5626ec301ca20833e78696978601
gcc-descr r15-83-g610415bb7ddc56
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: Wed May 1 01:39:47 UTC 2024
git commit g:754b14b98946894240ddc62e96d497194353bfe0
gcc-descr r11-11409-g754b14b9894689
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: Wed May 1 01:56:50 UTC 2024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
--- Comment #3 from Andrew Pinski ---
Note this is almost definitely a latent bug exposed by some change. Might be
interesting to see what change exposed it but not so much really.
git commit g:020133c0fd06f2ee682fb0bca6ce7a4a01c52a23
gcc-descr r12-10405-g020133c0fd06f2
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: Wed May 1
git commit g:610415bb7ddc5626ec301ca20833e78696978601
gcc-descr r15-83-g610415bb7ddc56
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: Wed May 1 00:33:24 UTC 2024
Hi Filip,
Thanks for your reply. But I'm not so familiar with VIM actually. Thus
when I try the options listed there, nothing happened. (VSCODE is the
IDE I'm using for development.)
And I notice that there is a `vimrc` in the `contrib` directory, I
tried it too, but sadly, it didn't work for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
Andrew Pinski changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Summary|wrong code at
git commit g:610415bb7ddc5626ec301ca20833e78696978601
gcc-descr r15-83-g610415bb7ddc56
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: Wed May 1 00:22:53 UTC 2024
Regressions on releases/gcc-13 at commit r13-8665 vs commit r13-8664 on
Linux/x86_64
New failures:
New passes:
FAIL: libgomp.c++/../libgomp.c-c++-common/for-5.c execution test
git commit g:72001c4cfb066ad3ceecb53ba0cd3a7cb7d0b936
gcc-descr r13-8666-g72001c4cfb066a
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: Wed May 1 00:24:27 UTC 2024
git commit g:72001c4cfb066ad3ceecb53ba0cd3a7cb7d0b936
gcc-descr r13-8666-g72001c4cfb066a
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: Wed May 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
--- Comment #11 from Sam James ---
also, do asan and ubsan give anything?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
--- Comment #10 from Sam James ---
also maybe obvious, but if you can find something from the cython testsuite, or
at least some other heavy use of cython, which fails, that may be a good
direction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
--- Comment #9 from Sam James ---
unfortunately*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
--- Comment #8 from Sam James ---
element.i is unfortunatley huge. It's hard to analyse things without a
standalone testcase, but it's even harder without _something_ one can run.
I'd suggest:
1) giving instructions to reproduce the crash
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
This patch improves GCC’s vectorization of __builtin_popcount for aarch64 target
by adding popcount patterns for vector modes besides QImode, i.e., HImode,
SImode and DImode.
With this patch, we now generate the following for HImode:
cnt v1.16b, v.16b
uaddlp v2.8h, v1.16b
For SImode, we
5035
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 15.0.0 20240430
(experimental) [remotes/origin/HEAD r15-82-g7b3ac57852] (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=20785
Campbell changed:
What|Removed |Added
CC||rlcamp.pdx at gmail dot com
--- Comment #19
On Tue, Apr 30, 2024 at 05:51:20PM -0400, Jason Merrill wrote:
> On 4/30/24 14:45, Qing Zhao wrote:
> >
> >
> > > On Apr 30, 2024, at 15:27, Jason Merrill wrote:
> > >
> > > On 4/30/24 07:58, Qing Zhao wrote:
> > > > The request for GCC to accept that the C99 flexible array member can be
> > >
5253
# of unsupported tests 23205
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xg++ version 15.0.0 20240430
(experimental) [master r15-82-g7b3ac57852] (GCC)
=== gcc tests ===
Running target unix/-m32
XPASS: gcc.dg/guality/example.c -O0 execution test
Regressions on releases/gcc-14 at commit r14-10154 vs commit r14-10149 on
Linux/x86_64
New failures:
New passes:
FAIL: 27_io/basic_istream/ignore/wchar_t/94749.cc -std=gnu++17 execution test
FAIL: gcc.dg/vect/tsvc/vect-tsvc-s317.c execution test
FAIL:
179477
# 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 20240430
(experimental) [remotes/origin/HEAD r15-82-g7b3ac578520] (G
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 20240430
(experimental) [remotes/origin/HEAD r15-82-g7b3ac57852] (GCC)
=== gfortran tests ===
Regressions on master at commit r15-70 vs commit r15-57 on Linux/x86_64
New failures:
New passes:
FAIL: 27_io/basic_istream/ignore/char/94749.cc -std=gnu++17 execution test
FAIL: 27_io/basic_istream/ignore/wchar_t/94749.cc -std=gnu++17 execution test
FAIL: gcc.dg/vect/tsvc/vect-tsvc-s317.c
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 196237
# of unexpected failures229
# of u
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 passes180915
# of unexpected failures173
# of unexpected successes 17
# of expected failures
2082
# of unexpected failures170
# of unexpected successes 14
# of expected failures 1468
# of unsupported tests 3895
/home/gccbuild/build/nightly/build-gcc-12/gcc/xgcc version 12.3.1 20240430
[remotes/origin/releases/gcc-12 r12-10404-ge8482b86ef] (GCC)
htly/build-gcc-13/gcc/xgcc version 13.2.1 20240430
[releases/gcc-13 r13-8665-g61c38a231d] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test
XPASS: gfortran.dg/large_real_kind_form_io_2.f90 -O1 execution
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240430 (ex
/nightly/build-gcc-13/gcc/xg++ version 13.2.1 20240430
[releases/gcc-13 r13-8665-g61c38a231d] (GCC)
=== gcc tests ===
Running target unix/-m32
XPASS: gcc.dg/guality/example.c -O0 execution test
XPASS: gcc.dg/guality/example.c -O1 -DPREVENT_OPTIMIZATION execution test
XPASS
On 4/30/24 2:36 PM, Patrick O'Neill wrote:
gcc/testsuite/ChangeLog:
PR middle-end/114734
* gcc.target/riscv/rvv/autovec/pr114734.c: New test.
OK
jeff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114862
--- Comment #3 from Jonathan Wakely ---
I've opened https://cplusplus.github.io/LWG/issue4084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114841
--- Comment #1 from Jason Merrill ---
Matheus' suggested wording:
"When performing deduction such that both A and P are template template
params, and A is the template name of a template specialization,
instead of just deducing A in that case,
> On Apr 30, 2024, at 15:52, Jason Merrill wrote:
>
> On 4/30/24 14:49, Qing Zhao wrote:
>>> On Apr 30, 2024, at 15:45, Qing Zhao wrote:
>>>
>>>
>>>
> gcc/doc/extend.texi | 34 ++
> 1 file changed, 34 insertions(+)
> diff --git
On 4/30/24 14:49, Qing Zhao wrote:
On Apr 30, 2024, at 15:45, Qing Zhao wrote:
gcc/doc/extend.texi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 7b54a241a7bf..cba98c8aadd7 100644
---
On 4/30/24 14:45, Qing Zhao wrote:
On Apr 30, 2024, at 15:27, Jason Merrill wrote:
On 4/30/24 07:58, Qing Zhao wrote:
The request for GCC to accept that the C99 flexible array member can be
in a union or alone in a structure has been made a long time ago
around 2012
for supporting
On Apr 30, 2024, at 15:45, Qing Zhao wrote:
gcc/doc/extend.texi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 7b54a241a7bf..cba98c8aadd7 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@
On Tue, 2024-04-30 at 21:15 +0200, Richard Biener via Gcc wrote:
>
>
> > Am 30.04.2024 um 21:11 schrieb Jason Merrill via Gcc
> > :
> >
> > On Fri, Apr 26, 2024 at 5:44 AM Aldy Hernandez via Gcc
> > wrote:
> > >
> > > In implementing prange (pointer ranges), I have found a 1.74%
> > >
On Apr 30, 2024, at 15:27, Jason Merrill wrote:
On 4/30/24 07:58, Qing Zhao wrote:
The request for GCC to accept that the C99 flexible array member can be
in a union or alone in a structure has been made a long time ago around 2012
for supporting several practical cases including glibc.
A GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81087
--- Comment #6 from Eric Botcazou ---
There is a fix in the pipeline for GCC 15, although I'm not sure if it will
handle all the issues.
On 4/30/24 12:22, Jakub Jelinek wrote:
On Tue, Apr 30, 2024 at 03:09:51PM -0400, Jason Merrill via Gcc wrote:
On Fri, Apr 26, 2024 at 5:44 AM Aldy Hernandez via Gcc wrote:
In implementing prange (pointer ranges), I have found a 1.74% slowdown
in VRP, even without any code path actually using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81756
--- Comment #3 from Joseph S. Myers ---
This sort of "???" comment about existing practice means that some past change
(in this case, the one adding support for [[]] attributes) was aiming to avoid
perturbing how the compiler behaved for
es psrl 2
=== gcc Summary ===
# of expected passes184709
# of unexpected failures209
# of unexpected successes 31
# of expected failures 1470
# of unresolved testcases 114
# of unsupported tests 3568
/home/haochenj/src/gcc-13-
On Apr 30, 2024, at 15:29, Jason Merrill wrote:
On 4/30/24 07:58, Qing Zhao wrote:
Add testing cases to test the _bos for flexible array members in unions
or alone in structures.
gcc/c/ChangeLog:
* c-decl.cc (add_flexible_array_elts_to_size): Handle the cases
when the DECL is union.
ss
errors)
=== gcc Summary ===
# of expected passes165811
# of unexpected failures31
# of unexpected successes 3
# of expected failures 1481
# of unsupported tests 2973
/home/gccbuild/build/nightly/build-gcc-13/gcc/xgcc version 13.2.1 20240430
[relea
On Tue, Apr 30, 2024 at 11:12:30PM +0200, Martin Jambor wrote:
> Would the following then perhaps describe the situation accurately?
> Note that I have moved the whole thing to C++ section because it seems
> porting issues in C because of this are quite unlikely.
>
> Michal, I assume that the
On 4/30/24 07:58, Qing Zhao wrote:
Add testing cases to test the _bos for flexible array members in unions
or alone in structures.
gcc/c/ChangeLog:
* c-decl.cc (add_flexible_array_elts_to_size): Handle the cases
when the DECL is union.
gcc/cp/ChangeLog:
* decl.cc
On 4/30/24 07:58, Qing Zhao wrote:
The request for GCC to accept that the C99 flexible array member can be
in a union or alone in a structure has been made a long time ago around 2012
for supporting several practical cases including glibc.
A GCC PR has been opened for such request at that time:
while working on some new range-op enhancements, I found a couple of
developing asserts that no longer apply. This removed them.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. pushed.
Andrew
From a89de3a24d2312438848e513a0b02b480d52c81e Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Also during stage 3/4, we discovered that it is unsafe to call ranger
from within SCEV. This is because ranger uses SCEV to resolve PHIS, and
we can end up in a bad loop under the right conditions.
The fix is for ranger's cache to NOT try to pre-evaluate PHIs (which is
kind of waste anyway
It was also requested that I make range_on_entry() and range_on_exit ()
part of the fomal API for a range_query. These are now provided along
with the orignal range_of_expr (), range_of_stmt (), and range_on_edge
(). The routines were already there, just not published for consumption
in the
If range_of_expr is called on an ssa-name with no context, ranger just
grabs whatever the global value is.
It was pointed out we can do better than this. If the name is in the
IL, there is no reason for ranger to not try to fold the statement and
see if we get a better result for it. It
https://gcc.gnu.org/g:7b3ac57852052822e3845bcd8d50b83d7724dfde
commit r15-82-g7b3ac57852052822e3845bcd8d50b83d7724dfde
Author: Andrew MacLeod
Date: Tue Feb 13 10:07:11 2024 -0500
Remove incorrect asserts.
Gimple_range_op handles builtin functions, and a couple of asserts that
https://gcc.gnu.org/g:0ade358cd72ffa591dd2f1404765b379bbf709d4
commit r15-80-g0ade358cd72ffa591dd2f1404765b379bbf709d4
Author: Andrew MacLeod
Date: Wed Mar 13 14:13:28 2024 -0400
Invoke range_of_stmt on ssa_names with no context.
Evalaute ssa-names when range_of_expr is called
https://gcc.gnu.org/g:39fe620963b29e7bdc8dcfa2037490df26b4edf2
commit r15-81-g39fe620963b29e7bdc8dcfa2037490df26b4edf2
Author: Andrew MacLeod
Date: Wed Mar 13 14:18:48 2024 -0400
Add range_on_entry/exit to value_query API.
Add range_on_entry and range_on_exit to the value_query
This came up during stage 4 when someone noticed a comment that said
when legacy EVRP was removed, the wrapper around accessing
SSA_NAME_RANGES for initial values could be removed.
To be clearer, the original discussion is here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html
https://gcc.gnu.org/g:e8ae56a7dc46e39a48017bb5159e4dc672ec7fad
commit r15-79-ge8ae56a7dc46e39a48017bb5159e4dc672ec7fad
Author: Andrew MacLeod
Date: Wed Mar 13 14:10:41 2024 -0400
Fix ranger when called from SCEV.
Do not pre-evaluate PHIs in the cache, and allow fill_block_cache
https://gcc.gnu.org/g:56aa8ad7cd91fbc42123f1190d3238e293020085
commit r15-78-g56aa8ad7cd91fbc42123f1190d3238e293020085
Author: Andrew MacLeod
Date: Tue Feb 20 12:27:51 2024 -0500
Remove wrapper around gimple_range_global.
Now that legacy EVRP has been removed, we can remove the
Hi,
On Thu, Apr 25 2024, Jakub Jelinek wrote:
> On Thu, Apr 25, 2024 at 02:34:22PM +0200, Martin Jambor wrote:
>> when looking at a package build issue with GCC 14, Michal Jireš noted a
>> different behavior of pragma GCC Target. This snippet tries to describe
>> the gist of the problem. I have
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::is_nothrow_invocable.
OK after addressing comments on other traits.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_nothrow_invocable.
* constraint.cc (diagnose_trait_expr): Handle
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::rank.
__rank seems too short, maybe __array_rank?
Actually, it occurs to me that perhaps we should have been adding
__builtin to all of these rather than just __ and the library trait
name. I guess it's too
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::decay.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __decay.
* semantics.cc (finish_trait_type): Handle CPTK_DECAY.
gcc/testsuite/ChangeLog:
* g++.dg/ext/has-builtin-1.C: Test
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::add_rvalue_reference.
gcc/cp/ChangeLog:
* cp-trait.def: Define __add_rvalue_reference.
* semantics.cc (finish_trait_type): Handle
CPTK_ADD_RVALUE_REFERENCE.
gcc/testsuite/ChangeLog:
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::add_lvalue_reference.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __add_lvalue_reference.
* semantics.cc (finish_trait_type): Handle
CPTK_ADD_LVALUE_REFERENCE.
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::remove_extent.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __remove_extent.
* semantics.cc (finish_trait_type): Handle CPTK_REMOVE_EXTENT.
gcc/testsuite/ChangeLog:
*
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::remove_all_extents.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __remove_all_extents.
* semantics.cc (finish_trait_type): Handle
CPTK_REMOVE_ALL_EXTENTS.
gcc/testsuite/ChangeLog:
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::add_pointer.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __add_pointer.
* semantics.cc (finish_trait_type): Handle CPTK_ADD_POINTER.
gcc/testsuite/ChangeLog:
*
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::is_unbounded_array.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_unbounded_array.
* constraint.cc (diagnose_trait_expr): Handle
CPTK_IS_UNBOUNDED_ARRAY.
* semantics.cc
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::is_pointer.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_pointer.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_POINTER.
* semantics.cc (trait_expr_value): Likewise.
On Tue, Apr 30, 2024 at 1:50 PM Jason Merrill wrote:
>
> On 3/15/24 01:15, Ken Matsui wrote:
> > Added diagnostics for build_invoke.
> >
> > Ok for 15?
>
> Thanks, just a few tweaks needed. Will you have time to make them? Or
> Patrick?
I believe I will have time later next week. Thank you so
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::is_volatile.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_volatile.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_VOLATILE.
* semantics.cc (trait_expr_value): Likewise.
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::is_const.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_const.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_CONST.
* semantics.cc (trait_expr_value): Likewise.
On 3/15/24 01:15, Ken Matsui wrote:
Added diagnostics for build_invoke.
Ok for 15?
Thanks, just a few tweaks needed. Will you have time to make them? Or
Patrick?
[...]
diff --git a/gcc/cp/method.cc b/gcc/cp/method.cc
index 98c10e6a8b5..2282ce71c06 100644
--- a/gcc/cp/method.cc
+++
1 - 100 of 374 matches
Mail list logo
