[Bug fortran/79840] New: Inconsistent exclamation mark in diagnostic

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

[Bug fortran/79840] Inconsistent exclamation mark in diagnostic

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.

[Bug fortran/79841] New: Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

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

[Bug fortran/79596] translation: argument to gfc_internal_error should not be translated

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

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

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

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

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

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

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

[Bug fortran/79842] New: i18n: subword translation in "Can't use the same %smodule"

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

[Bug c/79758] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in store_parm_decls_oldstyle, at c/c-decl.c:8973

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

[Bug c/79758] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in store_parm_decls_oldstyle, at c/c-decl.c:8973

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79758 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug libfortran/78379] Processor-specific versions for matmul

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

[Bug fortran/79843] New: diagnostics: missing word in fortran/symbol.c, conflict_std

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

[Bug fortran/79844] New: diagnostics: extra space at end of line

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

[Bug target/79845] New: rs6000: make code in rd6000.c more i18n-friendly

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

[Bug target/79846] New: s390: untranslatable diagnostic in s390.c

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

[Bug c/79847] New: diagnostics: missing space in "implicit declaration of function"

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

[Bug bootstrap/79814] pass-instances.def:36:14: error: ‘*.gcc::pass_manager::pass_warn_unused_result_1’ is used uninitialized in this function

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

[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)

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 ==

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning

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

[Bug target/79752] incorrect code generation for __divkf3 with -O2 -mcpu=power9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79752 acsawdey at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution

[Bug c++/70991] Uninitialized class allowed if it came from self-assignment, or a member function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70991 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/52167] self-assignment should at least produce use-of-uninitialized warning

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

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

[Bug target/79846] s390: untranslatable diagnostic in s390.c

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.

[Bug middle-end/71699] bogus -Wmaybe-uninitialized warning: gcc misses that non-NULL pointer + offset can never be NULL

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

[Bug middle-end/71699] bogus -Wmaybe-uninitialized warning: gcc misses that non-NULL pointer + offset can never be NULL

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

[Bug middle-end/78370] Missing uninitialzed warning

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

[Bug middle-end/79768] `-Wmaybe-uninitialized' false positive with optimisation

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

[Bug middle-end/78993] False positive from -Wmaybe-uninitialized

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

[Bug middle-end/78203] missing warning on return of unitialized variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78203 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug tree-optimization/18501] [5/6/7 Regression] Missing 'used uninitialized' warning (CCP)

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

[Bug middle-end/72826] bad pretty-printing of decl *((void*)& x +offset) for uninitialized structure field (ESRA)

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

[Bug middle-end/72826] bad pretty-printing of decl *((void*)& x +offset) for uninitialized structure field (ESRA)

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

[Bug tree-optimization/77627] Unexpected void * dereference in uninit warning (and missed out-of-bounds warning)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77627 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

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 ---

[Bug c/16351] NULL dereference warnings

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

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

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

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

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

[Bug middle-end/79768] `-Wmaybe-uninitialized' false positive with optimisation

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

[Bug c/79813] Hitting seg fault in cc1

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.

[Bug libstdc++/58909] C++11's condition variables fail with static linking

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909 abbycin changed: What|Removed |Added CC||abbytsing at hotmail dot com --- Comment #10 f

<    1   2