https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118920
Nathaniel Shead changed:
What|Removed |Added
CC||nshead at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118920
--- Comment #6 from Nathaniel Shead ---
In particular, it looks like the issue is that the forward-declared `out_ptr`
via 's instantiation of '__shared_ptr<__cxx11::_Impl>' inherits an
abi_tag attribute, but the declaration in does not have it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935
--- Comment #4 from chenglulu ---
(In reply to Thomas Koenig from comment #3)
> Is this a target or a libgfortran bug, then?
I'm not sure about this either, but if I understand correctly, the u->s in
find_file0 should not be modified in this fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118920
--- Comment #4 from Frank B. Brokken ---
Dear pinskia at gcc dot gnu.org, you wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118920
>
> --- Comment #3 from Andrew Pinski ---
> (In reply to Frank B. Brokken from comment #2)
> > ...
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118937
Bug ID: 118937
Summary: DO CONCURRENT: Add a warning if 'SHARED' (or
LOCAL(_INIT)) is not specified but multiple loop
iterations modify a variable
Product: gcc
V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118805
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #3)
> It is due to r15-7575.
Eh, r15-7573.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
--- Comment #5 from Uroš Bizjak ---
For func_40 the new ix86_find_max_used_stack_alignment finds stack_alignment =
256.
The only access with 256 bit alignment in func_40 is:
101: [`g_1679']=xmm0:V2DI
103: [const(`g_1679'+0x10)]=xmm0:V2DI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
--- Comment #6 from H.J. Lu ---
This works:
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 560e6525b56..f5d46296570 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -8494,7 +8494,7 @@ ix86_find_all_reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
--- Comment #7 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #6)
> This works:
>
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index 560e6525b56..f5d46296570 100644
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115218
--- Comment #3 from Jonathan Wakely ---
(In reply to Patrick Palka from comment #1)
> Does this also mean the iterator's default ctor needs a
> default_initializable<_Vs...[0]> constraint?
Yes, I think the default ctor should get deleted if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115218
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Patrick Palka from comment #1)
> > Does this also mean the iterator's default ctor needs a
> > default_initializable<_Vs...[0]> constraint?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118918
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118922
Sam James changed:
What|Removed |Added
Summary|[13/14/15 regression] |[13/14/15 regression]
|Mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
--- Comment #18 from Brecht Sanders ---
Thanks for you work on this.
My goal is to eventually have native binutils+GCC on Windows ARM64.
I tried using sources from:
https://github.com/Windows-on-ARM-Experiments/binutils-woarm64
https://github.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118931
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118925
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118908
--- Comment #5 from Jonathan Wakely ---
https://gcc.gnu.org/gcc-15/porting_to.html#header-dep-changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935
--- Comment #5 from Xi Ruoyao ---
I guess we have a race condition here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116351
--- Comment #6 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:25256ec1df10f2eb183e1c1ab0c890e9fdd94384
commit r15-7625-g25256ec1df10f2eb183e1c1ab0c890e9fdd94384
Author: Pan Li
Date: Wed Feb 19 09:3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #103 from LIU Hao ---
New test results on master:
```
UCRT64 ~/Desktop
$ cat test.c
extern __thread int i[8];
int foo (void)
{
return i[2] + i[4];
}
UCRT64 ~/Desktop
$ x86_64-w64-mingw32-gcc --version
x86_64-w64-mingw32-gcc.exe (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
--- Comment #9 from Uroš Bizjak ---
Also wrong is this part:
+static void
+ix86_find_all_reg_use_1 (rtx set, HARD_REG_SET &stack_slot_access,
+auto_bitmap &worklist)
+{
+ rtx dest = SET_DEST (set);
+ if (!REG_P (dest))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118300
--- Comment #5 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:58b90139e093aeb5494627d92257a97aebb4a6d9
commit r15-7626-g58b90139e093aeb5494627d92257a97aebb4a6d9
Author: David Malcolm
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118919
--- Comment #2 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:ee6619b1246b38cfb36f6efd931a6f475a9033c7
commit r15-7627-gee6619b1246b38cfb36f6efd931a6f475a9033c7
Author: David Malcolm
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
Bug ID: 118938
Summary: C++ compiler fails to build for m68k-linux-gnu
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116351
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118934
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
Summary|RISC-V: ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115218
--- Comment #5 from Patrick Palka ---
Ah right, the constraint is implicitly there since the variant data member
doesn't have an NSDMI. I was thinking of the case where we're default
initializing via an NSDMI and so we need to explicitly the de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115218
--- Comment #6 from Patrick Palka ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Patrick Palka from comment #1)
> > Does this also mean the iterator's default ctor needs a
> > default_initializable<_Vs...[0]> constraint?
> Asid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118923
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
--- Comment #8 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #7)
> (In reply to H.J. Lu from comment #6)
> > This works:
> >
> > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> > index 560e6525b56..f5d46296570 100644
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
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=118922
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
--- Comment #13 from Jan Hubicka ---
Thanks for running this through debugger
Breakpoint 2.2, profile_count::operator+= (this=0x76e7e888, other=...) at
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/profile-count.h:932
932
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118915
Sam James changed:
What|Removed |Added
Keywords|needs-bisection |
Summary|[12/13/14/15 Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118521
--- Comment #7 from Jeffrey A. Law ---
In the simplified testcase we have:
[local count: 131235111]:
MEM [(char * {ref-all})_53] = MEM [(char
* {ref-all})&C.0];
__result_46 = _53 + 2;
_150 = operator new (4);
goto ; [100.00%]
So _150 poin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118915
--- Comment #6 from Krister Walfridsson ---
(In reply to Andrew Pinski from comment #3)
> I am kinda of shock that smtgcc didn't find this earlier.
My guess is that the relevant testcases are written similarly to
```
int main() {
if (b(a + 21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
--- Comment #2 from Waldemar Brodkorb ---
with following command:
/home/wbx/openadk/toolchain_build_qemu-m68k-q800_glibc_68040/w-gcc-14.2.0-1/gcc-14.2.0/configure
--prefix=/home/wbx/openadk/toolchain_qemu-m68k-q800_glibc_68040/usr
--with-bugurl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118922
--- Comment #8 from Richard Biener ---
(In reply to Sam James from comment #7)
> Started with r13-6945-g429a7a88438cc8, ccing andrew
Works with --param ranger-recompute-depth=1, fails with
--param ranger-recompute-depth=2 (or higher)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
--- Comment #10 from Uroš Bizjak ---
IMO, the original patch that caused ICE is not ready to be committed. HJ, can
you please revert the original patch (+ my dependant patch)?
We will try again for gcc-16.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118919
--- Comment #3 from David Malcolm ---
Should be fixed on trunk for gcc 15 by the above patch.
Keeping this bug open to track backporting to gcc 13 and 14 which presumably
are also affected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118300
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2025-02-19
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
--- Comment #1 from Mikael Pettersson ---
How did you configure this gcc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
--- Comment #14 from Sam James ---
(In reply to Jan Hubicka from comment #13)
> Thanks for running this through debugger
> Breakpoint 2.2, profile_count::operator+= (this=0x76e7e888, other=...)
> at
> /usr/src/debug/sys-devel/gcc-15.0./g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118915
--- Comment #7 from Sam James ---
In some older testcases, you may see (__builtin_)exit(1) as well, but it's not
common. Thanks for looking!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
--- Comment #3 from Mikael Pettersson ---
Is that before or after you built the target glibc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
--- Comment #4 from Andrew Pinski ---
--enable-cxx-flags=-fPIC
I am not sure why you are using that but this while building the -mcpu=68000
multi-lib.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939
Bug ID: 118939
Summary: ada: executable segfaults on arm-linux-gnueabi when
assigning an access to controlled type
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118521
Jeffrey A. Law changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
Bug ID: 118940
Summary: [x86] inline assembly fails with 'asm' operand has
impossible constraints or there are not enough
registers
Product: gcc
Version: 15.0
from their respective masters as of
19 February 2025 in one-tree style, a build targeting tic6x-elf fails if C++ is
enabled. When built for just C, gcc reports this as the version:
tic6x-elf-gcc (GCC) 15.0.1 20250219 (experimental)
After enabling C++, failure output is as follows:
libtool: compi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
Sam James changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #13 from Sam James
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
Sam James changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
Summ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
Sam James changed:
What|Removed |Added
Component|c |target
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
Andrew Pinski changed:
What|Removed |Added
CC||joel at gcc dot gnu.org
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
Andrew Pinski changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #12 from Andrew Pinski --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118941
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
--- Comment #5 from Waldemar Brodkorb ---
(In reply to Mikael Pettersson from comment #3)
> Is that before or after you built the target glibc?
It is after target glibc build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #3 from Miao Wang ---
(In reply to Andrew Pinski from comment #2)
> I am suspect the inline-asm is just broken rather than the compiler being
> broken ...
However, by replacing the inline-asm with a simple nop, the issue persists. B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #2 from Andrew Pinski ---
I am suspect the inline-asm is just broken rather than the compiler being
broken ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
--- Comment #11 from Andrew Pinski ---
Created attachment 60533
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60533&action=edit
Reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118942
Bug ID: 118942
Summary: [14/15 Regression] vld1q_s{8,16}_x{3,4} use incorrect
pointer type
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Keywords: rejects-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110645
--- Comment #2 from Jeffrey A. Law ---
In the bowels of the relevant code, if we don't know the range of the source
size, then we set is to the range of the destination size. I vaguely recall
Martin doing this, but nothing about the reasoning b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118914
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #9 from Hongtao Liu ---
>
> > Because I think the operands usage is broken.
>
> Additionally, by removing the do{ ... } while(0) wrap from
> bigint_test_exec(), the issue disappears. I believe that if it is the
> operands usage is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #10 from Miao Wang ---
(In reply to Hongtao Liu from comment #9)
> >
> > > Because I think the operands usage is broken.
> >
> > Additionally, by removing the do{ ... } while(0) wrap from
> > bigint_test_exec(), the issue disappear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
--- Comment #16 from Jeffrey A. Law ---
Even if it doesn't help this diagnostic, it would be a good thing to do since
it would make the second conditional statically computable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #11 from Hongtao Liu ---
(In reply to Miao Wang from comment #10)
> (In reply to Hongtao Liu from comment #9)
> > >
> > > > Because I think the operands usage is broken.
> > >
> > > Additionally, by removing the do{ ... } while(0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118948
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209
--- Comment #4 from 康桓瑋 ---
> Our concat_view implementation is accidentally based off of an older
> revision of the paper, P2542R7 instead of R8. As far as I can tell the
> only semantic change in the final revision is the relaxed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #6 from Andrew Pinski ---
(In reply to Miao Wang from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > I am suspect the inline-asm is just broken rather than the compiler being
> > broken ...
>
> However, by replacing t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
Waldemar Brodkorb changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118944
Bug ID: 118944
Summary: deduced conflicting types for explicitly specified
(non-deduced) template parameter in explicit object
member function of struct template
Product: g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114592
Jeffrey A. Law changed:
What|Removed |Added
Summary|[12/13/14/15 regression]|[12/13/14 regression] Bogus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 117204, which changed state.
Bug 117204 Summary: [12/13/14/15 regression] After r12-2132-ga1108556677, bogus
-Warray-bounds warnings in std::vector::back()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117204
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117204
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111696
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 110764, which changed state.
Bug 110764 Summary: [12/13/14/15 Regression] False positive -Warray-bounds
warning swapping std::thread::id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
See Als
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
--- Comment #7 from Waldemar Brodkorb ---
This code was the culprit:
https://cgit.openadk.org/cgi/cgit/openadk.git/tree/toolchain/gcc/Makefile#n327
I have once got it from simplelinux from Greg Ungerer for coldfire/m68k builds.
I don't remember
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
--- Comment #2 from Andrew Pinski ---
_304 = _113 != 0;
_373 = _113 == 0;
_305 = _132 != 0;
_377 = _132 == 0;
_597 = () _377;
_598 = [vec_duplicate_expr] _597;
_599 = _359 + 20;
_602 = VIEW_CONVERT_EXPR(_305);
_603 = [vec_dupli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
--- Comment #3 from Andrew Pinski ---
Note I think -O3 -fwhole-program is enough to reproduce it and you don't need
-flto.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
Bug ID: 118945
Summary: RISC-V: VSETL pass: Don't promote Vectors ops from
Tail agnostic to Tail Undisturbed
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #5 from Andrew Pinski ---
Note I suspect using C with some (generic) builtins might be faster than what
the inline-asm could provide these days than the inline-asm that was used. Plus
I doubt the speed of big-int would ever be the bo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
--- Comment #1 from Vineet Gupta ---
Looking at the VSETVL dumps:
Splitting with gen_split_2313 (vector.md:1777)
scanning new insn with uid = 70. # New VSETVL for vector load
deleting insn with uid = 16. # or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118914
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
--- Comment #3 from Vineet Gupta ---
(In reply to JuzheZhong from comment #2)
> I have thought about this long time ago while I am working on supporting RVV
> on upstream GCC.
>
> https://github.com/riscv-non-isa/riscv-toolchain-conventions/iss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118938
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118914
--- Comment #3 from Andrew Pinski ---
Created attachment 60536
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60536&action=edit
patch under testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #8 from Miao Wang ---
(In reply to Andrew Pinski from comment #5)
> Note I suspect using C with some (generic) builtins might be faster than
> what the inline-asm could provide these days than the inline-asm that was
> used. Plus I d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118940
--- Comment #7 from Miao Wang ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Miao Wang from comment #3)
> > (In reply to Andrew Pinski from comment #2)
> > > I am suspect the inline-asm is just broken rather than the compiler bei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116604
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118914
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
--- Comment #4 from Vineet Gupta ---
The following hack does prevent the fusion
+ inline bool tail_policy_eq2_p (const vsetvl_info &prev,
+const vsetvl_info &next)
+ {
+return (((prev.get_policy_demand () =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114360
Jeffrey A. Law changed:
What|Removed |Added
Summary|[12/13/14/15 regression]|[12/13/14 regression] Bogus
1 - 100 of 141 matches
Mail list logo
