https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
--- Comment #10 from Richard Biener ---
(In reply to Jakub Jelinek from comment #9)
> Do you really need to hash it on TYPE_CANON, rather than just on whether the
> type is
> TYPE_STRUCTURAL_EQUALITY_P or not?
It's enough for the testcases
5235
# of unsupported tests 23211
/home/gccbuild/build/nightly/build-gcc-trunk/gcc/xg++ version 15.0.0 20240503
(experimental) [master r15-124-g87e35da16d] (GCC)
=== gcc tests ===
Running target unix/-m32
XPASS: gcc.dg/guality/example.c -O0 execution test
https://gcc.gnu.org/g:7117e1f6bf6de25c1ff26c4d7abcc79b407ca221
commit r15-125-g7117e1f6bf6de25c1ff26c4d7abcc79b407ca221
Author: Jakub Jelinek
Date: Fri May 3 09:44:30 2024 +0200
tree-inline: Add __builtin_stack_{save,restore} pair about inline calls
with calls to alloca [PR113596]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #12 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7117e1f6bf6de25c1ff26c4d7abcc79b407ca221
commit r15-125-g7117e1f6bf6de25c1ff26c4d7abcc79b407ca221
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
--- Comment #9 from Jakub Jelinek ---
Do you really need to hash it on TYPE_CANON, rather than just on whether the
type is
TYPE_STRUCTURAL_EQUALITY_P or not?
I'm worried that always computing the TYPE_CANON before calling type_hash_canon
is
9]+, q[0-9]+ 6
FAIL: gcc.target/arm/simd/mve-vshr.c scan-assembler-times
vshl.s[0-9]+tq[0-9]+, q[0-9]+ 3
FAIL: gcc.target/arm/simd/mve-vshr.c scan-assembler-times
vshl.u[0-9]+tq[0-9]+, q[0-9]+ 3
=== gcc Summary ===
# of expected passes180760
# of unexpected f
On Fri, 3 May 2024, Jakub Jelinek wrote:
> Hi!
>
> The following patch adds save_NNN = __builtin_stack_save (); ...
> __builtin_stack_restore (save_NNN);
> pair around inline calls which call alloca (alloca calls because of
> VLA vars are ignored in that decision).
> The patch doesn't change
https://gcc.gnu.org/g:fa7e05d90bb672b58424ddbe37a05a0fd0949b35
commit r14-10159-gfa7e05d90bb672b58424ddbe37a05a0fd0949b35
Author: Richard Biener
Date: Thu May 2 13:55:15 2024 +0200
tree-optimization/114921 - _Float16 -> __bf16 isn't noop
The vectorizer handles a _Float16 to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114921
--- Comment #3 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:fa7e05d90bb672b58424ddbe37a05a0fd0949b35
commit r14-10159-gfa7e05d90bb672b58424ddbe37a05a0fd0949b35
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
--- Comment #8 from Richard Biener ---
So a real fix might look like the following (requiring changes in all other
type builders to first set/compute the canonical type of course).
diff --git a/gcc/tree.cc b/gcc/tree.cc
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
--- Comment #6 from Richard Biener ---
When we build the pointer type there's already
(gdb) p to_type
$18 =
(gdb) p to_type->type_common.canonical
$15 =
(gdb) p to_type->type_common.canonical->type_common.canonical
$17 =
the interesting
Hi!
The following patch adds save_NNN = __builtin_stack_save (); ...
__builtin_stack_restore (save_NNN);
pair around inline calls which call alloca (alloca calls because of
VLA vars are ignored in that decision).
The patch doesn't change anything on whether we try to inline such calls or
not, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114932
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
150378
# 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 20240503
[releases/gcc-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #5 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114930
Richard Biener changed:
What|Removed |Added
Keywords||ice-checking,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114932
--- Comment #1 from Richard Biener ---
The change likely made SCEV/IVOPTs "stop" at more convenient places, but we can
only know when there's more detailed analysis.
On Fri, 3 May 2024, Richard Ball wrote:
> Hi,
>
> Requesting permission to backport:
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=24cf1f600b8ad34c68a51f48884e72d01f729893
> to gcc-13 in order to fix:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111882
>
> Applies cleanly and with no
https://gcc.gnu.org/g:87e35da16df74cd1c4729a55d94e7bc592487f48
commit r15-124-g87e35da16df74cd1c4729a55d94e7bc592487f48
Author: Richard Biener
Date: Thu May 2 13:55:15 2024 +0200
tree-optimization/114921 - _Float16 -> __bf16 isn't noop
The vectorizer handles a _Float16 to __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114921
--- Comment #2 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:87e35da16df74cd1c4729a55d94e7bc592487f48
commit r15-124-g87e35da16df74cd1c4729a55d94e7bc592487f48
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114924
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.5
Keywords|
On Thu, 2 May 2024, Alex Coplan wrote:
> Hi,
>
> The PR shows that when cfgrtl.cc:duplicate_insn_chain attempts to
> update the MR_DEPENDENCE_CLIQUE information for a MEM_EXPR we can end up
> accidentally dropping (e.g.) an ARRAY_REF from the MEM_EXPR and end up
> replacing it with the
failures 3852
# of unsupported tests 20896
/home/gccbuild/build/nightly/build-gcc-12/gcc/xg++ version 12.3.1 20240503
[remotes/origin/releases/gcc-12 r12-10411-gbf995b10e8] (GCC)
=== gcc tests ===
Running target unix/-m32
XPASS: gcc.dg/uninit-pred-7_a.c bogus
301 - 324 of 324 matches
Mail list logo
