https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66018
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65767
--- Comment #8 from amker at gcc dot gnu.org ---
Oh, missed messages. Will look into it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66150
--- Comment #1 from Jonathan Wakely ---
But the static_assert passes, doesn't that mean the cv-qualifier is ignored?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66155
Bug ID: 66155
Summary: Macro not replaced after multi-line string constant
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
Jonathan Wakely changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66156
Bug ID: 66156
Summary: [msp430] wrong code generated with -O2 -mlarge (zero
extension HI -> SI)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: wrong-co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66130
--- Comment #7 from Paolo Carlini ---
First blush I'm wondering if in this specific case we couldn't forward from
dump_decl to dump_expr and just print ‘l->*ptr’. AFAICS, wouldn't be a
regression and would allow us to adopt immediately Manuel' pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
Bug ID: 66157
Summary: bits/random.tcc compiler error when using
-fno-for-scope
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: major
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66134
--- Comment #1 from Ilya Enkovich ---
Author: ienkovich
Date: Fri May 15 09:38:44 2015
New Revision: 223215
URL: https://gcc.gnu.org/viewcvs?rev=223215&root=gcc&view=rev
Log:
gcc/
PR middle-end/66134
* tree-chkp.c (chkp_get_orgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #8 from Douglas Mencken ---
Created attachment 35546
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35546&action=edit
linker output for genmatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66153
--- Comment #1 from Peter Boyle ---
Created attachment 35547
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35547&action=edit
unprocessed source code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66150
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66150
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66158
Bug ID: 66158
Summary: Use DO loop constraints for optimizing bounds checking
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66130
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Paolo Carlini from comment #7)
> First blush I'm wondering if in this specific case we couldn't forward from
> dump_decl to dump_expr and just print ‘l->*ptr’. AFAICS, wouldn't be a
> regre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66140
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968
--- Comment #41 from Uroš Bizjak ---
The GCC bugzilla favicon now shows generic Bugzilla favicon. Previously, it was
a GCC favicon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66140
--- Comment #3 from dhowells at redhat dot com ---
The compiler works now, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66159
Bug ID: 66159
Summary: bogus warning for alias-declaration using
elaborated-type-specifier
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50221
Arjen Markus changed:
What|Removed |Added
CC||arjen.markus895 at gmail dot
com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66160
Bug ID: 66160
Summary: gcc-5.1.0 fails with "lambda-expression in unevaluated
context" where gcc-4.9.2 succeeds
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136
--- Comment #2 from Szabolcs Nagy ---
the posix standard does not seem to disallow \n in the replacement string so i
think freebsd sed should be fixed (or report the bug to the austingroup).
meanwhile i will prepare a fix for this in gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136
--- Comment #3 from Ed Maste ---
> the posix standard does not seem to disallow \n in the replacement string so
> i think freebsd sed should be fixed (or report the bug to the austingroup).
I can't find language that specifies sed must interpre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968
--- Comment #42 from Frédéric Buclin ---
(In reply to Uroš Bizjak from comment #41)
> The GCC bugzilla favicon now shows generic Bugzilla favicon. Previously, it
> was a GCC favicon.
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968
Frédéric Buclin changed:
What|Removed |Added
Attachment #35409|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
--- Comment #2 from Luca Stoppa ---
I'm sorry, what do you mean with "don't do that"?
Can you please tell me whether c++11/14 with -fno-for-scope is supported?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
Jonathan Wakely changed:
What|Removed |Added
Severity|major |minor
--- Comment #1 from Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66161
Bug ID: 66161
Summary: gcc silent about type incompleteness in error message
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66049
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946
Ramana Radhakrishnan changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65068
Ramana Radhakrishnan changed:
What|Removed |Added
Keywords||missed-optimization
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65225
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64835
Bug 64835 depends on bug 66015, which changed state.
Bug 66015 Summary: align directives not propagated after __attribute__
((__optimize__ ("O2")))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66015
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66015
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65225
--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to Ramana Radhakrishnan from comment #1)
> Presumably yours ?
Yes, and I think it's fixed. At least all the important aarch64 patches are in
with.
https://gcc.gnu.org/ml/gcc-patches/20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64783
Ramana Radhakrishnan changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
--- Comment #3 from Jonathan Wakely ---
The option works exactly as documented, and can be used freely with your own
code if you need to compile old code. Obviously if you include any code you
didn't write (such as standard library headers) then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
--- Comment #4 from Luca Stoppa ---
It is a very very very... old application written like 20 years ago.
Anyway, we'll try to remove that option from our build process.
Thanks for your answer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
--- Comment #5 from Luca Stoppa ---
I think you can close this "bug".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66150
Eric Fiselier changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #2 from Andrey V ---
Replacing throw/try/catch with longjmp/setjmp for non-returning function exit,
like so:
#include
#include
#include
pthread_once_t flag_ = PTHREAD_ONCE_INIT;
int call_count = 0;
jmp_buf catch_;
void func_()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66130
--- Comment #9 from Paolo Carlini ---
(In reply to Manuel López-Ibáñez from comment #8)
> (In reply to Paolo Carlini from comment #7)
> > First blush I'm wondering if in this specific case we couldn't forward from
> > dump_decl to dump_expr and j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66161
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13981
Jonathan Wakely changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66049
--- Comment #6 from vekumar at gcc dot gnu.org ---
(In reply to Ramana Radhakrishnan from comment #5)
> (In reply to vekumar from comment #4)
> > (In reply to ktkachov from comment #3)
> > > Venkat, are you planning to submit this patch to gcc-pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66162
Bug ID: 66162
Summary: Bug box compiling Ada.Finalization with -gnatc
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65903
--- Comment #5 from Jerry DeLisle ---
(In reply to Laurent Chardon from comment #4)
> Thanks for the fix. If I may suggest a modification of the testcase in order
> to check also when there are no blanks between the & and !. I know in
> Fortran i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163
Bug ID: 66163
Summary: [6 Regression] Not working Firefox built with LTO
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163
--- Comment #1 from Andrew Pinski ---
This really sounds like a bug in Firefox. This argument is not valid to be
null. Hmm, I suspect there should be an undefined sanitizer that should be
added to catch this case if not already there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163
--- Comment #2 from Martin Liška ---
(In reply to Andrew Pinski from comment #1)
> This really sounds like a bug in Firefox. This argument is not valid to be
> null. Hmm, I suspect there should be an undefined sanitizer that should be
> added to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66130
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Paolo Carlini from comment #9)
> But the error message is about l->*ptr, not about ptr per se.
Yes, but the location should already point to l->*ptr. I'm thinking in cases
such as:
stru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64454
--- Comment #11 from Marc Glisse ---
Author: glisse
Date: Fri May 15 17:34:15 2015
New Revision: 223221
URL: https://gcc.gnu.org/viewcvs?rev=223221&root=gcc&view=rev
Log:
2015-05-15 Marc Glisse
PR tree-optimization/64454
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66130
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|paolo.carlin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64454
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #3 from Martin Sebor ---
On Power, both glibc and AIX pthread_once behave the same way: i.e., they fail
to clear the once flag on exception. The test case below mimics glibc's
pthread_once and demonstrates the root cause of the probl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48956
--- Comment #12 from miyuki at gcc dot gnu.org ---
Author: miyuki
Date: Fri May 15 18:02:50 2015
New Revision: 223223
URL: https://gcc.gnu.org/viewcvs?rev=223223&root=gcc&view=rev
Log:
PR c/48956
gcc/c-family/
* c-common.c (int_safely_convertibl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64454
--- Comment #13 from Andrew Pinski ---
(In reply to Marc Glisse from comment #12)
> One last thing that would have been nice: in VRP, if the range of X is
> included in [10,14], X%5 can be simplified to X-10. But it is probably not
> worth the tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64454
--- Comment #14 from Marc Glisse ---
(In reply to Andrew Pinski from comment #13)
> It might also be useful if the range is [0,10] for x%5 to be simplified down
> to just "t = x-5; x>=5?t:x;"
(I assume you meant [0,9])
I agree, but the profitabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48956
--- Comment #13 from Manuel López-Ibáñez ---
(In reply to Mikhail Maltsev from comment #12)
Great! Please do not forget to close the bug (using your @gcc.gnu.org account).
I leave the honor to you. Perhaps even worth it to add this to
https://gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48956
Mikhail Maltsev changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
--- Comment #7 from Luca Stoppa ---
Well, even if my production code is 20 years old, the example I have attached
isn't. It is valid c++11/14 code.
Would you call something like this "old c++ code"?
#include
int main()
{
std::vector v{1,2,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972
--- Comment #6 from AK ---
Your patch did fix the problem. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66164
Bug ID: 66164
Summary: Strange behaviour calling functions with float as
parameter
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66165
Bug ID: 66165
Summary: vect_transform_slp_perm_load: vec out of range ?
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
--- Comment #8 from Jonathan Wakely ---
I already said that it works fine with C++ code *you* write, in any standard
mode. But don't expect everyone else's C++ code (including standard library
headers) to follow the old pre-1998 rules.
If you us
=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150515 (experimental) [trunk revision 223211] (GCC)
$
$ gcc-trunk -O0 small.c; ./a.out
$
$ gcc-trunk -O1 small.c
$ ./a.out
Aborted (core dumped)
$
---
int a, b, e, c = 1;
const int d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66167
Bug ID: 66167
Summary: Scalar Storage Order attribute has no effect on 2
dimensional arrays
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150515 (experimental) [trunk revision 223211] (GCC)
$
$ gcc-trunk -O2 -c small.c
$ gcc-5.1 -O3 -c small.c
$
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn1’:
small.c:15:1: internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #5 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #4)
> Thanks, Martin. So maybe something like this:
This happens on almost all non-x86 machines. I tested it on aarch64 and we had
the same failure as powerpc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66167
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66167
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66169
Bug ID: 66169
Summary: [c++-concepts] constraints on constructor are jammed
with inherited copy/move constructors
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66164
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66169
--- Comment #1 from Ying-Po Liao ---
The following example shows a Concept applied to the constructor of class A.
The compiler (r223061) will generate internal compiler error if A's subclass C
implements default behaviors of copy/move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66166
--- Comment #1 from H.J. Lu ---
GCC 4.0 also aborts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810
--- Comment #21 from Francois-Xavier Coudert ---
(In reply to Lawrence Velázquez from comment #20)
> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01377.html
Quick review of the patch:
- version_as_modern_macro(): you implement a specific beha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810
mrs at gcc dot gnu.org changed:
What|Removed |Added
CC||mrs at gcc dot gnu.org
Kno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66166
Mikhail Maltsev changed:
What|Removed |Added
CC||miyuki at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66166
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66004
--- Comment #3 from Hans-Peter Nilsson ---
Something supposedly very good happened recently, because:
r223225 18369501023
I'll just have to find out what caused that 50% cut! The test-case is
unchanged.
If the cause is related to inlining heuri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66164
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66170
Bug ID: 66170
Summary: Bogus warning with -Wsign-conversion when using
static_cast on an int
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66171
Bug ID: 66171
Summary: [6 Regression]: gcc.target/cris/biap.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810
--- Comment #23 from Lawrence Velázquez ---
(In reply to Francois-Xavier Coudert from comment #21)
> - version_as_legacy_macro(): same issue. Why do we need to handle major <=
> 9? You have rejected this possibility in macosx_version_as_macro()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66168
Mikhail Maltsev changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66153
--- Comment #2 from Peter Boyle ---
p.s. in case anyone is wondering this recursive construct is
a simplification of a construct I'm using in an expression
template framework, so this is not simply a convoluted test case.
Rather, I distilled th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66173
Bug ID: 66173
Summary: -fno-threadsafe-statics suppresses guard functions but
not guard variables
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66172
Bug ID: 66172
Summary: -fno-threadsafe-statics suppresses guard functions but
not guard variables
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66173
--- Comment #1 from Marc Singer ---
I neglected to include information about the version of the compiler. This is
a 64 bit compiler on amd64.
# g++ --version
g++ (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66165
Mikhail Maltsev changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66172
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47674
--- Comment #12 from Thomas Koenig ---
Is there interesting in further backporting?
If not, I would close this as fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55839
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|tkoenig at gcc do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66172
--- Comment #3 from Marc Singer ---
I've come to the same conclusion. My hope was that I could eliminate the guard
and force the compiler to initialize block scoped statics at the start of
execution. It looks like the standard stands in the way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25714
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|tkoenig at gcc do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38220
Thomas Koenig changed:
What|Removed |Added
Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--
1 - 100 of 104 matches
Mail list logo
