https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114476
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Here is a testcase where we don't need -fwrapv:
Ignore that, I was doing something wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477
Bug ID: 114477
Summary: The user-defined constructor of filter_view::iterator
is not fully compliant with the standard
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114476
--- Comment #3 from Andrew Pinski ---
Here is a testcase where we don't need -fwrapv:
```
signed int b = 9;
int c[23][23];
signed int d[23];
int main() {
for (int h = 0; h < 23; h += 2) {
c[h][h] = d[h];
b= -b;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114476
--- Comment #2 from Andrew Pinski ---
Note -fwrapv is important here ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114476
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-03-26
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114476
Bug ID: 114476
Summary: [14] RISC-V rv64gcv vector: Runtime mismatch at -O3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=951
Eric Gallager changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13756
Eric Gallager changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102660
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
--- Comment #6 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #5)
> Maybe we should always use kmask under AVX512, currently only >= 128-bits
> vector of vector _Float16 use kmask, < 128 bits vector still use vector mask.
>
and we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #17 from chenglulu ---
(In reply to Xi Ruoyao from comment #15)
> > Hi，Ruoyao:
> >
> > The results of spec2006 on 3A6000 were obtained, I removed the more
> > volatile
> > test items, '-falign-loops=8 -falign-functions=8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031
--- Comment #9 from Jerry DeLisle ---
The following trivial patch changes gfortran behavior and regression tests Ok
on x86_64.
I will see if I can come up with a test case to catch this.
diff --git a/libgfortran/io/file_pos.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031
Jerry DeLisle changed:
What|Removed |Added
Status|WAITING |NEW
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100557
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031
urbanjost at comcast dot net changed:
What|Removed |Added
CC||urbanjost at comcast dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114457
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
Well RTL might be already done via init-regs (but there was some movement on
removing that), see PR 61810 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-03-25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114468
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475
--- Comment #1 from Jürgen Reuter ---
I suspect this commit here,
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=44c0398e65347def316700911a51ca8b4ec0a411
but not totally certain.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114464
--- Comment #6 from Andrew Pinski ---
(In reply to Xi Ruoyao from comment #4)
> Interestingly, this only happens when N % 16 == 0.
That depends on the target, for aarch64 (and arm with neon enabled), GCC ICEs
for all multiplies of 8, while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114464
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475
Bug ID: 114475
Summary: [14.0 Regression] Regression with iso_c_binding and
submodules
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112571
Joseph S. Myers changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112571
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Joseph Myers
:
https://gcc.gnu.org/g:f2af129b68bc6b20f79a9a44b28c96650baa702c
commit r13-8495-gf2af129b68bc6b20f79a9a44b28c96650baa702c
Author: Joseph Myers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114349
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114347
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114349
--- Comment #6 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:8651991fe2ea90a7276e91673b15b5c3865f14d7
commit r14-9659-g8651991fe2ea90a7276e91673b15b5c3865f14d7
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114439
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114439
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:de0886d48032332d10e4acb5d15c8789b281b6fe
commit r14-9658-gde0886d48032332d10e4acb5d15c8789b281b6fe
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93410
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77384
Andrew Pinski changed:
What|Removed |Added
Keywords|needs-bisection |
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104817
Xi Ruoyao changed:
What|Removed |Added
CC||qing.zhao at oracle dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114473
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77384
Andrew Pinski changed:
What|Removed |Added
Known to fail||5.5.0
Known to work|5.5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77384
Andrew Pinski changed:
What|Removed |Added
Known to work||5.5.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114464
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114464
--- Comment #3 from Sam James ---
Reduced:
```
template void double_to_int(double, unsigned char *scratch, bool carry)
{
for (int i = 0; i < N; i++) {
bool b = scratch[i] <<= 1;
if (carry)
scratch[i] |= 1;
carry = b;
}
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110714
Patrick Palka changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114474
--- Comment #1 from anlauf at gcc dot gnu.org ---
Might have been caused by the fix for pr67804 (r10-10418).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114467
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114474
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
Known to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114474
Bug ID: 114474
Summary: [11/12/13/14 Regression] DATA statement with derived
type, pointer component rejected
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93595
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114465
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114472
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
ch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9652-20240325121350-gcf3fc6f414f-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240325 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113314
--- Comment #3 from Andrew Pinski ---
Note a volatile memory location change even without this being multi-threaded;
an async signal (USR1..USR4, or ALRM, etc.) could come in and change the value.
Or the memory could be shared memory between 2
linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9652-20240325121350-gcf3fc6f414f-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88309
--- Comment #2 from Andrew Pinski ---
Note I scanned the sources of the rs6000 backend and I don't see where `user
align:4` would be happening. I might try to debug this later this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114469
--- Comment #1 from Joseph S. Myers ---
I'd expect _Atomic _BitInt(5) to follow the same ABI (regarding upper bits
being defined or not) as plain _BitInt(5), and any simplification needs to deal
with that.
(In principle for atomics with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114465
--- Comment #1 from Joseph S. Myers ---
Note that transforming x % 1 % -1 to x % -1 wouldn't strictly be valid (because
of undefined behavior from INT_MIN % -1), though hopefully cases with constant
1 or -1 get optimized to 0 anyway and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114461
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-03-25
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114461
--- Comment #1 from Andrew Pinski ---
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114459
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-03-25
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114458
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-03-25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-03-25
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114457
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
--- Comment #3 from Sam James ---
float quantize_x_1, quantize_x_0;
short *quantize_xq;
short quantize_x0;
void quantize() {
short x1 = quantize_xq[0] =
quantize_x0 + ((quantize_x0 > 0) & (quantize_x_0 < 0));
quantize_xq[1] = 1 + ((x1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
--- Comment #5 from Jakub Jelinek ---
constexpr bool foo () { return true; }
volatile int v;
void
bar (int x)
{
switch (x)
{
case 0:
while (foo ()) ;
break;
case 1:
while (foo ()) {}
break;
case 2:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
--- Comment #4 from Jakub Jelinek ---
Ah, if there is a declaration in the condition, then it is not a valid trivial
empty iteration statement.
Anyway, I'd say cp_fold should for WHILE_STMT, DO_STMT and FOR_STMT if the body
is
a STATEMENT_LIST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114457
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114456
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114458
--- Comment #1 from Jakub Jelinek ---
Considering taking this for stage1 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114456
--- Comment #1 from Jakub Jelinek ---
I'll probably take this for stage1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
--- Comment #2 from Sam James ---
Created attachment 57812
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57812=edit
spec.i.orig.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
--- Comment #1 from Sam James ---
The original failed with:
```
../liblc3-1.0.4/src/spec.c: In function ‘quantize’:
../liblc3-1.0.4/src/spec.c:210:21: error: type mismatch in binary expression
210 | LC3_HOT static void quantize(enum lc3_dt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114455
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114460
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2024-03-25
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
Bug ID: 114471
Summary: [14 regression] ICE when building liblc3-1.0.4
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415
--- Comment #3 from Jakub Jelinek ---
BTW, with additional -mno-red-zone there is still movement of these insns,
though they
leaq128(%rbx), %rsp ! level 0
movq%r13, %rsi
movl%r10d, %edx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415
Jakub Jelinek changed:
What|Removed |Added
CC||sayle at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114466
--- Comment #6 from René Rebe ---
ok - good to know. I guess someone should tell the openssh developers and maybe
gcc should error out with a warning. Actually if gcc would error out it would
signal openssl's configure not to automatically try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114470
Bug ID: 114470
Summary: [OOP] Defined, type-bound assignment(=) of component
not called within class, allocatable parent
Product: gcc
Version: 13.2.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113314
--- Comment #2 from David Malcolm ---
(In reply to David Malcolm from comment #1)
[...]
> 70redo_next:
> 71 next = fdtab[fd].update.next;
> 72 if (next > -2)
> 73goto done;
> 74
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71962
Barry Revzin changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114466
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114468
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415
Jakub Jelinek changed:
What|Removed |Added
Summary|wrong code with -Oz |[13/14 Regression] wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114439
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923
--- Comment #9 from Antoni ---
Created attachment 57810
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57810=edit
Patch to fix the issue
I was unable to create a reproducer in C for the tests.
It seems the problem was actually in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114468
--- Comment #1 from Andrew Pinski ---
Gcc 10 is no longer supported. Can you test a newer gcc? Register allocation is
always improving between versions so this might be already fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114466
--- Comment #4 from René Rebe ---
Created attachment 57809
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57809=edit
preprocessed source from -freport-bug
preprocessed source from -freport-bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114469
Bug ID: 114469
Summary: gcc.dg/torture/bitint-64.c failure with -O2 -flto
-std=c23 -fwrapv
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114381
--- Comment #2 from Roland Mainz ---
Same issue happens on Cygwin 3.6.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114468
Bug ID: 114468
Summary: unixbench compilation performance results vary with
different gcc compilers
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #7 from Naveen N Rao ---
I have been looking at an alternative approach to see if we can move the entire
function patching sequence out of line. However, the approach I am considering
is very specific to the linux kernel, and I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114466
Sam James changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114466
--- Comment #2 from Sam James ---
Also:
>Please submit a full bug report, with preprocessed source (by using
>-freport-bug).
But no need here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
Sam James changed:
What|Removed |Added
CC||rene at exactcode dot de
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114466
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114467
Bug ID: 114467
Summary: f951: internal compiler error: Segmentation fault
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114466
Bug ID: 114466
Summary: mips: ICE during RTL pass: zero_call_used_regs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114377
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114303
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #4 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112470
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #15 from Richard
1 - 100 of 152 matches
Mail list logo
