https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
Andrew Pinski changed:
What|Removed |Added
Summary|AArch64: Wrong Register |aarch64: epoligue in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
Andrew Pinski changed:
What|Removed |Added
Severity|normal |critical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
--- Comment #6 from Andrew Pinski ---
Note I just happened to finish a build of aarch64 so I was able to create the
preprocessed source of unwind-dw2.i really quick. And then I just read the
aarch64.cc to see the saving of x0 happened due to __b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
--- Comment #7 from Andrew Pinski ---
Just an FYI on other targets on my reduced testcase (I just quickly looked at
the generated assembly to see if it worked or not):
backends that seems to work:
mips
riscv
x86
s390
m68k
sh
sparc
backends tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848
Andrew Pinski changed:
What|Removed |Added
Version|14.0|13.2.0
--- Comment #2 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114849
Bug ID: 114849
Summary: Static function pointer
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848
Xi Ruoyao changed:
What|Removed |Added
Summary|longarch: epilogue in |loongarch: epilogue in
|_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734
--- Comment #8 from Robin Dapp ---
Created attachment 58037
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58037&action=edit
Expand dump
Dump attached. Insn 209 is the problematic one.
The changing from _911 to 1078 happens in internal-f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114849
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114849
--- Comment #2 from Manjunath Bhavimani ---
Yes i am using same ld script, only compiler version changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848
--- Comment #4 from Andrew Pinski ---
Also it looks like I messed up comment #0 and forgot to change powerpc to
longarch64 :). That is what I get for trying to split this all out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114849
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114828
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114738
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> Just an FYI on other targets on my reduced testcase (I just quickly looked
> at the generated assembly to see if it worked or not):
>
> backends that seems to w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
--- Comment #2 from Kewen Lin ---
As https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843#c8, we may need some
similar handling like r14-6440-g4b421728289e6f.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #17 from Eric Botcazou ---
[...]
>>> The sparc64-unknown-linux-gnu one will be running f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114850
Bug ID: 114850
Summary: co_await a async function which result type is
std::unique_ptr<...> or shared_ptr in a initializer
list causes ICE
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114850
--- Comment #1 from Jeremy Pewterschmidt
---
Created attachment 58038
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58038&action=edit
compressed file generated by g++ with -freport-bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114850
--- Comment #2 from Jeremy Pewterschmidt
---
Created attachment 58039
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58039&action=edit
compressed file generated by g++ with -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96866
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96866
--- Comment #3 from Jiu Fu Guo ---
While, I'm wondering if we could accept this code, and handle it as something
like:
(insn 5 4 6 (set (reg/f:DI 118)
(mem/u/c:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC0") [flags 0x2])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114849
--- Comment #4 from Manjunath Bhavimani ---
We used same options for both toolchain version. Except linker option
-specs=nano.specs, this is not used for v10.3
Compiler Option:
-mcpu=cortex-m7
-mthumb
-mlittle-endian
-mfpu=fpv5-sp-d16
-mfloa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114851
Bug ID: 114851
Summary: Alternative to -Wmisexpect from LLVM in GCC
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714
--- Comment #7 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:af7d981ba40f145256f6f6d3409451e8fa647f75
commit r14-10118-gaf7d981ba40f145256f6f6d3409451e8fa647f75
Author: Pan Li
Date: Thu Apr 25 15:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105841
--- Comment #17 from Haojian Wu ---
> IIRC we didn't want to commit to an API for the built-in, and we also didn't
> have any motivating use cases for the it within libstdc++.
Thanks for the reply. Fair enough.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #20 from GCC Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:1d238c84025aaef1641e4000bd2a8f4328b474dd
commit r14-10119-g1d238c84025aaef1641e4000bd2a8f4328b474dd
Author: Eric Botcazou
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #22 from Jakub Kulik ---
Eric and Rainer, thank you both very much for all that testing and the fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
--- Comment #9 from Matt Thompson ---
Jerry,
I tried your patch, but it didn't seem to help my reproducer.
Stock GCC13:
Number of Modules | Build Time
- | --
10 | 0.336674
20 |2.34525
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114467
thomas changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94753
--- Comment #3 from r_new at rambler dot ru ---
Don't know gcc code, but
/* For C++11+ __cpp_constexpr and __cpp_static_assert should be defined. */
#if __cplusplus >= 201103L
is not true.
All standard predefined macros listed in chapter "16.8 P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114852
Bug ID: 114852
Summary: jpegxl 10.0.1 is faster with clang18 then with gcc14
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114853
Bug ID: 114853
Summary: Inefficient code with a bunch of bitwise checks
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114792
--- Comment #7 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:59ff81835fee22a9d4c9a481a4d1814583aae945
commit r14-10120-g59ff81835fee22a9d4c9a481a4d1814583aae945
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114792
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734
--- Comment #9 from Richard Biener ---
(In reply to Robin Dapp from comment #8)
> Created attachment 58037 [details]
> Expand dump
>
> Dump attached. Insn 209 is the problematic one.
> The changing from _911 to 1078 happens in internal-fn.cc:e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114853
Richard Biener changed:
What|Removed |Added
Component|c++ |tree-optimization
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114854
Bug ID: 114854
Summary: [14 Regression] ICE with default initializer of const
reference member at cp/cp-gimplify.cc:900
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99183
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #8 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734
--- Comment #10 from Robin Dapp ---
Yes it helps. Great that get_gimple_for_ssa_name is right below
get_rtx_for_ssa_name that I stepped through several times while debugging and I
didn't realize the connection, g.
But thanks! Good thing i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95682
Paul Thomas changed:
What|Removed |Added
Resolution|--- |WONTFIX
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114854
Patrick Palka changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837
--- Comment #2 from GCC Commits ---
The master branch has been updated by Richard Ball :
https://gcc.gnu.org/g:ad45086178d833254d66fab518b14234418f002b
commit r14-10122-gad45086178d833254d66fab518b14234418f002b
Author: Richard Ball
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837
--- Comment #3 from Richard Ball ---
Fixed on Trunk so far
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837
--- Comment #4 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Ball
:
https://gcc.gnu.org/g:5550214b58e95320b54e42ef0e37c6479e04b27b
commit r13-8647-g5550214b58e95320b54e42ef0e37c6479e04b27b
Author: Richard Ball
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837
--- Comment #5 from GCC Commits ---
The releases/gcc-12 branch has been updated by Richard Ball
:
https://gcc.gnu.org/g:441e194abcf3211de647d74c892f90879ae9ca8c
commit r12-10394-g441e194abcf3211de647d74c892f90879ae9ca8c
Author: Richard Ball
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99183
Paul Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837
--- Comment #6 from GCC Commits ---
The releases/gcc-11 branch has been updated by Richard Ball
:
https://gcc.gnu.org/g:dabd742cc25f8992c24e639510df0965dbf14f21
commit r11-11364-gdabd742cc25f8992c24e639510df0965dbf14f21
Author: Richard Ball
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837
--- Comment #7 from Richard Ball ---
Backported to gcc-11, gcc-12 and gcc-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837
Richard Ball changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113885
Paul Thomas changed:
What|Removed |Added
Summary|[13/14 Regression] ice in |[13 Regression] ice in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114853
--- Comment #2 from Andrew Pinski ---
Created attachment 58040
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58040&action=edit
testcase
Please next time, attach (or place inline) the testcase and not just link to
godbolt.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114854
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114853
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114844
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94753
--- Comment #4 from Jonathan Wakely ---
Maybe I've misunderstood you, but the feature test macros for C++11 features
should definitely be defined for C++11.
They're not "system-specific" or "GCC-specific".
Just because they weren't in the stand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94753
--- Comment #5 from Andrew Pinski ---
I will change the testcase's comment to be:
```
For C++11+ __cpp_constexpr and __cpp_static_assert GCC define these even with
-undef.
```
The feature macros as mentioned by Jonathan, we want them defined alm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114851
Andrew Pinski changed:
What|Removed |Added
Blocks||87403
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114851
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> I don't think GCC has a warning (yet).
Though I do wonder if the "hints" are used instead of the PGO here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114851
--- Comment #3 from Alexander Zaitsev ---
> Though I do wonder if the "hints" are used instead of the PGO here.
We already discussed this question a bit in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112806 . If I understand
correctly, no clea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79646
--- Comment #5 from Eric Gallager ---
(In reply to Abe from comment #4)
> Anybody who wants to chime in, but especially Eric Gallager: please let me
> know whether or not my patch looks good enough for submission to the
> gcc-patches mailing list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114836
--- Comment #1 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:d0e1e1291b10372d71ad3d6cb66b333ea91097e7
commit r14-10124-gd0e1e1291b10372d71ad3d6cb66b333ea91097e7
Author: Gaius Mulley
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114853
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |middle-end
--- Comment #4 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:14d48516e588ad2b35e2007b3970bdcb1b3f145c
commit r14-10130-g14d48516e588ad2b35e2007b3970bdcb1b3f145c
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102620
--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #9)
> (In reply to anlauf from comment #8)
> > I get the same behavior at r13-8559 as 14-mainline. There seems to be
> > another commit that fixed it indepe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #34 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c39654e7a431992773b48d61f804494b0d70855f
commit r14-10132-gc39654e7a431992773b48d61f804494b0d70855f
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827
--- Comment #6 from Neil Carlson ---
Here's a variation of the example involving arrays. I expect the source of the
failure here is the same, but I want to be sure this example is also fixed by
the eventual patch.
program main
call run
contai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189
Bug 87189 depends on bug 78017, which changed state.
Bug 78017 Summary: weak reference usage in gthr-posix.h (__gthread*) is broken
with new enough glibc (GTHREAD_USE_WEAK can be defined to 0 now)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7801
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284
--- Comment #10 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f541757ba4632e204169dd08a5f10c782199af42
commit r14-10134-gf541757ba4632e204169dd08a5f10c782199af42
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Target Milestone|14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111610
--- Comment #7 from GCC Commits ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:1fd4db58480a518b05dd835157e59b2ed9fd2bc1
commit r11-11371-g1fd4db58480a518b05dd835157e59b2ed9fd2bc1
Author: Iain Sandoe
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
Bug ID: 114855
Summary: ICE: Segfault
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #1 from Andrew Pinski ---
Worthing noting on the trunk most of the compile time seems to be in the ranger
code ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #2 from Andrew Pinski ---
The code basically does a bunch of:
const SWord8 s599 = s557 ? s595 : s598;
const SWord8 s600 = s561 ? 14 : 246;
const SWord8 s601 = s561 ? 3 : 72;
const SWord8 s602 = s559 ? s600 : s601;
const SW
ome/dklein/gcc-master --disable-multilib
--disable-bootstrap --enable-languages=c,c++,fortran,lto,objc --no-create
--no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240425 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
--- Comment #3 from Andrew Pinski ---
(In reply to Kewen Lin from comment #2)
> As https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843#c8, we may need some
> similar handling like r14-6440-g4b421728289e6f.
Note rs6000_emit_epilogue mostly handl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114857
Bug ID: 114857
Summary: Pointer attributes and qualifiers are parsed in wrong
order
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #10 from W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
--- Comment #12 from Andrew Pinski ---
(In reply to Wilco from comment #10)
> Since the whole eh_return is an internal ABI in libgcc, a fix would be to
> change EH_RETURN_DATA_REGNO(N) to avoid x0 and x1. Since eh_return already
> reserves 7 reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
--- Comment #13 from Wilco ---
(In reply to Andrew Pinski from comment #11)
> I have a fix for aarch64, able to produce now:
> ```
> f:
> .LFB0:
> .cfi_startproc
> stp x0, x1, [sp, -32]!
> .cfi_def_cfa_offset 32
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/gnustep/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
--- Comment #15 from Andrew Pinski ---
Created attachment 58043
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58043&action=edit
Patch but no testcases yet
Will add testcases in a little bit. Also I have not tested this fully yet. Will
do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114858
Bug ID: 114858
Summary: Compilation Hang and Excessive RAM Consumption in GCC
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114858
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.8.4, 4.8.5
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114858
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|[11/12/13/14 regre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114856
Nathaniel Shead changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
--- Comment #11 from Jerry DeLisle ---
I am able to run your reproducer and I can see the increasing times as the
number of modules goes up. I am curious if you could randomize the subroutine
names? These appear fairly repetitive and I wonder if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
Bug ID: 114859
Summary: Seeing new segmentation fault in same_type_as
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102620
--- Comment #11 from Paul Thomas ---
(In reply to anlauf from comment #10)
> (In reply to Paul Thomas from comment #9)
> > (In reply to anlauf from comment #8)
> > > I get the same behavior at r13-8559 as 14-mainline. There seems to be
> > > an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #3 from jeremy rutman ---
For what it's worth, clang is able to compile the code in question.
Ubuntu clang version 18.1.3 (1)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
1 - 100 of 101 matches
Mail list logo
