Hello,
On Fri, Apr 05 2024, PRANIL DEY wrote:
> Hello GCC Community,
> I am Pranil Dey and I had submitted a proposal for the project "Improve
> nothrow detection in GCC", but as the deadline period was a holiday time I
> wanted to ask you to review my proposal now.
> I am already getting
Hello,
On Fri, Apr 05 2024, Vedant5432 via Gcc wrote:
> Hello,
> I am a potential contributor for GSoC 2024, I made a submission for the
> project Extend the Static Analysis Pass, I was wondering about the process
> of ranking the proposals and the general timelines when the applicants will
> be
Snapshot gcc-12-20240412 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20240412/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/g:d97e784f9887aece6d857e5790ea931ea6e044ee
commit d97e784f9887aece6d857e5790ea931ea6e044ee
Author: Michael Meissner
Date: Fri Apr 12 03:25:09 2024 -0400
Revert all changes
Diff:
---
gcc/config/rs6000/rs6000.md | 44
1 file
Hi!
While translation of the verifier messages is questionable, that case is
something that ideally should never happen except to gcc developers
and so pressumably English should be fine, we use error etc. APIs and
those imply translatations and some translators translate it.
The following patch
EFT Payment - See attachment.
Regards,
Accounts team
p: 07 3622 3988 | f: 07 3622 3889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114130
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Hi,
This patch implemented optab_finite for SF/DF/TFmode by rs6000 test
data class instructions.
This patch relies on former patch which adds optab_finite.
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html
Bootstrapped and tested on powerpc64-linux BE and LE with no
htly/build-gcc-13/gcc/xgcc version 13.2.1 20240412
[releases/gcc-13 r13-8600-g54a235e636] (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
Hi,
This patch adds an optab for __builtin_isnormal. The normal check can be
implemented on rs6000 by a single instruction. It needs an optab to be
expanded to the certain sequence of instructions.
The subsequent patches will implement the expand on rs6000.
Bootstrapped and tested on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #25 from Richard Biener ---
I think it's more interesting why
* 119: [r216:SI (2 MEM[(struct Vec128 *)_179]+0 S4 A64)] =
{r0:SI..r3:SI}
isn't considered as dependence? Why does the earlier insn even come into
play? What's the
Regressions on native/releases/gcc-13 at commit r13-8600 vs commit r13-8595 on
Linux/x86_64
New failures:
FAIL: gcc.dg/vect/vect-bic-bitmask-10.c -flto -ffat-lto-objects (test for
excess errors)
FAIL: gcc.dg/vect/vect-bic-bitmask-11.c -flto -ffat-lto-objects (test for
excess errors)
FAIL:
LAST_UPDATED: Fri Apr 12 04:40:04 UTC 2024 (revision r13-8600-g54a235e6363)
Native configuration is x86_64-pc-linux-gnu
=== gcc tests ===
Running target unix
FAIL: gcc.dg/analyzer/data-model-4.c (test for excess errors)
FAIL: gcc.dg/analyzer/torture/conftest-1.c -O0 (test
On Fri, 12 Apr 2024, haochen.jiang wrote:
> On Linux/x86_64,
>
> c7e8a8d814229fd6fc4c16c2452f15dddc613479 is the first bad commit
> commit c7e8a8d814229fd6fc4c16c2452f15dddc613479
> Author: Richard Biener
> Date: Thu Apr 11 11:08:07 2024 +0200
>
> tree-optimization/109596 - wrong debug
From: Pan Li
This patch would like to fix one ICE when vector is not enabled
in hook TARGET_FUNCTION_VALUE_REGNO_P implementation. The vector
regno is available if and only if the TARGET_VECTOR is true. The
previous implement missed this condition and then result in ICE
when rv64gc build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
Xi Ruoyao changed:
What|Removed |Added
Summary|Front-end optimization |Front-end optimization
https://gcc.gnu.org/g:70490d46340627347654fe28f885a8c8577583c1
commit 70490d46340627347654fe28f885a8c8577583c1
Author: Michael Meissner
Date: Fri Apr 12 03:29:58 2024 -0400
Simplify converting between SImode and SF/DFmode.
2024-04-12 Michael Meissner
gcc/
https://gcc.gnu.org/g:6ae9d9f24734d61f20bc06a96cecd6c02f77d5d7
commit 6ae9d9f24734d61f20bc06a96cecd6c02f77d5d7
Author: Michael Meissner
Date: Fri Apr 12 03:30:47 2024 -0400
Update ChangeLog.*
Diff:
---
gcc/ChangeLog.bugs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Thu, 11 Apr 2024, Thomas Schwinge wrote:
> Hi Chung-Lin, Richard!
>
> From me just a few mechanical pieces, see below. Richard, are you able
> to again comment on Chung-Lin's general strategy, as I'm not at all
> familiar with those parts of the code?
I've queued all stage1 material and
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Friday, April 12, 2024 2:11 PM
To: Li, Pan2 ; gcc-patches
Cc: kito.cheng ; Li, Pan2
Subject: Re: [PATCH v1] RISC-V: Bugfix ICE non-vector in
TARGET_FUNCTION_VALUE_REGNO_P
LGTM。
https://gcc.gnu.org/g:dc51a6428f6d8e5a57b8b1bf559145288e87660b
commit r14-9930-gdc51a6428f6d8e5a57b8b1bf559145288e87660b
Author: Pan Li
Date: Fri Apr 12 11:12:24 2024 +0800
RISC-V: Bugfix ICE non-vector in TARGET_FUNCTION_VALUE_REGNO_P
This patch would like to fix one ICE when
Hi,
This patch folds builtin_isfinite on IBM long double to builtin_isfinite on
double type. The former patch
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649346.html
implemented the DFmode isfinite_optab.
Bootstrapped and tested on powerpc64-linux BE and LE with no
regressions. Is it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #11 from lin1.hu at intel dot com ---
(In reply to Richard Biener from comment #9)
> That that GCC doesn't promise that -ftrapv preserves all overflows and
> traps, it merely guarantees that all overflows that actually happen trap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #12 from Hu Lin ---
(In reply to Hu Lin from comment #11)
> (In reply to Richard Biener from comment #9)
> > That that GCC doesn't promise that -ftrapv preserves all overflows and
> > traps, it merely guarantees that all overflows
https://gcc.gnu.org/g:b6c8259076a336e8082853ed6dda083c25a465d0
commit r14-9931-gb6c8259076a336e8082853ed6dda083c25a465d0
Author: Stefan Schulze Frielinghaus
Date: Fri Apr 12 09:20:53 2024 +0200
testsuite: Fix loop-interchange-16.c
Prevent loop unrolling of the innermost loop
On Fri, Apr 12, 2024 at 1:25 AM Andrew Pinski (QUIC)
wrote:
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Thursday, April 11, 2024 2:31 AM
> > To: Andrew Pinski (QUIC)
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] match: Fix `!a?b:c` and `a?~t:t` patterns for
2079
# of unexpected failures170
# of unexpected successes 14
# of expected failures 1468
# of unsupported tests 3885
/home/gccbuild/build/nightly/build-gcc-12/gcc/xgcc version 12.3.1 20240412
[remotes/origin/releases/gcc-12 r12-10320-ge0173fbd38] (GCC)
5241
# of unsupported tests 23143
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xg++ version 14.0.1 20240412
(experimental) [master r14-9930-gdc51a6428f] (GCC)
=== gcc tests ===
Running target unix/-m32
XPASS: gcc.dg/guality/example.c -O0 execution test
On Fri, 12 Apr 2024, haochen.jiang wrote:
> On Linux/x86_64,
>
> c7e8a8d814229fd6fc4c16c2452f15dddc613479 is the first bad commit
> commit c7e8a8d814229fd6fc4c16c2452f15dddc613479
> Author: Richard Biener
> Date: Thu Apr 11 11:08:07 2024 +0200
>
> tree-optimization/109596 - wrong debug
On Thu 2024-04-11 20:51:55, Thomas Schwinge wrote:
> Hi!
>
> On 2024-04-11T19:52:51+0200, Martin Jambor wrote:
> > contrib/check-params-in-docs.py is a script that checks that all
> > options reported with ./gcc/xgcc -Bgcc --help=param are in
> > gcc/doc/invoke.texi and vice versa.
>
> Eh,
Hi!
On 2024-04-12T09:08:13+0200, Filip Kastl wrote:
> On Thu 2024-04-11 20:51:55, Thomas Schwinge wrote:
>> On 2024-04-11T19:52:51+0200, Martin Jambor wrote:
>> > contrib/check-params-in-docs.py is a script that checks that all
>> > options reported with ./gcc/xgcc -Bgcc --help=param are in
>>
Hi!
The tree-cfg.cc verifier only diagnoses returns_twice calls preceded
by non-label/debug stmts if it is in a bb with abnormal predecessor.
The following testcase shows that if a user lies in the attributes
(a function which never returns can't be pure, and can't return
twice when it doesn't
https://gcc.gnu.org/g:e30e760b51b108786946e04a26e92531762b022d
commit r14-9932-ge30e760b51b108786946e04a26e92531762b022d
Author: Filip Kastl
Date: Fri Apr 12 09:52:27 2024 +0200
contrib/check-params-in-docs.py: Ignore target-specific params
contrib/check-params-in-docs.py is a
LGTM。
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-12 14:08
To: gcc-patches
CC: juzhe.zhong; kito.cheng; Pan Li
Subject: [PATCH v1] RISC-V: Bugfix ICE non-vector in
TARGET_FUNCTION_VALUE_REGNO_P
From: Pan Li
This patch would like to fix one ICE when vector is not enabled
in hook
Hi Chung-Lin!
On 2024-04-11T22:08:47+0800, Chung-Lin Tang wrote:
> On 2024/3/15 7:24 PM, Thomas Schwinge wrote:
>> - if (n->refcount != REFCOUNT_INFINITY)
>> + if (n->refcount != REFCOUNT_INFINITY
>> + && n->refcount != REFCOUNT_ACC_MAP_DATA)
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #13 from Xi Ruoyao ---
And IIRC there are various suggestion saying "if you want -fwrapv, you are
likely actually wanting -fsanitize=signed-integer-overflow" and some plan
deprecating -fwrapv. So it's more important to fix the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114701
Bug ID: 114701
Summary: Missed optimization of loop invariant
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On Fri, Apr 12, 2024 at 6:53 AM Andrew Pinski wrote:
>
> The problem is `!a?b:c` pattern will create a COND_EXPR with an 1bit signed
> integer
> which breaks patterns like `a?~t:t`. This rejects when we have a signed
> operand for
> both patterns.
>
> Note for GCC 15, I am going to look at the
d failures270
# of expected failures 1763
# of unsupported tests 4169
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/bin/aarch64-linux-gnu-gcc
version 14.0.1 20240412 (experimental) [master revision
gcc-14-9929-gd1a21a6f947] (GCC)
Host is
EFT Payment - See attachment.
Regards,
Accounts team
p: 07 3622 3988 | f: 07 3622 3889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114130
--- Comment #5 from GCC Commits ---
The releases/gcc-11 branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:cb68221c59e8f98e107bb5842d319bee3a66b8dc
commit r11-11317-gcb68221c59e8f98e107bb5842d319bee3a66b8dc
Author: Kito Cheng
https://gcc.gnu.org/g:cb68221c59e8f98e107bb5842d319bee3a66b8dc
commit r11-11317-gcb68221c59e8f98e107bb5842d319bee3a66b8dc
Author: Kito Cheng
Date: Wed Feb 28 16:01:52 2024 +0800
RISC-V: Fix __atomic_compare_exchange with 32 bit value on RV64
atomic_compare_and_swapsi will use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #14 from Hu Lin ---
Created attachment 57933
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57933=edit
Untested fix.
https://gcc.gnu.org/g:c9e94ae448ba309dba74de3ee1974a3ed9248889
commit r14-9933-gc9e94ae448ba309dba74de3ee1974a3ed9248889
Author: Jakub Jelinek
Date: Fri Apr 12 10:59:54 2024 +0200
Limit special asan/ubsan/bitint returns_twice handling to calls in bbs with
abnormal pred [PR114687]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114687
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c9e94ae448ba309dba74de3ee1974a3ed9248889
commit r14-9933-gc9e94ae448ba309dba74de3ee1974a3ed9248889
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #24 from Tamar Christina ---
(In reply to Richard Biener from comment #23)
> Maybe easier to understand testcase:
>
> with -O3 -msse4.1 -fno-vect-cost-model we return 20 instead of 8. Adding
> -fdisable-tree-cunroll avoids the
Hi All,
This is a story all about how the peeling for gaps introduces a bug in the upper
bounds.
Before I go further, I'll first explain how I understand this to work for loops
with a single exit.
When peeling for gaps we peel N < VF iterations to scalar.
This happens by removing N iterations
1527
# of unsupported tests 3477
/export/gnu/import/git/gcc-test-release-1-ia32/bld/gcc/xgcc version 13.2.1
20240412 [releases/gcc-13-ia32 r13-8600-g54a235e6363] (GCC)
=== gfortran tests ===
Running target unix
=== gfortran Summary ===
# of expected passes
Hi,
On Fri, Apr 12 2024, Filip Kastl wrote:
> On Thu 2024-04-11 20:51:55, Thomas Schwinge wrote:
>> Hi!
>>
>> On 2024-04-11T19:52:51+0200, Martin Jambor wrote:
>> > contrib/check-params-in-docs.py is a script that checks that all
>> > options reported with ./gcc/xgcc -Bgcc --help=param are in
Does FP reg also need gurared with TARGET_HARD_FLOAT? could you try to
compile that case without F?
On Fri, Apr 12, 2024 at 2:19 PM Li, Pan2 wrote:
>
> Committed, thanks Juzhe.
>
>
>
> Pan
>
>
>
> From: juzhe.zh...@rivai.ai
> Sent: Friday, April 12, 2024 2:11 PM
> To: Li, Pan2 ; gcc-patches
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114695
--- Comment #3 from Vincent Piquet ---
Interesting. Now I think the issue may actually be caused by pack expansion on
the call site. The issue also happens when Foo only has one base class, albeit
with a different error that at least has
https://gcc.gnu.org/g:076f07ddf9d7a348da1459a81a14eaf7d7c256a5
commit r12-10321-g076f07ddf9d7a348da1459a81a14eaf7d7c256a5
Author: Iain Sandoe
Date: Mon May 2 19:42:49 2022 +0100
Objective-C, NeXT: Adjust symbol marking to match host tools.
Current host tools mark some additional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114689
--- Comment #2 from Andreas Schwab ---
Nevertheless it's better for clarity to parentize >> inside |.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
https://gcc.gnu.org/g:6e7e5943619a2c20d93fc7089c885483786558bc
commit r14-9936-g6e7e5943619a2c20d93fc7089c885483786558bc
Author: Pan Li
Date: Fri Apr 12 16:38:18 2024 +0800
RISC-V: Fix Werror=sign-compare in riscv_validate_vector_type
This patch would like to fix the
From: Pan Li
This patch would like to fix the Werror=sign-compare similar to below:
gcc/config/riscv/riscv.cc: In function ‘void
riscv_validate_vector_type(const_tree, const char*)’:
gcc/config/riscv/riscv.cc:5614:23: error: comparison of integer
expressions of different signedness: ‘int’ and
3425
=== gcc Summary ===
# of expected passes602046
# of unexpected failures339
# of unexpected successes 60
# of expected failures 4653
# of unresolved testcases 2
# of unsupported tests 10789
/export/project/git/gcc-test-master-
Regressions on master at commit r14-9929 vs commit r14-9909 on Linux/x86_64
New failures:
FAIL: gcc.dg/guality/pr43051-1.c -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions -DPREVENT_OPTIMIZATION line 34 c ==
[0]
FAIL: gcc.dg/guality/pr43051-1.c -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114701
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-04-12
of unsupported tests 4232
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240412
(experimental) [remotes/origin/HEAD r14-9930-gdc51a6428f6] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2.f90
As mentioned in PR114678 those failures will be fixed by
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648303.html
For GCC 14 just xfail them which should be reverted once the patch is
applied.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/range-sincos.c: Xfail for s390.
*
3492
/export/gnu/import/git/gcc-test-release-1-ia32/bld/gcc/xgcc version 13.2.1
20240412 [releases/gcc-13 r13-8600-g54a235e6363] (GCC)
=== gfortran tests ===
Running target unix
=== gfortran Summary ===
# of expected passes68120
# of expected fail
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gcc-wwwdocs".
The branch, master has been updated
via 033976162ed4745f7f808f14ba62b1c055e35d16 (commit)
from
Hi all,
When I am checking GCC14 documentation, I found that MCore forgot to uncomment
the title for their part, which caused the documentation is mixed with x86.
Uncomment that and commit as obvious.
Thx,
Haochen
---
htdocs/gcc-14/changes.html | 2 +-
1 file changed, 1 insertion(+), 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114689
--- Comment #3 from Jakub Jelinek ---
But guess that won't shut up cppcheck, I'd think it wants | (!!sticky) instead
of
| !!sticky. Haven't tried though.
Gentle ping. If this looks good, can someone commit to main (I don't have
commit privileges). This is also something that could be considered for stable,
since it's been around for many years.
-Ian
From: McInerney, Ian S
Sent: Thursday, April 4, 2024 4:16 PM
To: fort...@gcc.gnu.org ;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #28 from Richard Biener ---
(In reply to Richard Earnshaw from comment #27)
> (In reply to Richard Earnshaw from comment #26)
> > (In reply to Richard Biener from comment #25)
> > > I think it's more interesting why
> > >
> > > *
Alex Coplan writes:
> This is a v2 because I accidentally sent a WIP version of the patch last
> time round which used replace_equiv_address instead of
> replace_equiv_address_nv; that caused some ICEs (pointed out by the
> Linaro CI) since pair addressing modes aren't a subset of the addresses
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #27 from Richard Biener ---
I think that adjusting an existing upper bound by -1 because of gap peeling
is wrong when that upper bound may not apply to the IV exit. Because gap
peeling only affects the IV exit test and not the
https://gcc.gnu.org/g:3bd3ca05b519b99b5ea570c10fd80737cd4c6c49
commit r14-9937-g3bd3ca05b519b99b5ea570c10fd80737cd4c6c49
Author: Ian McInerney
Date: Thu Apr 4 16:16:32 2024 +0100
libgfortran: Fix compilation of gf_vsnprintf
The fallback function (gf_vsnprintf) to provide a
> Gentle ping. If this looks good, can someone commit to main (I don't have
> commit privileges). This is also something that could be considered for
> stable, since it's been around for many years.
Thanks for the patch. Pushed as
> Am 12.04.2024 um 09:58 schrieb Jakub Jelinek :
>
> Hi!
>
> While translation of the verifier messages is questionable, that case is
> something that ideally should never happen except to gcc developers
> and so pressumably English should be fine, we use error etc. APIs and
> those imply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114678
--- Comment #5 from Stefan Schulze Frielinghaus
---
Ok, done in https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649367.html
https://gcc.gnu.org/g:67e1433a94f8ca82e2c36b79af44256430c73c38
commit r14-9935-g67e1433a94f8ca82e2c36b79af44256430c73c38
Author: Stefan Schulze Frielinghaus
Date: Fri Apr 12 11:06:24 2024 +0200
analyzer: Bail out on function pointer for -Wanalyzer-allocation-size
On s390
5241
# of unsupported tests 23143
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xg++ version 14.0.1 20240412
(experimental) [master r14-9932-ge30e760b51] (GCC)
=== gcc tests ===
Running target unix/-m32
XPASS: gcc.dg/guality/example.c -O0 execution test
of unsupported tests 4232
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240412
(experimental) [remotes/origin/HEAD r14-9932-ge30e760b51b] (GCC)
=== gfortran tests ===
Running target unix
XPASS: gfortran.dg/large_real_kind_form_io_2.f90
Sure thing, the FP_RETURN only acts on ABI_xxx similar to below:
#define FP_RETURN (UNITS_PER_FP_ARG == 0 ? GP_RETURN : FP_ARG_FIRST)
I add some test for rv32/64imac option but don't cover all test cases without
f/d extension, will have a try and keep you posted.
Pan
-Original
5241
# of unsupported tests 23143
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xg++ version 14.0.1 20240412
(experimental) [master r14-9935-g67e1433a94] (GCC)
=== gcc tests ===
Running target unix/-m32
XPASS: gcc.dg/guality/example.c -O0 execution test
s147357
# of unexpected failures38
# of unexpected successes 4
# of expected failures 916
# of unresolved testcases 2
# of unsupported tests 2763
/home/gccbuild/build/nightly/build-gcc-11/gcc/xgcc version 11.4.1 20240412
[releases/gcc-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114696
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
# of expected passes178370
# of unexpected failures128
# of unexpected successes 13
# of expected failures 1595
# of unsupported tests 5017
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240412
(experimental) [remote
Hi,
This patch implemented optab_isnormal for SF/DF/TFmode by rs6000 test
data class instructions.
This patch relies on former patch which adds optab_isnormal.
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649366.html
Bootstrapped and tested on powerpc64-linux BE and LE with no
This is a v2 because I accidentally sent a WIP version of the patch last
time round which used replace_equiv_address instead of
replace_equiv_address_nv; that caused some ICEs (pointed out by the
Linaro CI) since pair addressing modes aren't a subset of the addresses
that are accepted by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114689
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
> Am 12.04.2024 um 09:50 schrieb Jakub Jelinek :
>
> Hi!
>
> The tree-cfg.cc verifier only diagnoses returns_twice calls preceded
> by non-label/debug stmts if it is in a bb with abnormal predecessor.
> The following testcase shows that if a user lies in the attributes
> (a function which
On Fri, 12 Apr 2024, Haochen Jiang wrote:
> Uncomment that and commit as obvious.
Thank you!
Gerald
1
/opt/gcc/gcc-20240412/Build/./gcc/gccgo version 14.0.1 20240412 (experimental)
[master r14-9929-gd1a21a6f9474e5] (GCC)
=== libgomp tests ===
Running target unix/-mabi=lp64
=== libgomp Summary ===
# of expected passes16264
# of expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103496
--- Comment #4 from Tobias Burnus ---
(In reply to anlauf from comment #3)
> The code in comment#0 compiles at r14-9893-gded646c91d2c0f
> and gives the indicated results.
which is the commit:
Fortran: fix argument checking of intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #26 from Richard Earnshaw ---
(In reply to Richard Biener from comment #25)
> I think it's more interesting why
>
> * 119: [r216:SI (2 MEM[(struct Vec128 *)_179]+0 S4 A64)] =
> {r0:SI..r3:SI}
>
> isn't considered as dependence?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #27 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #26)
> (In reply to Richard Biener from comment #25)
> > I think it's more interesting why
> >
> > * 119: [r216:SI (2 MEM[(struct Vec128 *)_179]+0 S4 A64)] =
Regressions on releases/gcc-13 at commit r13-8600 vs commit r13-8595 on
Linux/i686
New failures:
FAIL: ctestzstd
New passes:
https://gcc.gnu.org/g:8c6f13d2cc1884921e7c532e03786f0344bededd
commit r14-9934-g8c6f13d2cc1884921e7c532e03786f0344bededd
Author: Jakub Jelinek
Date: Fri Apr 12 11:00:43 2024 +0200
tree-cfg: Make the verifier returns_twice message translatable
While translation of the verifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114687
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14 Regression] ICE: in |[13 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114695
--- Comment #4 from Vincent Piquet ---
Note that MSVC latest now also fails this last sample regardless of the
language version (but the error differs from C++17 to C++20). Clang (>= 5.0.0)
still happily accepts it, on both versions.
# of expected passes178362
# of unexpected failures128
# of unexpected successes 13
# of expected failures 1595
# of unsupported tests 5017
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xgcc version 14.0.1 20240412
(experimental) [remote
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #11 from Jakub Jelinek ---
Actually I had another look.
Jason said in the c++: fix in-charge parm in constexpr mail back in December
(as well as in the r14-6507 commit message):
"Since a class with vbases can't have constexpr 'tors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #23 from Richard Biener ---
Maybe easier to understand testcase:
long x[9];
long a[20];
struct { long x; long b[40]; } b;
int __attribute__((noipa))
foo (int n)
{
int i = 0;
int k = 0;
do
{
if (x[k++]) // early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #16 from Jakub Jelinek ---
(In reply to Hu Lin from comment #11)
> I think it doesn't mean that's not a bug with -ftrapv, it should preserve
> all overflow traps. Because it doesn't work, we use -fsanitize=undefined
> instead of it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #26 from Tamar Christina ---
(In reply to Richard Biener from comment #25)
> That means, when the loop takes the early exit we _must_ take that during
> the vector iterations. Peeling for gaps means if we would take the early
>
1 - 100 of 334 matches
Mail list logo
