https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59769
--- Comment #3 from Jonathan Wakely ---
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2467r0.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103435
Bug ID: 103435
Summary: gcc/gimple-ssa-store-merging.c:879:13: runtime error:
shift exponent 64 is too large for 64-bit type 'long
unsigned int'
Product: gcc
Ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103435
Martin Liška changed:
What|Removed |Added
Summary|gcc/gimple-ssa-store-mergin |[12 Regression]
|g.c:8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103429
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103436
Bug ID: 103436
Summary: gnatD debug info refers to original rather than
generated file
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80701
Richard Biener changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
Richard Biener changed:
What|Removed |Added
CC||gustavo.hime at mpimet dot
mpg.de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
Bug 46476 depends on bug 80701, which changed state.
Bug 80701 Summary: Option for generating link symbol for functions removed by
DCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80701
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
--- Comment #22 from Richard Biener ---
Created attachment 51876
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51876&action=edit
-Wunreachable-code at CFG construction time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
--- Comment #23 from Richard Biener ---
Created attachment 51877
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51877&action=edit
some fallout in GCC
This fixes some fallout appearant when bootstrapping with the patch, mostly
style, so not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239
--- Comment #4 from luoxhu at gcc dot gnu.org ---
Simply adjust the sequence of dot instruction could produce expected code, is
this correct?
foo:
.LFB0:
.cfi_startproc
rldicr. 3,3,29,1
beq 0,.L2
#APP
# 10 "pr102239.c"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103423
Martin Liška changed:
What|Removed |Added
Summary|[12 Regression] 19% cpu2006 |[12 Regression] 19% cpu2006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159
Jonathan Wakely changed:
What|Removed |Added
Keywords|ABI, wrong-code |documentation
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159
--- Comment #6 from Jonathan Wakely ---
(In reply to Martin Uecker from comment #3)
> "The four non-arithmetic functions (load, store, exchange, and
> compare_exchange) all have a generic version as well. This generic version
> works on any data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103423
--- Comment #3 from hubicka at kam dot mff.cuni.cz ---
> Oh, you are right, then it started with r12-2353-g8da8ed435e9f01b3.
OK so mine, (as I sort of suspected :)
If it is easy for you to get -ftime-report of before and after
build, it would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103432
--- Comment #3 from hubicka at kam dot mff.cuni.cz ---
Caused by stupid thinko (also present in gcc11). I compute right
min_flags but then use wrong value (without dereference applied).
I am testing the following.
diff --git a/gcc/ipa-modref.c b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103437
Bug ID: 103437
Summary: gcc/ira-color.c:2813:5: runtime error: signed integer
overflow: 15 * 147462000 cannot be represented in type
'int'
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102753
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8dedf065aff22b09bd4e48e1be0b77c58d297100
commit r12-5537-g8dedf065aff22b09bd4e48e1be0b77c58d297100
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103423
--- Comment #4 from Martin Liška ---
> If it is easy for you to get -ftime-report of before and after
> build, it would be great to attach it.
Please do it yourself, I'm doing another wrf long-running bisection.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227
--- Comment #14 from Jan Hubicka ---
Seems the performance is now better than before
https://lnt.opensuse.org/db_default/v4/SPEC/graph?highlight_run=21683&plot.0=286.407.0
Still I think I should implement the logic to stabilize the order of node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103430
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Last reconfi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395
Daniel Berrange changed:
What|Removed |Added
CC||berrange at redhat dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103431
--- Comment #2 from Martin Liška ---
Started with r12-4853-g2a83259f837e5cbd .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
Thomas Schwinge changed:
What|Removed |Added
See Also||http://gcc.gnu.org/bugzilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
--- Comment #25 from Richard Biener ---
Created attachment 51878
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51878&action=edit
-Wunreachable-code-return at GIMPLE lowering time
This is an alternative change only implementing -Wunreachab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103435
--- Comment #1 from Jakub Jelinek ---
Untested fix:
2021-11-26 Jakub Jelinek
PR tree-optimization/103435
* gimple-ssa-store-merging.c (find_bswap_or_nop_finalize): Avoid UB if
n->range - rsize == 8, just clear both *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
--- Comment #26 from Richard Biener ---
diff --git a/gcc/gimple-low.c b/gcc/gimple-low.c
index 18e66450977..dc56e14b605 100644
--- a/gcc/gimple-low.c
+++ b/gcc/gimple-low.c
@@ -60,7 +60,7 @@ typedef struct return_statements_t return_statements_t;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103437
--- Comment #1 from Richard Biener ---
Huh, how come - the code doesn't look like 147462000 could happen.
log2(int) * nregs * (costa - costb), so it's likely ALLOCNO_MEMORY_COST
or ALLOCNO_CLASS_COST. Maybe uninitialized?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103431
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811
--- Comment #6 from Uroš Bizjak ---
Created attachment 51879
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51879&action=edit
Improve HI/HFmode scalar insert
The attached patch further improves HFmode -> SFmode conversion. HFmode values
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811
--- Comment #7 from Uroš Bizjak ---
The improvement with patch from comment #6:
The testcase:
_Float16 test (_Float16 a, _Float16 b)
{
return a + b;
}
compiles with unpatched gcc -O2 -mf16c to:
vmovss %xmm0, %xmm0, %xmm2 # 27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103434
Dominique d'Humieres changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811
--- Comment #8 from Uroš Bizjak ---
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 68606e57e60..a2ebaa5ac63 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -2528,12 +2528,12 @@
case TYPE_SSELOG:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103438
Bug ID: 103438
Summary: Updated documentation for gcc Optimization command
line options (sec 3.11)
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
--- Comment #15 from Richard Earnshaw ---
It seems perverse to me that you have a standard named pattern in the x86
backend that is enabled, but then you somehow expect the generic parts of the
compiler to know that it shouldn't be used.
Eith
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27851
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103438
--- Comment #1 from Andrew Pinski ---
-fprefetch-loop-arrays is not enabled by default on all targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103438
--- Comment #2 from Jonathan Wakely ---
Thanks for the report, and the patch. After addressing Andrew's comment could
you please send a new patch to the gcc-patches mailing list for review? Patches
attached here tend to get missed or forgotten a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
--- Comment #16 from Jakub Jelinek ---
(In reply to Richard Earnshaw from comment #15)
> It seems perverse to me that you have a standard named pattern in the x86
> backend that is enabled, but then you somehow expect the generic parts of
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103438
--- Comment #3 from Andrew Pinski ---
Oh the "enabled" thing when doing --help is confusing in the case of
-fprefetch-loop-arrays:
fprefetch-loop-arrays
Common Var(flag_prefetch_loop_arrays) Init(-1) Optimization
Generate prefetch instructions,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101803
--- Comment #5 from Hannes Hauswedell ---
Thanks a lot for the fix! Any chance this will make into the 10.x branch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103431
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=103393
--- Comment #17 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Richard Earnshaw from comment #15)
> > It seems perverse to me that you have a standard named pattern in the x86
> > backend that is enabled, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103438
--- Comment #4 from Nils Smeds ---
(In reply to Andrew Pinski from comment #1)
> -fprefetch-loop-arrays is not enabled by default on all targets.
$ gcc --version
gcc (GCC) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
--- Comment #18 from Jakub Jelinek ---
No. Generic vectors need to work too. And those always do use the standard
optabs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
--- Comment #19 from Richard Earnshaw ---
It sounds to me like you're trying to keep your cake and eat it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
--- Comment #20 from Jakub Jelinek ---
The aarch64 MOVE_MAX definition of (UNITS_PER_WORD * 2) clearly doesn't match
the documentation, because with Neon/SVE around, you can move quickly much more
bytes by a single instruction than that. And th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
--- Comment #27 from Richard Biener ---
(In reply to Richard Biener from comment #25)
> Created attachment 51878 [details]
> -Wunreachable-code-return at GIMPLE lowering time
...
> At least this patch passes bootstrap and would have found one rea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103439
Bug ID: 103439
Summary: genemit emits dead code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Ass
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211126 (experimental) [master r12-4647-g3f861a5c8fd] (GCC)
[672] %
[672] % gcctk -O1 small.c; ./a.out
[673] %
[673] % gcctk -Os small.c
[674] % timeout -s 9 10 ./a.out
Killed
[675] %
[675] % cat small.c
int a, b, c, d, e;
int main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409
Martin Liška changed:
What|Removed |Added
Summary|[12 Regression] 18% |[12 Regression] 18%
|S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
--- Comment #21 from Richard Biener ---
Note using MOVE_RATIO in gimple-fold but then always emitting just a single
stmt and not honoring MOVE_MAX on that is fishy - you seem to be expecting RTL
expansion to fix up but that's clearly not happeni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103439
--- Comment #1 from Uroš Bizjak ---
(In reply to Richard Biener from comment #0)
> I'm not sure if there are valid cases where we have a mix of a direct
> RTL pattern and manual expansion, so where the { } part falls thru.
Yes, we have quite so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811
--- Comment #9 from Hongtao.liu ---
(In reply to Uroš Bizjak from comment #8)
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index 68606e57e60..a2ebaa5ac63 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103439
--- Comment #2 from rguenther at suse dot de ---
On Fri, 26 Nov 2021, ubizjak at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103439
>
> --- Comment #1 from Uroš Bizjak ---
> (In reply to Richard Biener from comment #0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409
Jan Hubicka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103438
Richard Biener changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #29 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:a70faf6e4df7481c2c9a08a06657c20beb3043de
commit r12-5538-ga70faf6e4df7481c2c9a08a06657c20beb3043de
Author: Jan Hubicka
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103438
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103432
Jan Hubicka changed:
What|Removed |Added
Summary|[12 regression] libjxl-0.5 |[11 regression] libjxl-0.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103432
--- Comment #5 from Martin Liška ---
> GCC 11 is also affected, so I will backport it there are tonight testing.
Please fix the PR number in the backports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
--- Comment #22 from Richard Earnshaw ---
Looking at the different port definitions for MOVE_MAX, it would appear that
only the i386 port seems to be using a value that is not the size of a
general-purpose register.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101608
--- Comment #4 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:d0ac292c6083fab4bad79a08d23533f537a885d4
commit r10-10296-gd0ac292c6083fab4bad79a08d23533f537a885d4
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811
--- Comment #10 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #7)
> compiles with unpatched gcc -O2 -mf16c to:
>
> vmovss %xmm0, %xmm0, %xmm2 # 27[c=4 l=4] *movhf_internal/3
> pextrw $0, %xmm1, -4(%rsp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103439
--- Comment #3 from Uroš Bizjak ---
(In reply to rguent...@suse.de from comment #2)
> On Fri, 26 Nov 2021, ubizjak at gmail dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103439
> >
> > --- Comment #1 from Uroš Bizjak ---
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103438
--- Comment #7 from Nils Smeds ---
(In reply to Martin Liška from comment #6)
> Lemme take a look.
Great, thanks.
What happens in real life inside the code is beyond me, I am mostly after that
the documentation should describe what is really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811
--- Comment #11 from Hongtao.liu ---
> The above dumps show inconsistendy for PEXTRW (it should be VPEXTRW) and
> also open a question, why unpatched gcc prefers memory temp instead of GPR
> temp for PEXTRW/PINSRW.
>
Because RA thought memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98723
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103431
--- Comment #5 from Jakub Jelinek ---
Created attachment 51881
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51881&action=edit
gcc12-pr103431-wip.patch
I've tried this, but that is actually incorrect too.
Because for operands[1], what we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811
--- Comment #12 from Hongtao.liu ---
>
> Just noticed that for some reason two VPXORs are emitted. One should be
> enough for both VPINSRW insns.
With new alternative in your attached match(vpblenw one), RA could reuse zero
register, w/o that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103439
--- Comment #4 from Richard Biener ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to rguent...@suse.de from comment #2)
> > On Fri, 26 Nov 2021, ubizjak at gmail dot com wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103440
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395
--- Comment #18 from Jakub Jelinek ---
Note that we document how the size of asm is estimated:
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
and unfortunately asm inline ("..." ...) makes the size estimation 0 only for
inlining purposes a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811
--- Comment #13 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #12)
> >
> > Just noticed that for some reason two VPXORs are emitted. One should be
> > enough for both VPINSRW insns.
>
> With new alternative in your attached match(
trunk 20211126:
0x109eb913 crash_signal
../../src/gcc/toplev.c:322
0x1046f94c cgraph_node::verify_node()
../../src/gcc/cgraph.c:3582
0x1045adc3 symtab_node::verify()
../../src/gcc/symtab.c:1358
0x10a894f3 optimize_inline_calls(tree_node*)
../../src/gcc/tree-inline.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103432
Richard Biener changed:
What|Removed |Added
Target Milestone|12.0|11.3
Priority|P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103442
Bug ID: 103442
Summary: [12 Regression] trunk 20211126 ICE (segfault) in
cgraph_node::verify_node() building the 32bit libgo on
s390x-linux-gnu
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103442
Richard Biener changed:
What|Removed |Added
Keywords||build
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103441
Richard Biener changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Target Mil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103440
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
Summary|[12 Regression] wron
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101608
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103303
--- Comment #3 from Felix Wang ---
Could I assume this is a compiler bug in layout engine?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103443
Bug ID: 103443
Summary: consteval function rejected as constant expression
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103441
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103441
--- Comment #2 from Martin Liška ---
@Martin: Can you please take a look? It's a ISRA clone of a CP clone :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103437
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103437
--- Comment #3 from Martin Liška ---
With:
diff --git a/gcc/ira-costs.c b/gcc/ira-costs.c
index cb5ca8bc21b..ac993a9fa7d 100644
--- a/gcc/ira-costs.c
+++ b/gcc/ira-costs.c
@@ -1241,7 +1241,10 @@ record_address_regs (machine_mode mode, addr_spac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103437
--- Comment #4 from Martin Liška ---
Created attachment 51882
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51882&action=edit
Dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103442
--- Comment #1 from Martin Liška ---
Very likely dup of PR103441.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811
--- Comment #14 from Hongtao.liu ---
(In reply to Uroš Bizjak from comment #13)
> (In reply to Hongtao.liu from comment #12)
> > >
> > > Just noticed that for some reason two VPXORs are emitted. One should be
> > > enough for both VPINSRW insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103441
--- Comment #3 from hubicka at kam dot mff.cuni.cz ---
> #0 gimple_set_bb (stmt=0x3fffb01a2be0, bb=0x0) at ../../gcc/gimple.c:1772
> #1 0x107209b0 in gsi_remove (i=0x3fffd7c8,
> remove_permanently=) at ../../gcc/gimple-iterator.c:56
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159
--- Comment #7 from Martin Uecker ---
I do not think these functions are meant only as internal tools to implement
the language features.
We also seem to agree that the documentation implies that there should work for
all types and does not c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103431
Jakub Jelinek changed:
What|Removed |Added
Attachment #51881|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103441
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101870
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:a2139a9a95e624f99f470191335495d02254e1f1
commit r10-10301-ga2139a9a95e624f99f470191335495d02254e1f1
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101870
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|11.3|10.4
--- Comment #6 from Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103441
Andreas Schwab changed:
What|Removed |Added
Target|powerpc64le-linux-gnu |powerpc64le-linux-gnu,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239
--- Comment #5 from Segher Boessenkool ---
(In reply to luoxhu from comment #4)
> Simply adjust the sequence of dot instruction could produce expected code,
> is this correct?
No it isn't. Sorry.
> foo:
> .LFB0:
> .cfi_startproc
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811
--- Comment #15 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #14)
> (In reply to Uroš Bizjak from comment #13)
> > (In reply to Hongtao.liu from comment #12)
> > > >
> > > > Just noticed that for some reason two VPXORs are emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811
--- Comment #16 from Hongtao.liu ---
(In reply to Uroš Bizjak from comment #15)
> (In reply to Hongtao.liu from comment #14)
> > (In reply to Uroš Bizjak from comment #13)
> > > (In reply to Hongtao.liu from comment #12)
> > > > >
> > > > > Jus
1 - 100 of 176 matches
Mail list logo
