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=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=119131
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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=7826
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Resolution|
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=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=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=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=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 #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=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=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=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=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 #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=119198
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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=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=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=102194
Michael Kenzel changed:
What|Removed |Added
CC||michael.kenzel at gmail dot com
--- Co
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=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=119208
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=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=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=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=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=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=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=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=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=119187
Andrew Pinski changed:
What|Removed |Added
Depends on||95960
--- Comment #2 from Andrew Pinski
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=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=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=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=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=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=119203
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117512
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=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=119167
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
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=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=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=119181
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-03-10
Summary|Missed v
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=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=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=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=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=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=119183
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
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
--- 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=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=119199
--- Comment #2 from anlauf at gcc dot gnu.org ---
Likely r15-4104.
Null pointer dereference, obviously fixed by:
diff --git a/gcc/fortran/trans-common.cc b/gcc/fortran/trans-common.cc
index 70b45174f84..2db50da20dd 100644
--- a/gcc/fortran/tran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116860
--- Comment #11 from Konstantinos Eleftheriou ---
We have sent a solution for this
(https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677190.html).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119191
--- Comment #3 from Jonathan Wakely ---
The 'operator(int)' case is interesting because it could be a typo for several
other operators, operator+(int) or operator++(int) or operator[](int).
Personally, I know that I forget the double parens for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115439
--- Comment #9 from GCC Commits ---
The trunk branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:e187ed927ae52df7998376d6ccfdd2181fc8f774
commit r15-7926-ge187ed927ae52df7998376d6ccfdd2181fc8f774
Author: Christophe Lyon
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119135
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |13.4
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119192
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119166
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119195
Bug ID: 119195
Summary: GCC 14.2.0: Incorrect Handling of const
std::string_view& as a Template Argument
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119183
--- Comment #7 from Richard Biener ---
It would ask for a flag on the tree nodes so we don't repeatedly recurse down
the tree. TREE_NO_SIDE_EFFECTS?
But yes, limiting the search depth is the simplest solution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119196
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119201
Bug ID: 119201
Summary: Wrong plural forms in "missing primary template
attribute"
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119192
Gaius Mulley changed:
What|Removed |Added
Last reconfirmed||2025-03-10
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118871
--- Comment #1 from Bi6c ---
Is it considered as invalid code?
I tried with "goto l;", and it is compilable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118871
--- Comment #2 from Jakub Jelinek ---
It is invalid. Non-local goto is a special extension, which needs extra
handling on the assembler level, something that writers of inline asm have no
idea about and what exactly to use there.
So, it is noth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119112
--- Comment #1 from GCC Commits ---
The releases/gcc-14 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:ca0ea3d4192313ad00da4ff734baffcecafe0b1f
commit r14-11399-gca0ea3d4192313ad00da4ff734baffcecafe0b1f
Author: Iain Buclaw
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119190
--- Comment #3 from Richard Biener ---
Oh, so we don't have debug stmts at -O0 because we don't run var-tracking. I
guess the patch is reasonable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119191
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> callop.cc:3:16: error: expected type-specifier before ‘(’ token
> 3 | void operator(int, int);
> |^
Oops, I posted the output fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119187
--- Comment #3 from Tamar Christina ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > There is another bug report for a similar thing but with SSE and AVX2.
>
> yes PR 95960.
Ah yeah, I guess I w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119189
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-03-10
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119120
--- Comment #4 from Jakub Jelinek ---
I think this regressed with
r0-100845-gbd2e63a1c4d4159f576c31bee9e4090919462aa5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119203
--- Comment #1 from Jonathan Wakely ---
For the original example, clang says what's wrong:
arrow.cc:14:7: error: no viable overloaded 'operator->'
14 | iter->i;
| ^
arrow.cc:6:8: note: candidate function not viable: constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119203
Bug ID: 119203
Summary: A type with a constrained operator-> gives error: base
operand of '->' has non-pointer type
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115316
--- Comment #1 from David Binderman ---
As of today, 20250310, still broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119194
Bug ID: 119194
Summary: GCC 14.2.0: Incorrect Handling of const
std::string_view& as a Template Argument
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115316
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Summary|valgri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119192
--- Comment #3 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:40a4f3dead623db86bc8f7255cbe524701f4aeb0
commit r15-7931-g40a4f3dead623db86bc8f7255cbe524701f4aeb0
Author: Gaius Mulley
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119124
--- Comment #1 from Bi6c ---
I got ICE (verify_flow_info failed) with asm goto and local function call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119197
Bug ID: 119197
Summary: [feat req] `std::expected` should be nodiscard
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119188
--- Comment #2 from Luke Shumaker ---
I appreciate the explanation. Does that make it any less of a bug? Should I
change the title to "x86 red-zone not taken into account by
-fcallgraph-info=su"?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119199
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118897
--- Comment #1 from Bi6c ---
I try to minimize the input: https://godbolt.org/z/4G7rq4qGP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119199
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118899
--- Comment #1 from Bi6c ---
I try to minimize the input: https://godbolt.org/z/oETd8vnhP
The issue is that the parameters in the macro definition and the usage don't
match:
Defined as `A3(expect, expr, align)`
Used as `A3(0, 32, P64_P_P32_P_P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119120
--- Comment #3 from Andrew Pinski ---
(In reply to Zoltan Vajda from comment #0)
> This is not an academic problem. The implementation of operator /= of
> std::complex has this behavior until GCC 8.5 (inclusive).
The std::complex's operator /=
1 - 100 of 185 matches
Mail list logo
