https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71674
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Component|tree-optimizatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680
Bug ID: 71680
Summary: [7 Regression] ICE: Max. number of generated reload
insns per insn is achieved (90) w/ -Os -mlra
Product: gcc
Version: 7.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66313
Richard Biener changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71658
--- Comment #2 from Ulrich Mutze ---
Created attachment 38780
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38780&action=edit
This is a shortened version of the first attachment. It avoids a superfluous
complication.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70032
--- Comment #4 from Richard Biener ---
Yes, tail-merging needs to utilize a "value-numbering" like IPA ICF (in fact,
just re-use its implementation - I think this is what Martins patch set does).
My cleanup comment was supposed to be the first c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386
--- Comment #7 from Richard Biener ---
ISTR a similar bug in C++ lambda support related how we map them to nested
functions. PR69756.
is getting
new_dir='/usr/includesys/' where name should have been './usr/include/sys/')
Test example foo.c:
#include "foo/bar/baz.h"
#include
Used gcc version 7.0.0-20160628. Problem present also in several earlier GCC
versions. Problem actually detected for DJGPP, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66867
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Tue Jun 28 08:27:18 2016
New Revision: 237814
URL: https://gcc.gnu.org/viewcvs?rev=237814&root=gcc&view=rev
Log:
PR middle-end/66867
* builtins.c (expand_ifn_atomic_compar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71658
--- Comment #3 from Ulrich Mutze ---
(In reply to Martin Sebor from comment #1)
> I believe the test case is invalid.
>
> In a call to an operator, operator overload resolution in [over.match.oper]
> considers three sets of candidate functions:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71673
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Tue Jun 28 08:29:11 2016
New Revision: 237815
URL: https://gcc.gnu.org/viewcvs?rev=237815&root=gcc&view=rev
Log:
PR rtl-optimization/71673
* internal-fn.c (expand_arith_ov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71681
--- Comment #1 from Andris Pavenis ---
Created attachment 38781
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38781&action=edit
Fix for problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544
--- Comment #10 from Dominique d'Humieres ---
> Thank you for the suggested workaround. This can certainly be helpful in the
> short term. However, we would not want to rely on tuning compiler
> optimization switches in the future to ensure corr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70751
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71673
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66867
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680
Anton Blanchard changed:
What|Removed |Added
CC||anton at samba dot org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71682
Bug ID: 71682
Summary: [7 Regression] Several libjava failures on
x86_64-apple-darwin15 with -m32 after r237556
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680
Jiong Wang changed:
What|Removed |Added
CC||jiwang at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680
--- Comment #3 from Segher Boessenkool ---
anton: What flags for your test case? I fail to reproduce it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680
--- Comment #5 from Arseny Solokha ---
(In reply to Segher Boessenkool from comment #4)
> Oh never mind, I forgot -mlra, duh.
>
> Confirmed, also on BE, -O2 -mlra fails already.
I can't make it fail on 32-bit BE, though. Segher, is your machine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680
--- Comment #6 from Segher Boessenkool ---
Yes, but it fails with -m32 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71675
--- Comment #2 from Julian Stecklina ---
Return bool actually makes sense, because that is the result from the "compare"
part of compare/exchange. I am not sure what the meaning of 'type' as a result
would be.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680
--- Comment #7 from Segher Boessenkool ---
We have an insn:
(insn 32 33 34 3 (set (reg:DI 165)
(unspec:DI [
(fix:SI (subreg:SF (reg:SI 160 [ a ]) 0))
] UNSPEC_FCTIWZ)) 71680.c:11 334 {fctiwz_sf}
(expr_lis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71625
Jakub Jelinek changed:
What|Removed |Added
Component|middle-end |tree-optimization
Version|tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60882
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63607
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810
--- Comment #27 from Richard Earnshaw ---
(In reply to David Malcolm from comment #26)
> (In reply to Ramana Radhakrishnan from comment #25)
> > Fixed presumably ?
>
> Mostly. The remaining issue with configure-time options reaching the jit is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71679
--- Comment #1 from Markus Trippelsdorf ---
The testcase can be further reduced:
template struct A;
struct B {
template friend struct ::A;
};
When using A instead of ::A it works fine and gcc errors out:
llvm.ii:3:37: error: redeclared wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
--- Comment #23 from Richard Earnshaw ---
Any plans to backport to 4.9, or should this be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67037
--- Comment #9 from Richard Earnshaw ---
Any plans to backport to 4.9, or should this be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71639
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69187
--- Comment #15 from Richard Earnshaw ---
Any plans to backport this further?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69886
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71683
Bug ID: 71683
Summary: [7 Regression] ICE in gen_phi_arg_condition, at
tree-if-conv.c:1705 w/ -ftree-vectorize -O2 (and
above)
Product: gcc
Version: 7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71675
Martin Sebor changed:
What|Removed |Added
Keywords|documentation |rejects-valid
--- Comment #3 from Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71682
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71683
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71350
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.4
Summary|[4.8/4.9/5/6/7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71675
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70030
--- Comment #8 from Renlin Li ---
(In reply to Vladimir Makarov from comment #6)
> Created attachment 38033 [details]
> A patch
>
> Here is the patch which might solve the problem.
Hi Vladimir,
Do you have plan to check this patch in?
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684
Bug ID: 71684
Summary: Memory leak with std::mutex and std::lock_guard on
freebsd
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67037
--- Comment #10 from Bernd Edlinger ---
(In reply to Richard Earnshaw from comment #9)
> Any plans to backport to 4.9, or should this be closed?
I won't have time/resources for the necessary regression testing.
However the patch is quite simple,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685
Bug ID: 71685
Summary: Segmentation fault in gcc when compiling the attached
file.
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814
--- Comment #3 from Richard Earnshaw ---
Atomic loads and stores have to use the same policy for a single object, you
can't have loads using one model and stores another.
Atomic loads have to work even if the object is marked const.
C/C++ permi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685
Jakub Jelinek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684
--- Comment #3 from Jonathan Wakely ---
(In reply to nsz from comment #1)
> on a posix platform pthread_mutex_destroy should be called for a mutex if
> its life time ends, so the ifdef logic seems wrong (the initializer does not
> make a differen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> On some older versions of FreeBSD using PTHREAD_MUTEX_INITIALIZER and then
> pthread_mutex_destroy would segfault, see
> http://lists.freebsd.org/pipermail/fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71679
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71656
--- Comment #5 from Peter Bergner ---
Author: bergner
Date: Tue Jun 28 15:49:10 2016
New Revision: 237823
URL: https://gcc.gnu.org/viewcvs?rev=237823&root=gcc&view=rev
Log:
PR target/71656
* gcc.target/powerpc/pr71656-2.c: Fix sy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814
--- Comment #4 from Yichao Yu ---
Thanks for the explanation. I didn't realize that the load is the problem. Just
curious (since I somehow can't find documentation about it), would `ldaxp`
provide the right semantics without the corresponding sto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71675
--- Comment #5 from Martin Sebor ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01896.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685
Jakub Jelinek changed:
What|Removed |Added
Assignee|mpolacek at gcc dot gnu.org|jakub at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814
--- Comment #5 from Richard Earnshaw ---
I don't think so. It's to do with whether the CPU is permitted to 'crack' the
operation into multiple micro-ops that proceed independently down the pipeline.
LDAXP could still be cracked in this way prov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71683
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684
--- Comment #5 from nsz at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to nsz from comment #1)
> > on a posix platform pthread_mutex_destroy should be called for a mutex if
> > its life time ends, so the ifdef log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814
--- Comment #6 from Andrew Pinski ---
(In reply to Richard Earnshaw from comment #5)
> I don't think so. It's to do with whether the CPU is permitted to 'crack'
> the operation into multiple micro-ops that proceed independently down the
> pipeli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685
--- Comment #4 from Jim Wilson ---
The problem here is that I assumed that c_build_qualified_type would only be
called when we want to create a variant type. However, there are a number of
places that call it without checking to see if we have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814
--- Comment #8 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #7)
> Closing as invalid. Though for v8.4 or so it would be nice if there was
> 128bit atomic loads.
That probably wouldn't help. It would require a new ABI befor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814
--- Comment #9 from Andrew Pinski ---
(In reply to Richard Earnshaw from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > Closing as invalid. Though for v8.4 or so it would be nice if there was
> > 128bit atomic loads.
>
> That pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71683
--- Comment #2 from Arseny Solokha ---
(In reply to Jakub Jelinek from comment #1)
> Started wutg r235808.
Must be a duplicate of PR71503, then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58655
--- Comment #1 from denisc at gcc dot gnu.org ---
Author: denisc
Date: Tue Jun 28 17:56:37 2016
New Revision: 237825
URL: https://gcc.gnu.org/viewcvs?rev=237825&root=gcc&view=rev
Log:
PR target/58655
* config/avr/avr.opt (-mfract-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70524
Gerhard Steinmetz changed:
What|Removed |Added
CC||gerhard.steinmetz.fortran@t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71626
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Tue Jun 28 18:31:42 2016
New Revision: 237826
URL: https://gcc.gnu.org/viewcvs?rev=237826&root=gcc&view=rev
Log:
PR middle-end/71626
* config/i386/i386.c (ix86_expand_vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71686
Bug ID: 71686
Summary: ICE on broken character continuation
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71687
Bug ID: 71687
Summary: ICE in omp_add_variable, at gimplify.c:5821
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71687
--- Comment #1 from Gerhard Steinmetz
---
As known, case above works with "workshare" :
$ cat z2.f90
subroutine s (n, x)
integer :: n
real :: x(n)
!$omp parallel workshare
x(1:n) = x(n:1:-1)
!$omp end parallel workshare
end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71688
Bug ID: 71688
Summary: ICE in analyze, at cgraphunit.c:632
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71688
--- Comment #1 from Gerhard Steinmetz
---
Modified a bit :
$ cat z2.f90
program p
call s
contains
subroutine s
real :: x[*] = 1
block
end block
x = 2
end
end
$ gfortran-6 -fcoarray=lib z2.f90
z2.f90:1:0:
pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71626
Jakub Jelinek changed:
What|Removed |Added
Summary|[4.9/5/6/7 regression] ICE |[4.9/5/6 regression] ICE at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58655
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71689
Bug ID: 71689
Summary: Missing dwarf info when using nested function
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71552
--- Comment #6 from Martin Sebor ---
Author: msebor
Date: Tue Jun 28 20:09:36 2016
New Revision: 237829
URL: https://gcc.gnu.org/viewcvs?rev=237829&root=gcc&view=rev
Log:
PR c/71552 - Confusing error for incorrect struct initialization
gcc/c/Ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71552
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71671
Tiago de Paula Peixoto changed:
What|Removed |Added
CC||tiago at skewed dot de
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71671
Markus Trippelsdorf changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690
Bug ID: 71690
Summary: integer conversion defeats memcpy optimizaton
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690
--- Comment #1 from Martin Sebor ---
See also C++ bug 71654 for the "inverse" of the problem where VRP successfully
provides range information in the absence of a conversion but fails with it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70524
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to Gerhard Steinmetz from comment #5)
> There is a different ICE for a subset of the above group.
It is probably a similar issue: gfortran is passing a wrong location. You need
to figure out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71654
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690
--- Comment #2 from Andrew Pinski ---
(In reply to Martin Sebor from comment #1)
> See also C++ bug 71654 for the "inverse" of the problem where VRP
> successfully provides range information in the absence of a conversion but
> fails with it.
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Tue Jun 28 22:30:04 2016
New Revision: 237830
URL: https://gcc.gnu.org/viewcvs?rev=237830&root=gcc&view=rev
Log:
PR c/71685
* c-typeck.c (c_build_qualified_type): Don't cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690
--- Comment #3 from Andrew Pinski ---
To fix this, would mean we keep around copies and PHInodes longer. I don't
know if we want to do that because it causes code generation to be very bad
really.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685
Jakub Jelinek changed:
What|Removed |Added
Summary|[6/7 Regression]|[6 Regression] Segmentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685
--- Comment #7 from Jim Wilson ---
An early exit if type_quals is 0 does not work, as there is at least one place
that deliberately calls c_build_qualified_type with no type qualifiers to
create an unqualified type from a qualified type. Likewis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690
Martin Sebor changed:
What|Removed |Added
Summary|absence of integer |some integer conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71686
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71686
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690
--- Comment #5 from Martin Sebor ---
In addition to the data in comment #4, the script below extracts VRP ranges for
an argument passed via the ellipsis to __builtin_snprintf. The script output
shows that despite the same bounds on a variable, V
/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160628 (experimental) [trunk revision 237830
98 matches
Mail list logo
