https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
abbycin changed:
What|Removed |Added
CC||abbytsing at hotmail dot com
--- Comment #10 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79813
--- Comment #2 from Piers Finlayson ---
I have reproduced on 5.2.0, but I strongly suspect some sort of build
error/inconsistently, possibly to do with musl libc. I'm going to report to
the toolchain maintainers - happy for you to close this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79768
--- Comment #4 from Casper Ti. Vector ---
(In reply to Manuel López-Ibáñez from comment #3)
> This is just too weird code for GCC to analyze correctly at -O2. It doesn't
> warn at -O3 (with 5.4.0 20160609)
The coding pattern is quite common thou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841
--- Comment #5 from Jerry DeLisle ---
Author: jvdelisle
Date: Sat Mar 4 03:13:34 2017
New Revision: 245891
URL: https://gcc.gnu.org/viewcvs?rev=245891&root=gcc&view=rev
Log:
2017-03-03 Jerry DeLisle
PR fortran/79841
* openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841
--- Comment #4 from Jerry DeLisle ---
I will commit this:
diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 3ca23493..753dc5ad 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -3732,7 +3732,7 @@ check_symbol_not_point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #54 from Martin Sebor ---
(In reply to janus from comment #53)
Unfortunately, it isn't. The warning depends on actually dereferencing the
null pointer (i.e., trying to access the object it points to) and passing the
argument in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77627
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72826
Manuel López-Ibáñez changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72826
Manuel López-Ibáñez changed:
What|Removed |Added
Summary|Poor diagnostic for |bad pretty-printing of decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
Manuel López-Ibáñez changed:
What|Removed |Added
CC||fwd at quantentunnel dot de
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78203
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78993
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79768
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78370
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71699
--- Comment #11 from Manish Goregaokar ---
(In reply to Manuel López-Ibáñez from comment #10)
> (In reply to Manish Goregaokar from comment #9)
> > Already sent it :)
> >
> > https://gcc.gnu.org/ml/gcc-patches/2016-06/msg02057.HTML is the curren
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79846
--- Comment #1 from joseph at codesourcery dot com ---
The correct way to print HOST_WIDE_INT is with %wu etc. formats.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71699
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Manish Goregaokar from comment #9)
> Already sent it :)
>
> https://gcc.gnu.org/ml/gcc-patches/2016-06/msg02057.HTML is the current
> patch; need to look at the test failures before movin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 70991, which changed state.
Bug 70991 Summary: Uninitialized class allowed if it came from self-assignment,
or a member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70991
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52167
Manuel López-Ibáñez changed:
What|Removed |Added
CC||appfault at hotmail dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70991
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79752
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
--- Comment #32 from Manuel López-Ibáñez ---
(In reply to Vincent Lefèvre from comment #31)
> In any case, no warnings are generated. So, the problem here is not related
> to whether the address of j is taken, but to something else.
With a const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571
--- Comment #9 from Bernd Schmidt ---
Maybe we just need to declare this address to be invalid for TImode. The
following seems to cure the testcase; untested otherwise.
Index: i386.c
==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79814
--- Comment #2 from David Malcolm ---
The code in question is:
do { ((void)(!(
__null
== pass_warn_unused_result_1) ? fancy_abort ("./pass-instances.def", 36,
__FUNCTION__), 0 : 0)); if ((1) == 1) pass_warn_unused_result_1 =
make_pass_warn_u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79847
Bug ID: 79847
Summary: diagnostics: missing space in "implicit declaration of
function"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79846
Bug ID: 79846
Summary: s390: untranslatable diagnostic in s390.c
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79845
Bug ID: 79845
Summary: rs6000: make code in rd6000.c more i18n-friendly
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79844
Bug ID: 79844
Summary: diagnostics: extra space at end of line
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79843
Bug ID: 79843
Summary: diagnostics: missing word in fortran/symbol.c,
conflict_std
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379
--- Comment #29 from Thomas Koenig ---
(In reply to David Edelsohn from comment #28)
> Because PPC64LE Linux reset the base ISA level, VSX now is enabled by
> default, so a function clone for VSX probably isn't necessary. While
> special version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79758
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79758
--- Comment #3 from Marek Polacek ---
Author: mpolacek
Date: Fri Mar 3 22:19:24 2017
New Revision: 245886
URL: https://gcc.gnu.org/viewcvs?rev=245886&root=gcc&view=rev
Log:
PR c/79758
* c-decl.c (store_parm_decls_oldstyle): Chec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79842
Bug ID: 79842
Summary: i18n: subword translation in "Can't use the same
%smodule"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771
--- Comment #4 from Yaakov Selkowitz ---
This is an upstream issue in the recent zlib releases, here's a patch:
https://github.com/cygwinports/zlib/blob/master/1.2.11-gzopen_w.patch
Configuring with --with-system-zlib avoids this, as long as gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771
--- Comment #3 from Daniel Santos ---
I'm guessing that either they didn't test on Cygwin or they tested on a
pre-release version or I have some local/environmental issue, although my
environment was just recently generated.
Upstream is at 1.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841
--- Comment #2 from Roland Illig ---
German readers generally expect the %qs directly after the word "object".
This choice should eliminate all ambiguities, since in "object of type %qs",
the user no longer has to think about whether the %qs bel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79596
--- Comment #3 from joseph at codesourcery dot com ---
On Fri, 3 Mar 2017, roland.illig at gmx dot de wrote:
> I assume that somewhere there is some list of functions that take translatable
> strings, since xgettext has to decide which of these
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841
Bug ID: 79841
Summary: Inconsistent diagnostics in fortran/openmp.c, function
check_symbol_not_pointer
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79840
--- Comment #1 from Andrew Pinski ---
This is an internal compiler error diagnostic really. Though maybe it should be
consistent it is not a huge issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79840
Bug ID: 79840
Summary: Inconsistent exclamation mark in diagnostic
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79839
Bug ID: 79839
Summary: malloc(0) returns 0 on AIX even with
_LINUX_SOURCE_COMPAT
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79805
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79837
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79837
--- Comment #1 from Jakub Jelinek ---
Author: jakub
Date: Fri Mar 3 20:16:58 2017
New Revision: 245885
URL: https://gcc.gnu.org/viewcvs?rev=245885&root=gcc&view=rev
Log:
PR c/79837
* c-parser.c (c_parser_omp_clause_reduction): D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79838
Bug ID: 79838
Summary: inconsistent trailing dot in diagnostic "The name %qs
has already been used"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79836
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79836
--- Comment #1 from Jakub Jelinek ---
Author: jakub
Date: Fri Mar 3 19:56:54 2017
New Revision: 245883
URL: https://gcc.gnu.org/viewcvs?rev=245883&root=gcc&view=rev
Log:
PR c/79836
* c-parser.c (c_parser_generic_selection): Use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79837
Bug ID: 79837
Summary: incomplete diagnostic in c-parser: expected +, *, -,
&, ^, |, &&, ||, min or identifier
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379
--- Comment #28 from David Edelsohn ---
Because PPC64LE Linux reset the base ISA level, VSX now is enabled by default,
so a function clone for VSX probably isn't necessary. While special versions
might help AIX and PPC64BE, with lower ISA defaul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79836
Bug ID: 79836
Summary: typo in c/c-parser.c: pragma omp ordered
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379
--- Comment #27 from Thomas Koenig ---
(In reply to # David Edelsohn from comment #26)
> What is AVX-specific, as opposed to SIMD vector size-specific, about this
> feature? It seems that this should be enabled for all SIMD architectures of
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79835
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
--- Comment #1 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79805
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Fri Mar 3 19:32:01 2017
New Revision: 245882
URL: https://gcc.gnu.org/viewcvs?rev=245882&root=gcc&view=rev
Log:
PR middle-end/79805
* internal-fn.def (ATOMIC_BIT_TEST_AND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79835
Bug ID: 79835
Summary: load to a variable outside the scope of a function is
optimized out
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79834
Bug ID: 79834
Summary: c/c-parser.c: make code more i18n-friendly
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58987
Volker Reichelt changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
Known to work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77854
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71437
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78687
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79596
--- Comment #2 from Roland Illig ---
(In reply to Dominique d'Humieres from comment #1)
> > Internal errors should not be translated. Their only purpose is to give
> > information back to the developers, and this information should not be
> > mod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77687
Segher Boessenkool changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50467
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77687
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79804
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43763
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571
--- Comment #7 from Vladimir Makarov ---
I am working on the PR. I hope the fix will be ready at the beginning of the
next week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
--- Comment #10 from Jerry DeLisle ---
We are not handling the internal unit check correctly in unit.c (get_unit) and
we return a NULL to the caller which is then interpreted as an error. I am
working on the fix now. (just a little head scratchin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79833
Bug ID: 79833
Summary: std::put_time has the wrong values for 2 digit years
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43763
--- Comment #4 from Segher Boessenkool ---
Author: segher
Date: Fri Mar 3 17:00:50 2017
New Revision: 245880
URL: https://gcc.gnu.org/viewcvs?rev=245880&root=gcc&view=rev
Log:
rs6000: Fix for -mwarn-cell-microcode (PR43763)
If using -mwarn-cel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79699
--- Comment #7 from Martin Sebor ---
Author: msebor
Date: Fri Mar 3 16:35:00 2017
New Revision: 245878
URL: https://gcc.gnu.org/viewcvs?rev=245878&root=gcc&view=rev
Log:
PR tree-optimization/79699 - small memory leak in MPFR
gcc/ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79699
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828
--- Comment #8 from Arnd Bergmann ---
(In reply to Jakub Jelinek from comment #6)
> If the warning has false positives, then I'm sure the kernel will turn it
> off anyway like it does with tons of other warnings.
That is well possible. I try to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828
--- Comment #7 from Jeffrey A. Law ---
The thing is, if we could prove the trap is always executed, then we'd just zap
everything prior to the trap without visible side effects and everything after
the trap. It's actually not an interesting case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79812
Jakub Jelinek changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79812
--- Comment #2 from Jakub Jelinek ---
Created attachment 40880
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40880&action=edit
gcc7-pr79812.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79793
--- Comment #2 from Yulia Koval ---
Patch posted at
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00178.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68270
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79832
--- Comment #1 from Felix Morgner ---
adjusted the title to be more clear. sorry!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79832
Bug ID: 79832
Summary: [C++14/17] result of array subscript operator should
be xvlaue
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79796
--- Comment #5 from Marek Polacek ---
Surprisingly my naïve attempt to fix this works:
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8047,6 +8047,8 @@ build_over_call (struct z_candidate *cand, int flags,
tsubst_flags_t complain)
{
arg =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79812
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79831
Bug ID: 79831
Summary: [DOC][CHKP] Missing -Wchkp
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79830
--- Comment #3 from Petr ---
Sorry for misunderstanding, I really read initially that you replaced the exit
condition in the sample code :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79830
--- Comment #2 from Petr ---
I'm not sure I follow with the exit test. I mean the code should be correct as
each point has x|y coord, which is two doubles, so length 8 means 16 doubles (I
converted from my production code into a simpler form that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79830
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79830
Bug ID: 79830
Summary: GCC generates counterproductive code surrounding very
simple loops (improvement request)
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79829
Bug ID: 79829
Summary: Assumes host CC and CXX behave the same
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79827
--- Comment #7 from Richard Biener ---
You can look at imposed limits with
> ulimit -a
and for example raise stack limit with
> ulimit -s unlimited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79827
Richard Biener changed:
What|Removed |Added
Keywords||build
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79807
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79807
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Fri Mar 3 12:24:53 2017
New Revision: 245871
URL: https://gcc.gnu.org/viewcvs?rev=245871&root=gcc&view=rev
Log:
PR target/79807
* config/i386/i386.c (ix86_expand_multi_ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771
--- Comment #2 from Jakub Jelinek ---
There is
https://github.com/madler/zlib/commit/b4ce6caf0992296230e4e25b22a63e418bdf4dcf
but not enough further info why it has changed. So, report upstream?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79782
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46854
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79780
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79760
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
1 - 100 of 142 matches
Mail list logo