[Bug c++/82204] G++ doesn't connect friend and extern declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82204
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
--- gcc/cp/decl2.c.jj 2018-06-29 09:38:17.788306397 +0200
+++ gcc/cp/decl2.c 2018-06-30 09:54:59.516868946 +0200
@@ -5312,6 +5312,20 @@ mark_used (tree decl, tsubst_flags_t com
if (DECL_ODR_USED (decl))
return true;
+ /* If decl is local extern, recurse into corresponding decl. */
+ if (cfun
+ && cp_function_chain
+ && cp_function_chain->extern_decl_map
+ && VAR_OR_FUNCTION_DECL_P (decl)
+ && DECL_EXTERNAL (decl))
+{
+ struct cxx_int_tree_map *h, in;
+ in.uid = DECL_UID (decl);
+ h = cp_function_chain->extern_decl_map->find_with_hash (&in, in.uid);
+ if (h && !mark_used (h->to))
+ return false;
+}
+
/* Normally, we can wait until instantiation-time to synthesize DECL.
However, if DECL is a static data member initialized with a constant
or a constexpr function, we need it right now because a reference to
that helps with PR3698 doesn't help here.
[Bug c++/86243] unknown attribute before throw causes hard error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86243 Hannes Hauswedell changed: What|Removed |Added Keywords||rejects-valid Summary|unknown attributes causing |unknown attribute before |hard error |throw causes hard error --- Comment #3 from Hannes Hauswedell --- I have changed the title to reflect that this report is only about the error related to the throw and will open a separate issue for the warning.
[Bug c++/86368] New: an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 Bug ID: 86368 Summary: an unknown [[attribute]] should not trigger a warning in C++17 Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: h2+bugs at fsfe dot org Target Milestone: --- [this issue is split from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86243 ] Unknown attributes currently produce warnings in GCC (-Wattributes), however since C++17 the standard clearly states that C++ attributes (those with [[name]]) should be ignored when unknown: "Any attribute-token that is not recognized by the implementation is ignored." The purpose here is to let programmers add attributes that may not be supported on a platform (yet) and not force them to workaround their non-existance on that platform (be it via macros or extra compiler arguments). I would argue that is a very important aspect of attributes and that it will become increasingly important when more C++2a attributes are implemented in GCC and clang ([[likely]] [[unlikely]], [[expects: ]]...). I would even suggest not including a warning with -Wall or -Wextra, because an unknown attribute is and in the future even more likely will be part of the design and not an error. Moreover there is no clean way to workaround the warning, other than using macros which is not a clean way ;-) A stand-alone flag would of course still be useful to detect mistyped known attributes, but this should not trigger by default and IMHO also not with regular quality control (-Wall -Wextra).
[Bug c++/86369] New: constexpr const char* comparison fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369
Bug ID: 86369
Summary: constexpr const char* comparison fails
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: linuxfever at yahoo dot gr
Target Milestone: ---
The following snippet seems to produce contradictory results when comparing
const char* pointers in a constexpr expression:
constexpr auto name1() {
return "test1";
}
constexpr auto name2() {
return "test2";
}
int main() {
constexpr auto b1 = (name1() == name1()); // compiles cleanly
constexpr auto b2 = (name1() == name2()); // doesn't compile
}
This may be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71448, but
not sure as the latter is meant to be fixed.
I've tried other GCC versions here and all seem to fail:
https://godbolt.org/g/8KwV2g
[Bug fortran/86242] [6/7/8/9 Regression] [OOP] ICE for derived type with allocatable component and proc-ptr component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86242 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #7 from Paul Thomas --- I am just about to post a fix for this PR. Paul
[Bug fortran/82969] [6/7/8/9 Regression] ICE in gfc_class_vptr_get, at fortran/trans-expr.c:211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82969 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- I am just about to post a fix for this PR. Paul
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 --- Comment #7 from joseph at codesourcery dot com --- If you use __builtin_nansf128 (which returns _Float128) but __float128 is long double, it's possible the implicit conversion from storing the result of __builtin_nansq in y.value results in converting a signaling NaN to a quiet NaN (it's unspecified whether conversion by assignment to the same floating-point format is a convertFormat or copy operation). If that's what's going on, then, given that __builtin_nansq etc. correspond to the type name __float128 (not to _Float128), those built-in functions (all the *q ones) should be mapped to those for whatever type __float128 is equivalent to, to avoid such conversions of signaling to quiet NaNs. I.e., if the issue is such an implicit conversion of signaling to quiet NaN, the patch attached to this issue is using the right approach for a fix.
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 --- Comment #8 from Bill Schmidt --- That makes sense -- we already have a NaN rather than an SNaN by the time we hit the Ealias pass.
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 --- Comment #9 from Segher Boessenkool --- (In reply to Bill Schmidt from comment #8) > That makes sense -- we already have a NaN rather than an SNaN by the time we > hit the Ealias pass. It's already a QNaN in 004t.original (the very first dump file) (but at the time the builtin_nan* are constructed, in fold_const_builtin_nan, it is all okay still).
[Bug other/82383] Some new toplevel directories are not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82383 --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > libcilkrts can be removed from the list of directories to document, since it > no longer exists in trunk. Same with libmpx now too.
[Bug bootstrap/11799] The toplevel should handle multi-libs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11799 Eric Gallager changed: What|Removed |Added Status|ASSIGNED|NEW CC|egall at gwmail dot gwu.edu|egallager at gcc dot gnu.org, ||neroden at gcc dot gnu.org Assignee|neroden at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #5 from Eric Gallager --- (In reply to Nathanael C. Nerode from comment #3) > If anyone else wants to work on this, feel free; getting the current stuff > working again (with the various autoconf 2.5x transitions) is unfortunately > higher priority, so I haven't gotten properly started. :-P Unassigning then.
[Bug go/46986] Go is not supported on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 Eric Gallager changed: What|Removed |Added CC|egall at gwmail dot gwu.edu|egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=52268, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=46958, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=46965 --- Comment #40 from Eric Gallager --- (In reply to Jack Howarth from comment #24) > (In reply to comment #22) > > > > ucontext is missing altogether from Mac OS X 10.7, but there is no TLS > > either: > > > > error: thread-local storage not supported for this target > > There is tis support within clang in Xcode 4.2 (see radar:10291355, "Xcode > 4.2 miscompiles tls support in > MPFR 3.1.0" which was fixed in Xcode 4.2.1), however FSF gcc currently > doesn't generate the required assembly for tis support. This is bug 52268, for reference
