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=79919
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #2 from Andr
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=118038
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118038
--- Comment #10 from Andrew Pinski ---
>So:
bit_cast should only do exactly what it is supposed to do: bit-cast. No more,
no less.
Except that is not how compilers work. Especially since you still need to do
constant folding of floating point v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90321
Nathaniel Shead changed:
What|Removed |Added
Target Milestone|--- |15.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90321
--- Comment #1 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:a6a15bc5b77c8703a95130f410a944f5408a5cc4
commit r15-6251-ga6a15bc5b77c8703a95130f410a944f5408a5cc4
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102689
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118029
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106631
--- Comment #3 from David Malcolm ---
Jonathan: it would need some special-casing in the parser, I think; FWIW the
error is emitted here:
(gdb) bt
#0 error_at (richloc=0x4e6a9a0 , gmsgid=0x4e6a9a0
"")
at ../../src/gcc/diagnostic-global-co
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=117095
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b626ebc0d7888ddae16a55ca583b56a4b8434bdf
commit r15-6248-gb626ebc0d7888ddae16a55ca583b56a4b8434bdf
Author: Jakub Jelinek
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85460
--- Comment #2 from Andrew Pinski ---
Created attachment 59865
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59865&action=edit
Reduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61491
Andrew Pinski changed:
What|Removed |Added
Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot
gnu.org
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=117970
Lewis Hyatt changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118038
--- Comment #7 from Gero ---
Hello Andrew,
Ok. Could you give me a solution that I can use? Various attempts on my part
have so far been unsuccessful.
thx
Gero
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=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=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 #5 from Gero ---
Hello Andrew,
Thanks for your answers. However, I don't understand exactly what this has to
do with PR 104522.
bit_cast should only do the bit conversion and not worry about other
sensitivities. Whether the results
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=118038
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|NEW
Last reconfirmed|
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|UNCONFIRMED |RESOLVED
Resolution|---
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
--- Comment #1 from Andrew Pinski ---
Padding bits.
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=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=118036
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/ewlu/gcc
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=118018
John David Anglin changed:
What|Removed |Added
Target||hppa*-*-linux*
Build|
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=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=118037
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
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=118034
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
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=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=118026
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=118035
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-12-13
Keywords|
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=117133
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=112349
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |14.3
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=117942
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117942
--- Comment #7 from GCC Commits ---
The releases/gcc-14 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:3454cca24a92a535a46fe4ec9d5d41585002fc4b
commit r14-11087-g3454cca24a92a535a46fe4ec9d5d41585002fc4b
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117880
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117880
--- Comment #4 from GCC Commits ---
The releases/gcc-14 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:2fd2f40e0461e21df0a2f5ead083d53b641d2a86
commit r14-11086-g2fd2f40e0461e21df0a2f5ead083d53b641d2a86
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109214
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116989
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
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=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=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=94960
--- Comment #14 from Jan Hubicka ---
> Could we just add 'inline' to the functions that are 'constexpr' in later
> standards?
It would make sense to me - that would reduce differences between
codegens with different -std= options.
Also we may use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94960
--- Comment #15 from Jan Hubicka ---
> Oh, sorry, that was linked earlier. But still, isn't the problem that "inline"
> is too strong?
Do we have some data on this? I plan to do some inliner benchmarking
over christmas like I do every year. Wit
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116108
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=118013
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=117133
--- Comment #10 from Jason Merrill ---
(In reply to Jason Merrill from comment #7)
> Note that the new GCC behavior conforms to CWG2230/CWG2272. But compilers
(oops, CWG2772, not 2272)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117133
--- Comment #9 from Sam James ---
Sent https://github.com/official-stockfish/Stockfish/issues/5714.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117133
--- Comment #8 from Sam James ---
(In reply to Jason Merrill from comment #7)
OK, let me take it to them. Thanks.
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=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 #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=94960
Jason Merrill changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #11 from Jason Mer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118027
Arnaud Charlet changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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=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=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=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=118034
Bug ID: 118034
Summary: libgccjit++ has no wrapping C++ API to create a union
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106631
--- Comment #2 from Jonathan Wakely ---
Dave, is this something the existing spellchecking can handle, or does it need
parser changes in cc1plus to perform spellchecking in new places?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #41 from GCC Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:2089009210a1774c37e527ead8bbcaaa1a7a9d2d
commit r15-6246-g2089009210a1774c37e527ead8bbcaaa1a7a9d2d
Author: Christophe Lyon
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118033
--- Comment #1 from Dmytro Ovdiienko ---
I'm not sure about how to handle the side effects caused by the expression. The
code in the expression must not be executed but used by the compiler only for
the optimization.
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=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=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=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=117347
Andre Vehreschild changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #4 from Andre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019
--- Comment #10 from Robin Dapp ---
Ah I see - the actual vector code isn't even that bad and the vec_constructs
aren't either. The problem is rather that we have slow unaligned (scalar)
access with the default tune model. Thus we need to load
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=93921
Jan Hubicka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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=111600
--- Comment #41 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:6dcfe8743134936db17ffdfd0a5102a87338f494
commit r15-6223-g6dcfe8743134936db17ffdfd0a5102a87338f494
Author: Robin Dapp
Date: Tue No
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=118023
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118024
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=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=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
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=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=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=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=114612
Andre Vehreschild changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #2 from Andre V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117347
Andre Vehreschild changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #3 from Andre V
1 - 100 of 137 matches
Mail list logo
