compression algorithms: zlib zstd
gcc 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&action=edit
slightly less reduced testcase, ICEing elsewhere
The original testcase was ICEing at a different place, as does
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://inbox.sourceware
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 #3
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 f(__UINTPTR
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.
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 23
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 passe
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: gcc.dg/vect/tsvc/vect-tsvc-s114
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.
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
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 this
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 #6
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 ki
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 = (_BitInt(8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86072
Phosit changed:
What|Removed |Added
CC||phosit at autistici dot org
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment #
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)
{
return
extra-nobootstrap-amd64
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
> > --- config.h.g
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])) "hc2cf2_16.c":456:
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
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113113
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
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 f
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&action=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: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #4 from Jakub Jelinek ---
Bisection points to hc2cf2_16.o.
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 #
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,
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
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
Keywo
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 Ma
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
Se
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: F
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: F
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
x86_64-pc-linux-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113110
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110389
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
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.)?
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005
--- Comment #8 from Jakub Jelinek ---
Execution timeout is: 300
spawn [open ...]
STOP 2
Internal Error: Trying to free nonempty asynchronous unit
Error termination. Backtrace:
Internal Error: Trying to free nonempty asynchronous unit
Error ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005
--- Comment #7 from Jakub Jelinek ---
wget .../build.log; sed -n /^begin/,/^end/p build.log | uudecode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005
--- Comment #6 from Jakub Jelinek ---
But guess another case is on a loaded system.
When building on Fedora for distro builds on all of aarch64, powerpc64le, s390x
or x86_64 I see:
+FAIL: libgomp.fortran/rwlock_1.f90 -O0 execution test
+FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005
--- Comment #5 from Jakub Jelinek ---
I can confirm that on x86_64-linux with 16 cores/32 threads even the -O0
rwlock_1 and rwlock_3 tests aren't that slow, byt with OMP_NUM_THREADS=1024
and higher rwlock_1 STOPs:
$ OMP_NUM_THREADS=256 LD_LIBRAR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113111
Bug ID: 113111
Summary: -Werror=uninitialized is not consistent for
optimization level 0 or -std=before-c++20
Product: gcc
Version: unknown
Status: UNCONFIRMED
68 matches
Mail list logo
