https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #21 from Levi Zim ---
(In reply to Sam James from comment #18)
> (In reply to Levi Zim from comment #17)
> > (In reply to Sam James from comment #16)
> > > (In reply to Levi Zim from comment #15)
> > >
> > > As long as the flag is p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #20 from Levi Zim ---
I have minified it to the following commands:
git -C gcc checkout 1cd744a6828f6ab9179906d16434ea40b6404737
mkdir gcc-build && cd $_
export CFLAGS="-march=rv64gc -mabi=lp64d -O2 -Wp,-D_FORTIFY_SOURCE=3 -g
-ffil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #19 from Levi Zim ---
Another trigger flag, a little surprisingly, is
-ffile-prefix-map=/build/gcc/src=/usr/src/debug/gcc in CFLAGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #17 from Levi Zim ---
(In reply to Sam James from comment #16)
> (In reply to Levi Zim from comment #15)
>
> As long as the flag is passed correctly and applied to both the stage2 +
> stage3 builds, then the flag can't be to blame (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #15 from Levi Zim ---
(In reply to Sam James from comment #14)
> Thanks. Please try to reproduce it manually next.
If I didn't revert that commit, then bisection of the CFLAGS shows that
-Wp,-D_FORTIFY_SOURCE=3 is what causes the bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #13 from Levi Zim ---
Our full gcc 14.2.1+r753+g1cd744a6828f toolchain could bootstrap with
3228df20cfa3581015dc32657eb17d6f24af3104 reverted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #12 from Levi Zim ---
The bad commit is 3228df20cfa3581015dc32657eb17d6f24af3104 "rtl: Remove invalid
compare simplification" [PR117186]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #11 from Levi Zim ---
When building 14.2.1+r711+g3228df20cfa3, I got a different object that is
different between stage 2 and 3:
Comparing stages 2 and 3
Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #10 from Levi Zim ---
Sometimes I didn't get the comparison failure but a hard ICE instead:
*** stack smashing detected ***: terminated
during RTL pass: combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #9 from Levi Zim ---
(In reply to Sam James from comment #8)
> Thanks. First, try strip out various bits from the packaging like
> STAGE1_*FLAGS (which is only really safe if you're 100% sure the stage1
> compiler is robust, and I wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #7 from Levi Zim ---
(In reply to Levi Zim from comment #4)
> (In reply to Andrew Pinski from comment #1)
> > Can you attach the preprocessed source for rust-lex.cc ?
> >
> > The big difference between stage1 and stage2 is debug inf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #6 from Levi Zim ---
(In reply to Sam James from comment #5)
> Can you link me to your packaging script? Thanks.
Our packaging script is a patch[1] over Arch Linux's one[2].
After applying the patch, it is https://paste.rs/578r4
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #4 from Levi Zim ---
(In reply to Andrew Pinski from comment #1)
> Can you attach the preprocessed source for rust-lex.cc ?
>
> The big difference between stage1 and stage2 is debug info.
Here are the preprocessed source (*.ii, *.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #3 from Levi Zim ---
Weird. It seems that I cannot reproduce it outside of our packaging infra.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #2 from Levi Zim ---
(In reply to Andrew Pinski from comment #1)
> Can you attach the preprocessed source for rust-lex.cc ?
Do you mean re-running the command that produces rust-lex.o but with
-save-temps?
> The big difference betw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
Bug ID: 119012
Summary: [riscv] Bootstrap comparison failure:
gcc/rust/rust-lex.o differs
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Keywords: lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116662
--- Comment #10 from Levi Zim ---
(In reply to Jeffrey A. Law from comment #9)
> So the question in my mind, how important is this? On modern kernels &
> toolchains it's possible to query the cboz extension & its block size which
> effectively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116662
--- Comment #7 from Levi Zim ---
(In reply to Xi Ruoyao from comment #6)
> cppreference is not the standard. The standard never says
> hardware_destructive_interference_size means this.
>
> Instead it says:
>
> This number is the minimum reco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116662
--- Comment #5 from Levi Zim ---
(In reply to Andrew Pinski from comment #3)
> Any use of std::hardware_destructive_interference_size and
> std::hardware_constructive_interference_size for ABI purposes in a header
> file is very much discouraged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116662
Bug ID: 116662
Summary: Wrong value of __GCC_DESTRUCTIVE_SIZE for riscv64
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112434
--- Comment #5 from Levi Zim ---
Created attachment 59037
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59037&action=edit
Patch for fix this bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112434
--- Comment #4 from Levi Zim ---
I think the fix should be easy and this kind of bug has been fixed for
aarch64(in f541a48127a1940dce8dc8f48d88ccb04aa2a31e) and
loongarch(c44fd55784206ff5b32471dadaa8affbac840454).
Based on c44fd55784206ff5b3247
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112434
--- Comment #3 from Levi Zim ---
This bug still occurs in gcc 14.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112434
Bug ID: 112434
Summary: unexpected error when compiling for riscv64: invalid
'asm': invalid use of '%c'
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111448
Levi Zim changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111448
--- Comment #4 from Levi Zim ---
I tested it on gcc's latest commit(5b4acfa306d53c8473883552f1db7278b7065b18).
It doesn't trigger the ICE.
However, I do have another source file that still triggers the ICE with gcc's
latest commit. It is a quit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111448
--- Comment #2 from Levi Zim ---
(In reply to Andrew Pinski from comment #1)
> I suspect this is a dup of bug 110315. It works on the trunk but fails on
> 13.2.0 even on x86_64-linux-gnu.
I tested it with gcc 13.1.1 and gcc 12.3.0.
gcc 13.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111448
Bug ID: 111448
Summary: g++ ICE Segmentation fault in qemu-riscv64-static
emulator
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
28 matches
Mail list logo
