[Bug c++/54197] [4.7/4.8 regression] Lifetime of reference not properly extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54197 Ollie Wild changed: What|Removed |Added CC||aaw at gcc dot gnu.org AssignedTo|unassigned at gcc dot |aaw at gcc dot gnu.org |gnu.org | --- Comment #2 from Ollie Wild 2012-08-13 18:04:21 UTC --- The issue is that these cause a COMPOUND_EXPR to be passed to extend_ref_init_temps_1. I have a patch which replaces the second operand of the COMPOUND_EXPR with another call to extend_ref_init_temps_1. Testing now. Will send out for review shortly.
[Bug c++/54197] [4.7/4.8 regression] Lifetime of reference not properly extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54197 --- Comment #3 from Ollie Wild 2012-08-16 18:44:01 UTC --- Author: aaw Date: Thu Aug 16 18:43:52 2012 New Revision: 190450 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190450 Log: Fix some cases where lifetimes of temporaries bound to expressions are not properly extended (Google ref b/6946758). 2012-08-16 Ollie Wild PR c++/54197 * gcc/cp/call.c (extend_ref_init_temps_1): Handle COMPOUND_EXPR trees. * gcc/testsuite/g++.dg/init/lifetime3.C: New test. Added: branches/google/gcc-4_7/gcc/testsuite/g++.dg/init/lifetime3.C Modified: branches/google/gcc-4_7/gcc/cp/ChangeLog.google-4_7 branches/google/gcc-4_7/gcc/cp/call.c branches/google/gcc-4_7/gcc/testsuite/ChangeLog.google-4_7
[Bug c++/54197] [4.7/4.8 regression] Lifetime of reference not properly extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54197 --- Comment #4 from Ollie Wild 2012-08-16 18:46:42 UTC --- Fix submitted to the google/gcc-4_7 branch. Still waiting on maintainer approval for the trunk and gcc-4_7-branches.
[Bug c++/54293] When a reference is bound to subobject of a temporary, lifetime of the temporary is not extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54293 --- Comment #3 from Ollie Wild 2012-08-17 14:18:59 UTC --- No, this is a different failure. With my patch applied, the testcase still fails exactly as described.
[Bug c++/54197] [4.7/4.8 regression] Lifetime of reference not properly extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54197 --- Comment #5 from Ollie Wild 2012-08-31 15:47:37 UTC --- Author: aaw Date: Fri Aug 31 15:47:29 2012 New Revision: 190834 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190834 Log: 2012-08-31 Ollie Wild PR c++/54197 * gcc/cp/call.c (extend_ref_init_temps_1): Handle COMPOUND_EXPR trees. * gcc/testsuite/g++.dg/init/lifetime3.C: New test. Added: trunk/gcc/testsuite/g++.dg/init/lifetime3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/54197] [4.7/4.8 regression] Lifetime of reference not properly extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54197 --- Comment #6 from Ollie Wild 2012-08-31 17:16:47 UTC --- Author: aaw Date: Fri Aug 31 17:16:39 2012 New Revision: 190839 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190839 Log: Backport from mainline 2012-08-31 Ollie Wild PR c++/54197 * gcc/cp/call.c (extend_ref_init_temps_1): Handle COMPOUND_EXPR trees. * gcc/testsuite/g++.dg/init/lifetime3.C: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/init/lifetime3.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/call.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c++/54197] [4.7/4.8 regression] Lifetime of reference not properly extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54197 Ollie Wild changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Ollie Wild 2012-08-31 17:24:07 UTC --- Fixed for 4.7.2+.
[Bug libstdc++/54482] failures in static linking with libstdc++, due to versioned symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54482 Ollie Wild changed: What|Removed |Added AssignedTo|unassigned at gcc dot |aaw at gcc dot gnu.org |gnu.org | --- Comment #1 from Ollie Wild 2012-09-06 14:52:23 UTC --- The best solution I could come up with was to patch libtool to enable passing options destined for only the shared or static library builds. See http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00340.html for the temporary workaround I've applied to the google/* branches. Getting this submitted to trunk is going to be a roundabout process. I need to patch libtool, import an updated libtool to gcc (last one was in 2009), and convert libstdc++ to use a macro other than PIC for identifying that it's being compiled as part of a shared library. If other people have better ideas, I'm all ears.
[Bug libstdc++/54482] failures in static linking with libstdc++, due to versioned symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54482 --- Comment #3 from Ollie Wild 2012-09-12 04:58:29 UTC --- Note, however, that simply changing pic_flag to pic_flag="-D_GLIBCXX_SHARED -fPIC -DPIC" is insufficient. It suffers from the same issue as the original problem, namely that, when configured with --with-pic, pic_flag is passed even when compiling objects for libstdc++.a. Since your solution passes -DPIC and -D_GLIBCXX_SHARED in tandem, keying off the new macro suffers from the same limitations as the old one. See my previous comment. In particular, the link there points to a more detailed analysis, as well as a patch which outlines the basics of what I think needs to change. As you correctly suggest, we need a mechanism to pass flags based on whether we're compiling for a static or shared library independently of whether or not -fPIC is used. The aforementioned patch does that in our branch, but that will need to be cleaned up and submitted to upstream libtool before incorporating it in GCC trunk.
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #17 from Ollie Wild 2012-10-13 08:08:49 UTC --- I'm on vacation until Mon, Oct. 15. For compiler related questions, please email c-compiler-t...@google.com. If you need to contact a manager, please email lp-m...@google.com. Thanks, Ollie
[Bug c++/52538] Extend C++11 UDLs to be compatible with inttypes.h macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52538
--- Comment #3 from Ollie Wild 2012-04-27 14:29:39 UTC
---
Author: aaw
Date: Fri Apr 27 14:29:32 2012
New Revision: 186909
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186909
Log:
Add new option, -Wliteral-suffix.
This option, which is enabled by default, causes the preprocessor to warn
when a string or character literal is followed by a ud-suffix which does
not begin with an underscore. According to [lex.ext]p10, this is
ill-formed.
Also modifies the preprocessor to treat such ill-formed suffixes as separate
preprocessing tokens. This is consistent with the Clang front end (see
http://llvm.org/viewvc/llvm-project?view=rev&revision=152287), and enables
backwards compatibility with code that uses formatting macros from
, as in the following code block:
int main() {
int64_t i64 = 123;
printf("My int64: %"PRId64"\n", i64);
}
Google ref b/6377711.
2012-04-27 Ollie Wild
PR c++/52538
* gcc/c-family/c-common.c: Add CPP_W_LITERAL_SUFFIX mapping.
* gcc/c-family/c-opts.c (c_common_handle_option): Handle
OPT_Wliteral_suffix.
* gcc/c-family/c.opt: Add Wliteral-suffix.
* gcc/doc/invoke.texi (Wliteral-suffix): Document new option.
* gcc/testsuite/g++.dg/cpp0x/Wliteral-suffix.c: New test.
* libcpp/include/cpplib.h (struct cpp_options): Add new field,
warn_literal_suffix.
(CPP_W_LITERAL_SUFFIX): New enum.
* libcpp/init.c (cpp_create_reader): Default initialization of
warn_literal_suffix.
* libcpp/lex.c (lex_raw_string): Treat user-defined literals which
don't begin with '_' as separate tokens and produce a warning.
(lex_string): Ditto.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/Wliteral-suffix.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-opts.c
trunk/gcc/c-family/c.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/include/cpplib.h
trunk/libcpp/init.c
trunk/libcpp/lex.c
[Bug preprocessor/20262] __LINE__ implementation flaky.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262 Ollie Wild changed: What|Removed |Added CC||aaw at gcc dot gnu.org --- Comment #4 from Ollie Wild --- We recently ran into this issue in a context where __LINE__ was being used to produce goto labels inside a macro-wrapped block of code. The code in question compiled fine with Clang/LLVM but produced a compiler error with GCC. I've read through the standard (in this case, C++11), and as I read it "presumed source line" is used to allow for the possibility of modifying the source line via #line directives (which it says immediately thereafter in a footnote), not as general consent to be liberal with line numbering. Regardless, using the true physical line conforms to the principle of least surprise. Would anyone be opposed to revisiting this?
[Bug c++/51151] Invalid -Woverflow warning in C++ frontend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51151 --- Comment #7 from Ollie Wild 2012-01-02 17:35:07 UTC --- I'm on vacation until Jan. 6. For compiler related questions, please email c-compiler-t...@google.com. If you need to contact a manager, please email lp-m...@google.com. Thanks, Ollie
[Bug c++/61492] Nested-name-specifier lookup finds function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61492 Ollie Wild changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Ollie Wild --- This looks like a duplicate of 60994. *** This bug has been marked as a duplicate of bug 60994 ***
[Bug c++/60994] gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60994 Ollie Wild changed: What|Removed |Added CC||potswa at mac dot com --- Comment #6 from Ollie Wild --- *** Bug 61492 has been marked as a duplicate of this bug. ***
[Bug c++/49198] New: GCC trunk and 4.6 generate spurious "has incomplete type" errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49198 Summary: GCC trunk and 4.6 generate spurious "has incomplete type" errors Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: a...@gcc.gnu.org Created attachment 24376 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24376 Minimal reproduction See the attached tst.cc file. When compiled with GCC trunk and 4.6, it generates the following errors: tst.cc: In instantiation of ‘S’: tst.cc:14:7: instantiated from here tst.cc:3:32: error: ‘S::t’ has incomplete type tst.cc:1:7: error: forward declaration of ‘struct IC’ However, the code is structured such that IC need not be complete. According to the C++ standard (14.7.1): "Unless a class template specialization has been explicitly instantiated (14.7.2) or explicitly specialized (14.7.3), the class template specialization is implicitly instantiated when the specialization is referenced in a context that requires a completely-defined object type or when the completeness of the class type affects the semantics of the program." In this case, we only refer to S* (pointer), which does not require a complete type. Therefore, the class template specialization S should not be instantiated, and IC need not be complete. Various trivial modifications to this program (e.g. replacing S* with IC* or replacing FT(F) with F) do not generate an error. Nor does GCC 4.4.3.
[Bug c++/49198] GCC generates spurious "has incomplete type" errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49198 --- Comment #4 from Ollie Wild 2011-05-31 18:13:02 UTC --- Thanks for the clarification, Jason. I would not have figured that out on my own.
