[Bug tree-optimization/58011] GCC segfaults at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58011 --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org --- Is this done? If so, can we close this PR?
[Bug regression/60363] [4.9 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 Threaded 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug c/60360] __attribute((aligned(...))) changes sizeof(...) of struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60360
--- Comment #6 from DaBler dabler at gmail dot com ---
When I call sizeof(...) on the int type (instead of a variable), it is the
same:
typedef int TypeInt __attribute((aligned(64)));
printf(%zu %zu\n, sizeof(TypeInt), alignof(TypeInt)); // Output: 4 64
Moreover, It is not possible to use this type for a construction of arrays. In
contrast, When I call sizeof(...) on the struct type:
typedef struct {
int i;
} __attribute((aligned(64))) TypeStruct;
printf(%zu %zu\n, sizeof(TypeStruct), alignof(TypeStruct)); // Output: 64 64
Thus, I still see an inconsistency.
[Bug lto/55113] ICE with LTO and -fshort-double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113 --- Comment #16 from pmatos at gcc dot gnu.org --- (In reply to Richard Biener from comment #14) Well. At least to my theory (didn't try). Theory and practice match. It seems to fix the bug and work fine. I will do some further testing and post a patch. Thanks.
[Bug c++/60364] New: [[noreturn]] specified for second declaration but not first doesn't result in a diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60364
Bug ID: 60364
Summary: [[noreturn]] specified for second declaration but not
first doesn't result in a diagnostic
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: filip.roseen at gmail dot com
Created attachment 32232
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32232action=edit
testcase.cpp
void func ();
void func [[noreturn]] ();
int main () { }
--
The above should result in an error since [dcl.attr.noreturn]p1 explicitly
says;
The first declaration of a function shall specify the noreturn
attribute if any declaration of that function specifies the noreturn
attribute.
Both clang and icc correctly issues a diagnostic when trying to compile the
provided snippet.
[Bug c++/60365] New: multiple noreturn attribute specifiers in single declaration doesn't result in a diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60365
Bug ID: 60365
Summary: multiple noreturn attribute specifiers in single
declaration doesn't result in a diagnostic
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: filip.roseen at gmail dot com
Created attachment 32233
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32233action=edit
testcase.cpp
void func [[noreturn, noreturn]] ();
int main () { }
--
noreturn shall only be specified once for each declaration it is a part of, as
stated in [dcl.attr.noreturn]p1
The attribute-token noreturn specifies that a function does not
return. It shall appear at most once in each attribute-list and no
attribute-argument-clause shall be present.
Both clang and icc correctly issues a diagnostic when trying to compile the
provided snippet.
[Bug ipa/60306] [4.9 Regression] Incorrect devirtualization pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60306
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #4)
OK, I am re-considering my decision to not assign this to Martin.
The problem is the following. We have call:
struct Box x;
...
x = edges_connecting_to_node (1); [return slot optimization]
...
_19 = OBJ_TYPE_REF(_18;(const struct Object)x.D.8084-0) (x.D.8084);
The dynamic type of x at that point is Box. We however get it wrong as
Object. This is what come from detect_type_change.
The reason is that detect_type_change actually ignores
x = edges_connecting_to_node (1); [return slot optimization]
which it should not, since it gives it an useful information that x is fully
constructed when the return value happens.
But it considers other statement:
MEM[(struct new_allocator *)x + 8B] ={v} {CLOBBER};
MEM[(struct allocator *)x + 8B] ={v} {CLOBBER};
MEM[(struct _Vector_impl *)x + 8B] ={v} {CLOBBER};
MEM[(struct _Vector_base *)x + 8B] ={v} {CLOBBER};
MEM[(struct vector *)x + 8B] ={v} {CLOBBER};
MEM[(struct Object *)x]._vptr.Object = MEM[(void *)_ZTV6Object + 16B];
MEM[(struct Object *)x] ={v} {CLOBBER};
x ={v} {CLOBBER};
which is end of the loop the whole thing is contained in. The dead store to
._vptr.Object come from inlined destructor and it makes detect_type_change
to believe that the dynamic type is Object. That is true if you manage to
ignore the initialization.
Now I wonder how to fix this; simple fix is to make detect_type_change to
notice the call and constructors, that is useful by itself.
But I believe there is deeper problem, we need to prove that on _all_ paths
to the statement the dynamic type was changed in known way, not that on all
paths where we can understand the dynamic change the type changed same way.
It seems that the current code doesn't properly perform that merging. The
walker will happily walks all incoming edges of PHIs.
Can alias oracle walker tell us when it runs into default def?
Well, it simply stops walking, so no, it doesn't return whether the
callback returned always false (I didn't need it so I didn't implement it ...).
[Bug ipa/60306] [4.9 Regression] Incorrect devirtualization pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60306
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org ---
Of course the bug seems to be
static bool
stmt_may_be_vtbl_ptr_store (gimple stmt)
{
if (is_gimple_call (stmt))
return false;
^^^
this. I remember being very curious when seeing this ;)
Please at this point only fix that bug, not introduce more fancy stuff (we're
long past a stage where that is appropriate).
[Bug debug/57232] wcstol.c:213:1: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57232 --- Comment #20 from Alexandre Oliva aoliva at gcc dot gnu.org --- Author: aoliva Date: Fri Feb 28 12:45:36 2014 New Revision: 208219 URL: http://gcc.gnu.org/viewcvs?rev=208219root=gccview=rev Log: PR debug/57232 * var-tracking.c (vt_initialize): Apply the same condition to preserve the CFA base value. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c
[Bug debug/59992] [4.9 Regression] Compilation of insn-recog.c too slow due to var-tracking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59992 --- Comment #11 from Alexandre Oliva aoliva at gcc dot gnu.org --- Author: aoliva Date: Fri Feb 28 12:57:06 2014 New Revision: 208220 URL: http://gcc.gnu.org/viewcvs?rev=208220root=gccview=rev Log: PR debug/59992 * cselib.c (remove_useless_values): Skip to avoid quadratic behavior if the condition moved from... (cselib_process_insn): ... here holds. Modified: trunk/gcc/ChangeLog trunk/gcc/cselib.c
[Bug debug/59992] [4.9 Regression] Compilation of insn-recog.c too slow due to var-tracking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59992 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Alexandre Oliva aoliva at gcc dot gnu.org --- Fixed
[Bug debug/57232] wcstol.c:213:1: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57232 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #21 from Alexandre Oliva aoliva at gcc dot gnu.org --- Fixed
[Bug tree-optimization/60280] [4.9 Regression] gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c failed caused by preserving loop structure.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60280 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Feb 28 13:14:23 2014 New Revision: 208222 URL: http://gcc.gnu.org/viewcvs?rev=208222root=gccview=rev Log: 2014-02-28 Richard Biener rguent...@suse.de PR target/60280 * tree-cfgcleanup.c (tree_forwarder_block_p): Restrict previous fix and only allow to remove trivial pre-headers and latches. Also honor LOOPS_MAY_HAVE_MULTIPLE_LATCHES. (remove_forwarder_block): Properly update the latch of a loop. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-cfgcleanup.c
[Bug debug/59992] [4.9 Regression] Compilation of insn-recog.c too slow due to var-tracking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59992 --- Comment #12 from Alexandre Oliva aoliva at gcc dot gnu.org --- Author: aoliva Date: Fri Feb 28 12:57:40 2014 New Revision: 208221 URL: http://gcc.gnu.org/viewcvs?rev=208221root=gccview=rev Log: PR debug/59992 * cselib.c (cselib_hasher::equal): Special-case VALUE lookup. (cselib_preserved_hash_table): New. (preserve_constants_and_equivs): Move preserved vals to it. (cselib_find_slot): Look it up first. (cselib_init): Initialize it. (cselib_finish): Release it. (dump_cselib_table): Dump it. Modified: trunk/gcc/ChangeLog trunk/gcc/cselib.c
[Bug tree-optimization/53787] Possible IPA-SRA / IPA-CP improvement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53787 --- Comment #18 from Igor Zamyatin izamyatin at gmail dot com --- Martin, I checked the patch and can confirm it gives necessary speedup on the test (UMTmk_1.1) Thanks!
[Bug c++/60366] New: ICE with self-invoking lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60366
Bug ID: 60366
Summary: ICE with self-invoking lambdas
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
This not-so-serious code:
$ cat w.cpp
int main(int argc, const char **argv)
{
auto f = [](const struct __lambda0 self) { self(self); };
f(f);
return 0;
}
causes an ICE instead of just exiting(1):
$ g++ w.cpp -std=gnu++11 -o w -ggdb3 -Wall
w.cpp: In lambda function:
w.cpp:3:55: error: use of ‘main(int, const char**)::__lambda0’ before deduction
of ‘auto’
auto f = [](const struct __lambda0 self) { self(self); };
^
w.cpp:3:55: error: invalid use of ‘auto’
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.opensuse.org/ for instructions.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-4.8 --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
gcc version 4.8.2 20140225 [gcc-4_8-branch revision 208119] (SUSE Linux)
$ g++-4.9 w.cpp -std=gnu++11 -o w -ggdb3 -Wall
g++-4.9: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.opensuse.org/ for instructions.
$ g++-4.9 -v
Using built-in specs.
COLLECT_GCC=g++-4.9
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.9/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada,go --enable-checking=yes
--with-gxx-include-dir=/usr/include/c++/4.9 --enable-ssp --disable-libssp
--disable-libvtv --disable-plugin --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-version-specific-runtime-libs
--enable-linker-build-id --enable-linux-futex --program-suffix=-4.9
--without-system-libunwind --enable-multilib --with-arch-32=i586
--with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 4.9.0 20140226 (experimental) [trunk revision 208172] (SUSE Linux)
[Bug fortran/60359] [OOP] symbol `__io_MOD___copy_character_1' is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60359
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2014-02-28
CC||janus at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
Summary|Assembler messages symbol |[OOP] symbol
|`__io_MOD___copy_character_ |`__io_MOD___copy_character_
|1' is already defined |1' is already defined
Ever confirmed|0 |1
--- Comment #4 from janus at gcc dot gnu.org ---
This is due to a small bug in find_intrinsic_vtab. Patch:
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c(revision 208224)
+++ gcc/fortran/class.c(working copy)
@@ -2532,17 +2532,22 @@ find_intrinsic_vtab (gfc_typespec *ts)
c-tb = XCNEW (gfc_typebound_proc);
c-tb-ppc = 1;
- /* Check to see if copy function already exists. Note
- that this is only used for characters of different
- lengths. */
- contained = ns-contained;
- for (; contained; contained = contained-sibling)
-if (contained-proc_name
- strcmp (name, contained-proc_name-name) == 0)
- {
-copy = contained-proc_name;
-goto got_char_copy;
- }
+ if (ts-type != BT_CHARACTER)
+sprintf (name, __copy_%s, tname);
+ else
+{
+ /* __copy is always the same for characters.
+ Check to see if copy function already exists. */
+ sprintf (name, __copy_character_%d, ts-kind);
+ contained = ns-contained;
+ for (; contained; contained = contained-sibling)
+if (contained-proc_name
+ strcmp (name, contained-proc_name-name) == 0)
+ {
+copy = contained-proc_name;
+goto got_char_copy;
+ }
+}
/* Set up namespace. */
sub_ns = gfc_get_namespace (ns, 0);
@@ -2550,11 +2555,6 @@ find_intrinsic_vtab (gfc_typespec *ts)
ns-contained = sub_ns;
sub_ns-resolved = 1;
/* Set up procedure symbol. */
- if (ts-type != BT_CHARACTER)
-sprintf (name, __copy_%s, tname);
- else
-/* __copy is always the same for characters. */
-sprintf (name, __copy_character_%d, ts-kind);
gfc_get_symbol (name, sub_ns, copy);
sub_ns-proc_name = copy;
copy-attr.flavor = FL_PROCEDURE;
[Bug middle-end/59176] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59176 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org Assignee|mjambor at suse dot cz |unassigned at gcc dot gnu.org --- Comment #9 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #8) I believe it is bug somewhere in logic skipping thunks. Martin, this is probably yours. I on the other hand think this is either a verification false positive or some sort of cgraph node removal bug. What happens in IPA-CP is this: m_fn3/8 originally calls B::~B()/5 which is an alias (not a thunk as far as I can see but I do not see how that matters even if I was wrong) to B::~B()/4. IPA-CP does not gather constants for aliases or thunks separately (though it is careful not to propagate first parameters through thunks), so IPA-CP is only interested in the /4 real thing. Furthermore, it decides to clone B::~B()/4 and redirect the call from m_fn3/8 to the new clone. In fact, the modified edge passes verify_edge_corresponds_to_fndecl just fine several times because of !clone_of_p (cgraph_function_or_thunk_node (node, NULL), e-callee)) part of the checking correctly detects this case. But then, after being successfully verified a number of times, the above fails, because the cgraph_function_or_thunk_node (node, NULL) part stops returning the /4 node but returns the argument itself which is /5. When I now dump the node I cannot see it being an alias and that is because symtab_remove_unreachable_nodes had zapped it. I think that either symtab_remove_unreachable_nodes should remove nodes it cripples from the decl-symtab hash (why does it not call cgraph_remove_node?) or the verifier needs to understand that these nodes are no good and ignore them.
[Bug c++/60314] [C++1y] ICE with decltype(auto) when generating debug information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60314 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Fri Feb 28 16:51:21 2014 New Revision: 208225 URL: http://gcc.gnu.org/viewcvs?rev=208225root=gccview=rev Log: 2014-02-25 Paolo Carlini paolo.carl...@oracle.com PR c++/60314 * dwarf2out.c (is_cxx_auto): Handle decltype(auto). /testsuite 2014-02-25 Paolo Carlini paolo.carl...@oracle.com PR c++/60314 * g++.dg/cpp1y/auto-fn24.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn24.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug c++/60314] [C++1y] ICE with decltype(auto) when generating debug information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60314 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Sorry, this is the actual CL entry: 2014-02-28 Paolo Carlini paolo.carl...@oracle.com PR c++/60314 * dwarf2out.c (decltype_auto_die): New static. (gen_subprogram_die): Handle 'decltype(auto)' like 'auto'. (gen_type_die_with_usage): Handle 'decltype(auto)'. (is_cxx_auto): Likewise. Fixed for 4.9.0 anyway.
[Bug lto/60150] [4.9 Regression] ICE in function_and_variable_visibility, at ipa.c:1000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60150
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org ---
OK, this is ordering issue in the localization process: we localize comdat
groups one by one, but we also copy visibilities from functions to thunks (that
is somewhat useless fixup at LTO time).
This patch makes the comdat group localization to happen all at once.
Index: ipa.c
===
--- ipa.c (revision 207934)
+++ ipa.c (working copy)
@@ -970,15 +970,32 @@ function_and_variable_visibility (bool w
gcc_assert (whole_program || in_lto_p
|| !TREE_PUBLIC (node-decl));
node-unique_name = ((node-resolution == LDPR_PREVAILING_DEF_IRONLY
- || node-resolution ==
LDPR_PREVAILING_DEF_IRONLY_EXP)
- TREE_PUBLIC (node-decl));
+ || node-unqiue_name
+ || node-resolution ==
LDPR_PREVAILING_DEF_IRONLY_EXP)
+TREE_PUBLIC (node-decl));
node-resolution = LDPR_PREVAILING_DEF_IRONLY;
if (node-same_comdat_group TREE_PUBLIC (node-decl))
- /* cgraph_externally_visible_p has already checked all other nodes
- in the group and they will all be made local. We need to
- dissolve the group at once so that the predicate does not
- segfault though. */
- symtab_dissolve_same_comdat_group_list (node);
+ {
+ symtab_node *next = node;
+
+ /* Set all members of comdat group local. */
+ if (node-same_comdat_group)
+ for (next = node-same_comdat_group;
+next != node;
+next = next-same_comdat_group)
+ {
+ symtab_make_decl_local (next-decl);
+ next-unique_name = ((next-resolution ==
LDPR_PREVAILING_DEF_IRONLY
+ || next-unqiue_name
+ || next-resolution ==
LDPR_PREVAILING_DEF_IRONLY_EXP)
+TREE_PUBLIC (next-decl));
+ }
+ /* cgraph_externally_visible_p has already checked all other
nodes
+in the group and they will all be made local. We need to
+dissolve the group at once so that the predicate does not
+segfault though. */
+ symtab_dissolve_same_comdat_group_list (node);
+ }
symtab_make_decl_local (node-decl);
}
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #18 from Jan Hubicka hubicka at gcc dot gnu.org --- It is a speculative devirtualization; we see no other option than B, so we try to inline it. Speculative devirtualization already has logic in it so it won't pick method without definition (it also will pick if the method is const/pure, I can change that) Here we have extern inline function with a definition so speculative devirtualization is happy and inline it. I don't think we should be checking at devirtualization time if the inlined function has refernce to something external or not. So I would say that C++ FE should not produce extern inlines that can not be inlined after all or better mark them UNINLINABLE so they can be used for side effects analysis. Or perhaps we can extend tree_inlinable_function_p this way? Honza
[Bug c++/60367] New: Default argument object is not getting constructed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367
Bug ID: 60367
Summary: Default argument object is not getting constructed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rob.desbois at gmail dot com
Created attachment 32234
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32234action=edit
Preprocessed, minimal testcase triggering unexpected behaviour
The attached minimal testcase has the following function with
default-constructed default argument:
void do_something( foo f = {} )
{
std::cout default argument is at f std::endl;
}
The constructor for foo outputs its address; I got the following output from a
single run:
constructed foo @ 0x710bdb7f
default argument is at 0x710bdb60
It shows that only 1 foo was constructed, and not at the same address as that
of the default argument. It's been a lng week, but I can't see anything
wrong with the code. In the real code on which this was based, a segfault was
occurring when running the destructor of a foo that was move-constructed from
the default argument, because the underlying memory was seemingly
uninitialised.
build command output
--
[rob@localhost tests]$ g++ -v -save-temps -Wall -Wextra --std=c++0x
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations
default-args-fail.cpp -o ./default-args-fail
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++11'
'-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations' '-o'
'./default-args-fail' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/cc1plus -E -quiet -v -D_GNU_SOURCE
default-args-fail.cpp -mtune=generic -march=x86-64 -std=c++11 -Wall -Wextra
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations
-fpch-preprocess -o default-args-fail.ii
ignoring nonexistent directory
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/include-fixed
ignoring nonexistent directory
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../x86_64-redhat-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../include/c++/4.8.2/backward
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/include
/usr/local/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++11'
'-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations' '-o'
'./default-args-fail' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/cc1plus -fpreprocessed
default-args-fail.ii -quiet -dumpbase default-args-fail.cpp -mtune=generic
-march=x86-64 -auxbase default-args-fail -Wall -Wextra -std=c++11 -version
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -o
default-args-fail.s
GNU C++ (GCC) version 4.8.2 20131212 (Red Hat 4.8.2-7) (x86_64-redhat-linux)
compiled by GNU C version 4.8.2 20131212 (Red Hat 4.8.2-7), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.8.2 20131212 (Red Hat 4.8.2-7) (x86_64-redhat-linux)
compiled by GNU C version 4.8.2 20131212 (Red Hat 4.8.2-7), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 36de953cba87bab1ad58280401e36d59
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra'
[Bug fortran/60357] [F08] structure constructor with unspecified values for allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #3 from janus at gcc dot gnu.org --- (In reply to janus from comment #2) Draft patch: ... regtests cleanly!
[Bug middle-end/59176] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59176 --- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org --- hmm, I see, same body alias... Well, remove_unreachable_nodes does two things, it removes nodes that are completely unreachable and also removes definitions of nodes where definition is not needed, but they are still referenced and thus needs to stay. I suppose it is what happens here. I will check how to silence the verifier.
[Bug fortran/60359] [OOP] symbol `__io_MOD___copy_character_1' is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60359 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to janus from comment #4) This is due to a small bug in find_intrinsic_vtab. Patch: The patch from comment #4 regtests cleanly.
[Bug fortran/60359] [OOP] symbol `__io_MOD___copy_character_1' is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60359 --- Comment #6 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Fri, Feb 28, 2014 at 05:36:54PM +, janus at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60359 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to janus from comment #4) This is due to a small bug in find_intrinsic_vtab. Patch: The patch from comment #4 regtests cleanly. I've tested the patch against the original code. Looks good. You can commit the patch.
[Bug preprocessor/60368] New: ICE on not unibyte character in execution character set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60368
Bug ID: 60368
Summary: ICE on not unibyte character in execution character
set
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: rmansfield at qnx dot com
$ cat ~/ice.c
#include stdio.h
int main(int argc, char *argv[])
{
printf(hello world\n);
}
$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c++,lto
Thread model: posix
gcc version 4.9.0 20140228 (experimental) [trunk revision 208224] (GCC)
$ ./xgcc -B. -fexec-charset=UTF-16 ~/ice.c
/home/ryan/ice.c: In function ‘main’:
/home/ryan/ice.c:9:0: internal compiler error: character 0xa is not unibyte in
execution character set
^
0x5d0b64 c_cpp_error(cpp_reader*, int, int, unsigned int, unsigned int, char
const*, __va_list_tag (*) [1])
../../gcc/c-family/c-common.c:9713
0xf16cea cpp_diagnostic
../../libcpp/errors.c:63
0xf16e36 cpp_error(cpp_reader*, int, char const*, ...)
../../libcpp/errors.c:78
0xf0e15a cpp_host_to_exec_charset(cpp_reader*, unsigned int)
../../libcpp/charset.c:804
0x5d0c63 c_common_to_target_charset(long)
../../gcc/c-family/c-common.c:9731
0x618a8e init_target_chars
../../gcc/builtins.c:13529
0x63367c init_target_chars
../../gcc/builtins.c:13527
0x63367c fold_builtin_printf
../../gcc/builtins.c:13315
0x637a79 fold_builtin_1
../../gcc/builtins.c:10705
0x62d9a3 fold_builtin_n
../../gcc/builtins.c:11102
0x63b895 fold_call_expr(unsigned int, tree_node*, bool)
../../gcc/builtins.c:11233
0x7f8009 gimplify_call_expr
../../gcc/gimplify.c:2286
0x7ed947 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7419
0x7f2296 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5341
0x7f2f9f gimplify_bind_expr
../../gcc/gimplify.c:1079
0x7ede8e gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7645
0x7f2296 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5341
0x7f3b09 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:8555
0x7f40e6 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:8708
0x6827b7 analyze_function
../../gcc/cgraphunit.c:649
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #19 from Jason Merrill jason at gcc dot gnu.org --- I think it would make sense to suppress speculative devirtualization of a DECL_ARTIFICIAL destructor, since that seems to be the problem here (and in 53808). I think it's better to address this in devirtualization rather than inlining so that an explicitly non-virtual call (e.g. from a destructor to a base destructor) can still be inlined. This doesn't address user-declared inline destructors, including those declared as =default in the class body, but I'm comfortable saying that people who do that should expect it to be inlined, whereas people who don't mention a destructor at all can be forgiven for being surprised that we inline the destructor they weren't thinking about. I think I'm also inclined to allow non-speculative devirtualization, since in cases where we know the type of the object we presumably have access to the vtable in the current shared object. Do you have an opinion about whether this restriction should apply to virtual operator= as well? I think that's much less likely to occur, but it probably makes most sense to handle it the same way. Testing a patch now.
[Bug preprocessor/60368] ICE on not unibyte character in execution character set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60368 --- Comment #1 from Ryan Mansfield rmansfield at qnx dot com --- Maybe a WONTFIX. It's not clear to me why cpp_host_to_exec_charset is using CPP_DL_ICE for this instead of CPP_DL_ERROR
[Bug ada/51483] [4.7/4.8/4.9 regression] cstand.adb:Register_Float_Type makes invalid assumptions about FP representation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51483 --- Comment #17 from Jeffrey A. Law law at redhat dot com --- Eric, there's an updated patch in c#8 which reportedly fixes the problem by passing both the precision and storage size of Register_Float_Type. I'm nowhere near versed enough in Ada to know if Mikael's on the right track with that patch. It's been sitting there for ~2 years now ;( The SPARK issues in c#14 is separate and we should probably create a distinct BZ for that since I believe it completely stands in the way bootstrapping Ada on platforms without a functional Ada compiler. If you could help move along these issues, it'd be appreciated. Thanks, Jeff
[Bug target/60369] New: [PATCH] [TIC6X] new compiler intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60369
Bug ID: 60369
Summary: [PATCH] [TIC6X] new compiler intrinsics
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wojtek.golf at interia dot pl
Host: Linux wmigda-desktop 3.11.0-13-generic #20-Ubuntu SMP
Wed Oct 23 17:26:33 UTC 2013 i686 i686 i686 GNU/Linux
Target: tic6x-none-elf
Build: 4.8.3 20140224 (prerelease)
Texas Instruments TIC6X compiler suite offers a number of compiler intrinsics
(see e.g. SPRU197u document) which are absent in gcc.
This is a patch proposal which is supposed to amend that. The scope is rather
limited as this would be my first contribution to gcc so I would like to treat
this as a pilot to see if I got everything right.
The intrinsics I would like to add with my patch are:
_swap2
_swap4
_dmv
_packlh2
_packhl2
_rotl
1. Legal Prerequisites
I think this proposal is small enough not to require for a separate copyright
disclaimer/assignment.
2. Coding Standards
Applied.
3. Testing Patches
I have prepared few testcases which check whether the instruction descriptions
are correct and whether the expected assembler instruction is generated for
each of the intrinsics.
4. Documentation Changes
TIC6X intrinsics are not listed in gcc documentation, so no update is
necessary.
5. Web Site Changes
As above.
6. Submitting Patches
A description of the problem/bug and how your patch addresses it.
GCC is missing some of the compiler intrinsics available in the Texas
Instruments TIC6X compiler suite. This patch attempts to extend the intrinsics
set offered by gcc.
Testcases
I have created a total of 12 testcases and placed them inside the
gcc/testsuite/gcc.target/tic6x folder.
ChangeLog
2014-02-28 Wojciech Migda wojtek.g...@interia.pl
* gcc/config/c6x/c6x.c: new intrinsics entries in enum c6x_builtins,
c6x_init_builtins, bdesc_2arg, and bdesc_1arg. v2si_ftype_si_si definition.
* gcc/config/c6x/c6x.md: new instruction definitions.
* gcc/config/c6x/c6x_intrinsics.h: new intrinsics functions.
* gcc/testsuite/gcc.target/tic6x/{dmv-O2-scan.c,dmv-O2-volatile-scan.c,
packhl2-O2-scan.c,packhl2-O2-volatile-scan.c,packlh2-O2-scan.c,
packlh2-O2-volatile-scan.c,rotl-O2-scan.c,rotl-O2-volatile-scan.c,
swap2-O2-scan.c,swap2-O2-volatile-scan.c,swap4-O2-scan.c,
swap4-O2-volatile-scan.c}: testcases for new intrinsics.
Bootstrapping and testing
Host: Linux wmigda-desktop 3.11.0-13-generic #20-Ubuntu SMP Wed Oct 23 17:26:33
UTC 2013 i686 i686 i686 GNU/Linux
Target: tic6x-none-elf
Results for the new testcases (run with make check-gcc
RUNTESTFLAGS=CFLAGS_FOR_TARGET='$CFLAGS_FOR_TARGET
--sysroot=${CXTOOLS}${TRIPLET}/sysroot' -v -v tic6x.exp)
PASS: gcc.target/tic6x/dmv-O2-scan.c (test for excess errors)
PASS: gcc.target/tic6x/dmv-O2-scan.c scan-assembler \\(exit\\)
PASS: gcc.target/tic6x/dmv-O2-scan.c scan-assembler-not [\\t ]dmv[\\t ]
PASS: gcc.target/tic6x/dmv-O2-volatile-scan.c (test for excess errors)
PASS: gcc.target/tic6x/dmv-O2-volatile-scan.c scan-assembler dmv
PASS: gcc.target/tic6x/dmv-O2-volatile-scan.c scan-assembler-not \\(_dmv\\)
PASS: gcc.target/tic6x/packhl2-O2-scan.c (test for excess errors)
PASS: gcc.target/tic6x/packhl2-O2-scan.c scan-assembler \\(exit\\)
PASS: gcc.target/tic6x/packhl2-O2-scan.c scan-assembler-not [\\t ]packhl2[\\t ]
PASS: gcc.target/tic6x/packhl2-O2-volatile-scan.c (test for excess errors)
PASS: gcc.target/tic6x/packhl2-O2-volatile-scan.c scan-assembler packhl2
PASS: gcc.target/tic6x/packhl2-O2-volatile-scan.c scan-assembler-not
\\(_packhl2\\)
PASS: gcc.target/tic6x/packlh2-O2-scan.c (test for excess errors)
PASS: gcc.target/tic6x/packlh2-O2-scan.c scan-assembler \\(exit\\)
PASS: gcc.target/tic6x/packlh2-O2-scan.c scan-assembler-not [\\t ]packlh2[\\t ]
PASS: gcc.target/tic6x/packlh2-O2-volatile-scan.c (test for excess errors)
PASS: gcc.target/tic6x/packlh2-O2-volatile-scan.c scan-assembler packlh2
PASS: gcc.target/tic6x/packlh2-O2-volatile-scan.c scan-assembler-not
\\(_packlh2\\)
PASS: gcc.target/tic6x/rotl-O2-scan.c (test for excess errors)
PASS: gcc.target/tic6x/rotl-O2-scan.c scan-assembler \\(exit\\)
PASS: gcc.target/tic6x/rotl-O2-scan.c scan-assembler-not [\\t ]rotl[\\t ]
PASS: gcc.target/tic6x/rotl-O2-volatile-scan.c (test for excess errors)
PASS: gcc.target/tic6x/rotl-O2-volatile-scan.c scan-assembler rotl
PASS: gcc.target/tic6x/rotl-O2-volatile-scan.c scan-assembler-not \\(_rotl\\)
PASS: gcc.target/tic6x/swap2-O2-scan.c (test for excess errors)
PASS: gcc.target/tic6x/swap2-O2-scan.c scan-assembler \\(exit\\)
PASS: gcc.target/tic6x/swap2-O2-scan.c scan-assembler-not packlh2
PASS: gcc.target/tic6x/swap2-O2-scan.c scan-assembler-not _swap2
PASS: gcc.target/tic6x/swap2-O2-volatile-scan.c (test for excess errors)
PASS:
[Bug fortran/60370] New: TRANSPOSE on rhs of allocatable array assignment gives bounds error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60370 Bug ID: 60370 Summary: TRANSPOSE on rhs of allocatable array assignment gives bounds error Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu The following code: program foo real, allocatable :: a(:,:) real, allocatable :: b(:,:) allocate(a(10,5)) a = 0. b = TRANSPOSE(a) end program foo ...produces this error message at runtime, when compiled with -fcheck=all: At line 10 of file foo.f90 Fortran runtime error: Array bound mismatch for dimension 1 of array 'b' (1/5) This is on OS X: Using built-in specs. COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.9.0/lto-wrapper Target: x86_64-apple-darwin11.4.2 Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0' --build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk --with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk --with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran --disable-multilib --disable-nls --disable-libsanitizer Thread model: posix gcc version 4.9.0 20140201 (experimental) (GCC)
[Bug c++/58610] [4.7/4.8/4.9 Regression] [c++11] ICE with constexpr of class with template constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58610 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Fri Feb 28 20:20:21 2014 New Revision: 208226 URL: http://gcc.gnu.org/viewcvs?rev=208226root=gccview=rev Log: /cp 2014-02-28 Paolo Carlini paolo.carl...@oracle.com PR c++/58610 * cp-tree.h (DECL_DELETED_FN): Use LANG_DECL_FN_CHECK. * call.c (print_z_candidate): Remove STRIP_TEMPLATE use. * lambda.c (maybe_add_lambda_conv_op): Likewise. /testsuite 2014-02-28 Paolo Carlini paolo.carl...@oracle.com PR c++/58610 * g++.dg/cpp0x/constexpr-ice11.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ice11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/lambda.c trunk/gcc/testsuite/ChangeLog
[Bug c++/58610] [4.7/4.8/4.9 Regression] [c++11] ICE with constexpr of class with template constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58610 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|4.7.4 |4.9.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug c++/55004] [meta-bug] constexpr issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 58610, which changed state. Bug 58610 Summary: [4.7/4.8/4.9 Regression] [c++11] ICE with constexpr of class with template constructor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58610 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug ipa/60306] [4.9 Regression] Incorrect devirtualization pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60306 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org --- Created attachment 32235 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32235action=edit Better WIP patch Yep, ignoring the calls also surprised me. I spent some time trying to think of and produce more evil testcases to this issue, but rest of Martin's reasoning seems right. The code really just mixes up the case where it knows something on all understood places with the case it knows something on all possible paths through the code. It implements the first but wants the second. I also tried to give up on all calls first. That makes the intraprocedural and part of inter-procedural devirt to give up almost always. Except for trivial cases that are handled by SCCVN you almost always have a call in a way, so testsuite is not really happy about it. Other option is to simply give up on recording anything when type change is seen. This also fixes the bug, perhaps with less fallout. Third option is to record if walk ever reached top of function and if it did give up when type change is seen. This seems to be simple addition to ao walker, we just need some interface for it. Fourth option is to be smarter about the calls defining type that is something I would like to do for next stage1, patch attached. It is ortoghonal to 1/2/3, if we have it we will just understand more paths (and currently I punt if I see some not understood path) I can get some data on difference in between options 1,2,3 for mainline, or do we just want to give up?
[Bug target/57295] target c6x-elf // internal compiler error: in extract_insn, at recog.c:2150
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57295
Wojciech Migda wojtek.golf at interia dot pl changed:
What|Removed |Added
CC||wojtek.golf at interia dot pl
--- Comment #1 from Wojciech Migda wojtek.golf at interia dot pl ---
This is the smallest source code to reproduce this problem:
void foo(foid)
{
*(volatile int *)-1L = 0;
}
[Bug fortran/60359] [OOP] symbol `__io_MOD___copy_character_1' is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60359 --- Comment #7 from janus at gcc dot gnu.org --- Author: janus Date: Fri Feb 28 21:30:04 2014 New Revision: 208227 URL: http://gcc.gnu.org/viewcvs?rev=208227root=gccview=rev Log: 2014-02-28 Janus Weil ja...@gcc.gnu.org PR fortran/60359 * class.c (find_intrinsic_vtab): Prevent duplicate creation of copy procedure for characters. 2014-02-28 Janus Weil ja...@gcc.gnu.org PR fortran/60359 * gfortran.dg/unlimited_polymorphic_16.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/60359] [OOP] symbol `__io_MOD___copy_character_1' is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60359 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from janus at gcc dot gnu.org --- Fixed with r208227. Closing.
[Bug c++/60371] New: std::vector::emplace_back
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60371
Bug ID: 60371
Summary: std::vector::emplace_back
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
I use gcc 4.8.3 20140220 (prerelease), with libc 2.17 on a x86_64 bit system.
Compiling:
#include vector
#include string.h
#include stdlib.h
struct z {
char* var;
z (const char* str) { var = strdup (str); }
~z () { free (var); }
};
std::vectorz y;
int main () {
y.emplace_back (a);
y.emplace_back (b);
}
with
gcc -O0 -ggdb3 -std=c++11 vector_emplace_back.cpp -o vector_emplace_back
-lstdc++
I get the attached binary file.
Running valgrind revision 13842 on the resulting file with
valgrind --tool=memcheck --track-origins=yes ./vector_emplace_back
results the output
== Memcheck, a memory error detector
== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
== Command: ./vector_emplace_back
==
== Invalid free() / delete / delete[] / realloc()
==at 0x4C2B10C: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==by 0x400B1C: z::~z() (vector_emplace_back.cpp:8)
==by 0x401495: void std::_Destroyz(z*) (stl_construct.h:93)
==by 0x401397: void std::_Destroy_auxfalse::__destroyz*(z*, z*)
(stl_construct.h:103)
==by 0x4012C5: void std::_Destroyz*(z*, z*) (stl_construct.h:126)
==by 0x401103: void std::_Destroyz*, z(z*, z*, std::allocatorz)
(stl_construct.h:151)
==by 0x4015DC: std::vectorz, std::allocatorz ::~vector()
(stl_vector.h:415)
==by 0x53871E0: __run_exit_handlers (in /lib64/libc-2.17.so)
==by 0x5387264: exit (in /lib64/libc-2.17.so)
==by 0x5370A2B: (below main) (in /lib64/libc-2.17.so)
== Address 0x59fc090 is 0 bytes inside a block of size 2 free'd
==at 0x4C2B10C: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==by 0x400B1C: z::~z() (vector_emplace_back.cpp:8)
==by 0x401495: void std::_Destroyz(z*) (stl_construct.h:93)
==by 0x401397: void std::_Destroy_auxfalse::__destroyz*(z*, z*)
(stl_construct.h:103)
==by 0x4012C5: void std::_Destroyz*(z*, z*) (stl_construct.h:126)
==by 0x401103: void std::_Destroyz*, z(z*, z*, std::allocatorz)
(stl_construct.h:151)
==by 0x400D70: void std::vectorz, std::allocatorz
::_M_emplace_back_auxchar const () [2](char const () [2]) (vector.tcc:428)
==by 0x400BC6: void std::vectorz, std::allocatorz ::emplace_backchar
const () [2](char const () [2]) (vector.tcc:101)
==by 0x400A6E: main (vector_emplace_back.cpp:15)
==
==
== HEAP SUMMARY:
== in use at exit: 0 bytes in 0 blocks
== total heap usage: 4 allocs, 5 frees, 28 bytes allocated
==
== All heap blocks were freed -- no leaks are possible
==
== For counts of detected and suppressed errors, rerun with: -v
== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1)
There shall not be double free().
Inserting y.clear(); between the two y.emplace_back() does not lead to any
warnings from valgrind for the whole resulting programme.
std::list does not have this problem, as expected.
[Bug ada/51483] [4.7/4.8/4.9 regression] cstand.adb:Register_Float_Type makes invalid assumptions about FP representation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51483 --- Comment #18 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Eric, there's an updated patch in c#8 which reportedly fixes the problem by passing both the precision and storage size of Register_Float_Type. Right, this is the way to go. I'm nowhere near versed enough in Ada to know if Mikael's on the right track with that patch. It's been sitting there for ~2 years now ;( The SPARK issues in c#14 is separate and we should probably create a distinct BZ for that since I believe it completely stands in the way bootstrapping Ada on platforms without a functional Ada compiler. If you could help move along these issues, it'd be appreciated. Geert, could you have a look at the patch?
[Bug c++/60371] std::vector::emplace_back
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60371 Дилян Палаузов dilyan.palauzov at aegee dot org changed: What|Removed |Added CC||dilyan.palauzov at aegee dot org --- Comment #1 from Дилян Палаузов dilyan.palauzov at aegee dot org --- Created attachment 32236 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32236action=edit Resulting binary on my system
[Bug c++/32039] Using declaration accepts non-visible members from base classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32039 --- Comment #2 from fabien at gcc dot gnu.org --- (In reply to Andrew Stubbs from comment #0) The problem should be that B::foo hides A::foo from class C. Clause 7.3.3/14 of the C++ standard says the using declaration should not work, in this case - class A is not a direct base class of class C. However, GCC 4.1.1 accepts it with no diagnostic. 7.3.3/14 says ...The base class members mentioned by a using-declaration shall be visible in the scope of at least one of the direct base classes of the class where the using-declaration is specified... In the example above, A (from using A::foo) is visible from its direct base class B. Consequently, it is valid. Adding 'using A::foo' within B does not change anything to that. without 'using A::foo': 'int B::foo(long)' hides int A::foo(int) in B and 'using A::foo' brings 'int A::foo(int)' into C and hides 'int B::foo(long)'. with 'using A::foo': two overloads of 'foo' are present in B: 'int B::foo(long)' and 'int A::foo(int)' (brought into B scope by the using-declaration). and 'using A::foo' brings 'int A::foo(int)' into C and hides 'int B::foo(long)' (and 'using A::foo)
[Bug c++/32039] Using declaration accepts non-visible members from base classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32039 --- Comment #3 from fabien at gcc dot gnu.org --- (In reply to Eelis from comment #1) Still accepted by 4.4. Comeau concurs with reporter, and rejects saying: line 15: error: class member designated by a using-declaration must be visible in a direct base class Which seems wrong according to the standard quoted above. From Clang results and the analysis done in bug 19377, I am inclined to close this bug as invalid.
[Bug c++/32039] Using declaration accepts non-visible members from base classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32039 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #4 from fabien at gcc dot gnu.org --- Closed as invalid.
[Bug libgcc/60166] ARM default NAN encoding violates EABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60166 --- Comment #3 from jye2 at gcc dot gnu.org --- Author: jye2 Date: Fri Feb 28 21:53:40 2014 New Revision: 208229 URL: http://gcc.gnu.org/viewcvs?rev=208229root=gccview=rev Log: 2014-02-28 Joey Ye joey...@arm.com PR libgcc/60166 * config/arm/sfp-machine.h (_FP_NANFRAC_H, _FP_NANFRAC_S, _FP_NANFRAC_D, _FP_NANFRAC_Q): Set to zero. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/arm/sfp-machine.h
[Bug c++/60372] New: incorrect destruction order for function parameter objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60372
Bug ID: 60372
Summary: incorrect destruction order for function parameter
objects
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Parameter objects are not destroyed when the called function returns, but later
(too late). The C++ standard says in 5.2.2p4 [expr.call]:
... The lifetime of a parameter ends when the function in which it is defined
returns. ...
However, the following program shows that S is destroyed too late, after the
call to h():
#include stdio.h
struct S {
S(int) { printf(S(int)\n); }
~S() { printf(~S\n); }
};
void f(S) { printf(f(S)\n); }
void h() { printf(h()\n); }
int main()
{
f({0}), h();
}
g++ -Wall -Wextra -std=c++11 -pedantic func-destroy.cc
./a.out
S(int)
f(S)
h()
~S
S should be destroyed before the call to h(). Note that no temporary is
involved (which would correctly be destroyed at the end of the
full-expression); the copy-list-initialization initializes the parameter
object.
[Bug c++/60371] std::vector::emplace_back
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60371 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- This sounds like there is a copy constructor happening and you don't have a copy constructor defined so it is a direct assignment which means you will get a double free.
[Bug libgcc/60166] ARM default NAN encoding violates EABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60166 --- Comment #4 from jye2 at gcc dot gnu.org --- Author: jye2 Date: Fri Feb 28 22:00:52 2014 New Revision: 208230 URL: http://gcc.gnu.org/viewcvs?rev=208230root=gccview=rev Log: 2014-02-28 Joey Ye joey...@arm.com Backport from mainline r208229 2014-02-28 Joey Ye joey...@arm.com PR libgcc/60166 * config/arm/sfp-machine.h (_FP_NANFRAC_H, _FP_NANFRAC_S, _FP_NANFRAC_D, _FP_NANFRAC_Q): Set to zero. Modified: branches/gcc-4_8-branch/libgcc/ChangeLog branches/gcc-4_8-branch/libgcc/config/arm/sfp-machine.h
[Bug libgcc/60166] ARM default NAN encoding violates EABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60166 Joey Ye joey.ye at arm dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Joey Ye joey.ye at arm dot com --- Fixed in trunk 208229
[Bug libgcc/60166] ARM default NAN encoding violates EABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60166 --- Comment #6 from jye2 at gcc dot gnu.org --- Author: jye2 Date: Fri Feb 28 22:05:13 2014 New Revision: 208233 URL: http://gcc.gnu.org/viewcvs?rev=208233root=gccview=rev Log: 2014-02-28 Joey Ye joey...@arm.com Backport from mainline r208229 2014-02-28 Joey Ye joey...@arm.com PR libgcc/60166 * config/arm/sfp-machine.h (_FP_NANFRAC_H, _FP_NANFRAC_S, _FP_NANFRAC_D, _FP_NANFRAC_Q): Set to zero. Modified: branches/gcc-4_7-branch/libgcc/ChangeLog branches/gcc-4_7-branch/libgcc/config/arm/sfp-machine.h
[Bug c++/60371] std::vector::emplace_back
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60371
--- Comment #3 from Дилян Палаузов dilyan.palauzov at aegee dot org ---
Indeed, adding
z (const z x) { var = strdup (x.var); }
solves the problem. However, I don't understand how that y.clear(); between
the y.emplace_back() in the original program avoids the double free.
[Bug c++/60371] std::vector::emplace_back
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60371 Дилян Палаузов dilyan.palauzov at aegee dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Дилян Палаузов dilyan.palauzov at aegee dot org --- I have to put here some comment, despite the comment I posted on the bug report some minutes ago. Otherwise the system does not permit me to change the status from UNCONFIRMED to RESOLVED/INVALID.
[Bug c++/60373] New: half warning: visibility attribute ignored because it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60373 Bug ID: 60373 Summary: half warning: visibility attribute ignored because it Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org #include new __attribute__((visibility(hidden)))void*operator new(std::size_t); g++ -std=c++11 v.cc -c v.cc:2:43: warning: 'void* operator new(std::size_t)': visibility attribute ignored because it [-Wattributes] __attribute__((visibility(hidden)))void*operator new(std::size_t); ^ You need -Wsystem-headers to kill the suspense. I think we should get the second half of the sentence in all cases...
[Bug c++/60190] [c++1y] ICE with invalid return type of template lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60190 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #5 from Volker Reichelt reichelt at gcc dot gnu.org --- Fixed by Adam's patch.
[Bug c++/60374] New: [4.7/4.8/4.9 Regression] ICE with invalid template specialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60374
Bug ID: 60374
Summary: [4.7/4.8/4.9 Regression] ICE with invalid template
specialization
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid testcase (compiled with -std=c++11) triggers
an ICE since GCC 4.7.0:
===
templatetypename struct A {};
templatetypename...T struct AT::T... {};
Aint a;
===
bug.cc:3:31: error: template argument 'T:: T' involves template parameter(s)
templatetypename...T struct AT::T... {};
^
bug.cc:5:8: internal compiler error: in unify_one_argument, at cp/pt.c:16311
Aint a;
^
0x63a5ec unify_one_argument
../../gcc/gcc/cp/pt.c:16310
0x63b430 unify_pack_expansion
../../gcc/gcc/cp/pt.c:17129
0x6389de unify
../../gcc/gcc/cp/pt.c:17884
0x63e6ff get_class_bindings
../../gcc/gcc/cp/pt.c:18610
0x63f37e most_specialized_class
../../gcc/gcc/cp/pt.c:18852
0x64ecf9 instantiate_class_template_1
../../gcc/gcc/cp/pt.c:8867
0x64ecf9 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:9399
0x6e1d83 complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:134
0x5c8e58 start_decl_1(tree_node*, bool)
../../gcc/gcc/cp/decl.c:4719
0x5f1ef7 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:4682
0x6ce2be cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16684
0x6cfd49 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11205
0x6b3003 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11086
0x6da2d2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10983
0x6d8fc8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6da87a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6da87a c_parse_file()
../../gcc/gcc/cp/parser.c:31590
0x7f9fe3 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
[Bug c++/60374] [4.7/4.8/4.9 Regression] ICE with invalid template specialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60374 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Known to work||4.5.0, 4.6.0 Target Milestone|--- |4.7.4 Known to fail||4.7.0, 4.8.0, 4.9.0
[Bug c++/32039] Using declaration accepts non-visible members from base classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32039 Harald van Dijk harald at gigawatt dot nl changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #5 from Harald van Dijk harald at gigawatt dot nl --- This bug is about visibility, bug 19337 is about accessibility. I incorrectly used visibility in my comment on the other bug, I apologise if that has confused matters. The comments there do not apply here. Normally, a qualified name such as A::foo can be used to refer to a hidden member. In this instance, however, the standard makes a special exception, and states that A::foo must be visible in B as well, even though a qualified name is used, for the using declaration to be valid. In B, int A::foo(int) is hidden by int B::foo(long) because B's member function has the same name. (3.3.10p1) A name is said to be visible, if it is in scope, and not hidden. (3.3.10p5) So I think this bug report is valid and unrelated to 19337: A's member function is indeed not visible in any of the direct bases of C. Your comment (the In the example above, A (from using A::foo) is visible bit) suggests that you read the standard as requiring that the base class be visible, rather than the base class member.
[Bug c++/60375] New: [4.9 Regression] ICE with invalid use of lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60375
Bug ID: 60375
Summary: [4.9 Regression] ICE with invalid use of lambda
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid testcase (compiled with -std=c++11) triggers
an ICE on trunk:
===
struct A
{
decltype( [](){ return this; }() ) x;
};
===
bug.cc:3:13: error: lambda-expression in unevaluated context
decltype( [](){ return this; }() ) x;
^
bug.cc: In lambda function:
bug.cc:3:26: internal compiler error: Segmentation fault
decltype( [](){ return this; }() ) x;
^
0xbaa60f crash_signal
../../gcc/gcc/toplev.c:337
0x7587ed contains_struct_check
../../gcc/gcc/tree.h:2822
0x7587ed rvalue(tree_node*)
../../gcc/gcc/cp/tree.c:698
0x6b5fd2 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:4353
0x6b84cd cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:5971
0x6bb493 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7170
0x6bc17f cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7874
0x6bc661 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8112
0x6bea73 cp_parser_expression
../../gcc/gcc/cp/parser.c:8274
0x6b7bf2 cp_parser_expression
../../gcc/gcc/cp/parser.c:8313
0x6b7bf2 cp_parser_lambda_body
../../gcc/gcc/cp/parser.c:9228
0x6b7bf2 cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:8757
0x6b7bf2 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:4305
0x6b84cd cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:5971
0x6b9a3e cp_parser_decltype_expr
../../gcc/gcc/cp/parser.c:11904
0x6b9a3e cp_parser_decltype
../../gcc/gcc/cp/parser.c:12003
0x6ba117 cp_parser_qualifying_entity
../../gcc/gcc/cp/parser.c:5494
0x6ba117 cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.c:5249
0x6baadb cp_parser_nested_name_specifier
../../gcc/gcc/cp/parser.c:5448
0x6b2cd3 cp_parser_using_declaration
../../gcc/gcc/cp/parser.c:15938
Please submit a full bug report, [etc.]
[Bug c++/60375] [4.9 Regression] ICE with invalid use of lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60375 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Known to work||4.5.0, 4.6.0, 4.7.0, 4.8.0 Target Milestone|--- |4.9.0 Known to fail||4.9.0
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #20 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Sat Mar 1 00:17:09 2014 New Revision: 208241 URL: http://gcc.gnu.org/viewcvs?rev=208241root=gccview=rev Log: PR c++/58678 * ipa-devirt.c (ipa_devirt): Don't choose an implicitly-declared function. Added: trunk/gcc/testsuite/g++.dg/ipa/devirt-28.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c
[Bug c++/60376] New: [4.9 Regression] ICE with invalid use of using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60376
Bug ID: 60376
Summary: [4.9 Regression] ICE with invalid use of using
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid testcase (compiled with -std=c++1y) triggers
an ICE on trunk:
struct A
{
int foo();
};
templatetypename void bar()
{
using (A().foo);
}
bug.cc: In function 'void bar()':
bug.cc:8:9: error: expected nested-name-specifier before '(' token
using (A().foo);
^
bug.cc:8:9: error: expected unqualified-id before '(' token
bug.cc:8:9: error: expected ';' before '(' token
bug.cc:8:18: internal compiler error: in type_dependent_expression_p, at
cp/pt.c:20901
using (A().foo);
^
0x6049a1 type_dependent_expression_p(tree_node*)
../../gcc/gcc/cp/pt.c:20900
0x72d994 finish_expr_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:686
0x6b4788 cp_parser_statement
../../gcc/gcc/cp/parser.c:9473
0x6b5559 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9745
0x6b56c6 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9699
0x6c667b cp_parser_function_body
../../gcc/gcc/cp/parser.c:18694
0x6c667b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18730
0x6cdc12 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22843
0x6ceab1 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22755
0x6ceab1 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16589
0x6cee4a cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:23164
0x6cf134 cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:22966
0x6da4d9 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10947
0x6d8fc8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6da87a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6da87a c_parse_file()
../../gcc/gcc/cp/parser.c:31590
0x7f9fe3 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
[Bug c++/60376] [4.9 Regression] ICE with invalid use of using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60376 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 Target Milestone|--- |4.9.0 Known to fail||4.9.0
[Bug c++/60305] [4.7 Regression] ICE constexpr array of functions in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60305
Volker Reichelt reichelt at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||4.6.0, 4.8.3, 4.9.0
Keywords||ice-on-valid-code
Last reconfirmed||2014-03-01
CC||reichelt at gcc dot gnu.org
Ever confirmed|0 |1
Summary|ICE constexpr array of |[4.7 Regression] ICE
|functions in template |constexpr array of
||functions in template
Target Milestone|--- |4.7.4
Known to fail||4.7.0, 4.8.0, 4.8.1, 4.8.2
--- Comment #2 from Volker Reichelt reichelt at gcc dot gnu.org ---
Confirmed. Happens since GCC 4.7.0, but is already fixed on the trunk (for GCC
4.9.0) and on the 4.8 branch (for GCC 4.8.3). Valid testcase:
===
templateint I int foo() { return I; }
templateint... I void bar()
{
constexpr int (*X[])() = { fooI... };
}
template void bar1,3,5();
===
[Bug c++/60377] New: [c++1y] ICE with invalid function parameter in conjunction with auto parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60377
Bug ID: 60377
Summary: [c++1y] ICE with invalid function parameter in
conjunction with auto parameter
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: diagnostic, error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid testcase (compiled with -std=c++1y) triggers
an ICE on trunk:
void foo(auto, void (f*)());
struct A
{
int i;
};
bug.cc:1:23: error: expected ')' before '*' token
void foo(auto, void (f*)());
^
bug.cc:1:23: error: expected ')' before '*' token
bug.cc:1:23: error: expected initializer before '*' token
bug.cc:5:7: error: data member 'i' cannot be a member template
int i;
^
bug.cc:5:7: internal compiler error: in poplevel, at cp/decl.c:568
0x5c54a3 poplevel(int, int, int)
../../gcc/gcc/cp/decl.c:568
0x5feba8 end_template_decl()
../../gcc/gcc/cp/pt.c:3807
0x6a3951 finish_fully_implicit_template
../../gcc/gcc/cp/parser.c:32047
0x6acb0c cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:20482
0x6afa84 cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:20029
0x6afa84 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:19263
0x6afa84 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19490
0x6afa84 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14305
0x6c8fb0 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11547
0x6cfb69 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11137
0x6b3003 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11086
0x6da2d2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10983
0x6d8fc8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6da87a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6da87a c_parse_file()
../../gcc/gcc/cp/parser.c:31590
0x7f9fe3 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
Note that the error message in line 5 is bogus.
Adam, would you mind having a look?
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #21 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug c++/32039] Using declaration accepts non-visible members from base classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32039 fabien at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|INVALID |--- --- Comment #6 from fabien at gcc dot gnu.org --- (In reply to Harald van Dijk from comment #5) [...] Your comment (the In the example above, A (from using A::foo) is visible bit) suggests that you read the standard as requiring that the base class be visible, rather than the base class member. Obviously should read members of A are visible... Anyway thanks for the clarification.
