https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
--- Comment #1 from Andrew Pinski ---
Which version is your host compiler?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
Sam James changed:
What|Removed |Added
Blocks||84402
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562
Richard Biener changed:
What|Removed |Added
Target||i?86-*-*
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112861
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #7 from Iain Sandoe ---
Created attachment 57202
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57202&action=edit
patch under test
works on x86_64 Sonoma with XC CLT 15.1
testing more widely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
--- Comment #19 from rguenther at suse dot de ---
On Tue, 23 Jan 2024, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
>
> --- Comment #13 from Andrew Pinski ---
> (In reply to Yuxuan Shui from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113559
Gaius Mulley changed:
What|Removed |Added
Last reconfirmed||2024-01-24
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
--- Comment #4 from Matthias Klose ---
same version, r14-8314-g29f931e39f2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
--- Comment #16 from rguenther at suse dot de ---
On Wed, 24 Jan 2024, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
>
> --- Comment #15 from Andrew Pinski ---
> (In reply to Richard Biener from comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113560
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
--- Comment #17 from Andrew Pinski ---
(In reply to rguent...@suse.de from comment #16)
> On Wed, 24 Jan 2024, pinskia at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
> >
> > --- Comment #15 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113559
--- Comment #2 from Gaius Mulley ---
Created attachment 57204
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57204&action=edit
Proposed fix
Here is the proposed patch - it passes the regression test on x86_32 and
x86_64. The full bootstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113558
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Robin Dapp ---
> Would you mind giving the attached patch a try? I ran it on riscv and power10
> so far, x86 and aarch64 are still in progress.
Sure: I tested th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113571
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #6 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
--- Comment #7 from Robin Dapp ---
Ok, I'm going to check.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113560
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113560
--- Comment #4 from accelerator0099 at gmail dot com ---
Well, I hope gcc will just generate mulx instruction on arch with BMI2. Let's
look at the AMD64 Architecture Programmer’s Manual Volume 3:
Computes the unsigned product of the specified sou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
--- Comment #8 from Richard Biener ---
My host compiler (x86_64, older trunk) uses "just" 800MB. 3.5GB looks like a
runaway? What uarch is your i586 compiler targeting?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113560
--- Comment #5 from accelerator0099 at gmail dot com ---
If we are using an arch without BMI2, we can use single MUL instruction
instead. Here is the description of MUL reg64/mem64.
Multiplies a 64-bit register or memory operand by the contents o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113556
Rainer Orth changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113559
Gaius Mulley changed:
What|Removed |Added
Attachment #57204|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
--- Comment #10 from Richard Biener ---
btw, -fno-var-tracking also greatly improves compile-time (but does nothing to
memory use). Compiling with -O1 reduces memory use to 300MB even when
var-tracking is enabled. So an option might be to forc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
--- Comment #18 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #17)
> (In reply to rguent...@suse.de from comment #16)
> > On Wed, 24 Jan 2024, pinskia at gcc dot gnu.org wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
--- Comment #19 from rguenther at suse dot de ---
On Wed, 24 Jan 2024, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
>
> --- Comment #17 from Andrew Pinski ---
> (In reply to rguent...@suse.de from co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113565
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #3 from Jonat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110679
--- Comment #3 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #2)
> *** Bug 113543 has been marked as a duplicate of this bug. ***
^^ N.B. this has a number of other testcases for the missed optimizations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
--- Comment #20 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #18)
> But they are not correct for logical right shifts and they don't handle left
> shifts.
Oh, and then there are rotates and I think we need to punt on those, th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113565
--- Comment #4 from Jan Schultke ---
I would expect an error here because things that are undefined behavior are
generally supposed to fail in constant expressions. I don't see a good reason
why builtins should be exempt from that rule.
The lac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
Bug ID: 113576
Summary: [14 regression] 502.gcc_r hangs
r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #1 from Hongtao Liu ---
int
__attribute__((noinline))
sbitmap_first_set_bit (const_sbitmap bmap)
{
unsigned int n = 0;
sbitmap_iterator sbi;
EXECUTE_IF_SET_IN_SBITMAP (bmap, 0, n, sbi)
return n;
return -1;
}
hangs on th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79193
--- Comment #7 from Jonathan Wakely ---
Sandra, does the commit above fix this?
You mentioned it not being fully general, but is it good enough?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113565
--- Comment #5 from Jan Schultke ---
You can reproduce this as follows:
> static_assert(__builtin_clz(0u) == 32);
>
> unsigned x = 0;
>
> int main() {
> return __builtin_clz(x);
> }
For base x86_64, GCC emits: (https://godbolt.org/z/nqz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113559
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Gaius Mulley ---
> Created attachment 57205
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57205&action=edit
> Proposed fix v2
>
> Correction the cast shou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|2022-05-23 00:00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67067
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-01-24
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113560
--- Comment #6 from Roger Sayle ---
In the .optimized dump, we have:
__int128 unsigned __res;
__int128 unsigned _12;
...
__res_11 = in_2(D) w* 184467440738;
_12 = __res_11 & 18446744073709551615;
__res_7 = _12 * 100;
So the first mu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562
--- Comment #2 from Richard Biener ---
So the first difference is
@@ -4076,36 +4076,47 @@
fbt (0x7700b468: (reg/f:SI 16 argp)) == (address:SI -4)
fbt (0x771f6a68: (plus:SI (minus:SI (value/u/j:SI 13:4329
@0x4a213b0/0x498b
600)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324
Sam James changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113577
Bug ID: 113577
Summary: GCC crashes with co_await expression in
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
Bug ID: 113578
Summary: Incorrect signbit for -nan on RISC-V
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
Jonathan Wakely changed:
What|Removed |Added
Summary|Incorrect signbit for -nan |Incorrect sign printed for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113579
Bug ID: 113579
Summary: GCC leaks memory inside when using statement
expressions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113580
Bug ID: 113580
Summary: -Wunused-parameter in template imported from module
causes segmentation fault
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113581
Bug ID: 113581
Summary: Ignoring GCC unroll loop annotation for loops with
increment in condition
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113581
--- Comment #1 from Jan Schultke ---
Oh, I probably should have mentioned this: This only happens when times_three
is a function template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113579
--- Comment #1 from Richard Biener ---
I think we somewhere document that control transfer into / out of stmt
expressions invokes undefined behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
--- Comment #2 from Joseph S. Myers ---
If a conversion from float to double (for passing in variable arguments) occurs
at runtime on RISC-V, that will produce a positive-signed NaN (that's what the
RISC-V floating-point instructions do). Cf.
ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113556
--- Comment #2 from GCC Commits ---
The master branch has been updated by Rainer Orth :
https://gcc.gnu.org/g:b8f54195edbecd7151095f137f9ff27e1ddc8e36
commit r14-8388-gb8f54195edbecd7151095f137f9ff27e1ddc8e36
Author: Rainer Orth
Date: Wed J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113510
--- Comment #6 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #5)
> Yes the peephole2 in thumb1.md looks wrong:
> ```
> ;; Reloading and elimination of the frame pointer can
> ;; sometimes cause this optimization to be missed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113556
Rainer Orth changed:
What|Removed |Added
Status|NEW |RESOLVED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113559
--- Comment #5 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:3de031c96f28f19a68ea2080260d8fd2c78828ee
commit r14-8389-g3de031c96f28f19a68ea2080260d8fd2c78828ee
Author: Gaius Mulley
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67067
Rainer Orth changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113559
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #16 from Sergey Fedorov ---
(In reply to Andrew Pinski from comment #13)
> Oh yes there could be a bug here when the byte (lbarx/stbcx.) and half-word
> (lharx/sthcx.) instruction support was added (which was for Power8;
> r0-123873-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
--- Comment #21 from Jakub Jelinek ---
So, I think
--- gcc/tree-vect-patterns.cc.jj2024-01-03 11:51:37.487648527 +0100
+++ gcc/tree-vect-patterns.cc 2024-01-24 14:05:55.911356481 +0100
@@ -3002,6 +3002,12 @@ vect_recog_over_widening_pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #3 from Richard Biener ---
So the change enables early exit vectorization since may_be_zero is _10 == 0
here, resulting in an overall
number_of_iterationsm1 == _10 != 0 ? _10 + 4294967295 : 0
and
number_of_iterations = MAX_EXPR <_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110779
Gaius Mulley changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
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=113582
Bug ID: 113582
Summary: incorrect warning about unused label
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113485
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #5 from Richard Biener ---
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index fe631252dc2..28ad03e0b8a 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -991,8 +991,12 @@ vec_init_loop_exit_info (class l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112861
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Sandoe ---
> Created attachment 57201
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57201&action=edit
> patch under test
>
> works on x86_64 sonoma,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539
Filip Kastl changed:
What|Removed |Added
CC||fkastl at suse dot cz
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539
--- Comment #7 from Filip Kastl ---
I just reproduced the same issue on an x86_64 zen3 machine. Running both
500.perlbench_r and 400.perlbench with options -Ofast -march=native
-mtune=native -g -flto=32 results in
*** Miscompare of checkspam.25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113581
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
Bug ID: 113583
Summary: Main loop in 519.lbm not vectorized.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113582
--- Comment #1 from Nikolay Mihaylov ---
If you move the pragma outside the templated function, no warning is shown:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-label"
template
void do_something(){
start:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553
--- Comment #1 from Rainer Orth ---
The build works for me just fine on sparc-sun-solaris2.11.
I've also fired one off on sparc64-unknown-linux-gnu which worked just as well.
It was a rough ride, however, with the build aborting with
xgcc: fat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
--- Comment #1 from JuzheZhong ---
It's interesting, for Clang only RISC-V can vectorize it.
I think there are 2 topics:
1. Support vectorization of this codes of in loop vectorizer.
2. Transform gather/scatter into strided load/store for RISC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
--- Comment #2 from Robin Dapp ---
> It's interesting, for Clang only RISC-V can vectorize it.
The full loop can be vectorized on clang x86 as well when I remove the first
conditional (which is not in the snippet I posted above). So that's lik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #8 from Rainer Orth ---
Again tested on macOS 11 (unchanged) and 14. On the latter, the previous
failures
to find libatomic.1.dylib have been traded for
FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=single -O2 (test for
ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #9 from Iain Sandoe ---
(In reply to Rainer Orth from comment #8)
> Again tested on macOS 11 (unchanged) and 14. On the latter, the previous
> failures
> to find libatomic.1.dylib have been traded for
>
> FAIL: gfortran.dg/coarray/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113485
Richard Sandiford changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #7 from Richar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863
--- Comment #4 from Rainer Orth ---
On macOS 11, everything is still fine. On macOS 14, there's progress:
* Before your patch:
=== obj-c++ Summary ===
# of expected passes2813
# of unexpected failures378
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
--- Comment #3 from JuzheZhong ---
Ok I see.
If we change NN into 8, then we can vectorize it with load_lanes/store_lanes
with group size = 8:
https://godbolt.org/z/doe9c3hfo
We will use vlseg8e64 which is RVVM1DF[8] == RVVM1x8DFmode.
Here t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Iain Sandoe ---
> (In reply to Rainer Orth from comment #8)
>> Again tested on macOS 11 (unchanged) and 14. On the latter, the previous
>> failures
>> to find li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112977
--- Comment #2 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:e503f9aca9192654d83f141ae7865a3c9d90bf0d
commit r14-8391-ge503f9aca9192654d83f141ae7865a3c9d90bf0d
Author: David Malcolm
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112927
--- Comment #1 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:b6e537571c21d8f0bc276d7afa156d6d4a54a1c9
commit r14-8390-gb6e537571c21d8f0bc276d7afa156d6d4a54a1c9
Author: David Malcolm
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113584
Bug ID: 113584
Summary: ICE in unify, at cp/pt.cc:24640 with template
specialization on 2 matching template template
parameter
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113490
--- Comment #6 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:bc4a20bc57ce71da0a96bcc6ec5683640b9004d6
commit r14-8392-gbc4a20bc57ce71da0a96bcc6ec5683640b9004d6
Author: Martin Jambor
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113490
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #11 from Iain Sandoe ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #10)
> > --- Comment #9 from Iain Sandoe ---
> > (In reply to Rainer Orth from comment #8)
> >> Again tested on macOS 11 (unchanged) and 14. On the la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113141
Patrick Palka changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #5 from P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113520
--- Comment #8 from Jan Hubicka ---
I think the ipa-cp summaries should be used only when types match. At least
Martin added type streaming for all the jump functions. So we are missing some
check?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110075
--- Comment #5 from Marek Polacek ---
Yes, because we'd have to analyze the body of the function to see that it does
not return one of the parameters, which often we can't do.
There will be an attribute soon to suppress that warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113585
Bug ID: 113585
Summary: Poor codegen turning int compare into -1,0,1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113552
--- Comment #12 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:306713c953d509720dc394c43c0890548bb0ae07
commit r14-8393-g306713c953d509720dc394c43c0890548bb0ae07
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109636
--- Comment #12 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:dfa17fd3b1a50cab51803e8a63c5c7b7db173523
commit r14-8394-gdfa17fd3b1a50cab51803e8a63c5c7b7db173523
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109636
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113570
--- Comment #3 from Jeffrey A. Law ---
See pr84201 for more details as well as
https://www.spec.org/cpu2017/Docs/benchmarks/549.fotonik3d_r.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113570
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 113570, which changed state.
Bug 113570 Summary: RISC-V: SPEC2017 549 fotonik3d miscompilation in autovec
VLS 256 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113570
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84201
Jeffrey A. Law changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment
1 - 100 of 228 matches
Mail list logo
