c version 14.0.0 20231222 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113119
--- Comment #2 from Zdenek Sojka ---
Created attachment 56925
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56925=edit
slightly less reduced testcase, ICEing elsewhere
The original testcase was ICEing at a different place, as does this
On Friday, December 22nd, 2023 at 10:26 AM, Jason Merrill
wrote:
>
>
> On 12/22/23 04:01, waffl3x wrote:
>
> > int n = 0;
> > auto f = [](this Self){
> > static_assert(__is_same (decltype(n), int));
> > decltype((n)) a; // { dg-error {is not captured} }
> > };
> > f();
> >
> > Could you
Hi,
This patch will cause the following tests to fail: +FAIL:
gcc.dg/vect/pr97081-2.c (internal compiler error: in extract_insn, at
recog.cc:2812) +FAIL: gcc.dg/vect/pr97081-2.c (test for excess errors)
+FAIL: gcc.dg/vect/pr97081-2.c -flto -ffat-lto-objects (internal
compiler error: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #4 from Andrew Pinski ---
Hmm, see PR 32398 and PR 32769. PR 32769 is interesting because it was caused
by the merge of the df branch where the store was being removed just like here
on cris.
Oh and reading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085
--- Comment #2 from seurer at gcc dot gnu.org ---
Looks like it is 65,536
seurer@ltcden2-lp1:~/gcc/git/build/gcc-test$ getconf PAGESIZE
65536
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467
Saifi Khan changed:
What|Removed |Added
CC||saifi.khan at nishan dot io
--- Comment
Hi Juzhe,
Sorry but I'm not quite familiar with the group_overlap framework. Could you
take this pattern as an example to show how to disable an alternative in some
target?
Joshua
--
发件人：juzhe.zh...@rivai.ai
发送时间：2023年12月22日(星期五)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112883
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113109
--- Comment #3 from Hans-Peter Nilsson ---
It's __builtin_eh_return( that's miscompiled, such that the "handler" isn't
installed and the calling function will return to its caller instead of the
handler.
For the example below:
void
在 2023/12/23 上午10:26, chenglulu 写道:
在 2023/12/22 下午3:21, chenglulu 写道:
在 2023/12/22 下午3:09, Xi Ruoyao 写道:
On Fri, 2023-12-22 at 11:44 +0800, chenglulu wrote:
在 2023/12/21 下午8:00, chenglulu 写道:
Sorry, I've been busy with something else these two days. I don't
think there's anything wrong
在 2023/12/22 下午3:21, chenglulu 写道:
在 2023/12/22 下午3:09, Xi Ruoyao 写道:
On Fri, 2023-12-22 at 11:44 +0800, chenglulu wrote:
在 2023/12/21 下午8:00, chenglulu 写道:
Sorry, I've been busy with something else these two days. I don't
think there's anything wrong with the code,
but I need to test the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #25 from jiawei ---
I had run SPEC2017-v1.1.9 with rv64gcv_zvl256b, it passed the compile and run
on base and validate cases, used qemu 8.1.0.
LGTM!
Thanks!
在 2023/12/17 下午11:16, Xi Ruoyao 写道:
Remove a redundant sign extension.
gcc/ChangeLog:
* config/loongarch/loongarch.md (rotrsi3_extend): New
define_insn.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/rotrw.c: New test.
---
Bootstrapped and regtested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113112
--- Comment #1 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:290230034092898981488d0716ddae43bd36c09f
commit r14-6810-g290230034092898981488d0716ddae43bd36c09f
Author: Juzhe-Zhong
Date: Sat Dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #24 from JuzheZhong ---
CC jiawei who run SPEC for me. Maybe you can help him to reproduce such issue
then I can debug it from his feedback.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #23 from JuzheZhong ---
(In reply to palmer from comment #22)
> (In reply to JuzheZhong from comment #19)
> > (In reply to Vineet Gupta from comment #18)
> > > (In reply to JuzheZhong from comment #17)
> > > > PLCT told me they
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
palmer at gcc dot gnu.org changed:
What|Removed |Added
CC||palmer at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #21 from JuzheZhong ---
Btw, I saw there are 2 more FAILs:
FAIL: gcc.dg/vect/tsvc/vect-tsvc-s1115.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/tsvc/vect-tsvc-s1115.c execution test
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #20 from JuzheZhong ---
I am not able to build and test SPEC since I don't have QEMU and SPEC
environment.
I should ask my colleague to do that but they are quite busy with company's
things and frankly I can't pull more resource on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #19 from JuzheZhong ---
(In reply to Vineet Gupta from comment #18)
> (In reply to JuzheZhong from comment #17)
> > PLCT told me they passed with zvl256b.
> >
> > I always run SPEC with FIXED-VLMAX since we always care about peak
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #18 from Vineet Gupta ---
(In reply to JuzheZhong from comment #17)
> PLCT told me they passed with zvl256b.
>
> I always run SPEC with FIXED-VLMAX since we always care about peak
> performance
> on our board.
Sure we all have our
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #17 from JuzheZhong ---
PLCT told me they passed with zvl256b.
I always run SPEC with FIXED-VLMAX since we always care about peak performance
on our board.
Committed. Thanks Jeff.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-12-23 00:58
To: Juzhe-Zhong; gcc-patches
CC: kito.cheng; kito.cheng; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Make PHI initial value occupy live V_REG in
dynamic LMUL cost model analysis
On 12/22/23 02:51, Juzhe-Zhong
Consider this following case:
foo:
ble a0,zero,.L11
lui a2,%hi(.LANCHOR0)
addisp,sp,-128
addia2,a2,%lo(.LANCHOR0)
mv a1,a0
vsetvli a6,zero,e32,m8,ta,ma
vid.v v8
vs8r.v v8,0(sp) ---> spill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #16 from Vineet Gupta ---
(In reply to JuzheZhong from comment #15)
> Currently, we don't have much run FAIL and ICE left in full coverage testing.
>
> I suspect it is very corner case in SPEC.
>
> You don't have to debug it. Just
Snapshot gcc-12-20231222 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20231222/
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/bugzilla/show_bug.cgi?id=113087
--- Comment #15 from JuzheZhong ---
Currently, we don't have much run FAIL and ICE left in full coverage testing.
I suspect it is very corner case in SPEC.
You don't have to debug it. Just need to give me a preprocessed source file.
Like
On Fri, Dec 22, 2023 at 1:54 PM Olavi Esker via Gcc wrote:
>
> Hello,
>
> #include
> #include
>
> int main()
> {
> std::int8_t myInt{65};
> myInt += 1;
> std::cout << myInt;
> }
>
> Guess what this returns?
> Character "B".
>
> int main()
> {
> std::int8_t myInt{};
> std::cin >> myInt;
>
Hello,
#include
#include
int main()
{
std::int8_t myInt{65};
myInt += 1;
std::cout << myInt;
}
Guess what this returns?
Character "B".
int main()
{
std::int8_t myInt{};
std::cin >> myInt;
std::cout << myInt;
}
This will also read a character, and
print the characters ascii value.
So if I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113117
Patrick Palka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53499
Patrick Palka changed:
What|Removed |Added
CC||armagvvg at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #14 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #13)
> (In reply to JuzheZhong from comment #12)
> > (In reply to Patrick O'Neill from comment #11)
> > > (In reply to Patrick O'Neill from comment #10)
> > > > I've
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113119
--- Comment #1 from Jakub Jelinek ---
Without the second redundant __builtin_add_overflow, we get
a.0_1 = a;
_7 = .ADD_OVERFLOW (a.0_1, 0);
_2 = REALPART_EXPR <_7>;
_3 = IMAGPART_EXPR <_7>;
_4 = (_Bool) _3;
c = _4;
_5 =
Some spiders are hitting bugzilla hard generating dependency trees
or graphs, downloading large attachements or requesting all bugs
in xml format. Disallow all that.
---
htdocs/robots.txt | 4
1 file changed, 4 insertions(+)
diff --git a/htdocs/robots.txt b/htdocs/robots.txt
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86072
Phosit changed:
What|Removed |Added
CC||phosit at autistici dot org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment
RVV requires VSET?VL? instructions to dynamically configure VLEN at
runtime. There's a custom pass to do that which has a simple mode
which generates a VSETVL for each V insn and a lazy/optimal mode which
uses LCM dataflow to move VSETVL around, identify/delete the redundant
ones.
Currently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113118
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to work||14.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113118
--- Comment #2 from Bálint Aradi ---
Last note: replacing the problematic line with
allocate(item)
item%item = derived_type(name=name, val=val)
seems to compile (but I did not check, whether the compiled code behaves
correctly).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113118
--- Comment #1 from Bálint Aradi ---
Just a further note, if I leave away dummy argument names, I do not get an ICE
any more, but the program still does not compile:
24 | item = base_type_item(derived_type(name, val))
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113083
--- Comment #4 from Marek Polacek ---
The problem occurs only when we declone cdtors and are on a
targetm.cxx.cdtor_returns_this target like ARM.
Decloning causes us to create a thunk calling the "main" ctor:
A*
A::A (A *const this)
{
64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231222 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #10 from Jakub Jelinek ---
(In reply to Florian Weimer from comment #8)
> (In reply to Jakub Jelinek from comment #3)
> > Seems the package's configure is affected by most likely the modern C
> > changes,
> > I see
> > ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #9 from Jakub Jelinek ---
Seems in *.reload we have:
(insn 5 4 6 2 (set (reg/v/f:SI 4 si [orig:504 Im ] [504])
(mem/f/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 540 [0x21c])) [3 Im+0 S4 A32]))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113118
Bug ID: 113118
Summary: ICE on assignment of derived types with allocatable
class component
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100861
Andrew Pinski changed:
What|Removed |Added
CC||fchelnokov at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113113
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #7 from Jakub Jelinek ---
With -g0 in addition the assembly difference is
--- hc2cf2_16.s12023-12-22 13:14:14.0 -0500
+++ hc2cf2_16.s22023-12-22 13:14:06.0 -0500
@@ -16,7 +16,6 @@ hc2cf2_16:
.LCFI4:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #6 from Jakub Jelinek ---
Created attachment 56923
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56923=edit
hc2cf2_16.i.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #5 from Jakub Jelinek ---
$ /opt/notnfs/gcc-bisect/obj/gcc/cc1.r14-6209 -quiet -nostdinc -O3 -m32
-march=znver2 -ggdb3 hc2cf2_16.i -o hc2cf2_16.s1
$ /opt/notnfs/gcc-bisect/obj/gcc/cc1.r14-6210 -quiet -nostdinc -O3 -m32
-march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113117
--- Comment #2 from Vyacheslav Grigoryev ---
Looks so, checking on https://godbolt.org/z/vb6s6cY6Y. Hm... wasting a time on
filling the bug :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113117
Andrew Pinski changed:
What|Removed |Added
Keywords||accepts-invalid,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113117
Bug ID: 113117
Summary: ambiguous call during operator overloading is not
detected for templates
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #4 from Jakub Jelinek ---
Bisection points to hc2cf2_16.o.
On 12/22/23 04:01, waffl3x wrote:
int n = 0;
auto f = [](this Self){
static_assert(__is_same (decltype(n), int));
decltype((n)) a; // { dg-error {is not captured} }
};
f();
Could you clarify if this error being removed was intentional. I do
recall that Patrick Palka
On 12/22/23 01:07, juzhe.zh...@rivai.ai wrote:
You mean theadvector doesn't want the current RVV1.0 register overlap
magic as follows ?
*
The destination EEW is smaller than the source EEW and the overlap
is in the lowest-numbered part of the source register group (e.g.,
On 12/22/23 02:51, Juzhe-Zhong wrote:
Consider this following case:
foo:
ble a0,zero,.L11
lui a2,%hi(.LANCHOR0)
addisp,sp,-128
addia2,a2,%lo(.LANCHOR0)
mv a1,a0
vsetvli a6,zero,e32,m8,ta,ma
vid.v v8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114
Andrew Pinski changed:
What|Removed |Added
Keywords|needs-bisection |
Summary|ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
Jakub Jelinek changed:
What|Removed |Added
CC||fweimer at redhat dot com
--- Comment
On Thu, 21 Dec 2023, Martin Uecker wrote:
> This version now sets DECL_NONADDRESSABLE_P, DECL_PADDING_P
> and C_DECL_VARIABLE_SIZE and adds three new tests:
> c23-tag-alias-7.c, c23-tag-composite-10.c, and
> gnu23-tag-composite-5.c.
This version is OK.
--
Joseph S. Myers
> Am 22.12.2023 um 16:05 schrieb Di Zhao OS :
>
> Updated the fix in attachment.
>
> Is it OK for trunk?
Ok
> Tested on aarch64-unknown-linux-gnu and x86_64-pc-linux-gnu.
>
> Thanks,
> Di Zhao
>
>> -Original Message-
>> From: Di Zhao OS
>> Sent: Sunday, December 17, 2023 8:31 PM
Hi.
This patch adds the support of the sizeof operator.
I was wondering if this new API entrypoint should take a location as a
parameter. What do you think?
Thanks for the review.
From e86e00efae450f04bc92ae6e4e61cf92c38d9b7d Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Tue, 19 Sep 2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113116
Filip Kastl changed:
What|Removed |Added
Blocks||26163
--- Comment #1 from Filip Kastl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113116
Bug ID: 113116
Summary: ~11-17% exec time regression of 436.cactusADM on
aarch64
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization,
Updated the fix in attachment.
Is it OK for trunk?
Tested on aarch64-unknown-linux-gnu and x86_64-pc-linux-gnu.
Thanks,
Di Zhao
> -Original Message-
> From: Di Zhao OS
> Sent: Sunday, December 17, 2023 8:31 PM
> To: Thomas Schwinge ; gcc-patches@gcc.gnu.org
> Cc: Richard Biener
>
Hi.
This patch adds missing builtins needed by optimizations.
Thanks for the review.
From 5ef20748a140d3384294a4218e6db7420cef692d Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Tue, 3 Jan 2023 15:04:41 -0500
Subject: [PATCH] libgccjit: Add missing builtins needed by optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061
Wilco changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #16 from Wilco ---
Fixed by
v3: rebased to latest trunk
Cleanup memset implementation. Similar to memcpy/memmove, use an offset and
bytes throughout. Simplify the complex calculations when optimizing for size
by using a fixed limit.
Passes regress & bootstrap.
gcc/ChangeLog:
* config/aarch64/aarch64.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113115
Bug ID: 113115
Summary: ICE In extract_constrain_insn_cached recog.cc with
ppc64le-linux-gnu crosscompiler
Product: gcc
Version: 14.0
Status: UNCONFIRMED
From: Daniil Frolov
PR 66487 is asking to provide sanitizer-like detection for C++ object
lifetime violations that are worked around with -fno-lifetime-dse or
-flifetime-dse=1 in Firefox, LLVM (PR 106943), OpenJade (PR 69534).
The discussion in the PR was centered around extending MSan, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #2 from Sam James ---
(In reply to Jakub Jelinek from comment #1)
> Any progress with the bisection?
sorry, not yet. I've been away from the computer mostly for an emergency.
I did make a start, but I got frustrated with how the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114
Bug ID: 113114
Summary: ICE in try_promote_writeback aarch64-ldp-fusion.cc
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, needs-bisection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113113
Bug ID: 113113
Summary: False -Wmismatched-new-delete in case of destroying
operator delete
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758
--- Comment #17 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:cefae511ed7fa34ef6d24b67a7bc305459bf10e8
commit r14-6806-gcefae511ed7fa34ef6d24b67a7bc305459bf10e8
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112941
--- Comment #12 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0a6aa1927597d821a85bc3d1fd7682256c25b548
commit r14-6805-g0a6aa1927597d821a85bc3d1fd7682256c25b548
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113102
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f5198f0264e773d3b5d55f09a579313b0b231527
commit r14-6804-gf5198f0264e773d3b5d55f09a579313b0b231527
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113102
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d3defa435e9d04d6ab6585ac184989941c7ad51e
commit r14-6803-gd3defa435e9d04d6ab6585ac184989941c7ad51e
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005
--- Comment #10 from Jakub Jelinek ---
For the distro builds the log files are all I have (all logs in
https://koji.fedoraproject.org/koji/taskinfo?taskID=110644223 )
For what I can reproduce on my box (rwlock_1.exe built in the
> Bootstrapped/regtested on x86_64-linux and i686-linux (neither of which
> is WORD_REGISTER_OPERATIONS target), tested on the testcase using
> cross to riscv64-linux but don't have an easy access to a
> WORD_REGISTER_OPERATIONS target to bootstrap/regtest it there.
>
> Ok for trunk?
Yes, thanks
Yeah.
(define_insn "@pred_msbc"
[(set (match_operand: 0 "register_operand""=vr, vr, ")
(unspec:
[(minus:VI
(match_operand:VI 1 "register_operand" " 0, vr, vr")
(match_operand:VI 2 "register_operand" " vr, 0, vr"))
(match_operand: 3
Hi Juzhe,
What xtheadvector needs to handle is just that destination vector register
cannot overlap source vector register group for instructions like vmadc/vmsbc.
That is not what group_overlap means. We nned to add "&" to the registers in
the corresponding xtheadvector patterns while rvv 1.0
This patch resolves the second part of PR target/112992, building upon
Hongtao Liu's solution to the first part.
The issue addressed by this patch is that when initializing vectors by
broadcasting integer constants, the compiler has the flexibility to
select the most appropriate vector mode to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113110
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
---
This patch resolves the failure of pr43644-2.c in the testsuite, a code
quality test I added back in July, that started failing as the code GCC
generates for 128-bit values (and their parameter passing) has been in
flux. After a few attempts at tweaking pattern constraints in the hope
of
> Am 22.12.2023 um 09:26 schrieb Jakub Jelinek :
>
> Hi!
>
> Large/huge _BitInt types are returned in memory and the bitint lowering
> pass right now relies on that.
> The gimplification etc. use aggregate_value_p to see if it should be
> returned in memory or not and use
> = _123;
>
> Am 22.12.2023 um 09:17 schrieb Jakub Jelinek :
>
> Hi!
>
> On the following testcase earlier passes leave around an unreleased
> SSA_NAME - non-GIMPLE_NOP SSA_NAME_DEF_STMT which isn't in any bb.
> The following patch makes bitint lowering resistent against those,
> the first hunk is where
> Am 22.12.2023 um 09:12 schrieb Jakub Jelinek :
>
> Hi!
>
> My recent change to use m_data[save_data_cnt] instead of
> m_data[save_data_cnt + 1] when inside of a loop (m_bb is non-NULL)
> broke the following testcase. When we create a PHI node on the loop
> using prepare_data_in_out, both
This patch removes the testsuite_tr1.h dependency from g++.dg/ext/is_*.C
tests since the header is supposed to be used only by libstdc++, not
front-end. This also includes test code consistency fixes.
For the record this fixes the test failures reported at
Pushed to r14-6800.
在 2023/12/5 下午2:44, chenxiaolong 写道:
gcc/ChangeLog:
* doc/extend.texi:Add modifiers to the vector of asm in the doc.
* doc/md.texi:Refine the description of the modifier 'f' in the doc.
---
gcc/doc/extend.texi | 47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005
--- Comment #9 from Lipeng Zhu ---
Since I still can't reproduce the failure on my side :(, just curious, will the
new added 'rwlock' test cases failed on mutex lock?
On Thu, Dec 21, 2023 at 11:38 AM Jason Merrill wrote:
>
> On 12/21/23 10:52, Patrick Palka wrote:
> > On Thu, Dec 21, 2023 at 8:29 AM Patrick Palka wrote:
> >>
> >> On Wed, 20 Dec 2023, Ken Matsui wrote:
> >>
> >>> This patch removes the testsuite_tr1.h dependency from g++.dg/ext/is_*.C
> >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110389
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
Consider this following case:
foo:
ble a0,zero,.L11
lui a2,%hi(.LANCHOR0)
addisp,sp,-128
addia2,a2,%lo(.LANCHOR0)
mv a1,a0
vsetvli a6,zero,e32,m8,ta,ma
vid.v v8
vs8r.v v8,0(sp) ---> spill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #1 from Jakub Jelinek ---
Any progress with the bisection?
Or at least details what exactly are you compiling (with what patches etc.)?
Hm, this is weird, as it really seems to depend on the
-march= So if there is really a difference
between those structs which make them incompatible on
some archs, we should not consider them to be
compatible in general.
struct g { int a[n]; int b; } *y;
{ struct g { int a[4]; int b; } *y2
These two options are negative alias of -m[no-]strict-align.
This matches LLVM implmentation.
gcc/ChangeLog:
* config/riscv/riscv.opt: Add option alias.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/predef-align-10.c: New test.
* gcc.target/riscv/predef-align-7.c: New test.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113112
Bug ID: 113112
Summary: RISC-V: Dynamic LMUL feature stabilization for GCC-14
release
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
1 - 100 of 113 matches
Mail list logo
