https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117268
Bug ID: 117268
Summary: [14 Regression] GCC target("general-regs-only") leaves
__AVX__ defined after a push_options/pop_options
'scope'
Product: gcc
Version: 15.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117260
Thomas Schwinge changed:
What|Removed |Added
URL||https://inbox.sourceware.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
--- Comment #13 from Andrew Pinski ---
(In reply to Stas Sergeev from comment #12)
> Well I can move %rsp with an
> inline asm to some pre-defined
> buffer before recovering regs
> with swapcontext. Or I can manually
> adjust it in jmpbuf, in wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115285
--- Comment #13 from GCC Commits ---
The master branch has been updated by Francois Dumont :
https://gcc.gnu.org/g:ee030b28004eade3da872e7ae62a526a2940a705
commit r15-4561-gee030b28004eade3da872e7ae62a526a2940a705
Author: François Dumont
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117232
--- Comment #4 from Hongtao Liu ---
(In reply to Andrew Pinski from comment #0)
> This is expansion of PR 113609 which showed when I improved phiopt's factor
> operations to handle more than just 1 operand operations.
>
> New reduced testcase t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #408 from Oleg Endo ---
Maybe it would be good to override TARGET_DIFFERENT_ADDR_DISPLACEMENT_P on SH,
too?
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666155.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #407 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #406)
> (In reply to John Paul Adrian Glaubitz from comment #405)
> > File too large to be attached, so uploading it here:
> >
> > https://people.debian.org/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117232
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64700
Bug 64700 depends on bug 117232, which changed state.
Bug 117232 Summary: EQ/NE comparison between avx512 kmask and -1 can be
optimized with kxortest with checking CF when using cmov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117232
--- Comment #2 from GCC Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:ee7e77e9c121f5a6f27c92b6b24b2abf9cd66a4d
commit r15-4560-gee7e77e9c121f5a6f27c92b6b24b2abf9cd66a4d
Author: liuhongt
Date: Mon Oct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 114683, which changed state.
Bug 114683 Summary: [modules] name declared in GMF in inline namespace and
exported via using-decl from parent namespace is not visible to importer
https://gcc.gnu.org/bugzilla/show_bug.cgi?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114683
Nathaniel Shead changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #13 from H. Peter Anvin ---
On October 22, 2024 5:49:41 PM PDT, "pinskia at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
>
>--- Comment #12 from Andrew Pinski ---
>(In reply to H. Peter Anvin from co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #12 from Andrew Pinski ---
(In reply to H. Peter Anvin from comment #6)
> And THAT is exactly the point: *the two aren't equivalent.* Only the
> programmer knows when this instruction is usable, and for performance
> reasons, you *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #11 from H. Peter Anvin ---
For the record, MSVC has the following intrinsics, and no, I'm very much
not in favor of their particular prototypes (a structure like div_t
would be better than what they have.)
#include
unsigned __i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #10 from H. Peter Anvin ---
Well sizeof() ought to be sufficient to represent something with enough bits.
Even if x86 is the only architecture that has that specific instruction, I
would be extremely surprised if gcc couldn't use th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #9 from Andrew Pinski ---
As far getting the bitsize for the type, i think it was originally part of
bitint support but removed. Maybe it will be added back.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #8 from Andrew Pinski ---
I don't think we want to introduce div2 because it will also introduce an extra
undefined behavior. Plus it is only 86 which has that instruction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #7 from H. Peter Anvin ---
> _BitInt(sizeof(foo_t)*CHAR_BIT)
Should of course have been _BitInt(sizeof(foo_t)*CHAR_BIT*2) ...
-hpa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #6 from H. Peter Anvin ---
On 10/22/24 13:53, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
>
> --- Comment #5 from Andrew Pinski ---
> Also you are mixing two different issues together.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
--- Comment #12 from Stas Sergeev ---
Well I can move %rsp with an
inline asm to some pre-defined
buffer before recovering regs
with swapcontext. Or I can manually
adjust it in jmpbuf, in which case
I won't be on a wrong stack even
temporarily.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
Stas Sergeev changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117252
--- Comment #2 from Andrew Pinski ---
Yes it is a missed reassociation. Most likely because we don't reassociate
pointerplus ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> You can always use statement expressions with macros for what you want to be
> done.
That is this works:
#define setjmp(env1) ({ \
struct __jmp_buf *__env = (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
--- Comment #8 from Andrew Pinski ---
You can always use statement expressions with macros for what you want to be
done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
--- Comment #7 from Andrew Pinski ---
The way __builtin_setjmp is implemented is via a non-local goto which GCC does
not allow to be inlined.
GCC has been erroring out since at least 4.5.0 (14 years ago). Changing how
__builtin_setjmp works i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
--- Comment #6 from Stas Sergeev ---
In order to restore the stack, I
need it to be inlined. Otherwise
it won't restore the right stack.
But even in that case it generates this:
Dump of assembler code for function setjmp:
=> 0x00401160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
--- Comment #5 from Andrew Pinski ---
(In reply to Stas Sergeev from comment #4)
> No, this is wrong.
> I am perfectly aware that it doesn't
> restore the full register set. I need
> it to only restore stack. But it simply
> doesn't compile.
> W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
--- Comment #4 from Stas Sergeev ---
No, this is wrong.
I am perfectly aware that it doesn't
restore the full register set. I need
it to only restore stack. But it simply
doesn't compile.
Why on clang it works properly?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
--- Comment #3 from Andrew Pinski ---
>GCC provides the built-in functions __builtin_setjmp and __builtin_longjmp
>which are similar to, but not interchangeable with, the C library functions
>setjmp and longjmp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117107
Bug 117107 depends on bug 92687, which changed state.
Bug 92687 Summary: decltype of a structured binding to a tuple component is a
reference type inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92687
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
Bug ID: 117267
Summary: 'setjmp' can never be copied because it receives a
non-local goto
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92687
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117107
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117107
--- Comment #5 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:7de78f7353f125663a22f5514159ea966a120049
commit r14-10826-g7de78f7353f125663a22f5514159ea966a120049
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92687
--- Comment #8 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:7de78f7353f125663a22f5514159ea966a120049
commit r14-10826-g7de78f7353f125663a22f5514159ea966a120049
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117107
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:71e13ea134b04562f8f2cdd9c4a55dbb0905f96a
commit r15-4557-g71e13ea134b04562f8f2cdd9c4a55dbb0905f96a
Author: Jason Merrill
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92687
--- Comment #7 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:71e13ea134b04562f8f2cdd9c4a55dbb0905f96a
commit r15-4557-g71e13ea134b04562f8f2cdd9c4a55dbb0905f96a
Author: Jason Merrill
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116929
--- Comment #7 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:5c6c1aba338d1e563e3da2c5e255f490f0865994
commit r15-4556-g5c6c1aba338d1e563e3da2c5e255f490f0865994
Author: Jason Merrill
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264
--- Comment #7 from Vladimir Terzi ---
(In reply to anlauf from comment #5)
> Please show the exact failing code.
I noticed that my comment is somewhat misleading, so I will clarify.
(In reply to Vladimir Terzi from comment #4)
> That's strang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264
--- Comment #6 from kargls at comcast dot net ---
Agree with Harald, we need to see the actual code and error.
program p
type, abstract :: t
integer :: i = 0
end type
type, extends(t) :: tt
integer :: j = 0
end type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117190
--- Comment #11 from Frank Scheiner ---
(In reply to GCC Commits from comment #10)
> The master branch has been updated by Jakub Jelinek :
>
> https://gcc.gnu.org/g:a6db5908a55adbef0a0dc1eb2a22743064fe17b8
>
> commit r15-4554-ga6db5908a55adbef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117106
--- Comment #3 from Fedor Chelnokov ---
(comment #1 corrected)
> This crash is reproducible in C++20 mode as well without deducing this:
```
struct A {
int x;
template
void foo() noexcept(noexcept(x)) {}
auto bar() -> decltype(fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116634
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117107
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #5 from Andrew Pinski ---
Also you are mixing two different issues together.
First is the multiply N*N->2N which is fixed with _BitInt by casting; though
maybe there should be a way added to get what the precission of the _BitInt
typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117107
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
--- Comment #4 from H. Peter Anvin ---
On October 22, 2024 1:19:05 PM PDT, "pinskia at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
>
>Andrew Pinski changed:
>
> What|Removed |A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117106
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2024-10-22
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117258
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to David Binderman from comment #2)
> I had a quick look:
>
> BUILD $ find elk* -name libxcifc.f90 -print
> elk-9.2.12/src.orig/libxcifc.f90
> elk-9.2.12/src/libxcifc.f90
> BUILD $ find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #4 from Andrew Pinski ---
Actually _BitInt solves the abstract problem by of having types of bigger size.
The division problem should be solved in the compiler and not by a new builtin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #3 from H. Peter Anvin ---
On October 22, 2024 1:33:33 PM PDT, "pinskia at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
>
>Andrew Pinski changed:
>
> What|Removed |A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117258
--- Comment #2 from David Binderman ---
I had a quick look:
BUILD $ find elk* -name libxcifc.f90 -print
elk-9.2.12/src.orig/libxcifc.f90
elk-9.2.12/src/libxcifc.f90
BUILD $ find elk-9.2.12 -name xc_f03_lib_m.mod -print
BUILD $
So where shoul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117190
--- Comment #10 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a6db5908a55adbef0a0dc1eb2a22743064fe17b8
commit r15-4554-ga6db5908a55adbef0a0dc1eb2a22743064fe17b8
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117262
--- Comment #4 from David Malcolm ---
(In reply to Jakub Jelinek from comment #2)
> Sure, it is trunk only, introduced in r15-4375.
> Would be nice if it could be handled similarly to apply_ctor_val_to_range by
> creating just a single record fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
--- Comment #1 from Andrew Pinski ---
I don't think these are useful. Especially now with _BitInt.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117266
Bug ID: 117266
Summary: RFE: builtins for N*N -> 2N multiplication and 2N/N ->
N div/mod
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116929
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 116929, which changed state.
Bug 116929 Summary: [14 regression] ICE in write_unnamed_type_name when
building redumper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116929
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116929
--- Comment #5 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:01d3a974fe3474c37cd52b595c29dddafad954dc
commit r14-10825-g01d3a974fe3474c37cd52b595c29dddafad954dc
Author: Nathaniel Shea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Vladimir Terzi from comment #4)
> (In reply to kargls from comment #3)
> > Works for me with 13.2.0, 14.2.0, and top of tree on x86_64-*-freebsd.
> >
> > You can also do the allocat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
--- Comment #3 from Andrew Pinski ---
Let me expand on this and question why what you want is needed.
Can you explain exactly what kind of macros that are asm macros are being used
and why they can't be C processor macros that will then be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117190
--- Comment #9 from Frank Scheiner ---
(In reply to GCC Commits from comment #8)
> The master branch has been updated by Jakub Jelinek :
>
> https://gcc.gnu.org/g:8f173da4520ddf64f3926580042f1103146bf0bd
Works splendid for my use case. Much ob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264
--- Comment #4 from Vladimir Terzi ---
(In reply to kargls from comment #3)
> Works for me with 13.2.0, 14.2.0, and top of tree on x86_64-*-freebsd.
>
> You can also do the allocation explicitly instead of allocation
> on assignment.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117262
--- Comment #3 from David Malcolm ---
I see:
(gdb) pt ctor
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea664348 precision:8 min max
pointer_to_this >
BLK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-10-22
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
--- Comment #1 from Andrew Pinski ---
Why not use the c preprocessor and string concating?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
Bug ID: 117265
Summary: RFE: extended asm support for assembly macros/assembly
headers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109066
--- Comment #5 from Andrew Benson ---
With apologies for the long delay in replying - thanks for pointing out that I
had the result of a constructor undefined. In this updated example I think that
constructor results are now correctly defined, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117128
--- Comment #5 from Davide Italiano ---
Another example:
int f(int a) {
int arr[5];
for (int i = 0; i < 5; i++) {
if (i % 2 == 0 && a > 5 || i % 3 == 0 && a < -2) {
arr[i] = a + i * 2;
} else {
arr[i] = a + i;
}
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264
--- Comment #2 from Vladimir Terzi ---
(In reply to anlauf from comment #1)
> Confirmed up to current trunk.
>
> As a workaround, you may try the result clause on function f, e.g.:
>
> function f() result(r)
> class(t), allocatable :: r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117258
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2024-10-22
Ever confirme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117262
--- Comment #2 from Jakub Jelinek ---
Sure, it is trunk only, introduced in r15-4375.
Would be nice if it could be handled similarly to apply_ctor_val_to_range by
creating just a single record for the whole range, just with slightly different
me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117262
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117230
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:5fd1c0c1b6968d55e3f997d67a4c149edf20c012
commit r15-4553-g5fd1c0c1b6968d55e3f997d67a4c149edf20c012
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117238
--- Comment #3 from John David Anglin ---
Not quite. As things currently stand, it's theoretically possible
to hold up to two OI mode values in registers.
As far as I can tell, it doesn't seem possible to handle SUBREG spills
in pa_emit_move_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117199
--- Comment #14 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f616bc412c820d1fe1211ab68873607d7bfe2709
commit r15-4552-gf616bc412c820d1fe1211ab68873607d7bfe2709
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117190
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8f173da4520ddf64f3926580042f1103146bf0bd
commit r15-4551-g8f173da4520ddf64f3926580042f1103146bf0bd
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #406 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #405)
> File too large to be attached, so uploading it here:
>
> https://people.debian.org/~glaubitz/pr-55212-404.tgz
Ping.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116780
--- Comment #17 from Segher Boessenkool ---
(In reply to Georg-Johann Lay from comment #16)
> (In reply to Segher Boessenkool from comment #15)
> > It makes sense never, not on any target, not with LRA nor without.
> Though there are test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117238
--- Comment #2 from Segher Boessenkool ---
So the only way you can handle anything OImode is via a function call, with it
pointed to by a function argument? Should you support OImode at all then
(you can do that with a pointer to void argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117251
--- Comment #11 from Michael Meissner ---
For singlebuff.c, there is a clear improvement when using the XXEVAL
instruction:
XXEVAL TRUNK GCC14 GCC13 GCC12 GCC11
-- - - - - -
-O3: 4.46 5.40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117263
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264
Bug ID: 117264
Summary: Segfault when using assignment for allocatable class
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115242
--- Comment #7 from Segher Boessenkool ---
(In reply to Florian Weimer from comment #6)
> The issue on POWER is different because the ABI was enhanced retroactively,
> supposedly in a transparent way.
The PowerPC AltiVec ABI is separate from th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117253
--- Comment #6 from Davide Italiano ---
(In reply to Richard Biener from comment #4)
> So probably IVOPTs related. With -fno-ivopts code generated by GCC 13 and
> trunk are about the same size.
Slightly less contrived example that points to th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117253
--- Comment #5 from Davide Italiano ---
(In reply to Sam James from comment #3)
> Davide, was this reduced from a real application or are you
> fuzzing/experimenting? (The reports are welcome either way.)
Hi Sam, these are not reduced by a real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117260
Andrew Pinski changed:
What|Removed |Added
Attachment #59412|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117263
Bug ID: 117263
Summary: genautomata.cc does not compile with -DNDEBUG due to
unused but set variable
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117260
--- Comment #5 from Andrew Pinski ---
Created attachment 59412
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59412&action=edit
Patch which I am going to test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117251
--- Comment #10 from Michael Meissner ---
There is an instruction that was added in power10 (XXEVAL) that does provide
fusion between VSX vectors that includes ANDC->XOR and XOR->XOR fusion. I have
coded up patches to support this and I will be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116347
Christoph Müllner changed:
What|Removed |Added
Last reconfirmed|2024-10-17 00:00:00 |2024-10-22
Ever confirmed|0
1 - 100 of 169 matches
Mail list logo
