https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116010
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |15.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116013
Richard Biener changed:
What|Removed |Added
Component|middle-end |target
Target|x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
Richard Biener changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #81 from rusty at rustcorp dot com.au ---
(In reply to Jakub Jelinek from comment #76)
> (void) casts not quieting the warning was an intentional request when the
> warning has been added, I really don't think it is a good idea to chan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116028
Bug ID: 116028
Summary: [15 regression] gcc.dg/pr10474.c test failure
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116028
Surya Kumari Jangala changed:
What|Removed |Added
Last reconfirmed||2024-07-22
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116028
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
Summar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98289
--- Comment #7 from Jorn Wolfgang Rennecke ---
Created attachment 58719
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58719&action=edit
patch to fix internal compiler errors in shrink-wrap.cc on EDGE_CROSSING edges
I'm currently using thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115793
--- Comment #5 from Bi6c ---
gcc-trunk also not reporting signed integer overflow at -O2, -O3, and -Os
(https://godbolt.org/z/8xnq1bo7s).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115997
--- Comment #3 from anlauf at gcc dot gnu.org ---
The original issue was reported for findloc, but did occur with several other
intrinsics accepting deferred-length character. If you edit the bugzilla
search to include resolved issues, you will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115565
--- Comment #6 from GCC Commits ---
The releases/gcc-14 branch has been updated by Maciej W. Rozycki
:
https://gcc.gnu.org/g:323d010fa5d433e6eb5ec5124544f19fb4b4eee6
commit r14-10485-g323d010fa5d433e6eb5ec5124544f19fb4b4eee6
Author: Maciej W.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115565
--- Comment #7 from GCC Commits ---
The releases/gcc-13 branch has been updated by Maciej W. Rozycki
:
https://gcc.gnu.org/g:4ce7c81212c7819dfe6dbbe2399220fb12da6d71
commit r13-8932-g4ce7c81212c7819dfe6dbbe2399220fb12da6d71
Author: Maciej W. R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115565
--- Comment #8 from GCC Commits ---
The releases/gcc-12 branch has been updated by Maciej W. Rozycki
:
https://gcc.gnu.org/g:8d8f804b18e4a38671957b3e4c239ef625506317
commit r12-10633-g8d8f804b18e4a38671957b3e4c239ef625506317
Author: Maciej W.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116024
--- Comment #5 from Artemiy Volkov ---
Hi Andrew, thank you for the breakdown. For i1() (the case applicable to the
initial bug report) something like this seems to fix the issue:
diff --git a/gcc/match.pd b/gcc/match.pd
index cf359b0ec0f..8ab
Hi,
When processing large header files, the C preprocessor reports error on
the wrong line.
This is 100% reproducible on my side with gcc mainline.
Reproducer:
# Build
mkdir build; cd build
../configure --host=x86_64-pc-linux-gnu --target=x86_64-wrs-linux
--enable-languages=c --disable-mul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531
--- Comment #5 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:af792f0226e479b165a49de5e8f9e1d16a4b26c0
commit r15-2191-gaf792f0226e479b165a49de5e8f9e1d16a4b26c0
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531
--- Comment #6 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:0c5c0c959c2e592b84739f19ca771fa69eb8dfee
commit r15-2192-g0c5c0c959c2e592b84739f19ca771fa69eb8dfee
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 115531, which changed state.
Bug 115531 Summary: vectorizer generates inefficient code for masked
conditional update loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88624
--- Comment #5 from GCC Commits ---
The master branch has been updated by Andre Vehreschild :
https://gcc.gnu.org/g:9d650e97cb76e4ea3b5d060e4a4cef38fc58
commit r15-2193-g9d650e97cb76e4ea3b5d060e4a4cef38fc58
Author: Andre Vehreschild
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45215
--- Comment #4 from rguenther at suse dot de ---
On Fri, 19 Jul 2024, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45215
>
> Andrew Pinski changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907
--- Comment #58 from Jonathan Wakely ---
(In reply to cqwrteur from comment #43)
> If GNU folks continue f things up, I can guarantee
> you everyone will move to LLVM
You keep saying this, but you're still here. Feel free to leave any time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89270
--- Comment #17 from Richard Biener ---
(In reply to Georg-Johann Lay from comment #16)
> (In reply to Richard Biener from comment #14)
> > Fixed on trunk sofar. Joseph correctly mentioned that iff AVR would define
> > __int24 using INT_N in avr
On 22/07/24 12:24 +0300, Ovidiu Panait wrote:
Hi,
When processing large header files, the C preprocessor reports error
on the wrong line.
This mailing list is for automated emails fom our bug tracker, not for
reporting bugs. Emails sent directly to this list will not get tracked
as bugs, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
--- Comment #9 from Andre Vehreschild ---
(In reply to Paul Thomas from comment #8)
> Hi Andre,
>
> Two of the remaining dependencies are associated with (excuse the pun)
> coarrays. PR102973 is probably spurious and is marked as waiting.
>
> C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115793
--- Comment #6 from Jakub Jelinek ---
This bugreport is based on the unwarranted assumption that UBSAN reports all UB
even at higher optimization levels. It doesn't, that is part of the tradeoff
between code speed and amount of reported issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907
--- Comment #59 from cqwrteur ---
you think it is not a reality? android freebsd wasm and even windows had
already moved to llvm. GCC does not even support android any more. glibc on
linux is the only reason people still stay with gcc. But now l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907
--- Comment #60 from cqwrteur ---
i am here? Have you even checked my repository? i have been working on llvm
backend for my projects for nearly a year. At this point i won't even be
shocked even microsoft giving up msvc and moving to llvm.
Get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021
--- Comment #8 from Iain Sandoe ---
(In reply to Eric Gallager from comment #7)
> Well ok, could someone send me a binary x86_64 build of GCC for darwin20
> with Ada support that they can bootstrap with successfully, then, so that I
> can get ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116009
Richard Sandiford changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876
--- Comment #11 from Martin Jambor ---
Our weekend ubsan bootstrap and test (of revision
r15-2173-ge0d997e913f811) still reported failures when compiling
testcase gfortran.dg/ieee/large_1.f90 (at -O2 and higher).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116029
Bug ID: 116029
Summary: Linux kernel doesn't build with gcc 11.5.0
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116029
Jakub Jelinek changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110171
--- Comment #2 from Arsen Arsenović ---
no - it is because convert_to_void does not know how to warn about discarded
co_awaits, and it does not get re-invoked when we expand co_awaits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116029
--- Comment #2 from Jakub Jelinek ---
First differences are in the veclower21 dump in several functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #82 from Segher Boessenkool ---
(In reply to rusty from comment #81)
> Not many function returns are as clearly required as realloc...
Then they shouldn't use warn_unused_result! The documentation of that is
very very clear: both ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116029
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85510
Andre Vehreschild changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #4 from Jakub Jelinek ---
That is not a prototype. Prototype is what is the C or C++ function type of
the builtin. Neither ptr->FAM nor const_exp_with_int_type are valid C types.
There is no reason why the second argument should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104981
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021
--- Comment #9 from Eric Gallager ---
Ah, looking at gcc/ada/gcc-interface/Makefile.in, perhaps the issue is that I
need to set GNATLINK in my environment, too, besides just GNATMAKE and
GNATBIND... perhaps the issue was arising due to having ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115897
--- Comment #9 from Patrick Palka ---
Looks like we also need to consider dependent attributes when stripping
non-template aliases. Patch posted at
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657706.html, I wonder if it
fully handles yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116023
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116024
--- Comment #6 from Richard Biener ---
(In reply to Artemiy Volkov from comment #5)
> Hi Andrew, thank you for the breakdown. For i1() (the case applicable to
> the initial bug report) something like this seems to fix the issue:
>
> diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021
--- Comment #10 from Iain Sandoe ---
(In reply to Eric Gallager from comment #9)
> Ah, looking at gcc/ada/gcc-interface/Makefile.in, perhaps the issue is that
> I need to set GNATLINK in my environment, too, besides just GNATMAKE and
> GNATBIND.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116028
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114501
Jan Hubicka changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #4)
> That is not a prototype. Prototype is what is the C or C++ function type of
> the builtin. Neither ptr->FAM nor const_exp_with_int_type are valid C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #6 from Jakub Jelinek ---
That is a bad example, __builtin_call_with_static_chain is not a builtin
function, but a keyword.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116030
Bug ID: 116030
Summary: ICE "could not split insn" in final_scan_insn_1, at
final.cc on power pc
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ice-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116030
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033
--- Comment #18 from Jan Hubicka ---
modref_eaf_analysis::analyze_ssa_name misinterprets EAF flags. If dereferenced
parameter is passed (to map_iterator in the testcase) it can be returned
indirectly which in turn makes it to escape into the ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877
--- Comment #11 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:88d16194d0c8a6bdc2896c8944bfbf3e6038c9d2
commit r15-2196-g88d16194d0c8a6bdc2896c8944bfbf3e6038c9d2
Author: Jeff Law
Date: Mon Jul 22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033
--- Comment #19 from Andrew Pinski ---
(In reply to Jan Hubicka from comment #18)
> modref_eaf_analysis::analyze_ssa_name misinterprets EAF flags. If
> dereferenced
> parameter is passed (to map_iterator in the testcase) it can be returned
> in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109867
--- Comment #3 from Arsen Arsenović ---
(In reply to Arsen Arsenović from comment #2)
> this corresponds to the four switches emitted for the coroutine
> implementation after morphing these fns into coroutine functions. the other
> cases are un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114207
--- Comment #5 from Jan Hubicka ---
The offset gets lost in ipa-prop.cc
diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index 7d7cb3835d2..99ebd6229ec 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -1370,9 +1370,9 @@ unadjusted_ptr_and_un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116009
--- Comment #7 from Sam James ---
I have a sparc testcase too but I won't bother spending time on that unless you
want it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116009
--- Comment #8 from Sam James ---
(mpfr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116031
Bug ID: 116031
Summary: signed integer overflow check at optimization level
-O3
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #6)
> That is a bad example, __builtin_call_with_static_chain is not a builtin
> function, but a keyword.
A little confused here, this function is clearly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #8 from Jakub Jelinek ---
It doesn't matter how it is documented, what matters is how it is implemented.
E.g. can you do (__builtin_call_with_static_chain) (fn, ptr)?
Or __typeof (__builtin_call_with_static_chain)?
Regular builtins a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115969
--- Comment #9 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:ebde0cc101a3b26bc8c188e0d2f79b649bacc43a
commit r15-2197-gebde0cc101a3b26bc8c188e0d2f79b649bacc43a
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116009
--- Comment #9 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:34f33ea801563e2eabb348e8d3e9344a91abfd48
commit r15-2199-g34f33ea801563e2eabb348e8d3e9344a91abfd48
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116031
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115969
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116009
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115793
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:0d19fbc7b0760ce665fa6a88cd40cfa0311358d7
commit r15-2200-g0d19fbc7b0760ce665fa6a88cd40cfa0311358d7
Author: Jan Hubicka
Date: Mon J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114207
--- Comment #6 from GCC Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:391f46f10b0586c074014de82efe76787739bb0c
commit r15-2201-g391f46f10b0586c074014de82efe76787739bb0c
Author: Jan Hubicka
Date: Mon J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116020
--- Comment #1 from Fedor Chelnokov ---
Another problematic problem example is as follows:
struct A {
static void f();
};
void foo() {
A::f(); //ok
}
void A::f(this void) {}
int main() {
A::f(); //error in GCC after A::f definiti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033
--- Comment #20 from GCC Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:cf8ffc58aad3127031c229a75cc4b99c8ace25e0
commit r15-2202-gcf8ffc58aad3127031c229a75cc4b99c8ace25e0
Author: Jan Hubicka
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291
--- Comment #11 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jan Hubicka
:
https://gcc.gnu.org/g:9a7d668fc58f817027ec7f9fa7e20a6dce08bddb
commit r14-10486-g9a7d668fc58f817027ec7f9fa7e20a6dce08bddb
Author: Jan Hubicka
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105475
--- Comment #3 from Arsen Arsenović ---
ah, seems that we're missing handling of error_mark_node in a few places while
processing a coroutine, causing the middle-end to be confused later. I'll
leave that for later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877
--- Comment #12 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:ab7c0aed52054976d0b5e12c52e82239d4277b98
commit r15-2203-gab7c0aed52054976d0b5e12c52e82239d4277b98
Author: Jeff Law
Date: Mon Jul 22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #9 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> It doesn't matter how it is documented, what matters is how it is
> implemented.
> E.g. can you do (__builtin_call_with_static_chain) (fn, ptr)?
> Or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111613
--- Comment #7 from Jan Hubicka ---
I suppose there is not much to do about past noread flags. I do not see how
optimization can invalidate other properties, so I am testing the following:
diff --git a/gcc/ipa-modref.cc b/gcc/ipa-modref.cc
inde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277
--- Comment #6 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jan Hubicka
:
https://gcc.gnu.org/g:c5397d343ff1365fcebcf3ebabe140608874aac3
commit r14-10487-gc5397d343ff1365fcebcf3ebabe140608874aac3
Author: Jan Hubicka
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114207
--- Comment #7 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jan Hubicka
:
https://gcc.gnu.org/g:f2e98084792821c3849074867d5b007c49028854
commit r14-10488-gf2e98084792821c3849074867d5b007c49028854
Author: Jan Hubicka
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277
Jan Hubicka changed:
What|Removed |Added
Summary|[13/14/15 regression] ICF |[13 regression] ICF needs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033
--- Comment #21 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jan Hubicka
:
https://gcc.gnu.org/g:27ef3a0779e551ca116c56c431436c8d2191b253
commit r14-10489-g27ef3a0779e551ca116c56c431436c8d2191b253
Author: Jan Hubicka
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033
Jan Hubicka changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13 Regression]
|Inc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114207
Jan Hubicka changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13 Regression] modref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116032
Bug ID: 116032
Summary: [12/13/14/15 Regression] gcc.target/arm/pr40457-2.c
produces larger code for armv7ve+neon
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111613
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:14074773350ffed7efdebbc553adf0f23b572e87
commit r15-2205-g14074773350ffed7efdebbc553adf0f23b572e87
Author: Jan Hubicka
Date: Mon J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111613
Jan Hubicka changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13 Regression] Bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Jan Hubicka changed:
What|Removed |Added
Summary|[12/13/14/15 regression]|[12/13 regression] ICU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115086
--- Comment #6 from Andrew Pinski ---
Note andc optab was added with r15-1890-gf379596e0ba99d .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83355
Andi Kleen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116033
Bug ID: 116033
Summary: [14/15] RISC-V: -march=rv64gv_xtheadmemidx generates
illegal vse8.v insn
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114189
--- Comment #11 from Andrew Pinski ---
(In reply to Richard Biener from comment #4)
> aarch64 reports just
>
> FAIL: gcc.target/aarch64/if-compare_2.c check-function-bodies bar1
> FAIL: gcc.target/aarch64/if-compare_2.c check-function-bodies ba
with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r15-2206-20240722194717-g6f81b7fa799-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116034
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116035
Bug ID: 116035
Summary: [14/15] RISC-V: -march=rv64g_xtheadmemidx_zba
generates illegal lwu insn
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277
Sam James changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033
Sam James changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Kno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116034
--- Comment #2 from Andrew Pinski ---
Folding statement: _1 = &c + 1;
Queued stmt for removal. Folds to: &MEM <__complex__ short unsigned int>
[(void *)&c + 1B]
Folding statement: _3 = MEM [(char * {ref-all})_1];
Folded into: _3 = MEM [(char
1 - 100 of 183 matches
Mail list logo
