Hi
I'm trying to format my code in GCC style.
But I don't know how to finish it. I try `indent` and
`check_GNU_style.sh` in the `contrib` directory. But none of them seem
to work well.
So I wondered is there any official tools to do that?
Thanks
Hanke Zhang
Hi Harald,
This patch is verging on 'obvious', . once one sees it :-)
Yes, it's good for mainline and all active branches, when available.
Thanks
Paul
PS The fall-out pr114874 is so peculiar that I am dropping everything to
find the source.
On Mon, 29 Apr 2024 at 19:39, Harald Anlauf
LAST_UPDATED: Tue Apr 30 04:10:17 UTC 2024 (revision r15-57-g22b20ac6c6a)
Native configuration is i686-pc-linux-gnu
=== gcc tests ===
Running target unix
UNRESOLVED: gcc.c-torture/compile/2009-1.c -O0
UNRESOLVED: gcc.c-torture/compile/2009-1.c -O1
UNRESOLVED:
git commit g:22b20ac6c6aead2d3f36c413a77dd0b80adfec39
gcc-descr r15-57-g22b20ac6c6aead
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: Tue Apr 30 04:09:55 UTC 2024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114893
Bug ID: 114893
Summary: -Wanalyzer-null-dereference false positive in Emacs
select_window
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
git commit g:bb78099d2624b52c781ed6e5d85e43d54c3cda1a
gcc-descr r12-10403-gbb78099d2624b5
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: Tue Apr 30 04:05:49 UTC 2024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114892
--- Comment #1 from Andrew Pinski ---
I should note I found this while helping a junior engineer and we went looking
for the documentation and it was not there for it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114892
Bug ID: 114892
Summary: folding and others dump options are not documented
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
git commit g:22b20ac6c6aead2d3f36c413a77dd0b80adfec39
gcc-descr r15-57-g22b20ac6c6aead
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: Tue Apr 30
LAST_UPDATED: Tue Apr 30 01:35:09 UTC 2024 (revision r14-10149-g3c925ac349b)
Native configuration is i686-pc-linux-gnu
=== gcc tests ===
Running target unix
UNRESOLVED: gcc.c-torture/compile/2009-1.c -O0
UNRESOLVED: gcc.c-torture/compile/2009-1.c -O1
UNRESOLVED:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891
--- Comment #1 from Andrew Pinski ---
So a C++23 library header (generator) is using a C++20 feature
(is_pointer_interconvertible_base_of_v) ...
Especially since GCC 14.1.0 will most likely be released with this header and
14.2.0 won't come
git commit g:22b20ac6c6aead2d3f36c413a77dd0b80adfec39
gcc-descr r15-57-g22b20ac6c6aead
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: Tue Apr 30 02:33:35 UTC 2024
LAST_UPDATED: Tue Apr 30 01:25:07 UTC 2024 (revision r15-56-g3900e944b0a)
Native configuration is i686-pc-linux-gnu
=== gcc tests ===
Running target unix
UNRESOLVED: gcc.c-torture/compile/2009-1.c -O0
UNRESOLVED: gcc.c-torture/compile/2009-1.c -O1
UNRESOLVED:
git commit g:88f22217521564e1a956e14ac55456caa160e055
gcc-descr r13-8661-g88f22217521564
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: Tue Apr 30 02:38:56 UTC 2024
LAST_UPDATED: Mon Apr 29 17:05:18 UTC 2024 (revision r15-51-g050a4f7fc5c)
=== acats tests ===
FAIL: cb1010a
=== acats Summary ===
# of expected passes2327
# of unexpected failures1
Native configuration is s390x-ibm-linux-gnu arch14
git commit g:88f22217521564e1a956e14ac55456caa160e055
gcc-descr r13-8661-g88f22217521564
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: Tue Apr 30 02:13:22 UTC 2024
# From https://ci.linaro.org/job/tcwg_gcc_check--master-arm-build/2040/:
LAST_UPDATED: 2024-04-30T03:09:41+00:00 (master revision
gcc-15-57-g22b20ac6c6a) armv8l-unknown-linux-gnueabihf
Native configuration is armv8l-unknown-linux-gnueabihf
=== libatomic tests ===
Running
git commit g:bb78099d2624b52c781ed6e5d85e43d54c3cda1a
gcc-descr r12-10403-gbb78099d2624b5
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: Tue Apr 30
git commit g:42d2e2f57e943c0f79940729d1ef1945388499de
gcc-descr r15-55-g42d2e2f57e943c
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: Tue Apr 30 01:07:01 UTC 2024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891
Bug ID: 114891
Summary: Unconditional use of
std::is_pointer_interconvertible_base_of_v in
makes the header unusable with Clang 18
Product: gcc
Version: 15.0
Add an "AC_CONFIG_MACRO_DIRS" call in configure.ac, with the same
directories as specified in "ACLOCAL_AMFLAGS", in Makefile.in.
This makes it possible to re-generate aclocal.m4 using "autoreconf".
---
fixincludes/configure| 1 +
fixincludes/configure.ac | 1 +
2 files changed, 2
git commit g:88f22217521564e1a956e14ac55456caa160e055
gcc-descr r13-8661-g88f22217521564
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: Tue Apr 30 01:12:56 UTC 2024
git commit g:a44b37044dd66de6d4b32fc067b3053a352e421d
gcc-descr r13-8660-ga44b37044dd66d
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: Tue Apr 30
5035
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 15.0.0 20240429
(experimental) [remotes/origin/HEAD r15-54-g93a9c40ea9] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test
XPASS: gfortra
I get a diff when running "autoreconf" in this directory. I think that
the current state is erroneous: it appears to have been generated using
aclocal -I ../config -I ..
even though configure.ac and Makefile.am list the include flag in the
reverse order:
aclocal -I .. -I ../config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114873
--- Comment #5 from Halalaluyafail3 ---
(In reply to Joseph S. Myers from comment #4)
> These are not meant to be valid C (although the relevant requirement isn't a
> Constraint, so a diagnostic isn't required); see the discussion in DR#341.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114889
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |14.2
https://gcc.gnu.org/g:22b20ac6c6aead2d3f36c413a77dd0b80adfec39
commit r15-57-g22b20ac6c6aead2d3f36c413a77dd0b80adfec39
Author: Patrick Palka
Date: Mon Apr 29 21:27:59 2024 -0400
c++/modules: imported spec befriending class tmpl [PR114889]
When adding to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114889
--- Comment #1 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:22b20ac6c6aead2d3f36c413a77dd0b80adfec39
commit r15-57-g22b20ac6c6aead2d3f36c413a77dd0b80adfec39
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888
--- Comment #8 from GCC Commits ---
The releases/gcc-14 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:3c925ac349b03ae9439c632fb1c042cdc8d78f40
commit r14-10149-g3c925ac349b03ae9439c632fb1c042cdc8d78f40
Author: Patrick Palka
https://gcc.gnu.org/g:3c925ac349b03ae9439c632fb1c042cdc8d78f40
commit r14-10149-g3c925ac349b03ae9439c632fb1c042cdc8d78f40
Author: Patrick Palka
Date: Mon Apr 29 21:14:18 2024 -0400
c++: ICE with templated sizeof(E1) / sizeof(E2) [PR114888]
In the sizeof / sizeof operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
Pushed to r13-8661.
在 2024/4/29 下午4:09, Lulu Cheng 写道:
From: Yang Yujie
On LoongArch, the regitsters $r4 - $r7 (EH_RETURN_DATA_REGNO) will be saved
and restored in the function prologue and epilogue if the given function calls
__builtin_eh_return. This causes the return value to be
https://gcc.gnu.org/g:3900e944b0ac9db77380c5bb8635977dfd3b0691
commit r15-56-g3900e944b0ac9db77380c5bb8635977dfd3b0691
Author: Patrick Palka
Date: Mon Apr 29 21:14:18 2024 -0400
c++: ICE with templated sizeof(E1) / sizeof(E2) [PR114888]
In the sizeof / sizeof operator expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888
--- Comment #7 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:3900e944b0ac9db77380c5bb8635977dfd3b0691
commit r15-56-g3900e944b0ac9db77380c5bb8635977dfd3b0691
Author: Patrick Palka
Date:
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 20240429
(experimental) [remotes/origin/HEAD r15-54-g93a9c40ea97] (G
https://gcc.gnu.org/g:88f22217521564e1a956e14ac55456caa160e055
commit r13-8661-g88f22217521564e1a956e14ac55456caa160e055
Author: Yang Yujie
Date: Fri Dec 8 18:01:18 2023 +0800
LoongArch: Fix eh_return epilogue for normal returns.
On LoongArch, the regitsters $r4 - $r7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848
--- Comment #7 from GCC Commits ---
The releases/gcc-13 branch has been updated by LuluCheng
:
https://gcc.gnu.org/g:88f22217521564e1a956e14ac55456caa160e055
commit r13-8661-g88f22217521564e1a956e14ac55456caa160e055
Author: Yang Yujie
Date:
Pushed to r12-10403.
在 2024/4/29 下午4:09, Lulu Cheng 写道:
From: Yang Yujie
On LoongArch, the regitsters $r4 - $r7 (EH_RETURN_DATA_REGNO) will be saved
and restored in the function prologue and epilogue if the given function calls
__builtin_eh_return. This causes the return value to be
https://gcc.gnu.org/g:bb78099d2624b52c781ed6e5d85e43d54c3cda1a
commit r12-10403-gbb78099d2624b52c781ed6e5d85e43d54c3cda1a
Author: Yang Yujie
Date: Fri Dec 8 18:01:18 2023 +0800
LoongArch: Fix eh_return epilogue for normal returns.
On LoongArch, the regitsters $r4 - $r7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848
--- Comment #6 from GCC Commits ---
The releases/gcc-12 branch has been updated by LuluCheng
:
https://gcc.gnu.org/g:bb78099d2624b52c781ed6e5d85e43d54c3cda1a
commit r12-10403-gbb78099d2624b52c781ed6e5d85e43d54c3cda1a
Author: Yang Yujie
Date:
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 20240429
(experimental) [remotes/origin/HEAD r15-54-g93a9c40ea9] (GCC)
=== gfortran tests ===
> So how about this. I'll ack this for the trunk, but not for gcc-14 (at
> this time). We can revisit for gcc-14 after it's been on the trunk a
> bit. Realistically that likely means gcc-14.2 at the end of the summer
> rather than gcc-14.1 which is due in roughly a week.
Thanks Jeff, I will
5241
# of unsupported tests 23201
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xg++ version 15.0.0 20240429
(experimental) [master r15-54-g93a9c40ea9] (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=114883
--- Comment #10 from Hongtao Liu ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 58073 [details]
> gcc14-pr114883.patch
>
> Full untested patch.
This will fix 521.wrf_r ICE, and pass runtime validation.
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
On 4/29/24 00:11, Jakub Jelinek wrote:
Hi!
The following patch implements the P0609R3 paper; we build the
VAR_DECLs for the structured binding identifiers early, so all we need
IMHO is just to parse the attributed identifier list and pass the attributes
to the VAR_DECL creation.
The paper
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 20240429
[releases/gcc-1
LAST_UPDATED: Sat Apr 27 21:35:46 UTC 2024 (revision r15-11-g140124ad54e)
Native configuration is powerpc-ibm-aix7.2.5.0
=== g++ tests ===
Running target unix
FAIL: g++.dg/compat/eh/new1 cp_compat_x_tst.o-cp_compat_y_tst.o execute
XPASS: g++.dg/debug/pr46583.C -gdwarf-2 -g1
On Mon, Apr 29, 2024 at 4:26 PM Lucier, Bradley J via Gcc
wrote:
>
> The question: How to interpret scheduling info with the compiler listed below.
>
> Specifically, a tight loop that was reported to be scheduled in 23 cycles (as
> I understand it) actually executes in a little over 2 cycles per
https://gcc.gnu.org/g:93a9c40ea9764773f0288e5b7ba2d8399e670f2c
commit r15-54-g93a9c40ea9764773f0288e5b7ba2d8399e670f2c
Author: Alexandre Oliva
Date: Mon Apr 29 20:33:37 2024 -0300
Revert "decay vect tests from run to link for pr95401"
This reverts commit
That should be 4 cycles per loop, sorry.
> On Apr 29, 2024, at 7:24 PM, Lucier, Bradley J wrote:
>
> Specifically, a tight loop that was reported to be scheduled in 23 cycles (as
> I understand it) actually executes in a little over 2 cycles per loop
On Apr 22, 2024, Richard Biener wrote:
>> Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with
>> gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
> That makes sense. OK
>> for gcc/testsuite/ChangeLog
>>
>> * lib/target-supports.exp
The question: How to interpret scheduling info with the compiler listed below.
Specifically, a tight loop that was reported to be scheduled in 23 cycles (as I
understand it) actually executes in a little over 2 cycles per loop, as I
interpret two separate experiments.
Am I misinterpreting
On Apr 29, 2024, "Kewen.Lin" wrote:
> Thanks for catching this and sorry
> that I didn't check it before suggesting it, I think we can aggressively
> drop this effective target instead to avoid any possible confusion.
The 128-bit ones, unfortunately, follow the same pattern but are
probably
This patch solves another ICE-after-error problem in the C family
front-ends. Upon a conflicting type redeclaration, the ambiguous
type is poisoned with an error_mark_node to indicate to the middle-end
that the type is suspect, but care has to be taken by the front-end to
avoid passing these
On 4/29/24 02:34, Nathaniel Shead wrote:
On Fri, Apr 26, 2024 at 09:16:40PM -0400, Jason Merrill wrote:
On 4/19/24 09:29, Nathaniel Shead wrote:
On Fri, Apr 19, 2024 at 12:14:06PM +1000, Nathaniel Shead wrote:
On Wed, Apr 17, 2024 at 02:02:21PM -0400, Patrick Palka wrote:
On Mon, 15 Apr
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
5035
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 15.0.0 20240429
(experimental) [remotes/origin/HEAD r15-53-ga05efc8bf5] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test
XPASS: gfortra
On 4/29/24 06:50, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14 (I guess after 14.1 is released)?
OK for both.
-- >8 --
We need to look through TEMPLATE_DECL like make_friend_class does when
adding to CLASSTYPE_BEFRIENDING_CLASSES.
Otherwise
On 4/29/24 07:52, Marek Polacek wrote:
On Mon, Apr 29, 2024 at 10:28:19AM -0400, Patrick Palka wrote:
Lightly tested on x86_64-pc-linux-gnu so far, does this look OK for
trunk/14.1 after bootstrap+regtest finishes?
LGTM.
Yes, OK.
-- >8 --
We're missing a dependence check for the second
On Thu, 25 Apr 2024, Jakub Jelinek wrote:
> Hi!
>
> While the C23 standard isn't officially release yet,
> in 2011 we've changed __STDC_VERSION__ value for C11 already
> in the month in which the new __STDC_VERSION__ value has been
> finalized, so we want to change this now or wait
> until we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874
Paul Thomas changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114873
--- Comment #4 from Joseph S. Myers ---
These are not meant to be valid C (although the relevant requirement isn't a
Constraint, so a diagnostic isn't required); see the discussion in DR#341.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114869
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114869
Joseph S. Myers changed:
What|Removed |Added
Last reconfirmed||2024-04-29
CC|
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 20240429
(experimental) [remotes/origin/HEAD r15-53-ga05efc8bf5] (GCC)
=== gfortran tests ===
5241
# of unsupported tests 23201
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xg++ version 15.0.0 20240429
(experimental) [master r15-53-ga05efc8bf5] (GCC)
=== gcc tests ===
Running target unix/-m32
XPASS: gcc.dg/guality/example.c -O0 execution test
On Wed, 24 Apr 2024, Krishna Narayanan via Gcc wrote:
> Hi all,
> Is the RISC-V community planning to add support for trapping math in RISC-V
> in the near future!?
> This LLVM thread
> https://discourse.llvm.org/t/trapping-math-for-risc-v/72168/7 suggests a
> software emulation of traps, is the
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 20240429
(experimental) [remotes/origin/HEAD r15-53-ga05efc8bf5e] (G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874
--- Comment #2 from anlauf at gcc dot gnu.org ---
The dump-fortran-original shows the following difference between 13 and 14:
@@ -58,7 +58,7 @@
code:
ASSIGN p:c 'abc'
- BLOCK
+ SELECT TYPE
symtree: '__tmp_CHARACTER_0_1'||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
--- Comment #7 from Antonio Rojas ---
(In reply to Sam James from comment #5)
> Some ideas:
> * Could you maybe give a reproducer for the runtime crash?
In sage, calling any libgap function in exactly 3 parameters triggers this. For
instance:
5035
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 15.0.0 20240429
(experimental) [remotes/origin/HEAD r15-51-g050a4f7fc5] (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/g:bf1ef45735e94247fe632602ee4dda091a5fd2bf
commit bf1ef45735e94247fe632602ee4dda091a5fd2bf
Author: Ondřej Machota
Date: Mon Apr 29 21:38:47 2024 +0200
rtl-ssa: Create new dce pass
Diff:
---
gcc/dce.cc | 41 +
gcc/dce.h
/nightly/build-gcc-13/gcc/xg++ version 13.2.1 20240429
[releases/gcc-13 r13-8659-g129b64b0c2] (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
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 20240429
(experimental) [remotes/origin/HEAD r15-51-g050a4f7fc5] (GCC)
=== gfortran tests ===
es ompexp
"__atomic_fetch_add" 1
FAIL: c-c++-common/gomp/atomic-9.c -std=gnu++14 scan-tree-dump-times ompexp
"__atomic_fetch_add" 1
FAIL: c-c++-common/gomp/atomic-9.c -std=gnu++17 scan-tree-dump-times ompexp
"__atomic_fetch_add" 1
FAIL: c-c++-common/gomp/atomic-9.c -std=
Regressions on master at commit r15-51 vs commit r15-46 on Linux/x86_64
New failures:
FAIL: libgomp.c/../libgomp.c-c++-common/for-14.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/for-15.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/for-9.c execution test
New passes:
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
--- Comment #9 from Jakub Jelinek ---
Created attachment 58073
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58073=edit
gcc14-pr114883.patch
Full untested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106813
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
This libgo patch, by Rainer Orth, dumps register values on Solaris on
a crash. This fixes GC PR 106813. Bootstrapped and ran Go testsuite
on x86_64-pc-linux-gnu. Committed to mainline.
Ian
a05efc8bf5ed329ea7d9b1740c326bdc6b04e37a
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
https://gcc.gnu.org/g:a05efc8bf5ed329ea7d9b1740c326bdc6b04e37a
commit r15-53-ga05efc8bf5ed329ea7d9b1740c326bdc6b04e37a
Author: Ian Lance Taylor
Date: Sun Apr 28 13:30:39 2024 -0700
runtime: dump registers on Solaris
Patch by Rainer Orth .
Fixes PR go/106813
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106813
--- Comment #3 from GCC Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:a05efc8bf5ed329ea7d9b1740c326bdc6b04e37a
commit r15-53-ga05efc8bf5ed329ea7d9b1740c326bdc6b04e37a
Author: Ian Lance Taylor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827
--- Comment #11 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2024-April/060464.html
htly/build-gcc-13/gcc/xgcc version 13.2.1 20240429
[releases/gcc-13 r13-8659-g129b64b0c2] (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
Dear all,
the attached patch fixes issues with assignments of unlimited polymorphic
entities that were found with the help of valgrind or asan, see PR. Looking
further into it, it turns out that allocation sizes as well as array spans
could be set incorrectly, leading to wrong results or heap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114875
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Mon, 29 Apr 2024, Jakub Jelinek wrote:
> On Mon, Apr 29, 2024 at 01:44:24PM +, Joseph Myers wrote:
> > > glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is
> > > a
> > > dummy shared library with just some symbol versions for compatibility, but
> > > all the
This libgo patch changes runtime/runtime.h to use the C99
header file rather than defining a bool type and true/false constants
itself. C99 was a long time ago and in case this file is always
compiled by the newly built GCC. This should fix GCC PR 114875.
Bootstrapped on x86_64-pc-linux-gnu.
https://gcc.gnu.org/g:678dc5e85053f1a1ca76997eec95ba8823bb6830
commit r15-52-g678dc5e85053f1a1ca76997eec95ba8823bb6830
Author: Ian Lance Taylor
Date: Sun Apr 28 09:57:35 2024 -0700
runtime: use
has been available since C99. Use it rather than defining
our own boolean type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
--- Comment #8 from Jakub Jelinek ---
Just changing the min in the testcase to max results on ICE with IFN_COND_MAX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
--- Comment #7 from Jakub Jelinek ---
Slightly more reduced testcase:
subroutine pr114883(a, b, c, d, e, f, g, h, o)
real(8) :: c(1011), d(1011), e(0:1011)
real(8) :: p, q, f, r, g(1011), h(1011), b, bar
integer :: o(100), a, t, u
p =
f expected failures 1550
# of unsupported tests 3992
/home/gccbuild/build/nightly/build-gcc-13/gcc/xgcc version 13.2.1 20240429
[releases/gcc-13 r13-8659-g129b64b0c2] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
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 20240429
(experimental) [remotes/origin/HEAD r15-51-g050a4f7fc5c] (G
5241
# of unsupported tests 23201
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xg++ version 15.0.0 20240429
(experimental) [master r15-51-g050a4f7fc5] (GCC)
=== gcc tests ===
Running target unix/-m32
XPASS: gcc.dg/guality/example.c -O0 execution test
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 20240429
[relea
1 - 100 of 261 matches
Mail list logo
