https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119191
--- Comment #1 from Jonathan Wakely ---
Clang is no better, it also just says "that's wrong" without a fix-it:
callop.cc:2:8: error: 'operator()' cannot be the name of a variable or data
member
2 | void operator();
|^
callop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119205
Bug ID: 119205
Summary: internal compiler error: in tree_to_uhwi, at
tree.cc:6587
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119209
Bug ID: 119209
Summary: SLP failed to recognize dot_prod pattern(it's taked as
a normal reduction)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119131
--- Comment #6 from Andrew Pinski ---
I am trying to understand why there were checks for DECIMAL_FLOAT_MODE_P in
the first place. Removing them allows the testcase to pass.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119131
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119131
--- Comment #8 from Andrew Pinski ---
Created attachment 60706
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60706&action=edit
Patch which I am testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112542
--- Comment #4 from Andrew Pinski ---
So disabling dominator opts (-fno-tree-dominator-opts) allows this to be
optimized.
It looks like DOM is causing the lose of the __builtin_unreachable .
Before DOM we had:
```
[local count: 1073741824]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119208
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109941
--- Comment #7 from Arthur O'Dwyer ---
I've split out the `std::expected` feature request specifically into bug
#119197.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98904
Andre Vehreschild changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|WAITIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118896
Mikael Morin changed:
What|Removed |Added
Component|tree-optimization |fortran
--- Comment #6 from Mikael Morin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119193
Bug ID: 119193
Summary: Suboptimal packing codegen
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119183
--- Comment #6 from Jakub Jelinek ---
Reduced testcase:
int foo (void);
#define A(x) (1.0f * (1.0f * (1.0f * (1.0f * (1.0f * (1.0f * (1.0f * (1.0f *
(x)
float
bar (float r)
{
r += A (A (A (A (A (A (A (A (foo ();
return r;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119162
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119183
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71369
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116087
--- Comment #4 from Andi Kleen ---
After some digging into the code: libcpp already keeps track of how many tokens
get expanded in a global. This is even accessible for through linemap's
statistics dumped on -fmem-report, but only as a averaged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119192
--- Comment #2 from Gaius Mulley ---
Created attachment 60694
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60694&action=edit
Proposed fix for TBITSIZE
Here is a proposed fix which bootstraps on amd64 gnu linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #6 from Joseph S. Myers ---
I don't think we should add this prematurely. We can wait for the specification
to mature in WG14, and I think it's a bad idea to split the discussion between
multiple places.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119187
Andrew Pinski changed:
What|Removed |Added
Depends on||95960
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119207
Bug ID: 119207
Summary: ICE after error with flexible array definition and too
large size for array
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: er
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97986
Andrew Pinski changed:
What|Removed |Added
CC||bic60176 at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119206
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119192
Bug ID: 119192
Summary: ICE if TBITSIZE is used in an expression
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119208
Bug ID: 119208
Summary: internal compiler error: in extract_constrain_insn, at
recog.cc:2783
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #8 from Alejandro Colomar ---
(In reply to Joseph S. Myers from comment #7)
> In particular, the subtle issues around semantics for bit-field expression
> operands (see N2958) are definitely something that should be discussed in a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119205
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119210
--- Comment #4 from xiezhiheng at huawei dot com ---
(In reply to Andrew Pinski from comment #3)
> So:
> mrs x16, tpidr2_el0
> cbnzx16, .L22 <== it will branch to .L22, and miss 'smstart za'
> mov x0, x3
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119210
--- Comment #6 from Andrew Pinski ---
(In reply to xiezhiheng from comment #5)
> And I am using kernel 5.10 (5.10.0-216.0.0.115.oe2203sp4.aarch64 openEuler
> 22.03 (LTS-SP4))
I don't think SME support was added until 5.19 but I could be wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119210
--- Comment #5 from xiezhiheng at huawei dot com ---
(In reply to Andrew Pinski from comment #3)
> So:
> mrs x16, tpidr2_el0
> cbnzx16, .L22 <== it will branch to .L22, and miss 'smstart za'
> mov x0, x3
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119210
--- Comment #7 from xiezhiheng at huawei dot com ---
For other information,
https://godbolt.org/z/xdPYGsjYd
LLVM seems always dominate block .LBB0_14
.LBB0_11:
add x23, x23, #1
msr TPIDR2_EL0, xzr
cmp x23, #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #9 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118579
sandra at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7826
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119206
Bug ID: 119206
Summary: Internal compiler error when processing a va_arg
expression
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115258
--- Comment #7 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:31dcf941ac78c4b1b01dc4b2ce9809f0209153b8
commit r15-7933-g31dcf941ac78c4b1b01dc4b2ce9809f0209153b8
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119189
--- Comment #2 from Jeffrey A. Law ---
Almost certainly the change I made to cut down on the size of the livein sets.
It can leave the RTX iterator in an undesirable place in some cases resulting
in missed optimizations. I saw it right before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
--- Comment #17 from Martin Jambor ---
After reading from ao_compare::compare_ao_refs, I tend to think the
correct predicate for "tbaa_hazard" from my comment #14 is
types_equal_for_same_type_for_tbaa_p (with the last argument true in
early SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95287
--- Comment #2 from Raul Tambre ---
Clang is now conformant and MSVC remains so.
GCC remains the odd one out of the bunch many years later.
Notably back when I filed this it did affect me on some real world code as this
causes rejection of valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119203
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119204
Bug ID: 119204
Summary: Internal Compiler Error (“verify_gimple” failed) when
compiling code with strcspn
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119204
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119188
--- Comment #3 from Andrew Pinski ---
So reading
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Developer-Options.html#index-fstack-usage
"The qualifier static means that the function manipulates the stack statically:
a fixed number of bytes are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116568
Nathaniel Shead changed:
What|Removed |Added
Status|ASSIGNED|NEW
Target Milestone|15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102194
Michael Kenzel changed:
What|Removed |Added
CC||michael.kenzel at gmail dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114518
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> I am not sure where we should put that transformation or should the target
> have a matching pattern for the above and make sure the const value of the
> and do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98904
--- Comment #14 from David Binderman ---
I confirm that the problem seems to have gone away.
I used this configure script:
CC="gcc -g1 -O3 -march=znver3" CXX="g++ -g1 -O3 -march=znver3" \
../trunk/configure --prefix=$HOME/gcc/results.$DATE.valgr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119210
Bug ID: 119210
Summary: [SME] 'smstart za' seems not to dominate the block
that uses za register
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119198
Bug ID: 119198
Summary: ICE: segmentation fault with __builtin_assoc_barrier()
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119178
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119198
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119210
--- Comment #1 from Andrew Pinski ---
Created attachment 60705
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60705&action=edit
testcase
-O2-march=armv9-a+sve+sve2+sme-f64f64
Next time please attach the testcase (the attach a file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119210
--- Comment #2 from xiezhiheng at huawei dot com ---
(In reply to Andrew Pinski from comment #1)
> Created attachment 60705 [details]
> testcase
>
> -O2-march=armv9-a+sve+sve2+sme-f64f64
>
>
> Next time please attach the testcase (the att
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114518
--- Comment #7 from Andrew Pinski ---
Created attachment 60704
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60704&action=edit
This fixes the issue
The only issue is it turns back on late combine^wforwprop which exposes the
broken define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119210
--- Comment #3 from Andrew Pinski ---
So:
mrs x16, tpidr2_el0
cbnzx16, .L22 <== it will branch to .L22, and miss 'smstart za'
mov x0, x3
smstart za
bl __arm_tpidr2_restore
.L22:
This me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119189
--- Comment #3 from Jeffrey A. Law ---
And just to confirm, with the patch I'm testing, these all snap back to
passing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788
newbie-02 changed:
What|Removed |Added
CC||newbie-02 at gmx dot de
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119183
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.5
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115024
--- Comment #10 from Haochen Jiang ---
I could not reproduce that from scratch for now either since if I recalled that
correctly, I reproduce that on one specific Sky Lake machine, not all.
BTW, the DSB issue is some time just a "bad luck" caus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118999
--- Comment #2 from Jennifer Schmitz ---
Thanks for looking into this. The regression looks to have been resolved by:
AArch64: Enable early scheduling for -O3 and higher (PR118351)
On our machines, the runtimes are back to normal. Do you still s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115118
--- Comment #5 from Filip Kastl ---
Btw I also ran into 5% -Ofast -march=native -flto *speedup* on a Zen5 machine.
But that still doesn't offset the 13% that the graph shows.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
--- Comment #32 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:1301e18f69ced6a14a7648a24d1eb3addd836b6c
commit r15-7921-g1301e18f69ced6a14a7648a24d1eb3addd836b6c
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119179
--- Comment #2 from Giuseppe D'Angelo ---
For instance something like this:
class VLA
{
private:
static constexpr int DEFAULT_CAP = 256;
int m_size = 0;
int m_capacity = DEFAULT_CAP;
int m_data[DEFAULT_CAP]; // uninit; just sto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119183
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119184
Bug ID: 119184
Summary: internal compiler error: in tokens_buff_and_token
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115118
Filip Kastl changed:
What|Removed |Added
Summary|[15 Regression] 5-13% |[15 Regression] 5-13%
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119136
--- Comment #8 from Andre Vehreschild ---
Jerry, may be you can use an atomic https://gcc.gnu.org/wiki/Atomic . This way
you don't need an expensive lock. My strategy would be to declare a global
atomic bool value (e.g. in_output) and in each __
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119183
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
--- Comment #1 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119183
--- Comment #3 from Andrew Pinski ---
#68 0x014ad3af in save_expr (expr=expr@entry=0x77395af0) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree.cc:4059
#69 0x00a34565 in build_modify_expr (location=location@entry=196167297
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119182
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119179
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119189
Bug ID: 119189
Summary: [15 Regression] Code quality regressions on aarch64
since ext-dce change r15-7915-g4ed07a11ee2845
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119185
--- Comment #4 from Xi Ruoyao ---
(In reply to Jonathan Wakely from comment #2)
> What if the function is not called indirectly, wouldn't the implicit object
> ref just be garbage?
>
> My response to this is "just use C++". Then you have functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119186
Bug ID: 119186
Summary: Using __builtin_ctz results in a error result.
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119185
--- Comment #6 from Xi Ruoyao ---
(In reply to Uroš Platiše from comment #5)
> My assumption was that the object is anyway in the regs and the mere issue
> would be accessing its value.
You assumption is incorrect as I've already said. It's j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #7 from Joseph S. Myers ---
In particular, the subtle issues around semantics for bit-field expression
operands (see N2958) are definitely something that should be discussed in a
single place (i.e. the standard committee) rather than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118869
--- Comment #6 from Andrew Pinski ---
*** Bug 119198 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114991
--- Comment #7 from GCC Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:e355fe414aa3aaf215c7dd9dd789ce217a1b458c
commit r15-7932-ge355fe414aa3aaf215c7dd9dd789ce217a1b458c
Author: Vladimir N. Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119181
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-03-10
Summary|Missed v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119190
--- Comment #5 from Jakub Jelinek ---
I'd say for PR119120 we should better change expansion so that either at -O0
only or always it performs the complex part moves of COMPLEX_EXPR in
corresponding integral moves (and do something reasonable als
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119196
Bug ID: 119196
Summary: Missed folding of vector comparisons
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119196
--- Comment #1 from Andrew Pinski ---
Confirmed.
In fre we have:
_3 = _1 < _2;
_7 = _1 == _2;
_26 = _3 | _7;
Note the T definition is enough for this is just:
typedef int T1;
typedef __attribute__((vector_size(sizeof(T1 T1 T;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119167
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119187
--- Comment #4 from Richard Biener ---
It's one of the TODOs that look easy but are not. Related is to support a
fractional VF so we can re-roll
for (...)
a[32*i] = ..;
a[32*i+1] = ..;
...
a[32*i + 31] = ...;
to match the number of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119185
Bug ID: 119185
Summary: Feature: quasi object programming by retrieving base
object of indirect C calls
Product: gcc
Version: unknown
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119188
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119190
Jakub Jelinek changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Target Mil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119190
Bug ID: 119190
Summary: [15 Regression] Debug info quality regression at -O0
since r15-3128
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119127
--- Comment #8 from GCC Commits ---
The master branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:c7d493baf13f1f144f2c4bc375383b6ce5d88a76
commit r15-7923-gc7d493baf13f1f144f2c4bc375383b6ce5d88a76
Author: Xi Ruoyao
Date: Fri Mar 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119186
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119186
--- Comment #3 from hao an ---
thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
--- Comment #34 from Kees Cook ---
Hi! The proposed patch fixes the warning for me. Thank you!
vm-project/tree/main/flang/test
file Semantics/num_images01.f90 does this
test $ ~/gcc/results.20250310.valgrind/bin/gfortran -c -w
./Semantics/num_images01.f90
==569772== Invalid read of size 4
==569772==at 0x7C0DC0: gfc_format_decoder(pretty_printer*, text_info*, char
const*, int, bool,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119198
--- Comment #2 from Bi6c ---
(In reply to Andrew Pinski from comment #1)
> dup.
>
> *** This bug has been marked as a duplicate of bug 118869 ***
Thank you for reviewing my bug report, but I believe this may not be a
duplicate of bug #118869.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119201
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2025-03-10
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116564
Alex Coplan changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119174
Jeffrey A. Law changed:
What|Removed |Added
Priority|P1 |P4
--- Comment #14 from Jeffrey A. Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119127
Xi Ruoyao changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119151
--- Comment #10 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:21109b37e8585a7a1b27650fcbf1749380016108
commit r15-7924-g21109b37e8585a7a1b27650fcbf1749380016108
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119185
--- Comment #1 from Andrew Pinski ---
Does this apply to all indirect functions? If so this might require an abi
change.
Otherwise I am not 100% sure of the semantics.
Do you want an attribute that gets added to a field of a struct which contai
1 - 100 of 185 matches
Mail list logo
