https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113916
Bug ID: 113916
Summary: gcc allows overriding a non-deleted private base class
dtor with a deleted defaulted dtor
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
--- Comment #10 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #9)
> This should work, I think:
With that I get on the reduced testcase:
```
f:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > cannot be conditional executed.
>
> That is because most of the insn patterns in sync.md don't have
> [(set_a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> cannot be conditional executed.
That is because most of the insn patterns in sync.md don't have
[(set_attr "conds" "nocond")])
on them
Someone will ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
--- Comment #7 from Andrew Pinski ---
Seems like the code in arm_final_prescan_insn does not realize arm_atomic_store
cannot be conditional.
That is:
```
(insn 10 9 11 (set (mem/v:SI (reg/v/f:SI 0 r0 [orig:116 aD.6109 ] [116]) [-1
S4 A32])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-02-14
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
Andrew Pinski changed:
What|Removed |Added
Severity|normal |blocker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
Orion Poplawski changed:
What|Removed |Added
CC||orion at nwra dot com
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
--- Comment #5 from Sam James ---
(In reply to Sam James from comment #0)
> glibc seems to go from 30 failing innocent tests (*) to over 400 between
> gcc-13 and gcc-14. Bisected to r14-4365-g0731889c026bfe which fixed PR111235.
>
> It's hard t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
--- Comment #4 from Sam James ---
better bt:
```
begin: no errors
[New LWP 250625]
Thread 2.1 "ld-linux-armhf." received signal SIGSEGV, Segmentation fault.
[Switching to LWP 250624]
_dl_find_object_update_1 (count=, loaded=) at
dl-find_object.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
--- Comment #3 from Sam James ---
On glibc trunk (491e55beab7457ed310a4a47496f4a333c5d1032), I can reproduce
with:
```
CC=/tmp/gcc/bin/gcc CXX=/tmp/gcc/bin/g++ ~/git/glibc/configure --prefix=/usr
make -j$(nproc)
make test t=posix/tst-getopt-canc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
Sam James changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
--- Comment #1 from Sam James ---
glibc's WAIT_FOR_DEBUGGER support for tests seems broken, as it drops me into a
waiting process with:
```
/var/tmp/portage/sys-libs/glibc-2.38-r10/work/build-arm-armv7a-unknown-linux-gnueabihf-nptl/posix/tst-get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
Bug ID: 113915
Summary: [14 regression] glibc miscompiled for armv7a since
r14-4365-g0731889c026bfe
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: wr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545
--- Comment #5 from Hans-Peter Nilsson ---
Thank you!
Hello,
I'm offering my late husband's Yamaha Baby Grand Piano to any passionate music
enthusiast. Please inform me if you are
interested or know someone who would appreciate having this instrument.
Thanks,
Sarenaa Fuller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312
--- Comment #24 from Andrew Pinski ---
(In reply to Riccardo Mutschlechner from comment #21)
> Not sure if this is the best place to start, but here goes. I've noticed
> another similar issue.
>
> Let's say you've compiled a binary, `test`, from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113914
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113914
Bug ID: 113914
Summary: GCC accepts user-defined integer-literal that does not
fit in any type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90155
--- Comment #2 from Andrew Pinski ---
Patch finally submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645516.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760
--- Comment #17 from Marek Polacek ---
Partially fixed for GCC 14. Leaving this open for more changes in GCC 15.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760
--- Comment #16 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:6fec511f2d23cc70ab29d1ba79c2415ab51bcb60
commit r14-8967-g6fec511f2d23cc70ab29d1ba79c2415ab51bcb60
Author: Marek Polacek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210
--- Comment #7 from Jerry DeLisle ---
Submitted for approval.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113913
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887
--- Comment #11 from Joseph S. Myers ---
As I said in comment#2, I prefer a constant suffix for __int128 to the wb/uwb
hack - I think it's cleaner, as well as allowing int128_t to work properly on
all the targets that support __int128 but have n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113913
Bug ID: 113913
Summary: [14] RISC-V: suboptimal code gen for intrinsic vcreate
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113899
--- Comment #3 from Andrew Pinski ---
Note I do think there is something wrong with your remote testing too but that
is only slightly related.
check_sse_hw_available should still be returning 1 there since SSE should
always be available for x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113899
--- Comment #2 from Andrew Pinski ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645507.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113912
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |14.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113866
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904
--- Comment #4 from sandra at gcc dot gnu.org ---
Dynamic selectors are completely broken on mainline, since the patches that at
least partially implements this feature for metadirectives has not been
approved or committed yet. I'm also very muc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113899
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
"GCC: (GNU) 14.0.1 20240213 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-3 apx-1]$
With -mpreferred-stack-boundary=3, the coming stack is 8-byte aligned.
push2/pop2
shouldn't be generated in this case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887
--- Comment #10 from Jakub Jelinek ---
#if 42 == ((__int128) +42wb) && -35 == ((__int128) +-35wb)
#else
#warning warn
#endif
works with both gcc and clang if __BITINT_MAXWIDTH__ >= 128. That said, for
UINT128_C
it would need to use __uint128_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> Running f951 on the testcase under valgrind shows (among others) a
> frontend memleak in gfc_resolve_substring_charlen, obviously fixed by
Slash that. It p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911
--- Comment #4 from anlauf at gcc dot gnu.org ---
Running f951 on the testcase under valgrind shows (among others) a
frontend memleak in gfc_resolve_substring_charlen, obviously fixed by
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904
--- Comment #3 from Tobias Burnus ---
See comment 1 for remaining to-do items.
I also note that the Fortran resolution comes too early - during parsing - as
the following shows:
module m
implicit none
contains
subroutine test
!$omp declare v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887
--- Comment #9 from Jens Gustedt ---
(In reply to Jakub Jelinek from comment #8)
> > #define INT128_C(N) ((__int128)+ N ## W)
>
> You mean WB?
Yes, probably ;-)
> > With that observation you easily also create `MIN` and `MAX` macros
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887
--- Comment #8 from Jakub Jelinek ---
(In reply to Jens Gustedt from comment #7)
> (In reply to Joseph S. Myers from comment #5)
> > ... including __INT128_C and __UINT128_C
> > defined to use an appropriate constant suffix.
>
> You don't need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210
--- Comment #6 from Jerry DeLisle ---
I have reapplied the patch in comment #3 and it regression tests fine and
appears to fix the issue. I have need to work up the test case and submit this
for approval.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113876
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113876
--- Comment #3 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:ab71fd7ac7a2307723117c796e7ae4d7e9711058
commit r14-8966-gab71fd7ac7a2307723117c796e7ae4d7e9711058
Author: H.J. Lu
Date: Tue Feb 13 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911
--- Comment #3 from anlauf at gcc dot gnu.org ---
The following semi-obvious patch seems to fix it:
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 2181990aa04..7fc409140b0 100644
--- a/gcc/fortran/trans-array.cc
+++ b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887
--- Comment #7 from Jens Gustedt ---
(In reply to Joseph S. Myers from comment #5)
> ... including __INT128_C and __UINT128_C
> defined to use an appropriate constant suffix.
You don't need a specific suffix for these types if you have `_BitInt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113876
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904
--- Comment #2 from GCC Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:a5d34b60c949e85aa3e213872fbc42f4eee7457b
commit r14-8965-ga5d34b60c949e85aa3e213872fbc42f4eee7457b
Author: Tobias Burnus
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911
--- Comment #2 from anlauf at gcc dot gnu.org ---
Looking at the tree-dump before and after r14-8947, I see:
- a change in the main program that seems to be desirable:
bitsizetype D.4340;
sizetype D.4341;
+ *_c6 = 0;
D.4339 = *_c6;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887
--- Comment #6 from Jens Gustedt ---
(In reply to Joseph S. Myers from comment #5)
> Compiler and library are not in practice independent for this issue ...
For this particular issue they are indeed independent. As said, I have proof of
concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #15 from Marek Polace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911
--- Comment #1 from anlauf at gcc dot gnu.org ---
Created attachment 57418
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57418&action=edit
Testcase
Extended testcase that works with gcc-13. The deferred-length dummy may
be optional or no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113866
--- Comment #4 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:f4935df217ad89f884f908f39086b322e80123d0
commit r14-8961-gf4935df217ad89f884f908f39086b322e80123d0
Author: Harald Anlauf
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113903
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106009
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2024-02-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 99568, which changed state.
Bug 99568 Summary: ICE when compiling basic module: internal compiler error: in
module_may_redeclare, at cp/module.cc:18453
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99568
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99568
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911
Bug ID: 113911
Summary: [14 Regression] Length is lost passing deferred-length
character to subroutine
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706
Jason Merrill changed:
What|Removed |Added
Component|tree-optimization |c++
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #15 from Jan Hubicka ---
>
> IVOPTs does the above but it does it (or should) as
>
> offset = (uintptr)&base2 - (uintptr)&base1;
> val = *((T *)((uintptr)base1 + i + offset))
>
> which is OK for points-to as no POINTER_PLUS_EX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113876
Jakub Jelinek changed:
What|Removed |Added
Summary|ICE: in |ICE: in
|ix86_expand_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904
--- Comment #1 from Tobias Burnus ---
Patch for rejecting non-const arguments in Fortran (wrong-code bit) to bring it
in line with C/C++:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645488.html
* * *
TODO as follow up:
* Permit n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113883
--- Comment #4 from Steve Kargl ---
On Tue, Feb 13, 2024 at 04:51:02AM +, cvs-commit at gcc dot gnu.org wrote:
> The trunk branch has been updated by Jerry DeLisle :
>
> https://gcc.gnu.org/g:6caec7d9ec37e60e718a12934c85bac9c12757ac
>
Tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #24 from Jakub Jelinek ---
static inline int
foo (int len, void *indata, void *outdata)
{
if (len < 0 || (len & 7) != 0)
return 0;
if (len != 0 && indata != outdata)
__builtin_memcpy (outdata, indata, len);
return len;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113612
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113612
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:ef7738d2d0ee0103946e5243aa7e5c8ad2fb0c6d
commit r13-8324-gef7738d2d0ee0103946e5243aa7e5c8ad2fb0c6d
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113612
--- Comment #5 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:19ac327de421fe05916e234e3450e6e1cc5c935c
commit r14-8960-g19ac327de421fe05916e234e3450e6e1cc5c935c
Author: Jason Merrill
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #23 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #22)
> (In reply to Andrew Pinski from comment #21)
> > Yep that is the same descriptions as what is happening in PR 113665.
>
> Specifically https://gcc.gnu.org/bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Andrew Pinski ---
>>Configure with --enable-checking=release to disable checks.
I'm seeing the same slowdown with release builds of GCC 12.3.0 and
13.2.0.
> Can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113742
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:7eac19be5f7dd92fcbcfe13f6edbb4f9bd45c15c
commit r14-8959-g7eac19be5f7dd92fcbcfe13f6edbb4f9bd45c15c
Author: Monk Chiang
Date: Tue Feb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #22 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #21)
> Yep that is the same descriptions as what is happening in PR 113665.
Specifically https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665#c5 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #21 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #20)
> Ah, I think it is IPA-ICF.
> What happens is that fnsplit splits the uprv_copyArray{16,32,64} functions,
> where the
> inline part does what is actually differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Jakub Jelinek changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910
Andrew Pinski changed:
What|Removed |Added
Keywords||compile-time-hog
--- Comment #4 from An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113909
--- Comment #1 from H.J. Lu ---
It fails on Solaris because of:
sol2.h:#undef NO_PROFILE_COUNTERS
Just skip these tests for Solaris.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887
--- Comment #5 from Joseph S. Myers ---
Compiler and library are not in practice independent for this issue. GCC
typically provides for freestanding compilations and forwards to a
libc version for hosted compilations, and in both cases it needs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #19 from Jakub Jelinek ---
Diffing the -fdump-{tree,ipa}-all-alias dumps from r14-5108 and r14-5109,
085i.fnsummary still looks good (the 2/4/8 in the ranges corresponds to whether
it is in 16/32/64 suffixed/infixed function).
But th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910
--- Comment #3 from Rainer Orth ---
Created attachment 57416
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57416&action=edit
GCC 14.0.1 -ftime-report output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910
--- Comment #2 from Rainer Orth ---
Created attachment 57415
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57415&action=edit
GCC 11.4.0 -ftime-report output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910
--- Comment #1 from Rainer Orth ---
Created attachment 57414
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57414&action=edit
preprocessed input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910
Bug ID: 113910
Summary: [12/13/14 regression] Factor 15 slowdown compiling
AMDGPUDisassembler.cpp on SPARC
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #17 from Jakub Jelinek ---
One set of range changes in evrp is more precise ranges in return values of
uprv_swapArray{16,32,64}, those contain early return 0 if
length<0 || (length&1)!=0
or
length<0 || (length&3)!=0
or
length<0 || (l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111457
Filip Kastl changed:
What|Removed |Added
CC||pheeck at gcc dot gnu.org
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #16 from Sam James ---
(In reply to Jakub Jelinek from comment #14
> So it certainly doesn't surprise me some length < 8 check is optimized away
> given the above range info. The question is if it is correct and what
> values the le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #15 from Andrew Pinski ---
Note the range part looks correct when taking the mask into account so I am
suspecting the mask is messed up. Let me see if I could spot it later today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #14 from Jakub Jelinek ---
There are significant differences in the ranges starting with evrp.
Even optimized has:
--- pr113907.ii.261t.optimized_ 2024-02-13 09:52:13.090609512 -0500
+++ pr113907.ii.261t.optimized 2024-02-13 09:53:3
--enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240213 (experimental) (GCC)
[520] %
[520] % gcctk -O1 small.c
during GIMPLE pass: fre
small.c: In function ‘main’:
small.c:8:1: internal compiler error: in copy_reference_ops_from_ref, at
tree-ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #13 from Sam James ---
(In reply to Andrew Pinski from comment #11)
> Does -fwrapv help?
no (and ubsan suppresses the crash, everything works fine w/ no ubsan output)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #12 from Sam James ---
-O2 -march=i686 -std=c++11 -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #11 from Andrew Pinski ---
Does -fwrapv help?
If so does -fsanitize=undefined say anything?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #10 from Jakub Jelinek ---
g++ command line for that TU?
-O2 -march=i686 -std=c++14 -m32
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #5 from Filip Kastl ---
(In reply to Robin Dapp from comment #4)
> Judging by the graph it looks like it was slow before, then got faster and
> now slower again. Is there some more info on why it got faster in the first
> place? Di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113909
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113909
Bug ID: 113909
Summary: gcc.target/i386/pr113689-1.c etc. FAIL
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #9 from Sam James ---
(In reply to Sam James from comment #4)
> Created attachment 57409 [details]
> udataswp.ii.xz
>
> It goes wrong in common/udataswp.cpp's uprv_copyArray16 and uprv_copyArray64.
>
ah, uprv_copyArray64 -> uprv_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #8 from Sam James ---
Created attachment 57413
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57413&action=edit
udataswp.o (bad, r14-5109-ga291237b628f41)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #7 from Sam James ---
Created attachment 57412
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57412&action=edit
udataswp.o (good, r14-5108-g751fc7bcdcdf25)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #6 from Sam James ---
Created attachment 57411
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57411&action=edit
udataswp.cpp.262r.expand (bad)
1 - 100 of 185 matches
Mail list logo
