https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
--- Comment #5 from Andrew Pinski ---
This fixes patch causes the code to be rejected:
```
diff --git a/gcc/function.cc b/gcc/function.cc
index 5ffd438475e..7a0f7faa2d7 100644
--- a/gcc/function.cc
+++ b/gcc/function.cc
@@ -242,7 +242,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
--- Comment #4 from Andrew Pinski ---
(In reply to Sam James from comment #1)
> I can reproduce with: gcc -c ./ext/filter/filter.i -march=znver2
> -fno-vect-cost-model -O3.
`-O3 -fno-vect-cost-model -mavx2` is enough with my reduced testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504
Walter Spector changed:
What|Removed |Added
CC||w6ws at earthlink dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082
--- Comment #1 from Roland Illig ---
If you decide to keep the guidelines, here are a few ideas:
* Use the simplest English you can, while still being precise.
* Don't try to be funny. (See #114083 for a possible case)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
--- Comment #1 from Sam James ---
I can reproduce with: gcc -c ./ext/filter/filter.i -march=znver2
-fno-vect-cost-model -O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #1 from Jakub Jelinek ---
That is undefined behavior, __int128/__int128_t/__uint128_t needs 16-byte
alignment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113083
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:fdf9df9d55802e1d8ff0bd14585ea61b2bb9d798
commit r14-9158-gfdf9df9d55802e1d8ff0bd14585ea61b2bb9d798
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #5 from Chris Rapier ---
So what you are saying is that behaviour *has* changed and what was a valid
operation for 15 years is now invalid. I'm not mad about that. I just needed to
know.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #8 from Chris Rapier ---
My apologies for misunderstanding and for coming across as aggressive in my
last response. This section of the code is about 15 years old so it hasn't,
obviously, been subject to a close enough review until
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113986
--- Comment #4 from Wilco ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646408.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #9 from Jakub Jelinek ---
Note, most not too old compilers handle small constant size memcpy as an
efficient way to load/store unaligned values and it is also portable. So,
instead of
*dstp = *srcp ^ *bufp;
if all those can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
--- Comment #2 from Andrew Pinski ---
Created attachment 57515
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57515=edit
Reduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114028
--- Comment #3 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:85c12ae8b80902ed46c97f33dbb61533e07f2905
commit r14-9159-g85c12ae8b80902ed46c97f33dbb61533e07f2905
Author: Robin Dapp
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #4 from Jonathan Wakely ---
You could have checked this very easily using -fsanitize=undefined just like it
asks you to at https://gcc.gnu.org/bugs/ and at the top of the page when you
created this bug.
dst is 512-bit aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #7 from Andrew Pinski ---
(In reply to Chris Rapier from comment #5)
> So what you are saying is that behaviour *has* changed and what was a valid
> operation for 15 years is now invalid. I'm not mad about that. I just needed
> to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #27 from Sam James ---
Can someone sanity-check me on this by trying the instructions at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114079#c0?
I think I can still hit the original crash, it's just flaky (it might pass
sometimes).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114079
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #26 from Sam James ---
*** Bug 114079 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Bug ID: 114081
Summary: [14 regression] ICE in verify_dominators when building
php-8.3.3 (error: dominator of 16 should be 111, not
3)
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
--- Comment #3 from Andrew Pinski ---
#5 0x0110cb3f in simplify_const_unary_operation (code=ZERO_EXTEND,
mode=E_DImode, op=0x776e0440, op_mode=E_SImode) at
../../gcc/simplify-rtx.cc:2131
2131 result = wide_int::from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
--- Comment #2 from Andrew Pinski ---
Oh yes because I am building without `--enable-checking=release` .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874
--- Comment #4 from Sam James ---
I was just going off "incorrect debug info" in comment 0 given it's the only
thing I changed recently. If not, then I've got no idea.
If I were sure it were dwz, I'd file a bug there ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114073
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114078
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
--- Comment #14 from Tamar Christina ---
patch submitted
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646415.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #3 from Jakub Jelinek ---
The testcase segfaults since r13-1607-gc3ed9e0d6e96d8697e4bab994f8acbc5506240ee
when the backend started using more aggressively vector instructions for
operations like the 128-bit logical ops, but that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
Andrew Pinski changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083
Bug ID: 114083
Summary: Possible word play on conditional/unconditional
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083
--- Comment #2 from Roland Illig ---
I don't understand why the word 'unconditionally' is necessary or useful here.
Isn't the option -mmovcc by itself already a condition? That would make the
word 'unconditionally' wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
--- Comment #1 from Andrew Pinski ---
I get a different ICE:
t5.c: In function ‘foo’:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874
Sam James changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113083
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083
--- Comment #1 from Andrew Pinski ---
This is not a play on words though. The flag enables the use of "conditional
moves" always (unconditionally).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082
Bug ID: 114082
Summary: Guidelines for options are empty
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874
--- Comment #5 from Andreas Schwab ---
If the unwinder crashes you have either incorrect unwind info or a corrupted
stack. Neither should be papered over.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083
Jonathan Wakely changed:
What|Removed |Added
CC||macro at orcam dot me.uk
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024
--- Comment #4 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:80d126ba99f4b9bc64d4861b3c4bae666497f2d4
commit r14-9160-g80d126ba99f4b9bc64d4861b3c4bae666497f2d4
Author: Steve Kargl
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289
John David Anglin changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114037
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114069
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114054
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114084
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082
Andrew Pinski changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114069
Andrew Pinski changed:
What|Removed |Added
Depends on||103433
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499
--- Comment #6 from Jerry DeLisle ---
This is an interesting puzzle. I took the -fdump-tree-original output of
compiling the test case and edited out all except the initialization of the two
variables char1 and char2.
I lined these up so we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103433
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112375
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Andreas Krebbel changed:
What|Removed |Added
CC||stefansf at linux dot ibm.com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114085
Bug ID: 114085
Summary: Internal (cross) compiler error when building
libstdc++ for the H8/300 family
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083
--- Comment #4 from Maciej W. Rozycki ---
The flag enables the use of the conditional-move operations even with
hardware that has no support for such operations, hence unconditionally.
Such operations, where unavailable, are then synthesized as
ssion algorithms: zlib zstd
gcc version 14.0.1 20240223 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113749
--- Comment #4 from Gaius Mulley ---
Created attachment 57516
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57516=edit
Proposed fix
Here is a proposed patch. The bug fix changes the FIO module to use the target
O_RDONLY, O_WRONLY,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114069
Andrew Pinski changed:
What|Removed |Added
Summary|Type punning RISC-V vectors |Type punning RISC-V and SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114084
--- Comment #2 from Andrew Pinski ---
Here is another testcase, the only use of _BitInt is in the cast, everything
else is a bitfield:
```
struct a
{
unsigned t:(sizeof(int)*8-1);
};
typedef unsigned _BitInt(sizeof(int)*8-1) ub31;
struct a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113749
Gaius Mulley changed:
What|Removed |Added
Attachment #57516|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114062
--- Comment #2 from Matthias Klose ---
this is seen when building with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64
and applying the proposed patch from PR114065.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98238
Rainer Orth changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96109
--- Comment #16 from Rainer Orth ---
The two tests still/again? FAIL on 32 and 64-bit Solaris/SPARC.
If I understand the dumps correctly
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/slp-47.c:9:21: note:
==> examining statement: _3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114071
--- Comment #1 from Rainer Orth ---
PRs tree-optimization/113557 and testsuite/96109 seem to be the same issue
(and I didn't manage to set See Also: accordingly).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
--- Comment #9 from Sam James ---
```
template struct Array1DRef {
T data;
T *addressOf(int eltIdx) { return + eltIdx; }
};
template struct CroppedArray1DRef {
Array1DRef base;
int numElts;
void getAsArray1DRef() {
if (numElts)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114067
--- Comment #4 from Andrew Pinski ---
(In reply to Jason Liam from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > Actually A at that point is incomplete type.
>
> Yes, it is incomplete at that point but that is not the reason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114071
Bug ID: 114071
Summary: gcc.dg/vect/pr37027.c etc. FAIL
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
--- Comment #7 from Andrew Pinski ---
Created attachment 57508
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57508=edit
Reduced a lot
This could be reduced more though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057
Filip Kastl changed:
What|Removed |Added
CC||fxue at os dot
amperecomputing.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114072
Bug ID: 114072
Summary: gcc.dg/vect/vect-pr111779.c FAILs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114073
Bug ID: 114073
Summary: during GIMPLE pass: bitintlower: internal compiler
error: in lower_stmt, at gimple-lower-bitint.cc:5530
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114067
--- Comment #3 from Jason Liam ---
(In reply to Andrew Pinski from comment #2)
> Actually A at that point is incomplete type.
Yes, it is incomplete at that point but that is not the reason for the program
to be ill-formed. The reason is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
Jakub Jelinek changed:
What|Removed |Added
Summary|[14 regression] ICE when|[14 regression] ICE when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113557
Rainer Orth changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96109
--- Comment #15 from Rainer Orth ---
Created attachment 57507
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57507=edit
current sparc-sun-solaris2.11 dumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90785
--- Comment #3 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:bff1cbf2f61d9532eceaa6ebe71185f4b0902a76
commit r14-9148-gbff1cbf2f61d9532eceaa6ebe71185f4b0902a76
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
Jakub Jelinek changed:
What|Removed |Added
Blocks|114073 |
Depends on|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
Andrew Pinski changed:
What|Removed |Added
Attachment #57508|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114040
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:be1f2bc4522f772184a4d16d8f3fec75baed89cf
commit r14-9150-gbe1f2bc4522f772184a4d16d8f3fec75baed89cf
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114040
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
--- Comment #10 from Sam James ---
last one:
```
struct c {
int b;
int *d(int e) { return + e; }
};
struct g {
c base;
int f;
void j() {
if (f)
__builtin_unreachable();
}
int (int e) {
if (e > 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114074
--- Comment #3 from Richard Biener ---
I would guess some match pattern triggers, the bisection is odd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114075
Bug ID: 114075
Summary: [14 Regression] s390x miscompilation since r14-322
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114075
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
--- Comment #12 from Tamar Christina ---
looks like the moving of the store didn't update a stray out of block use of
the MEM.
working on patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114075
Jakub Jelinek changed:
What|Removed |Added
CC||jchrist at linux dot ibm.com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114070
--- Comment #4 from Sam James ---
reduced:
```
struct name_entry {
int mode;
} traverse_trees(), *unresolved_n;
void unresolved(int i, unsigned dirmask, unsigned mask) {
for (; i; i++) {
mask |= 1;
if (!unresolved_n[i].mode ||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114076
Bug ID: 114076
Summary: list-initialization with assignment expression
triggers wrong template instanciation
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114070
--- Comment #6 from Richard Biener ---
So we vectorize this to
_97 = vect__4.15_91 == { 0, 0 };
vect_patt_8.17_98 = VEC_COND_EXPR <_97, { 1, 1 }, { 0, 0 }>;
_102 = vect__5.16_93 != { 0, 0 };
vect_patt_19.18_103 = VEC_COND_EXPR <_102, {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114075
--- Comment #4 from jchrist at linux dot ibm.com ---
(In reply to Jakub Jelinek from comment #2)
> Ah, there is
> https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645928.html
> but that didn't come up with a testcase.
> Not sure if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105645
Julian Waters changed:
What|Removed |Added
CC||tanksherman27 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114075
--- Comment #5 from jchrist at linux dot ibm.com ---
Just sent a v2 of the patch including your suggested test and updated the
commit message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120
--- Comment #6 from GCC Commits ---
The releases/gcc-12 branch has been updated by Richard Earnshaw
:
https://gcc.gnu.org/g:0de82d2c2ec0b7ed65a1122884feab40f90c0483
commit r12-10174-g0de82d2c2ec0b7ed65a1122884feab40f90c0483
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120
--- Comment #7 from GCC Commits ---
The releases/gcc-11 branch has been updated by Richard Earnshaw
:
https://gcc.gnu.org/g:98032b3e320a5b63309d6a843f6e97fb0506953a
commit r11-11251-g98032b3e320a5b63309d6a843f6e97fb0506953a
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
1 - 100 of 141 matches
Mail list logo
