https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113168
Bug ID: 113168
Summary: ABOUT-NLS seems way out of date
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: internal-improvement
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
--- Comment #7 from Haochen Jiang ---
(In reply to Uroš Bizjak from comment #1)
> Created attachment 56962 [details]
> Proposed patch
>
> Patch in testing.
>
> lowpart_subreg can't handle:
>
> lowpart_subreg (V4SFmode, operands[0], DFmode);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113157
--- Comment #2 from Andrew Pinski ---
That is this works:
[apinski@xeond2 pr113157]$ gcc --coverage -o test 1.c 2.c -O3
[apinski@xeond2 pr113157]$ ./test
[apinski@xeond2 pr113157]$ gcc -O3 -fprofile-use -o test 1.c 2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113157
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113167
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113167
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:200531d5b9fb99eca2b0d6b8d1e42d176413225f
commit r14-6861-g200531d5b9fb99eca2b0d6b8d1e42d176413225f
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113167
--- Comment #3 from Andrew Pinski ---
Oh it is not on either x86_64 or aarch64:
/* { dg-do run { target vect_cmdline_needed } } */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113167
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113167
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113167
Bug ID: 113167
Summary: [14 Regression] gcc.dg/tree-ssa/gen-vect-26.c started
failing many targets after recent change
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
--- Comment #6 from Haochen Jiang ---
Aha, I see what happened. x/ymm16+ are usable for AVX512F w/o AVX512VL and that
is why I added that to allow them.
Let me find a way to see if we can fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
--- Comment #5 from Haochen Jiang ---
(In reply to Uroš Bizjak from comment #3)
> This patch also fixes the failure:
>
> --cut here--
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index ca6dbf42a6d..cdb9ddc4eb3 100644
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
--- Comment #11 from Alexander von Gluck ---
Hm.. Could you point me to where Linux is using the (get/set/swap)context
calls? I still haven't found them in the codebase.
I don't want to miss any edge cases if I work up a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113130
--- Comment #2 from Andrew Pinski ---
Oh right but the following testcase it should be valid to do and not worry
about INT_MIN either:
```
int f(int a, unsigned short c)
{
// c = 1;
int b = a > 0 ? a : -a;
return b == c;
}
int f1(int a,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113130
--- Comment #1 from Joseph S. Myers ---
Note that the first example (and the suggested one with ABS_EXPR) has undefined
behavior for a == INT_MIN, while the second has undefined behavior for c ==
INT_MIN (and is also not equivalent to the first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #5 from Andrew Pinski ---
(In reply to Jan Engelhardt from comment #4)
> >And in upcoming Glibc-2.39 there will be a major reimplementation of qsort
>
> Even so, a recent commit strongly suggests that sticking to array bounds
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Jan Engelhardt changed:
What|Removed |Added
CC||fweimer at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113166
--- Comment #1 from JuzheZhong ---
Suspect it is subreg issue again.
#include "riscv_vector.h"
void foo (void *in, void *out, int x)
{
vint32m2_t dup = __riscv_vmv_v_x_i32m2 (x, 8);
vint32m2x4_t tuple1 = __riscv_vlseg4e32_v_i32m2x4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113166
Bug ID: 113166
Summary: RISC-V: Redundant move instructions in RVV intrinsic
codes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113120
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899
--- Comment #13 from Andrew Pinski ---
Seems to be most of this should not implemented this way but rather an IPA RA
pass (which GCC already does but not always and definitely not across IPA
boundaries).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113165
--- Comment #2 from kargl at gcc dot gnu.org ---
With the attached example code and the patch at the end of this
message, gfortran can be changes to identify both lines of code.
Fixing the run-on errors when -fimplicit-none is used is left as
an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
Andrew Pinski changed:
What|Removed |Added
CC||ats-gccbugs at offog dot org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113086
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113086
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
--- Comment #22 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:2cb93e6686e4af5725d8c919cf19f535a7f3aa33
commit r14-6857-g2cb93e6686e4af5725d8c919cf19f535a7f3aa33
Author: Rimvydas Jasinskas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
Uroš Bizjak changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #3 from Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
--- Comment #2 from Uroš Bizjak ---
Another testcase:
--cut here--
void
foo1 (double *d, float f)
{
register float x __asm ("xmm16") = f;
asm volatile ("" : "+v" (x));
*d = x;
}
void
foo2 (float *f, double d)
{
register double x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2023-12-28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113160
--- Comment #4 from Jonathan Wakely ---
Or more precisely, you can't deduce a const valarray from it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113160
--- Comment #3 from Jonathan Wakely ---
> Any function returning a valarray is permitted to return an object
> of another type, provided all the const member functions of valarray
> are also applicable to this type.
This means you can do v[0]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113161
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-12-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113164
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113137
--- Comment #10 from Tamar Christina ---
Ok, so this bug is simply fixed by:
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index f51ae3e719e..e7a5917bc4c 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -976,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
--- Comment #9 from Mikael Pettersson ---
Created attachment 56961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56961=edit
proposed fix, only tested on the given test case so far
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113165
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P5
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
--- Comment #8 from Mikael Pettersson ---
The generic code synthesizes a move from CONST0_RTX (XFmode) to an XFmode FP
reg, and that causes the ice. Forcing the mode of both to SFmode or DFmode
avoids the ice and generates sane-looking code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113165
Bug ID: 113165
Summary: Code containing more than one type declaration for a
variable results in confusing error messages from
compiler
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113164
Bug ID: 113164
Summary: [missed optimization] struct fields should not alias
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113137
--- Comment #9 from Tamar Christina ---
Ok, have a working patch but it's a bit ugly, working on cleaning it up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163
--- Comment #8 from Tamar Christina ---
Created attachment 56959
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56959=edit
nonlinear IV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163
Tamar Christina changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108900
--- Comment #3 from Libin Dang ---
For the uploaded test case, `-fdump-internal-locations' gives the following
output:
ORDINARY MAP: 9
location_t interval: 274912 <= loc < 1342178464
file: header3.h
starting at line: 1
column and range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
--- Comment #7 from Mikael Pettersson ---
The issue appears to be the clearing of FP regs. If I add an m68k-specific
version of TARGET_ZERO_CALL_USED_REGS which handles integer (address and data)
regs but skips FP regs, then the test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
--- Comment #8 from Xi Ruoyao ---
(In reply to Alexey Dobriyan from comment #7)
> > fancy C++ extension
>
> It is not fancy.
>
> C99 initialisers is the only feature where Modern C beats Modern C++.
Fancy or not you should ask the standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163
--- Comment #6 from Tobias Burnus ---
and for that condition, we have:
3375 if (!integer_onep (*step_vector))
(gdb) p debug_tree(*step_vector)
constant 8>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163
--- Comment #5 from Tobias Burnus ---
While higher at the call stack:
#3 0x0148714f in vect_transform_loop
(loop_vinfo=loop_vinfo@entry=0x350f2a0,
loop_vectorized_call=loop_vectorized_call@entry=0x0)
at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163
--- Comment #4 from Tamar Christina ---
Hmm so can't seem to reproduce it with x86_64 or aarch64.
let me build a --target=amdgcn-amdhsa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163
--- Comment #3 from Tamar Christina ---
Thanks, taking a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163
--- Comment #2 from Tobias Burnus ---
Created attachment 56958
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56958=edit
Reduced testcase (
$ amdgcn-amdhsa-gcc -g -O2 inp5.i -march=gfx900
during GIMPLE pass: vect
inp5.i: In function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
--- Comment #7 from Alexey Dobriyan ---
> fancy C++ extension
It is not fancy.
C99 initialisers is the only feature where Modern C beats Modern C++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163
Bug ID: 113163
Summary: [14 Regression][GCN] ICE in
vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113144
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113162
--- Comment #1 from JuzheZhong ---
We can have this following reduced intrinsic codes to represent the subreg
issue:
https://godbolt.org/z/KfvT7hjnz
#include "riscv_vector.h"
void foo (void *in, void *out, int x)
{
vint32m2_t dup =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113162
Bug ID: 113162
Summary: RISC-V: Unexpected register spillings in vectorized
codes and intrinsic codes that have subregs.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #17 from JuzheZhong ---
(In reply to Tamar Christina from comment #16)
> >
> > I wonder whether ARM SVE can also use this approach VEC_EXTRACT with index =
> > 0.
>
> Perhaps, I'll look into it thanks. though this is ofcourse only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113161
Bug ID: 113161
Summary: Add a special "ramfunc" attribute for sections in the
linker script (*.ld files)
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
65 matches
Mail list logo
