https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #31 from Richard Biener ---
(In reply to Patrick J. LoPresti from comment #29)
> (In reply to Jakub Jelinek from comment #27)
> >
> > No, that is not a reasonable fix, because it severely pessimizes common code
> > for a theoretical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112676
Bug ID: 112676
Summary: [14 regression] ICE in extract_insn, at recog.cc:2804
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112675
Bug ID: 112675
Summary: [14 Regression] r14-5385-g0a140730c97087 caused
regression on testcases
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
--- Comment #12 from Richard Biener ---
Created attachment 56668
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56668=edit
patch (not working)
So this tries this, moving the duplicate-and-interleave check and changing
code generation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #30 from post+gcc at ralfj dot de ---
There have been several assertions above that a certain way to solve this
either has no performance cost at all or severe performance cost. That sounds
like we are missing data -- ideally, someone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
--- Comment #25 from urs at akk dot org ---
(In reply to Haochen Jiang from comment #24)
> Patch aims to fix that:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637865.html
Yes, that solved the issue for me. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112661
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=112643
--- Comment #24 from Haochen Jiang ---
Patch aims to fix that:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637865.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
--- Comment #8 from Li Pan ---
For gcc.dg/torture/pr58955-2.c, we can simply reproduce it by options
Pass when: -O3
Pass when: -O3 -ftracer -fno-schedule-insns -fno-schedule-insns2
Fail when: -O3 -ftracer -fno-schedule-insns2
10154:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #5 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #4)
>
> I think
> Value_Range vr (operand_type);
> if (TREE_CODE_CLASS (operation) == tcc_unary)
> ipa_vr_operation_and_type_effects (vr,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112642
--- Comment #10 from Jonathan Wakely ---
(In reply to Miro Palmu from comment #9)
> Mine is 13.2.1 20230801 so way before Oct 21. (I did not know there were
> different snapshots of the releases, I'm just a user trying to help :) )
13.2.1 (and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734
--- Comment #5 from Julian Waters ---
Note: Trying this with a top level asm gives me:
$ g++ -O3 -flto=auto -std=c++14 -pedantic -Wpedantic -fno-omit-frame-pointer
exceptions.cpp
exceptions.cpp:8:1: error: expected unqualified-id before 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
--- Comment #3 from Andrew Pinski ---
parityhi2 should have:
rtx extra = gen_reg_rtx (HImode);
emit_move_insn (extra, operands[1]);
emit_insn (gen_parityhi2_cmp (extra));
Or something similar because parityqi2_cmp clobbers its argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112464
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
Andrew Pinski changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112336
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=112445
--- Comment #6 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #4)
> I think this goes wrong during combine.
Combine does not / should not combine moves from hard registers just because of
extending register live range. It looks
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:
m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=112592
John David Anglin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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=112445
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112464
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
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=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=112506
Gaius Mulley changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Gaius
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=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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112669
Thomas Schwinge changed:
What|Removed |Added
Last reconfirmed||2023-11-22
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 @@
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112510
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
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=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:
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=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=112336
--- Comment #3 from Jakub Jelinek ---
Seems one doesn't need the sanitizer for that,
unsigned _BitInt(1) v1;
unsigned _BitInt(1) *p1 =
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
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
ed LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231122 (experimental) (GCC)
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
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
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
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
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
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")
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)
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=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
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
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
>
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 #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
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
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
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=112344
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=111911
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
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=111922
Jakub Jelinek changed:
What|Removed |Added
CC||amacleod at redhat dot com,
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.
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=112668
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2023-11-22
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=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
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=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 #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=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=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
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
> +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
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
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
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
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 :
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=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=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
Ever confirmed|0 |1
CC|
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=111677
--- Comment #14 from Gianfranco ---
Hello, any news for this issue?
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
>
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=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=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())
{
//
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
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=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=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
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=112669
Bug ID: 112669
Summary: GCN: wrong 'LIBRARY_PATH' in presence of several
different '-march=[...]' flags
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
---
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=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
1 - 100 of 117 matches
Mail list logo
