https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118038
--- Comment #6 from Andrew Pinski ---
(In reply to Gero from comment #5)
> Hello Andrew,
> Thanks for your answers. However, I don't understand exactly what this has
> to do with PR 104522.
So this is an internal to GCC issue. ...
> bit_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118038
--- Comment #9 from Gero ---
Hi Andrew,
I would like to provide future function
(https://en.cppreference.com/w/c/experimental/fpext1) in C++ and/or improve
existing functions that are not up to standard.
Leterem also includes your quadmath::nanq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44574
--- Comment #18 from Heiko Eißfeldt ---
While going through a new list of ato[ilq]{,l} usages I found that both
libbacktrace and lib_vtv implement their own PE COFF reader.
Could/should this PE COFF parsing code be extracted to one place (which?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118035
--- Comment #3 from Jonathan Wakely ---
The fix will be to just return early if inserting no elements, but I'll check
for other problems too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118038
--- Comment #8 from Andrew Pinski ---
(In reply to Gero from comment #7)
> Hello Andrew,
> Ok. Could you give me a solution that I can use? Various attempts on my part
> have so far been unsuccessful.
The only workaround is not to use bit_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117347
Andre Vehreschild changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117990
--- Comment #9 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:9b4cc2710f97138805a1db6a89bc792e22f02db2
commit r15-6208-g9b4cc2710f97138805a1db6a89bc792e22f02db2
Author: Pan Li
Date: Fri Dec 13 10:4
On 13/12/24 11:24 +0100, Basile Starynkevitch wrote:
On Fri, 2024-12-13 at 11:03 +0100, Basile Starynkevitch wrote:
Hello all,
On GNU Linux/Ubuntu/x86_64 I am using libgccjit++ (in
https://github.com/RefPerSys/RefPerSys/ - a GPLv3+ inference engine
project) but I cannot understand how to create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102689
--- Comment #8 from Christophe Lyon ---
Sorry for the delay: it took me a while to reproduce the problem manually,
while it does show up in CI.
The problem does not happen when I rebuild a full toolchain (trunk binutils +
trunk glibc + trunk gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019
--- Comment #6 from JuzheZhong ---
(In reply to Robin Dapp from comment #5)
> According to Li Pan's results this is "just" vector strict align again?
> We should be vectorizing the first loop, in particular after the
> SLP-grouping changes.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118011
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019
--- Comment #8 from JuzheZhong ---
(In reply to Robin Dapp from comment #7)
> > The problem is GCC-15 has performance regression compare to GCC-14 on both
> > strict align and we should fix it, we can't specify use no strict align in
> > GCC-15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117878
--- Comment #8 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:cfdab86f20f6e77d9c8bf982989f78ef975c7611
commit r15-6210-gcfdab86f20f6e77d9c8bf982989f78ef975c7611
Author: Robin Dapp
Date: Thu Dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
--- Comment #10 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:cfdab86f20f6e77d9c8bf982989f78ef975c7611
commit r15-6210-gcfdab86f20f6e77d9c8bf982989f78ef975c7611
Author: Robin Dapp
Date: Thu De
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117878
Robin Dapp changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 117878, which changed state.
Bug 117878 Summary: RISC-V: ICE when build spec17 526.blender_r with -O3
-march=rv64gcv_zvl256b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117878
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
Robin Dapp changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117897
Paul Thomas changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118024
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118027
Bug ID: 118027
Summary: Real_Literal ans Integer_Literal aspects do not work
for literals beginning with a sign
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118008
Sam James changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #8 from Sam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118025
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118025
Bug ID: 118025
Summary: gcc.dg/field-merge-9.c FAILs
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118026
Bug ID: 118026
Summary: RISC-V Vector Intrinsic "__riscv_vfwadd_wv_f64m2_tu"
generates redundant vmv instructions
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116979
--- Comment #16 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:99b9dfaff66ca6edd534bcf0e7b943a6f816c9bf
commit r15-6215-g99b9dfaff66ca6edd534bcf0e7b943a6f816c9bf
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117990
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116979
--- Comment #17 from Jakub Jelinek ---
Not marking as fixed for GCC 15 yet, as there is the scalar cost computation
issue unresolved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117878
--- Comment #12 from Li Pan ---
(In reply to Robin Dapp from comment #11)
> I'm not really sure. For now I hope not. If we hit similar problems again
> that are not easily fixable we can reconsider.
Sure thing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118028
Bug ID: 118028
Summary: A better vectorized reduction across multi-level
loop-nest
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118029
Bug ID: 118029
Summary: Wrong location info in caret diagnostic about enum &=
enum|enum
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: diagnostic
On Fri, 2024-12-13 at 11:03 +0100, Basile Starynkevitch wrote:
> Hello all,
>
> On GNU Linux/Ubuntu/x86_64 I am using libgccjit++ (in
> https://github.com/RefPerSys/RefPerSys/ - a GPLv3+ inference engine
> project) but I cannot understand how to create in C++ a union type.
>
>
> Today (Dec 13, 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116979
--- Comment #18 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #17)
> Not marking as fixed for GCC 15 yet, as there is the scalar cost computation
> issue unresolved.
There is also a issue how the final result for SFmode is constru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114612
Andre Vehreschild changed:
What|Removed |Added
Last reconfirmed||2024-12-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114612
Andre Vehreschild changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #2 from Andre V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118030
Bug ID: 118030
Summary: [C++23] Implement P0401R6, Providing size feedback in
the Allocator interface
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117347
Andre Vehreschild changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #3 from Andre V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118031
Bug ID: 118031
Summary: [C++23] ranges::starts_with and ranges::ends_with
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
Bug ID: 118032
Summary: Bootstrap slowdown for risc-v
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimizati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117878
--- Comment #10 from Li Pan ---
(In reply to Robin Dapp from comment #9)
> Should be fixed.
Thanks Robin for fixing this, do we still need to do something like
ix86_pre_reload_split for the risc-v backend? Which avoid the the define expand
to b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117878
--- Comment #11 from Robin Dapp ---
I'm not really sure. For now I hope not. If we hit similar problems again
that are not easily fixable we can reconsider.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118029
--- Comment #1 from Jonathan Wakely ---
For extra fun:
enum E { E0, E1, E2 };
E operator|(E lhs, E rhs) { return E(int(lhs) | int(rhs)); }
void f(E e)
{
e |= E1|E2;
}
e2.cc: In function 'void f(E)':
e2.cc:6:11: error: invalid conversion fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
Bug 113934 depends on bug 116778, which changed state.
Bug 116778 Summary: [lra][avr] Wrong code with -mlra (bitfld-lra.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116778
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116778
Denis Chertykov changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019
--- Comment #9 from Robin Dapp ---
I think I'll post a patch to increase vec_construct costs first. It's just too
cheap right now. That should already help with the default settings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
Bug 56183 depends on bug 116778, which changed state.
Bug 116778 Summary: [lra][avr] Wrong code with -mlra (bitfld-lra.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116778
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #24 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019
--- Comment #5 from Robin Dapp ---
According to Li Pan's results this is "just" vector strict align again?
We should be vectorizing the first loop, in particular after the SLP-grouping
changes.
I realize it's annoying having to resort to strict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118024
--- Comment #2 from Sam James ---
```
void *realloc(void *, long);
void *reallocarray(void *);
void *reallocarray(void *) __attribute__((__malloc__(reallocarray)));
void stravis() {
char *buf = reallocarray(0);
realloc(buf, 1);
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019
--- Comment #7 from Robin Dapp ---
> The problem is GCC-15 has performance regression compare to GCC-14 on both
> strict align and we should fix it, we can't specify use no strict align in
> GCC-15 to pretend that we don't have such performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114087
Oliver Kozul changed:
What|Removed |Added
CC||oliver.ko...@rt-rk.com
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112349
--- Comment #3 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:b8314ebff2495ee22f9e2203093bdada9843a0f5
commit r15-6247-gb8314ebff2495ee22f9e2203093bdada9843a0f5
Author: Patrick Palka
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112349
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |14.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117133
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118026
--- Comment #1 from Andrew Pinski ---
Created attachment 59862
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59862&action=edit
Testcase
Next time please attach the testcase or place the testcase inline instead of
just linking to godbolt.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118036
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/ewlu/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118026
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> There are 2 issues with the source (I will file the not unswitching loop
> seperately).
Filed the unswitching loops issue as PR 118037.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118038
Bug ID: 118038
Summary: constexpr std::bit_cast with long double/float80_t
does not work
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118038
--- Comment #1 from Andrew Pinski ---
Padding bits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118038
--- Comment #2 from Andrew Pinski ---
Created attachment 59864
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59864&action=edit
Full testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118038
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118037
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116424
--- Comment #16 from GCC Commits ---
The releases/gcc-13 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:5eca4dc76ded61a959447bd11d1edf6d4030a51d
commit r13-9251-g5eca4dc76ded61a959447bd11d1edf6d4030a51d
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116424
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117969
--- Comment #2 from Marek Polacek ---
I think the problem is that when we call explain_invalid_constexpr_fn, we don't
have current_class_ptr/_ref available, so then build_data_member_initialization
doesn't go here:
else if (op == current_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104522
Andrew Pinski changed:
What|Removed |Added
CC||gero.peterhoff at gmx dot net
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118038
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118033
--- Comment #4 from Andrew Pinski ---
You could use the assume attribute to avoid the side effects ...
#if defined(NDEBUG)
#if __has_attribute(assume)
#define assert(a) [[assume(a)]]
#endif
#endif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118018
John David Anglin changed:
What|Removed |Added
Target||hppa*-*-linux*
Build|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118035
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-12-13
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118035
--- Comment #2 from Jonathan Wakely ---
We can call it a regression, since this C++98 version used to work correctly
and now doesn't:
#include
#include
#include
using namespace std;
int main() {
deque my_deque;
my_deque.push_back("one"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118026
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118036
Bug ID: 118036
Summary: [15 Regression] RISC-V:
gcc.dg/vect/vect-alias-check-11.c abort
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118037
Bug ID: 118037
Summary: missing unswitch loops with RISCV intrinsics
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118034
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118036
Edwin Lu changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
Summary|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118036
Robin Dapp changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79919
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #2 from Andr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118038
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118028
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100118
Andre Vehreschild changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Assignee|unass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #35 from Jan Hubicka ---
On
#include
bool test1(const std::vector& in) {
return in == std::vector{42};
}
we produce:
bool test1 (const struct vector & in)
{
bool _12;
int * _13;
int * _14;
long int _24;
unsigned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115328
--- Comment #7 from GCC Commits ---
The releases/gcc-14 branch has been updated by Gaius Mulley
:
https://gcc.gnu.org/g:da470844aebd0836ce5b6921be62be954e1f8b52
commit r14-11085-gda470844aebd0836ce5b6921be62be954e1f8b52
Author: Gaius Mulley
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118034
--- Comment #2 from Basile Starynkevitch ---
Two questions related to this bug:
Perhaps in libgccjit a "union" is just a gcc_jit_struct with some extra data
telling that all fields have byte offset 0?
Then the documentation could say how to cr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118033
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94960
--- Comment #16 from Jonathan Wakely ---
I think libc++ makes everything always_inline as a way to avoid libc++ symbol
names being ABI artifacts that user code depends on, not because they really
want everything inlined. I could be wrong about th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118035
Bug ID: 118035
Summary: deque bug when inserting an empty iterator
interval
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116053
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118023
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94960
--- Comment #12 from Sam James ---
(In reply to Jason Merrill from comment #11)
> Could we just add 'inline' to the functions that are 'constexpr' in later
> standards?
Apologies if I'm missing something, but see PR93008 if not aware.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117133
--- Comment #7 from Jason Merrill ---
Looking into this more, Stockfish's use of
https://github.com/graphitemaster/incbin/ just seems wrong; since incbin
defines global symbols, putting the use in an anonymous namespace doesn't make
sense.
Note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #17 from Sam James ---
https://inbox.sourceware.org/gcc-patches/ZzYehtM9WcSgrSpc@tucnak/ was posted
for feeble-inline although there was a lot of discussion on IRC afterwards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94960
--- Comment #13 from Sam James ---
Oh, sorry, that was linked earlier. But still, isn't the problem that "inline"
is too strong?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118033
--- Comment #3 from Dmytro Ovdiienko ---
I believe in 99% cases whatever is passed to the assert() is a legal expression
that returns bool. And there is an opportunity to optimize the output assembly
in case we if want to reuse that expression f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118033
Bug ID: 118033
Summary: [Missing optimization] Keep __builtin_unreachable for
asserts in the release build
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94960
--- Comment #10 from Jan Hubicka ---
Note that passing function body to middle-end does not only enable inlining,
but other optimizations too. Often ipa-modref is able to summarize side effects
of the function and enables more optimization, since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117347
Andre Vehreschild changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #4 from Andre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #12 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #9)
> match patterns should almost never be conditional unless
The pattern in question was introdiced as optimization, not as
canonicalization.
I don't think that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #34 from Antony Polukhin ---
The memory allocation is still not elided for a sample from duplicate ticket
116651:
bool test1(const std::vector& in) {
return in == std::vector{42};
}
My naiive expectation is that the `test1` fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118034
--- Comment #1 from Antoni ---
Many C API does not have a C++ wrapper.
Contributions are welcomed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #33 from Marc Poulhiès ---
Hello Nicolas,
Sorry this is taking so long, thank you for your patience.
Thank you also for having rebased your changes, I've been able to apply it
internally and run some tests. I only have partial test
1 - 100 of 137 matches
Mail list logo
