https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111971
Jiu Fu Guo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110879
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112666
Bug ID: 112666
Summary: Missed optimization: Value initialization
zero-initializes members with user-defined constructor
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112667
Bug ID: 112667
Summary: [OpenMP] C++: Handle static local variable in target
regions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: openmp, rejects-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
--- Comment #23 from Haochen Jiang ---
I have root caused the issue and also discovered some other minor problems
unrelated to this PR but hard to discover.
I will write a patch to fix all of them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106120
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Hans-Peter Nilsson ---
> (In reply to Rainer Orth from comment #10)
>> Since 20230106, this test produces an XPASS, according to gcc-testresults
>> postings this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112344
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
--- Comment #3 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #2)
> Someone will have to debug ifcvt.cc to see why it fails on x86_64 but works
> on aarch64. Note there are some new changes to ifcvt.cc in review which
> might imp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Andrew Pinski from comment #2)
>
> > Someone will have to debug ifcvt.cc to see why it fails on x86_64 but works
> > on aarch64. Note there are some n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
--- Comment #5 from Uroš Bizjak ---
Digging a bit further:
if_info.max_seq_cost is calculated via targetm.max_noce_ifcvt_seq_cost, where
without params set we return:
return BRANCH_COST (true, predictable_p) * COSTS_N_INSNS (2);
with:
#def
ersion 14.0.0 20231122 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
--- Comment #6 from Uroš Bizjak ---
This is by design, CMOV should not be used instead of well predicted jumps.
FYI, CMOV is quite problematic on x86, there are several PRs where conversion
to CMOV resulted in 2x slower execution. Please see e.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112344
--- Comment #9 from Richard Biener ---
In particular the final jump is miscalculated somehow, possibly path-ranger
mishandles the situation. For the loop header we thread through we
first clear dependent ranges (good) but then do compute_ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112518
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8c24011b2ba0f268e74b72519fc8119c2c99d92b
commit r14-5752-g8c24011b2ba0f268e74b72519fc8119c2c99d92b
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112518
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112526
Jakub Jelinek changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112611
--- Comment #4 from Xi Ruoyao ---
(In reply to Jiahao Xu from comment #3)
> We now consider it as undefined behavior rather than a bug for [x]vshuf
> instructions. In vec_perm pattern, we use vector logical AND instructions to
> perform modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
--- Comment #4 from Richard Biener ---
We do use the alias oracle in folding memmove:
/* If the destination and source do not alias optimize into
memcpy as well. */
if ((is_gimple_min_invariant (dest)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112669
Bug ID: 112669
Summary: GCN: wrong 'LIBRARY_PATH' in presence of several
different '-march=[...]' flags
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112670
Bug ID: 112670
Summary: RISC-V: Run fail on pr65518.c with -flto
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
--- Comment #6 from JuzheZhong ---
Hi, there are these following run FAILs left on RV32/RV64 C/C++:
after this patch fix:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637753.html
FAIL: gcc.dg/vect/pr65518.c -flto -ffat-lto-objects e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112644
--- Comment #4 from Tamar Christina ---
I've asked Matthew to take a look since he wrote the initial support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112644
--- Comment #5 from Jakub Jelinek ---
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112642
--- Comment #7 from Miro Palmu ---
(In reply to Jonathan Wakely from comment #6)
> The examples in comment 4 do compile using libstdc++ on clang, if you use
> libstdc++ headers from after sept 29 (for trunk) or oct 21 (for gcc-13).
I was testin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110879
--- Comment #4 from Jonathan Wakely ---
Ah I think that's probably expected. In _M_realloc_insert (and now
_M_realloc_append) we have:
#if __cplusplus >= 201103L
if _GLIBCXX17_CONSTEXPR (_S_use_relocate())
{
// Rel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112669
--- Comment #1 from Thomas Schwinge ---
Tracing through 'gcc/gcc.cc': 'build_search_list' -> 'for_each_path', I find:
For '-march=gfx908', we have:
(gdb) print multilib_dir
$3 = 0x82e6c0 "gfx908"
(gdb) print multilib_os_dir
$4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112668
--- Comment #1 from Jakub Jelinek ---
Reduced:
/* PR middle-end/112668 */
/* { dg-do compile { target bitint } } */
/* { dg-options "-std=c23 -fnon-call-exceptions" } */
#if __BITINT_MAXWIDTH__ >= 495
struct T495 { _BitInt(495) a : 2; unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112666
--- Comment #1 from Jonathan Wakely ---
(In reply to Francisco Paisana from comment #0)
> The struct "C" which is just "B" and an int is much slower at being
> initialized than B when value initialization (via {}) is used. However, my
> understa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
--- Comment #14 from Gianfranco ---
Hello, any news for this issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110158
--- Comment #9 from Jonathan Wakely ---
Odd, I thought I'd checked it when testing r14-4334-g28adad7a32ed92.
Seems like the same issue as PR 112642 though (which has a minimized version
without std::string).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112642
--- Comment #8 from Jonathan Wakely ---
(In reply to Miro Palmu from comment #7)
> (In reply to Jonathan Wakely from comment #6)
> > The examples in comment 4 do compile using libstdc++ on clang, if you use
> > libstdc++ headers from after sept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
Richard Biener changed:
What|Removed |Added
Summary|[14] RISC-V ICE: in |[14] RISC-V ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
--- Comment #6 from Richard Biener ---
As suggested in the review at time the change would ideally be restricted to
actual mask operands, not random BOOLEAN_TYPE ones.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112668
--- Comment #2 from Jakub Jelinek ---
No loop is needed:
/* PR middle-end/112668 */
/* { dg-do compile { target bitint } } */
/* { dg-options "-std=c23 -fnon-call-exceptions" } */
#if __BITINT_MAXWIDTH__ >= 495
struct T495 { _BitInt(495) a : 2;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
--- Comment #7 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:de6f3e12bd188fee30bc79a5e323e16e0dbbe8ca
commit r14-5755-gde6f3e12bd188fee30bc79a5e323e16e0dbbe8ca
Author: Juzhe-Zhong
Date: Wed Nov 22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112642
--- Comment #9 from Miro Palmu ---
(In reply to Jonathan Wakely from comment #8)
> > Also tried it locally with clang 16.0.6 with
> > gcc-13.2.1 libstdc++
>
> Which gcc-13.2.1 though? That's a snapshot that could date from any time in
> the pas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
--- Comment #7 from Richard Biener ---
diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index 4a09b3c2aca..d0967240ae3 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -766,7 +766,10 @@ vect_get_and_check_slp_defs (vec_inf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112563
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Jakub Jelinek ---
> So, shall we go with
> --- libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h.jj
> 2023-11-15 12:45:17.359586776 +0100
> +++ libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98925
--- Comment #3 from Jan Hubicka ---
Return value range propagation was added in
r:53ba8d669550d3a1f809048428b97ca607f95cf5
however it works on scalar return values only for now. Extending it to
aggregates is a logical next step and should not be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
--- Comment #5 from Jan Hubicka ---
> but the issue is that test2 escapes which makes this conflict:
It is passed to memmove which is noescape and returned. Why local PTA
considers returned values to escape?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112563
--- Comment #10 from Jakub Jelinek ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #9)
> > --- Comment #8 from Jakub Jelinek ---
> > So, shall we go with
> > --- libsanitizer/sanitizer_common/sanitizer_redefine_builtins.h.jj
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
--- Comment #8 from Jan Hubicka ---
The negative return value branch predictor is set to have 98% hitrate (measured
on SPEC2k17 some time ago). There is --param predictable-branch-outcome that
is also set to 2% so indeed we consider the branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112563
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Jakub Jelinek ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #9)
[...]
>> I've now come up with an alternative. It's a bit ugly, but it gets the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
--- Comment #8 from Richard Sandiford ---
I think we're going down the wrong path here. If I've understood
the original change correctly, dummy masks aren't special because
they're masks. They're special because all elements are equal to
the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112671
Bug ID: 112671
Summary: libiconv support lacks separate
--with-libiconv-{include,lib}
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112668
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2023-11-22
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112610
--- Comment #2 from CVS Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:95f61de95bbcc2e4fb7020e27698140abea23788
commit r14-5757-g95f61de95bbcc2e4fb7020e27698140abea23788
Author: Vladimir N. Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
--- Comment #9 from Richard Biener ---
(In reply to Richard Sandiford from comment #8)
> I think we're going down the wrong path here. If I've understood
> the original change correctly, dummy masks aren't special because
> they're masks. They
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
Jakub Jelinek changed:
What|Removed |Added
CC||amacleod at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
--- Comment #6 from Richard Biener ---
(In reply to Jan Hubicka from comment #5)
> > but the issue is that test2 escapes which makes this conflict:
>
> It is passed to memmove which is noescape and returned. Why local PTA
> considers returned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111911
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112344
--- Comment #10 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:6bf66276e3e41d5d92f7b7260e98b6a111653805
commit r14-5759-g6bf66276e3e41d5d92f7b7260e98b6a111653805
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112344
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
--- Comment #10 from Richard Sandiford ---
(In reply to Richard Biener from comment #9)
> So do we expect - independed of whether a constant/external is used as mask
> - that uniform constants/externals are generatable and thus we can elide the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #26 from Rich Felker ---
> The only reasonable fix on the compiler side is to never emit memcpy but
> always use memmove.
No, it can literally just emit (equivalent at whatever intermediate form of):
cmp src,dst
je 1f
call memcpy
1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112671
--- Comment #1 from Arsen Arsenović ---
yes, this also came up from the binutils side. see
https://inbox.sourceware.org/binutils/874jhg2x6p@adacore.com/
I will restore the modifications in the shared tree with the few other patches
I menti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112671
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Arsen Arsenović ---
[...]
> I will restore the modifications in the shared tree with the few other patches
> I mentioned on the GCC ML recently soon (I've ran a li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112671
--- Comment #3 from Arsen Arsenović ---
hm, actually, I think I confused reports - sorry.
do you know if this worked a short while ago? and if so, how did such a
configuration look?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112671
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Arsen Arsenović ---
> hm, actually, I think I confused reports - sorry.
>
> do you know if this worked a short while ago? and if so, how did such a
> configuratio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #27 from Jakub Jelinek ---
(In reply to Rich Felker from comment #26)
> > The only reasonable fix on the compiler side is to never emit memcpy but
> > always use memmove.
>
> No, it can literally just emit (equivalent at whatever in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Jakub Jelinek ---
> Strange. On cfarm211 which is
> SunOS gcc-solaris11 5.11 11.3 sun4u sparc SUNW,SPARC-Enterprise
> the test passes.
Can you check which libico
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652
--- Comment #3 from Jakub Jelinek ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > --- Comment #1 from Jakub Jelinek ---
> > Strange. On cfarm211 which is
> > SunOS gcc-solaris11 5.11 11.3 sun4u sparc SUNW,SPARC-Enterprise
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #31 from Li Pan ---
We still have some unnecessary code here, which is stack-related, will take
care of it in another PATCH.
After this patch:
test:
lui a5,%hi(.LANCHOR0)
addia5,a5,%lo(.LANCHOR0)
li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
--- Comment #5 from Jakub Jelinek ---
Just changing
--- i386.md.xx 2023-11-22 09:47:22.746637132 +0100
+++ i386.md 2023-11-22 20:38:07.216218697 +0100
@@ -9984,7 +9984,7 @@
[(set (match_operand: 0 "register_operand" "=r,A")
(mult
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112510
--- Comment #17 from Vladimir Sadovnikov ---
Reproducible with 11.4.0
~$ export ASAN_OPTIONS=detect_stack_use_after_return=1
~$ g++ -fsanitize=address -Og test-case.cpp
~$ ./a.out
Aborted (core dumped)
~$ gcc --version
gcc (Ubuntu 11.4.0-1ubun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #7 from Andrew Macleod ---
Explicit casts would be no problem as they go through the proper machinery. The
IL for that case has an explicit cast in it.
_1 = (int) x_2(D);
foo (_1);
its when that cast is not present,and we try t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112617
--- Comment #4 from CVS Commits ---
The master branch has been updated by John David Anglin :
https://gcc.gnu.org/g:a89224f819381b77657145fdd8b1d997b989fdc0
commit r14-5764-ga89224f819381b77657145fdd8b1d997b989fdc0
Author: John David Anglin
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106120
--- Comment #13 from CVS Commits ---
The master branch has been updated by Hans-Peter Nilsson :
https://gcc.gnu.org/g:e935151bad1c2a02dc6a31fce3cc21b17d616243
commit r14-5767-ge935151bad1c2a02dc6a31fce3cc21b17d616243
Author: Hans-Peter Nilsson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #30 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:990769a343f090088f5025ad233f88824b2c6263
commit r14-5769-g990769a343f090088f5025ad233f88824b2c6263
Author: Pan Li
Date: Mon Nov 13 11:
ed LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231122 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112336
--- Comment #3 from Jakub Jelinek ---
Seems one doesn't need the sanitizer for that,
unsigned _BitInt(1) v1;
unsigned _BitInt(1) *p1 = &v1;
ICEs as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112592
--- Comment #2 from CVS Commits ---
The master branch has been updated by John David Anglin :
https://gcc.gnu.org/g:6f59f959e751d73b371d52f9c657f78d7a77983c
commit r14-5765-g6f59f959e751d73b371d52f9c657f78d7a77983c
Author: John David Anglin
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #8 from Jakub Jelinek ---
(In reply to Andrew Macleod from comment #7)
> Alternatively, if IPA could figure out when things need promoting.. GCC
> must already do it, although I suppose thats in the front ends :-P
Well, in this cas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #6 from Jakub Jelinek ---
I don't know the IPA code enough to know whether different operand_type vs.
param_type (in the !types_compatible_p sense) means just user bug (in that case
returning VARYING is perfectly fine), or if it can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112633
--- Comment #4 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:3f266c84a15d63e42bfad46397fea9aff92b0720
commit r14-5763-g3f266c84a15d63e42bfad46397fea9aff92b0720
Author: Patrick Palka
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112633
--- Comment #6 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:63c65224e778124eee52acc7b9fcb32cd8ad61e8
commit r13-8090-g63c65224e778124eee52acc7b9fcb32cd8ad61e8
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112674
--- Comment #1 from Jeffrey A. Law ---
And possibly more interesting than the compare-debug failure is this patch
seems to be causing Wstringop-overflow-17 to fail on multiple targets,
including c6x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112617
John David Anglin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
--- Comment #7 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #5)
> Just changing
> --- i386.md.xx2023-11-22 09:47:22.746637132 +0100
> +++ i386.md 2023-11-22 20:38:07.216218697 +0100
> @@ -9984,7 +9984,7 @@
>[(s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112510
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112669
Thomas Schwinge changed:
What|Removed |Added
Last reconfirmed||2023-11-22
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #8)
> Well, in this case the user explicitly told compiler not to do that by not
> using a prototype and syntax which doesn't provide one from the definition.
> It i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:4f1ebd54380e16927cd0085be939165870354eac
commit r14-5768-g4f1ebd54380e16927cd0085be939165870354eac
Author: Costas Argyris
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #28 from Rich Felker ---
> No, that is not a reasonable fix, because it severely pessimizes common code
> for a theoretical only problem.
Far less than a call to memmove (which necessarily has something comparable to
that and other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506
Gaius Mulley changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Gaius Mulle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #46 from CVS Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:4f1ebd54380e16927cd0085be939165870354eac
commit r14-5768-g4f1ebd54380e16927cd0085be939165870354eac
Author: Costas Argyris
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112633
--- Comment #5 from Hana Dusíková ---
Thanks for really quick fix! You are awesome!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112670
--- Comment #1 from Robin Dapp ---
The problem is exposed with the ipa copy propagation pass. I haven't narrowed
it down yet but will continue tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112464
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112674
Bug ID: 112674
Summary: [14 Regression] Compare-debug failure after recent
change on c6x
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #29 from Patrick J. LoPresti ---
(In reply to Jakub Jelinek from comment #27)
>
> No, that is not a reasonable fix, because it severely pessimizes common code
> for a theoretical only problem.
The very existence of (and interest in)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112592
John David Anglin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-5761-20231122145100-ge9b39df9333-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231122 (experimental) (GCC)
At the asm output, the problem is obvious
1 - 100 of 117 matches
Mail list logo
