[Bug fortran/57596] Wrong code for allocatable deferred-length strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57596 --- Comment #5 from Tobias Burnus --- Author: burnus Date: Fri Jun 14 07:41:42 2013 New Revision: 200084 URL: http://gcc.gnu.org/viewcvs?rev=200084&root=gcc&view=rev Log: 2013-06-14 Tobias Burnus PR fortran/57596 * trans-decl.c (gfc_trans_deferred_vars): Honor OPTIONAL for nullify and deferred-strings' length variable. 2013-06-14 Tobias Burnus PR fortran/57596 * gfortran.dg/deferred_type_param_9.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/deferred_type_param_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/57596] Wrong code for allocatable deferred-length strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57596 Tobias Burnus changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Tobias Burnus --- FIXED on the trunk (4.9). Thanks for the report!
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Bug 45170 depends on bug 57596, which changed state. Bug 57596 Summary: Wrong code for allocatable deferred-length strings http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57596 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug target/57608] [4.8/4.9 Regression] wrong code for expression at -O3 on x86_64-linux-gnu with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57608 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-14 CC||jakub at gcc dot gnu.org Summary|wrong code for expression |[4.8/4.9 Regression] wrong |at -O3 on x86_64-linux-gnu |code for expression at -O3 |with -m32 |on x86_64-linux-gnu with ||-m32 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r193553.
[Bug target/57608] [4.8/4.9 Regression] wrong code for expression at -O3 on x86_64-linux-gnu with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57608 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |4.8.2
[Bug target/57608] [4.8/4.9 Regression] wrong code for expression at -O3 on x86_64-linux-gnu with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57608 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED CC||hubicka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #2 from Jan Hubicka --- mine :(
[Bug tree-optimization/57608] [4.8/4.9 Regression] wrong code for expression at -O3 on x86_64-linux-gnu with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57608 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target||i?86-*-* CC||rguenth at gcc dot gnu.org Component|target |tree-optimization --- Comment #3 from Richard Biener --- I'm sure PRE is only the enabler, not the culprit here, is it?
[Bug c++/57599] result of dynamic_cast is just T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57599 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #6 from Paolo Carlini --- Fixed for 4.9.0.
[Bug c++/57593] Friendship not extended into friend member-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57593 --- Comment #1 from Paolo Carlini --- If a defect report has been submitted, then we should add its number to the Subject of this bug and suspend it immediately. Do you have the number?
[Bug c++/57599] result of dynamic_cast is just T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57599 --- Comment #7 from Andrey Belevantsev --- (In reply to Paolo Carlini from comment #6) > Fixed for 4.9.0. Do you plan to backport this to 4.7 and 4.8?
[Bug bootstrap/57604] LRA related bootstrap comparison failure on s390x --with-arch=zEC12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604 --- Comment #1 from Andreas Krebbel --- This is caused by a miscompilation of cp/lex.c: #define DEF_OPERATOR(NAME, CODE, MANGLING, ARITY, ASSN_P)\ sprintf (buffer, ISALPHA (NAME[0]) ? "operator %s" : "operator%s", NAME); \ identifier = get_identifier (buffer);\ ... The problem is that during LRA an add insn is being generated which is placed between the "ISALPHA" check and the conditional load for the format string. The ADD which is generated clobbers the condition code why DSE later removes the "ISALPHA" check completely. When generating the ADD LRA probably needs to check whether it will break dataflow. On S/390 we can do such address calculations without clobbering CC by using the load address instruction. Unfortunately la cannot be used for generic add patterns when generating 32 bit code since it only deals with the lower 31 bits. Breakpoint 1, make_insn_raw (pattern=0x3fff6195580) at /home/andreas/clean/gcc-head/gcc/emit-rtl.c:3651 3651 insn = rtx_alloc (INSN); (gdb) p debug_rtx(pattern) (parallel [ (set (reg:DI 3022) (plus:DI (reg/f:DI 34 %fp) (const_int 176 [0xb0]))) (clobber (reg:CC 33 %cc)) ]) $1 = void (gdb) bt #0 make_insn_raw (pattern=0x3fff6195580) at /home/andreas/clean/gcc-head/gcc/emit-rtl.c:3651 #1 0x805b4578 in emit_insn (x=0x3fff6195580) at /home/andreas/clean/gcc-head/gcc/emit-rtl.c:4736 #2 0x807d5e74 in lra_emit_add (x=0x3fff7a079c0, y=0x3fff78754c0, z=0x3fff632a630) at /home/andreas/clean/gcc-head/gcc/lra.c:266 #3 0x807d656e in lra_emit_move (x=0x3fff7a079c0, y=0x3fff6199600) at /home/andreas/clean/gcc-head/gcc/lra.c:415 #4 0x807eb7fa in curr_insn_transform() () #5 0x807ed45c in lra_constraints(bool) () #6 0x807dc616 in lra (f=0x816a46f0) at /home/andreas/clean/gcc-head/gcc/lra.c:2278 #7 0x807845a6 in do_reload () at /home/andreas/clean/gcc-head/gcc/ira.c:4641 #8 0x8078485e in rest_of_handle_reload () at /home/andreas/clean/gcc-head/gcc/ira.c:4753 #9 0x8085a4b2 in execute_one_pass (pass=0x81359060 ) at /home/andreas/clean/gcc-head/gcc/passes.c:2337 #10 0x8085a76a in execute_pass_list (pass=0x81359060 ) at /home/andreas/clean/gcc-head/gcc/passes.c:2389 #11 0x8085a7b8 in execute_pass_list (pass=0x813597d0 ) at /home/andreas/clean/gcc-head/gcc/passes.c:2390 #12 0x804ece5e in expand_function (node=0x3fff62f1130) at /home/andreas/clean/gcc-head/gcc/cgraphunit.c:1582 #13 0x804ed418 in expand_all_functions () at /home/andreas/clean/gcc-head/gcc/cgraphunit.c:1686 #14 0x804ee00c in compile () at /home/andreas/clean/gcc-head/gcc/cgraphunit.c:2020 #15 0x804ee1f0 in finalize_compilation_unit () at /home/andreas/clean/gcc-head/gcc/cgraphunit.c:2097 #16 0x802667fc in cp_write_global_declarations () at /home/andreas/clean/gcc-head/gcc/cp/decl2.c:4356 #17 0x80966c06 in compile_file () at /home/andreas/clean/gcc-head/gcc/toplev.c:558 #18 0x809697e8 in do_compile () at /home/andreas/clean/gcc-head/gcc/toplev.c:1872 #19 0x809699c4 in toplev_main (argc=32, argv=0x3fff138) at /home/andreas/clean/gcc-head/gcc/toplev.c:1948 #20 0x004f6a8ec30c in __libc_start_main () from /lib64/libc.so.6 #21 0x801335aa in _start () (gdb)
[Bug tree-optimization/57358] segmentation fault with attribute(optimize(O0))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57358 Martin Jambor changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-06/msg00666.htm ||l --- Comment #4 from Martin Jambor --- I have submitted a fix for the 4.8 branch here: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00663.html and for the current trunk here: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00666.html
[Bug tree-optimization/57539] [4.9 Regression] ice in ipa_edge_duplication_hook
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57539 Martin Jambor changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-06/msg00661.htm ||l --- Comment #4 from Martin Jambor --- I have submitted the fix to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00661.html
[Bug c++/57599] result of dynamic_cast is just T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57599 --- Comment #8 from Paolo Carlini --- No, because isn't a regression. If you care a lot about that, just ask on the mailing list.
[Bug c++/48453] [C++0x] Invalid reference initialization via explicit conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48453 --- Comment #4 from Paolo Carlini --- It would be nice to have a DR # for this. In any case, if in practice the compiler is already Ok, we can probably close it, right?
[Bug c++/48632] Internal compiler error when using OpenMP with template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48632 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Paolo Carlini --- I suppose we can close this.
[Bug fortran/57508] [4.8/4.9 Regression] [OOP] Intrinsic assignment+defined-assignment for comps: PROCEDURE attribute of '_F.DA0' conflicts with VARIABLE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57508 --- Comment #6 from Tobias Burnus --- Author: burnus Date: Fri Jun 14 11:24:27 2013 New Revision: 200089 URL: http://gcc.gnu.org/viewcvs?rev=200089&root=gcc&view=rev Log: 2013-06-14 Tobias Burnus PR fortran/57508 * resolve.c (get_temp_from_expr): Don't copy function result attributes to temporary. 2013-06-14 Tobias Burnus PR fortran/57508 * gfortran.dg/defined_assignment_7.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/defined_assignment_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/57508] [4.8/4.9 Regression] [OOP] Intrinsic assignment+defined-assignment for comps: PROCEDURE attribute of '_F.DA0' conflicts with VARIABLE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57508 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Tobias Burnus --- FIXED - now also on the trunk; GCC 4.8 was fixed in comment 4. At the end, the same patch was applied to the trunk as on the branch, cf. http://gcc.gnu.org/ml/fortran/2013-06/msg00086.html
[Bug fortran/49074] [OOP] Defined assignment w/ CLASS arrays: Incomplete error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49074 Mikael Morin changed: What|Removed |Added Status|REOPENED|RESOLVED Version|4.7.0 |4.9.0 Resolution|--- |FIXED --- Comment #13 from Mikael Morin --- FIXED again.
[Bug bootstrap/57609] New: S/390 ESA mode bootstrap failure since r197266
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57609 Bug ID: 57609 Summary: S/390 ESA mode bootstrap failure since r197266 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: krebbel at gcc dot gnu.org cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mlong-double-128 -mesa -m31 -march=g5 -auxbase-strip _negdi2.o -g -g -g -O2 -O2 -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fbuilding-libgcc -fno-stack-protector -fPIC -fvisibility=hidden -o libgcc2.s Program received signal SIGSEGV, Segmentation fault. 0x70685820 in ?? () (gdb) bt #0 0x70685820 in ?? () #1 0x006cc074 in fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #2 0x00714c20 in fold(tree_node*) () #3 0x00537e0c in c_fully_fold_internal(tree_node*, bool, bool*, bool*) () #4 0x00538998 in c_fully_fold(tree_node*, bool, bool*) () #5 0x004e81ba in build_function_call_vec(unsigned int, tree_node*, vec*, vec*) () #6 0x004fd24e in c_parser_postfix_expression_after_primary(c_parser*, unsigned int, c_expr) () #7 0x004f57e8 in c_parser_postfix_expression(c_parser*) () #8 0x004f6b4c in c_parser_unary_expression(c_parser*) () #9 0x004fb0ac in c_parser_cast_expression(c_parser*, c_expr*) () #10 0x004fb2a6 in c_parser_binary_expression(c_parser*, c_expr*, c_parser_prec) () #11 0x004fba44 in c_parser_conditional_expression(c_parser*, c_expr*) () #12 0x004fc00c in c_parser_expr_no_commas(c_parser*, c_expr*) () #13 0x004fc49c in c_parser_expression(c_parser*) () #14 0x004f588a in c_parser_postfix_expression(c_parser*) () #15 0x004f6b4c in c_parser_unary_expression(c_parser*) () #16 0x004fb0ac in c_parser_cast_expression(c_parser*, c_expr*) () #17 0x004fb2a6 in c_parser_binary_expression(c_parser*, c_expr*, c_parser_prec) () #18 0x004fba44 in c_parser_conditional_expression(c_parser*, c_expr*) () #19 0x004fc00c in c_parser_expr_no_commas(c_parser*, c_expr*) () #20 0x004fc49c in c_parser_expression(c_parser*) () #21 0x004fc924 in c_parser_expression_conv(c_parser*) () #22 0x00505784 in c_parser_statement_after_labels(c_parser*) () #23 0x00502528 in c_parser_compound_statement_nostart(c_parser*) () #24 0x00502ce0 in c_parser_compound_statement(c_parser*) () #25 0x00503936 in c_parser_declaration_or_fndef(c_parser*, bool, bool, bool, bool, bool, tree_node**) () #26 0x005083fc in c_parser_external_declaration(c_parser*) () #27 0x00508d02 in c_parse_file() () #28 0x0054e950 in c_common_parse_file() () #29 0x008e2650 in compile_file() () #30 0x008e485a in toplev_main(int, char**) () #31 0x7dd008e6 in __libc_start_main (main=0x4aca88 , argc=33, ubp_av=0x7fffef44, init=, fini=0xd11ecc <__libc_csu_fini>, rtld_fini=0x7dfef84c <_dl_fini>, stack_end=0x7fffeed8) at libc-start.c:226 #32 0x004acbd6 in _start ()
[Bug c++/48453] [C++0x] [DR 1287] Invalid reference initialization via explicit conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48453 Jason Merrill changed: What|Removed |Added Summary|[C++0x] Invalid reference |[C++0x] [DR 1287] Invalid |initialization via explicit |reference initialization |conversion |via explicit conversion --- Comment #5 from Jason Merrill --- Added DR 1287 reference. I'm inclined to leave the bug suspended until that issue is resolved.
[Bug c++/57593] Friendship not extended into friend member-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57593
--- Comment #2 from David Krauss ---
The maintainer (Mike Miller at EDG) said simply that he will add it to the
list, but as far as I know a number isn't assigned until the new list is
drafted. The title is "access granted by friendship to class-scope friend
declaration." (But I suppose he could take a liberty and remove the redundant
"class-scope".)
Regardless of any possible defect, GCC is inconsistent. The change in access
applies to certain declarations, not others, but GCC is applying it to parts of
certain declarations (seemingly only the function body is excluded). To be
consistent with the current standard, the only choices are to allow all 3
examples or disallow all 3. The latter choice would be a nasty breaking change.
If it helps, here is the text of DR submission.
Friendship is not transitive, but it does grant access to "member declarations
of the befriended class." ([class.friend]/2) And a friend is declared by a
member-declaration. Is a grammatical member-declaration with the friend
specifier still a member declaration?
class c {
class n {};
friend struct s;
};
struct s {
friend class c::n; // 1
friend c::n g(); // 2
friend void f() { c::n(); } // 3
};
If a friend member-declaration is not a member declaration, then it is
impossible to grant access to a private nested class (1) or a function composed
from a type specified using a private nested class (2). Both GCC and Clang
allow these examples.
If a friend member-declaration is a member declaration, then it implements one
degree of transitive friendship, if it is also a definition (3). Clang accepts
this example, but GCC rejects it.
Friends are enough like members that the access should apply. One common
application is operator<< . A manipulator proxy class may need access from its
insertion operator to its client's restricted members. Another application is
to define a function that would otherwise be a nonstatic member but receives a
container or smart pointer, not a direct reference to the object. These are the
most common cases for the inline friend definition syntax. They are found by
ADL so the namespace-scope declaration may be omitted.
Working around by befriending the pseudo-member friend may be troublesome as it
may violate separation of concerns, form undesired associated classes for ADL,
or require forming a declaration which may use inconvenient nested types or
reduplicated SFINAE.
Although access control isn't really a security mechanism, no "exploit" would
be opened by granting access because a friend can always delegate to a static
member anyway.
Proposed resolution:
Modify [class.friend]:
… can be accessed in the base-specifiers, member-declarations, and definitions
of members of the befriended class.
Is there any context within a class-specifier where access control is performed
besides its base-specifiers and member-declarations? It doesn't seem to apply
to name lookup in the template-name of a partial or explicit specialization,
but I can't find the spec. Perhaps it should be:
… can be accessed in the class-specifier and definitions of members of the
befriended class.
[Bug c++/57593] Friendship not extended into friend member-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57593 --- Comment #3 from Paolo Carlini --- Ok. Please, when you have a number, send it here. In any case, I suppose we'd rather prefer to have a resolution in order to act, otherwise we are not sure in which way we want to resolve any inconsistency.
[Bug c++/48453] [C++0x] [DR 1287] Invalid reference initialization via explicit conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48453 --- Comment #6 from Paolo Carlini --- Ok, thanks.
[Bug c++/48453] [C++0x] [DR 1287] Invalid reference initialization via explicit conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48453 --- Comment #7 from Paolo Carlini --- Oh, by the way, the status is .
[Bug c++/57610] New: Result of conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 Bug ID: 57610 Summary: Result of conversion Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: o_kniemeyer at maxon dot net
[Bug c++/57610] Result of conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Paolo Carlini --- .
[Bug c++/57610] Result of conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 --- Comment #2 from Ole Kniemeyer --- Created attachment 30301 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30301&action=edit cpp file (without any #includes) which shows the bug
[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 Ole Kniemeyer changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from Ole Kniemeyer --- In the example X can be converted to B which is a derived class of A. When an A reference is initialized with an X object, the result of the X::operator B() should be used directly for the A reference, but GCC creates a temporary A object and initializes this by copy-construction from the conversion result. At least if the classes use virtual functions, this leads to wrong results.
[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 --- Comment #4 from Ole Kniemeyer --- As I commented in the cpp example, the C++11 standard shows exactly this example in sections 8.5.3. So this is definitely a bug according to C++11. I think the GCC behaviour is correct according to older C++11 standards.
[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 --- Comment #5 from Ole Kniemeyer --- Ops, sorry, of course I meant "... to older C++ standards."
[Bug fortran/56136] [OOP] ICE on lhs-reallocation of an object with overloaded (elemental) assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56136 Dominique d'Humieres changed: What|Removed |Added CC||mikael.morin at sfr dot fr --- Comment #2 from Dominique d'Humieres --- This PR seems to have been fixed between revisions 200062 and 200078 (r200069?).
[Bug fortran/57611] New: [Fortran-Dev Regression] Too much memory allocated (gfortran.dg/coarray_lib_alloc_2.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57611 Bug ID: 57611 Summary: [Fortran-Dev Regression] Too much memory allocated (gfortran.dg/coarray_lib_alloc_2.f90) Product: gcc Version: fortran-dev Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Blocks: 56818 The following should be: yy._data.base_addr = (void * restrict) __builtin_malloc (1); however, it is yy._data.base_addr = (void * restrict) __builtin_malloc (128); type t end type t class(t), allocatable :: yy(:) allocate(yy(2)) end Similarly for coarrays, cf. gfortran.dg/coarray_lib_alloc_2.f90: class(t), allocatable :: xx[:], yy(:)[:] allocate(yy(2)[*], stat=stat, errmsg=errmsg) which gives xx._data.base_addr = _gfortran_caf_register (72, 1, &xx._data.token, &stat.0, &errmsg, 200); yy._data.base_addr = _gfortran_caf_register (192, 1, &yy._data.token, &stat.2, &errmsg, 200); The first arguments should be "1" instead of 72/192. As the email at http://gcc.gnu.org/ml/fortran/2013-06/msg00071.html indicates, there seems to be some pointer involved as the size varies between 32 and 64 bit systems.
[Bug c/57612] New: add builtin to assert that expression does not have side effects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57612 Bug ID: 57612 Summary: add builtin to assert that expression does not have side effects Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org It would sometimes be useful to be able to assert that an expression does not have side effects. For example, this would be very nice to have for macros which expand their arguments more than once: #define multi_expand(x) __builtin_assert_no_side_effects(x) + (x) Specifically, this builtin would check its argument and give an error if the argument had an assignment or a call to a function which is neither "const" nor "pure". The builtin would evaluate to the value of its argument.
[Bug lto/57613] New: [LTO] error "multiple definition symbol" for local symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57613
Bug ID: 57613
Summary: [LTO] error "multiple definition symbol" for local
symbol
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
$ cat foo.i
void foo()
{
}
$ gcc -fpreprocessed -flto -c foo.i
$ ld -m elf_x86_64 -r -o hidden.o --whole-archive foo.o --no-whole-archive
$ objcopy -G bar hidden.o
$ cp hidden.o hidden2.o
$ gcc -flto hidden.o hidden2.o
hidden2.o (symbol from plugin): In function `foo':
(.text+0x0): multiple definition of `foo'
hidden.o (symbol from plugin):(.text+0x0): first defined here
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
$ nm hidden.o
t foo
0001 C __gnu_lto_v1
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --with-multilib-list=m64
--enable-checking=yes,df,fold,rtl,tree --enable-languages=c,c++,lto
--enable-plugin --with-tune=native --with-arch=native
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.9.0 20130614 (experimental) [trunk revision 200088] (GCC)
gcc-4.8.1 from Fedora 19 FAIL too
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.1/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.1-20130603/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.1-20130603/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.1 20130603 (Red Hat 4.8.1-1) (GCC)
[Bug c++/57614] New: Friend declaration and qualified class member access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57614
Bug ID: 57614
Summary: Friend declaration and qualified class member access
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
In the snippet below, a weird interaction happens between two overloaded friend
declarations and a class member access using a qualified id-expression.
// -- test.cc
class A
{
protected:
int s;
public:
A();
};
class B : public A
{
protected:
public:
B();
// By reversing the order of these two declarations
// you can change the location of the error
friend void foo(B &, int);
friend void foo(B &, B& b);
};
void foo(B& a, int)
{
// This is only fine if this function was the first "friend" declared
a.A::s = 3;
// Always fine
a.s = 3;
}
void foo(B& a, B& b)
{
// This is only fine if this function was the first "friend" declared
a.A::s = 3;
// Always fine
a.s = 3;
}
// -- end of test.cc
g++ is 4.7.3
$ g++ -c test.cc
test.cc: In function ‘void foo(B&, B&)’:
test.cc:4:7: error: ‘int A::s’ is protected
test.cc:32:7: error: within this context
If we reverse the order of the friend declarations we can change the error
location.
$ g++ -c test.cc
test.cc: In function ‘void foo(B&, int)’:
test.cc:4:7: error: ‘int A::s’ is protected
test.cc:24:7: error: within this context
The error seems to happen with the second overloaded friend declaration.
This problem can be worked around if the id-expression of the class member
access is unqualified.
[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #6 from Daniel Krügler --- 1) Your example code is a bit misleading, because irrespective of your concerns the compiler is allowed to create one copy of B (and thus of A) when returning the B value as result of the function call. You cannot rely on that the compiler will not create at one copy and that is not related to this issue. 2) The core language was considering to change exactly this wording you mention, see http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1287 The part related to the example was deferred and my understanding is that http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1650 is now focusing on class prvalues during reference-binding sub-part. My suggestion is to suspend this bug until this core issue CWG 1650 has been resolved.
[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 --- Comment #7 from Ole Kniemeyer --- OK, thanks for your comments. I wasn't aware of the ongoing discussion about this issue (I was referring to the the draft version N3376 of the C++11 standard). A B-copy would be OK, but as I said copying B into A is not a good idea if those classes have virtual functions. The N3376 wording would be much better for such cases. In my case A is an interface (with dummy implementations of the virtual functions), B an implementation of A and X an unrelated class with conversion operator to B. Now if a function has a const A& parameter (so it works with the interface), N3376 allows me to pass an X object to this function by implicitly creating a temporary B object which makes X look like an A. With the variant discussed in the links you posted this wouldn't work (copying B into A makes no sense).
[Bug target/57615] New: power8 support does not deal with -mquad-memory -mno-vsx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57615
Bug ID: 57615
Summary: power8 support does not deal with -mquad-memory
-mno-vsx
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Created attachment 30302
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30302&action=edit
Function to show the problem.
If you compile the Advance Toolchain dl-lookup.c with the following options:
-m64 dl-lookup.c -c -std=gnu99 -fgnu89-inline -O3 -Wall -Winline
-Wwrite-strings -fmerge-all-constants -frounding-math -g -mcpu=power8
-mlong-double-128 -finline-limit=2000 -Wstrict-prototypes -mlong-double-128
-fpic -fexceptions -fasynchronous-unwind-tables -ffixed-32 -ffixed-33
-ffixed-34 -ffixed-35 -ffixed-36 -ffixed-37 -ffixed-38 -ffixed-39 -ffixed-40
-ffixed-41 -ffixed-42 -ffixed-43 -ffixed-44 -ffixed-45 -ffixed-46 -ffixed-47
-ffixed-48 -ffixed-49 -ffixed-50 -ffixed-51 -ffixed-52 -ffixed-53 -ffixed-54
-ffixed-55 -ffixed-56 -ffixed-57 -ffixed-58 -ffixed-59 -ffixed-60 -ffixed-61
-ffixed-62 -ffixed-63 -ffixed-v0 -ffixed-v1 -ffixed-v10 -ffixed-v11 -ffixed-v12
-ffixed-v13 -ffixed-v14 -ffixed-v15 -ffixed-v16 -ffixed-v17 -ffixed-v18
-ffixed-v19 -ffixed-v2 -ffixed-v20 -ffixed-v21 -ffixed-v22 -ffixed-v23
-ffixed-v24 -ffixed-v25 -ffixed-v26 -ffixed-v27 -ffixed-v28 -ffixed-v29
-ffixed-v3 -ffixed-v30 -ffixed-v31 -ffixed-v4 -ffixed-v5 -ffixed-v6 -ffixed-v7
-ffixed-v8 -ffixed-v9 -ffixed-vrsave -ffixed-vscr -mno-altivec -mno-vsx
It fails with the message:
dl-lookup.c: In function ‘_dl_lookup_symbol_x’:
dl-lookup.c:854:1: error: could not split insn
(insn:TI 1693 4115 1696 (set (reg:TI 10 10 [orig:838 val2 ] [838])
(mem/c:TI (reg/f:DI 18 18 [889]) [19 val2+0 S16 A128])) dl-lookup.c:976
454 {*movti_ppc64}
(expr_list:REG_DEAD (reg/f:DI 18 18 [889])
(expr_list:REG_EQUIV (mem/c:TI (reg/f:DI 22 22 [874]) [19 val+0 S16
A128])
(nil
dl-lookup.c:854:1: internal compiler error: in final_scan_insn, at final.c:2887
This is due to the fact that I did not think about somebody having quad memory
enabled but not VSX instructions. The non-VSX movti 64-bit insn always does a
"#" to split the insn, but the split function will not split it since it could
be handled by a "lq" instruction.
The fix is to use the function rs6000_output_move_128bit to properly generate
lq/stq if it is safe to do so.
[Bug target/57615] power8 support does not deal with -mquad-memory -mno-vsx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57615 Michael Meissner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-06-14 CC||bergner at gcc dot gnu.org, ||dje.gcc at gmail dot com Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/57615] power8 support does not deal with -mquad-memory -mno-vsx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57615 --- Comment #1 from Michael Meissner --- Created attachment 30303 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30303&action=edit Proposed patch to fix problem
[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52347 Simon Richter changed: What|Removed |Added CC||Simon.Richter at hogyros dot de --- Comment #2 from Simon Richter --- In 4.8, this causes build failures for me: $ g++ -g -Wall -W -Werror -Wno-unused -I. -o stage1/tree_bison_lex.o -c tree_bison_lex.cpp tree_bison_lex.cpp:1744:13: error: unused parameter 'yyscanner' [-Werror=unused-parameter] As can be guessed from the name, this is a file that is generated from flex, which is why I've added -Wno-unused for this file specifically. 4.7 did not warn.
[Bug fortran/46459] ICE (segfault): Invalid read in compare_actual_formal [error recovery]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46459 --- Comment #5 from Mikael Morin --- The initial test doesn't lead to a segfault any more. It is now rejected with: comment_0.f90:7.8: call sub(1) 1 Error: Explicit interface required for 'sub' at (1): volatile argument However, the following variant is also rejected with the same error: call sub(1) contains subroutine sub(j) integer, volatile :: j end subroutine sub end
[Bug libstdc++/53477] pretty printer fails with: Python Exception list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477
Tomasz Gajewski changed:
What|Removed |Added
CC||tomga at wp dot pl
--- Comment #8 from Tomasz Gajewski ---
The testcase can be reduced to:
#include
typedef std::map IntToIntMap;
int main()
{
IntToIntMap amap;
IntToIntMap & mapref = amap;
amap[1] = 1;
return 0;
}
and the problem is with map references. Executing on line with 'amap[1] = 1;'
commands to print 'amap' and 'mapref' I get:
(gdb) set python print-stack full
(gdb) p mapref
Traceback (most recent call last):
File "/home/tomga/devel/gdb-scripts/python/libstdcxx/v6/printers.py", line
438, in children
rep_type = find_type(self.val.type, '_Rep_type')
File "/home/tomga/devel/gdb-scripts/python/libstdcxx/v6/printers.py", line
52, in find_type
field = typ.fields()[0]
IndexError: list index out of range
$3 = std::map with 0 elements
(gdb) p amap
$4 = std::map with 0 elements
I get this with:
$ g++ --version
g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
...
$ gdb --version
GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
...
Pretty printers from svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python
(currently latest revision: 200105.
Currently I don't know how to debug this further.
[Bug fortran/57616] New: Support -fsanitize=undefined in Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57616 Bug ID: 57616 Summary: Support -fsanitize=undefined in Fortran Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org The newly being added patches for -fsanitize=undefined are partially done in the the FE. Thus, we need to add some Fortran support for them. Seemingly, the following should be handled: * Integer divide by zero * Invalid bit shifts Fortran 2008 has for shift: 13.7.50 DSHIFTL (I, J, SHIFT) 13.7.51 DSHIFTR (I, J, SHIFT) ... SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT_SIZE (I) if I is of type integer; otherwise, it shall be less than or equal to BIT_SIZE (J). 13.7.84 ISHFT (I, SHIFT) ... SHIFT shall be of type integer. The absolute value of SHIFT shall be less than or equal to BIT_SIZE (I). 13.7.85 ISHFTC (I, SHIFT [, SIZE]) ... SIZE (optional) shall be of type integer. The value of SIZE shall be positive and shall not exceed BIT SIZE (I). 13.7.150 SHIFTA (I, SHIFT) 13.7.151 SHIFTL (I, SHIFT) 13.7.151 SHIFTR (I, SHIFT) ... SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT SIZE (I).
[Bug c/57490] ICE on c-c++-common/cilk-plus/AN/an-if.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57490 Rainer Orth changed: What|Removed |Added Target|sparc*-sun-solaris2.* |*-*-solaris2.* Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-14 CC||ro at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Rainer Orth --- As of 2013-06-14 (r200089), I see the following ICE on both Solaris/SPARC and Solaris/x86, can be reproduced with x86_64-unknown-linux-gnu x i386-pc-solaris2.10 cross compiler: % cc1 -fpreprocessed an-if.i -quiet -fcilkplus -o an-if.s /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c: In function 'main': /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c:14:9: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2042 int i = 0; ^ 0x7884f7 gimplify_var_or_parm_decl /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:2042 0x790c18 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:7565 0x7a2980 gimplify_modify_expr /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:4851 0x790b6f gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:7160 0x797758 gimplify_stmt(tree_node**, gimple_statement_d**) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:5692 0x79a5d3 gimplify_and_add /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:327 0x79a5d3 gimplify_decl_expr /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:1468 0x790629 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:7327 0x797758 gimplify_stmt(tree_node**, gimple_statement_d**) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:5692 0x790e33 gimplify_statement_list /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:1521 0x790e33 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:7549 0x797758 gimplify_stmt(tree_node**, gimple_statement_d**) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:5692 0x79786a gimplify_body(tree_node*, bool) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:8193 0x797d82 gimplify_function_tree(tree_node*) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:8325 0x621c77 analyze_function /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:630 0x624399 analyze_functions /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:914 0x624b07 finalize_compilation_unit() /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2088 0x4e7092 c_write_global_declarations() /vol/gcc/src/hg/trunk/local/gcc/c/c-decl.c:10118 Preprocessed testcase attached. Balaji, could you please have a look. At least on Solaris/x86, this is the last remaining cilkplus testsuite failure (Solaris/SPARC bootstrap still running). Rainer
[Bug c/57490] ICE on c-c++-common/cilk-plus/AN/an-if.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57490 --- Comment #2 from Rainer Orth --- Created attachment 30304 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30304&action=edit preprocessed testcase
[Bug target/57615] power8 support does not deal with -mquad-memory -mno-vsx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57615 Michael Meissner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Michael Meissner --- Fixed in subversion id 200107.
[Bug c++/57617] New: OpenMP critical does not seem to synchronise correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57617 Bug ID: 57617 Summary: OpenMP critical does not seem to synchronise correctly Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nmm1 at cam dot ac.uk Created attachment 30305 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30305&action=edit Gzipped tar file of sources, command to run the test and output There are some ancient problems that match this (e.g. 45025), but I can't find a new one. I have written a portable, multi-interface memory consistency checker for some common 'atomic' paradigms, and one of my tests finds that gcc -fopenmp isn't behaving. In the attached files, look for 'NOT expected' in output - I will report the store/load one separately. Regrettably, there is no documentation yet and this is not stripped down, but the code is structured so that the relevant function's assembler can be inspected (with -O0 at least). I ran commands to generate output. If you find a bug in my code, I shan't be surprised :-(
[Bug c++/57618] New: OpenMP atomic read and write are not sequentially consistent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57618 Bug ID: 57618 Summary: OpenMP atomic read and write are not sequentially consistent Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nmm1 at cam dot ac.uk See bug 57617 for the data and more description. But the same program finds that OpenMP atomic read and write are not sequentially consistent. That will assuredly cause wrong answers when yer everage programmer attempts to use them. But should they be? If you can decode any specification on this matter from what OpenMP are pleased to call a standard, you are more intelligent than I am. So is this a bug, a gotcha or a feature?
[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52347 --- Comment #3 from Manuel López-Ibáñez --- (In reply to Simon Richter from comment #2) > In 4.8, this causes build failures for me: > > $ g++ -g -Wall -W -Werror -Wno-unused -I. -o stage1/tree_bison_lex.o -c > tree_bison_lex.cpp > tree_bison_lex.cpp:1744:13: error: unused parameter 'yyscanner' > [-Werror=unused-parameter] Could you attach a self-contained preprocessed testcase? See http://gcc.gnu.org/bugs/
[Bug libstdc++/57619] New: std::unordered_map and std::unordered_multimap::insert invoking std::pair move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57619
Bug ID: 57619
Summary: std::unordered_map and std::unordered_multimap::insert
invoking std::pair move constructor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gdjss2728 at gmail dot com
The following code is invoking the std::pair move constructor:
int main ()
{
std::unordered_map mymap;
std::unordered_multimap mymultimap;
std::pair mypair{std::string("key"),
std::string("value")};
mymultimap.insert(mypair); // std::pair move constructor invoked here
mymap.insert(mypair); // strings already moved out!
}
This seems related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53657.
As far as I can tell, overload resolution is choosing `insert(_Pair&& __x)`
over `insert(const value_type& __x)`. Since this is an lvalue, the latter
should be chosen. This happens for std::unordered_map::insert and
std::unordered_multimap::insert.
[Bug libstdc++/57619] std::unordered_map and std::unordered_multimap::insert invoking std::pair move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57619
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-06-14
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
(In reply to Jesse Good from comment #0)
> The following code is invoking the std::pair move constructor:
Complete testcase:
#include
#include
#include
int main ()
{
std::unordered_multimap mymultimap;
std::pair mypair{std::string("key"),
std::string("value")};
mymultimap.insert(mypair); // std::pair move constructor invoked here
assert( mypair.first.length() && mypair.second.length() );
}
> As far as I can tell, overload resolution is choosing `insert(_Pair&& __x)`
> over `insert(const value_type& __x)`. Since this is an lvalue, the latter
> should be chosen.
Calling that overload is correct, the problem is that it uses std::move() not
std::forward<_Pair>
[Bug c++/57620] New: Phantom terminator confuses raw string literal parsing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57620 Bug ID: 57620 Summary: Phantom terminator confuses raw string literal parsing. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: crowl at google dot com The first example of C++11 section 2.14.5 paragraph 5 confuses the scanner. $ cat test.cc const char *phantom_terminator = R"a( )\ a" )a"; $ xg++ -std=c++11 -g -O2 -c test.cc test.cc:4:3: warning: missing terminating " character [enabled by default] )a"; ^ test.cc:4:1: error: missing terminating " character )a"; ^ test.cc:4:1: error: expected ',' or ';' before ')' token
[Bug c++/57163] Link failure with thread_local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57163 Marcel Meyer changed: What|Removed |Added CC||meyerm at fs dot tum.de --- Comment #2 from Marcel Meyer --- Confirmed for gcc 4.8.1.
[Bug c++/57163] Link failure with thread_local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57163 --- Comment #3 from Marcel Meyer --- Please have a look at bug #55800 .
[Bug c++/55800] Link failure with thread_local in unnamed namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55800 Marcel Meyer changed: What|Removed |Added CC||meyerm at fs dot tum.de --- Comment #1 from Marcel Meyer --- Confirmed for 4.8.1 (using -std=c++11). Seems to be the same as bug #57163.
[Bug c++/51413] Broken diagnostic with __builtin_offsetof
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51413 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #2 from Paolo Carlini --- Fixed for 4.9.0.
[Bug libstdc++/57619] std::unordered_map and std::unordered_multimap::insert invoking std::pair move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57619 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.8.2 --- Comment #2 from Paolo Carlini --- Let's fix this.
[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52347
--- Comment #4 from Simon Richter ---
Testcase is simple:
$ cat tt.cpp
void bar(int baz) { }
$ g++-4.7 -c -W -Wall -Werror -Wno-unused tt.cpp
$ g++-4.8 -c -W -Wall -Werror -Wno-unused tt.cpp
tt.cpp:1:6: error: unused parameter ‘baz’ [-Werror=unused-parameter]
void bar(int baz) { }
^
cc1plus: all warnings being treated as errors
[Bug rtl-optimization/57451] Incorrect debug ranges emitted for -freorder-blocks-and-partition -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57451
--- Comment #4 from Cary Coutant ---
The problem is a lexical block in main() that appears to be getting split by
-freorder-blocks-and-partition, but when debug info is emitted during
rest_of_handle_final(), this particular lexical block still appears to be a
single block -- BLOCK_FRAGMENT_CHAIN is NULL, so the DWARF output code decides
that it can emit a DW_AT_low_pc/high_pc pair instead of a DW_AT_ranges. The
DW_AT_high_pc is now being output relative to DW_AT_low_pc, so we see an
assembly expression .LBE14 - .LBB14, which are labels attached to the block
start and block end, and should be in the same section.
Here's the block:
(gdb) p stmt
$1 = (tree) 0x75f4c4b0
(gdb) pt
warning: Expression is not an assignment (and might have no effect)
sizes-gimplified unsigned DI
size
unit size
align 64 symtab 0 alias set -1 canonical type 0x7609b930>
readonly tree_1 tree_3 unsigned decl_5 DI file pr49115.C line 21 col 25
size unit size
align 64 context >
supercontext
used tree_1 tree_3 decl_5 SI file pr49115.C line 18 col 8
size
unit size
align 128 context
(reg/v:SI 64 [ data ])>
supercontext
subblocks supercontext subblocks chain
(gdb) p stmt->block
$2 = {base = {code = BLOCK, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0,
volatile_flag = 0, readonly_flag = 0, asm_written_flag = 1, nowarning_flag
= 0, visited = 0,
used_flag = 1, nothrow_flag = 0, static_flag = 0, public_flag = 0,
private_flag = 0,
protected_flag = 0, deprecated_flag = 0, default_def_flag = 0, u = {bits =
{lang_flag_0 = 0,
lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0,
lang_flag_5 = 0,
lang_flag_6 = 0, saturating_flag = 0, unsigned_flag = 0, packed_flag =
0, user_align = 0,
nameless_flag = 1, spare0 = 0, spare1 = 0, address_space = 0}, length =
2048,
version = 2048}}, chain = 0x0, abstract_flag = 0, block_num = 14, locus =
0,
vars = 0x7608bc78, nonlocalized_vars = 0x0, subblocks = 0x0, supercontext
= 0x760c00f0,
abstract_origin = 0x0, fragment_origin = 0x0, fragment_chain = 0x0}
Here's the fragment of assembly code between .LBB14 and .LBE14:
.LBB14:
# pr49115.C:21
.loc 1 21 0
call__cxa_begin_catch
.LVL7:
call__cxa_end_catch
.LVL8:
.p2align 4,,5
# SUCC: 3 [100.0%] count:1
jmp .L15
.cfi_endproc
.section.text.unlikely
.cfi_startproc
.cfi_personality 0x3,__gxx_personality_v0
.cfi_lsda 0x3,.LLSDAC4
# BLOCK 6 freq:5000 seq:4
# PRED: 4 [50.0%] (CROSSING,CAN_FALLTHRU)
.L14:
.cfi_def_cfa_offset 16
.p2align 4,,8
.LEHB1:
# SUCC:
call_Unwind_Resume
.LEHE1:
.LVL9:
.LBE14:
.LBE15:
.cfi_endproc
You can see that the block from .LBB14 to .LBE14 has been split across two
sections. In order for dwarf2out to generate the proper debug info,
BLOCK_FRAGMENT_CHAIN(stmt) needs to be non-NULL. I'm not sure why that's not
happening when the block is split.
[Bug libstdc++/57619] std::unordered_map and std::unordered_multimap::insert invoking std::pair move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57619 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to fail||4.8.1 --- Comment #3 from Paolo Carlini --- Fixed mainline and 4.8.2.
[Bug c++/57620] Phantom terminator confuses raw string literal parsing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57620 Paolo Carlini changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Paolo Carlini --- Maybe Jakub can have a look.
[Bug c++/52762] Firefox 11 segfault with gcc 4.7 (-O3 -march=corei7-avx)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52762 Paolo Carlini changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #10 from Paolo Carlini --- Feedback not forthcoming.
[Bug c++/53099] Internal compiler error on short testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53099 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.8.0, 4.9.0 Resolution|--- |FIXED --- Comment #2 from Paolo Carlini --- Can't reproduce with the released 4.8.0, current 4_8-branch and mainline. If somebody can, please provide further details and re-open, thanks.
[Bug c/57621] New: -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57621
Bug ID: 57621
Summary: -Og
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: naruse at airemix dot jp
Folloing program is to verify func's argument is not larger than 3 at compile
time.
And this program uses valid argument 0.
Threfore I want the code is compiled without error.
This idea works on -O, -O1, -O2, -O3, -Os.
But on -Og, it fails with attribute error.
Of course it is not what I want, but is this intended behavior?
% cat og.c
#include
int ruby$safe_level$4(void) __attribute__((error("$SAFE=4 is obsolete")));
#define func(a) (__builtin_constant_p(a) && (a) > 3) ? ruby$safe_level$4() :
(a)
struct foo {
int n;
};
void show(struct foo *p) {
printf("%d\n", func(p->n));
}
void hoge(void) {
struct foo f;
f.n = 0;
show(&f);
}
int main(void) {
hoge();
return 0;
}
% gcc49 -O og.c && ./a.out
0
% gcc49 -Og og.c && ./a.out
og.c: In function 'show':
og.c:9:11: error: call to 'ruby$safe_level$4' declared with attribute error:
$SAFE=4 is obsolete
printf("%d\n", func(p->n));
^
% gcc49 -v
Using built-in specs.
COLLECT_GCC=gcc49
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd9.1/4.9.0/lto-wrapper
Target: x86_64-portbld-freebsd9.1
Configured with: ./../gcc-4.9-20130526/configure --disable-nls
--libdir=/usr/local/lib/gcc49 --libexecdir=/usr/local/libexec/gcc49
--program-suffix=49 --with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc49/include/c++/
--with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local
--with-pkgversion='FreeBSD Ports Collection' --with-system-zlib
--disable-libgcj --enable-languages=c,c++,objc,fortran --prefix=/usr/local
--mandir=/usr/local/man --infodir=/usr/local/info/gcc49
--build=x86_64-portbld-freebsd9.1
Thread model: posix
gcc version 4.9.0 20130526 (experimental) (FreeBSD Ports Collection)
% uname -a
FreeBSD windy.airemix.net 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0: Mon Apr 29
18:27:25 UTC 2013
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
[Bug c/57621] attribute error is interpreted even if it is switched with __builtin_constant_p on -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57621 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Andrew Pinski --- Dup.
