[Bug c/51849] -Wc99-compat would be considered useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51849 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Sun Aug 10 06:10:49 2014 New Revision: 213786 URL: https://gcc.gnu.org/viewcvs?rev=213786root=gccview=rev Log: PR c/51849 gcc/ * gcc/doc/invoke.texi: Document -Wc90-c99-compat. gcc/c-family/ * c-opts.c (sanitize_cpp_opts): Pass warn_c90_c99_compat to libcpp. * c.opt (Wc90-c99-compat): Add option. gcc/c/ * c-decl.c (build_array_declarator): Remove check for !flag_isoc99. Call pedwarn_c90 instead of pedwarn. (check_bitfield_type_and_width): Likewise. (declspecs_add_qual): Likewise. (declspecs_add_type): Likewise. (warn_variable_length_array): Unify function for -pedantic and -Wvla. Adjust to only call pedwarn_c90. (grokdeclarator): Remove pedantic !flag_isoc99 check. Call pedwarn_c90 instead of pedwarn. * c-errors.c (pedwarn_c90): Handle -Wc90-c99-compat. * c-parser.c (disable_extension_diagnostics): Handle warn_c90_c99_compat. (restore_extension_diagnostics): Likewise. (c_parser_enum_specifier): Remove check for !flag_isoc99. Call pedwarn_c90 instead of pedwarn. (c_parser_initelt): Likewise. (c_parser_postfix_expression): Likewise. (c_parser_postfix_expression_after_paren_type): Likewise. (c_parser_compound_statement_nostart): Remove check for !flag_isoc99. * c-tree.h: Fix formatting. * c-typeck.c (build_array_ref): Remove check for !flag_isoc99. Call pedwarn_c90 instead of pedwarn. gcc/testsuite/ * gcc.dg/Wc90-c99-compat-1.c: New test. * gcc.dg/Wc90-c99-compat-2.c: New test. * gcc.dg/Wc90-c99-compat-3.c: New test. * gcc.dg/Wc90-c99-compat-4.c: New test. * gcc.dg/Wc90-c99-compat-5.c: New test. * gcc.dg/Wc90-c99-compat-6.c: New test. * gcc.dg/wvla-1.c: Adjust dg-warning. * gcc.dg/wvla-2.c: Adjust dg-warning. * gcc.dg/wvla-4.c: Adjust dg-warning. * gcc.dg/wvla-6.c: Adjust dg-warning. libcpp/ * lex.c (_cpp_lex_direct): Warn when -Wc90-c99-compat is in effect. * charset.c (_cpp_valid_ucn): Likewise. * include/cpplib.h (cpp_options): Add cpp_warn_c90_c99_compat. * macro.c (replace_args): Warn when -Wc90-c99-compat is in effect. (parse_params): Likewise. Added: trunk/gcc/testsuite/gcc.dg/Wc90-c99-compat-1.c trunk/gcc/testsuite/gcc.dg/Wc90-c99-compat-2.c trunk/gcc/testsuite/gcc.dg/Wc90-c99-compat-3.c trunk/gcc/testsuite/gcc.dg/Wc90-c99-compat-4.c trunk/gcc/testsuite/gcc.dg/Wc90-c99-compat-5.c trunk/gcc/testsuite/gcc.dg/Wc90-c99-compat-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/c-family/c.opt trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/c/c-errors.c trunk/gcc/c/c-parser.c trunk/gcc/c/c-tree.h trunk/gcc/c/c-typeck.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/wvla-1.c trunk/gcc/testsuite/gcc.dg/wvla-2.c trunk/gcc/testsuite/gcc.dg/wvla-4.c trunk/gcc/testsuite/gcc.dg/wvla-6.c trunk/libcpp/ChangeLog trunk/libcpp/charset.c trunk/libcpp/include/cpplib.h trunk/libcpp/lex.c trunk/libcpp/macro.c
[Bug c/51849] -Wc99-compat would be considered useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51849 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- -Wc90-c99-compat has been added.
[Bug tree-optimization/62071] [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62071 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed by r213781.
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org| --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com --- The parser gets confused when in cp_parser_new_expression it tries first a cp_parser_new_placement: the bogus error is produced as part of that. As a parenthesized type-id, 'pure (*[3])' is normally accepted.
[Bug preprocessor/61613] ,##__VA_ARGS__ fails to expand the first variadic argument if it is a macro-name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613 David Krauss potswa at mac dot com changed: What|Removed |Added CC||potswa at mac dot com --- Comment #3 from David Krauss potswa at mac dot com --- The surprising result is because you passed print to itself, and the ## operator disables pre-expansion of argument tokens. If you want to expand print(print(…)), you can use the double-expansion idiom used for other special macros. #define do_print(x,...) (print(1,macro),print(1, ##__VA_ARGS__)) #define print(...) do_print( __VA_ARGS__ ) GCC 2.95 is not a role model. Regardless of what future compilers do, you should suggest the above fix to the Boost.ScopeExit maintainer. Note that I plan to propose the current behavior for standardization; see http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3882.pdf . (It is dated in the past, but it has not been processed yet due to a technicality.) Your use case does sound quite reasonable, but unless the implementations move soon, the door might shut as it ceases to have the flexibility of a GCC extension. On the other hand, if GCC does change here, I'll be compelled to propose standardizing the update instead.
[Bug middle-end/62078] New: [4.10 Regression] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 2 with -fdelete-dead-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62078 Bug ID: 62078 Summary: [4.10 Regression] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 2 with -fdelete-dead-exceptions Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 33278 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33278action=edit mostly reduced testcase Compiler output: $ $ /mnt/svn/gcc-trunk/binary-latest/bin/gcc -Og -fdelete-dead-exceptions -fnon-call-exceptions testcase.C testcase.C: In function 'void foo()': testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 40 } ^ testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 38 testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 36 testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 34 testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 32 testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 30 testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 28 testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 26 testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 24 testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 22 testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 18 testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 16 testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 14 testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 12 testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 10 testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 8 testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 6 testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 4 testcase.C:31:1: error: missing REG_EH_REGION note at the end of bb 2 testcase.C:31:1: internal compiler error: verify_flow_info failed 0x91f1d6 verify_flow_info() /mnt/svn/gcc-trunk/gcc/cfghooks.c:260 0xc28ac4 execute_function_todo /mnt/svn/gcc-trunk/gcc/passes.c:1761 0xc294d3 execute_todo /mnt/svn/gcc-trunk/gcc/passes.c:1806 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. (gdb) bt #0 internal_error (gmsgid=gmsgid@entry=0x16e67fb verify_flow_info failed) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:1130 #1 0x0091f1d7 in verify_flow_info () at /mnt/svn/gcc-trunk/gcc/cfghooks.c:260 #2 0x00c28ac5 in execute_function_todo (fn=0x76dfc498, data=optimized out) at /mnt/svn/gcc-trunk/gcc/passes.c:1761 #3 0x00c294d4 in execute_todo (flags=131136) at /mnt/svn/gcc-trunk/gcc/passes.c:1806 #4 0x00c2b86e in execute_one_pass (pass=pass@entry=0x1f9f350) at /mnt/svn/gcc-trunk/gcc/passes.c:2162 #5 0x00c2bdb6 in execute_pass_list_1 (pass=0x1f9f350) at /mnt/svn/gcc-trunk/gcc/passes.c:2201 #6 0x00c2bdc8 in execute_pass_list_1 (pass=0x1f9e9f0, pass@entry=0x1f9b930) at /mnt/svn/gcc-trunk/gcc/passes.c:2202 #7 0x00c2be09 in execute_pass_list (fn=0x76dfc498, pass=0x1f9b930) at /mnt/svn/gcc-trunk/gcc/passes.c:2212 #8 0x0094ab40 in expand_function (node=node@entry=0x76aa7450) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1776 #9 0x0094c20c in expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1910 #10 compile () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2254 #11 0x0094dba5 in finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2331 #12 0x0072a166 in cp_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/cp/decl2.c:4644 #13 0x00d268bd in compile_file () at /mnt/svn/gcc-trunk/gcc/toplev.c:562 #14 0x00d28c05 in do_compile () at /mnt/svn/gcc-trunk/gcc/toplev.c:1947 #15 toplev_main (argc=16, argv=0x7fffd7b8) at /mnt/svn/gcc-trunk/gcc/toplev.c:2023 #16 0x76e67db5 in __libc_start_main () from /lib64/libc.so.6 #17 0x0063e401 in _start () According to PR61031#c1, this might be just exposed by extended checking in 4.10. Tested revisions: r213777 - ICE 4_9 r212703 - OK
[Bug middle-end/62078] [4.10 Regression] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 2 with -fdelete-dead-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62078 Zdenek Sojka zsojka at seznam dot cz changed: What|Removed |Added Attachment #33278|0 |1 is obsolete|| --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz --- Created attachment 33279 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33279action=edit mostly reduced testcase Uploaded wrong testcase...
[Bug tree-optimization/62079] New: [4.9/4.10 Regression] ICE: in calc_dfs_tree, at dominance.c:401 with -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62079 Bug ID: 62079 Summary: [4.9/4.10 Regression] ICE: in calc_dfs_tree, at dominance.c:401 with -fnon-call-exceptions Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 33280 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33280action=edit partially reduced testcase Compiler output: $ gcc -std=c++0x -O2 -fnon-call-exceptions testcase.C testcase.C: In function 'int main()': testcase.C:75:1: internal compiler error: in calc_dfs_tree, at dominance.c:401 } ^ 0x98b7ab calc_dfs_tree /mnt/svn/gcc-trunk/gcc/dominance.c:401 0x98c7c1 calculate_dominance_info(cdi_direction) /mnt/svn/gcc-trunk/gcc/dominance.c:662 0x9220a7 flow_loops_find(loops*) /mnt/svn/gcc-trunk/gcc/cfgloop.c:414 0xb903c7 loop_optimizer_init(unsigned int) /mnt/svn/gcc-trunk/gcc/loop-init.c:92 0x157db93 if_convert /mnt/svn/gcc-trunk/gcc/ifcvt.c:4427 0x157fe8d execute /mnt/svn/gcc-trunk/gcc/ifcvt.c:4650 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. Tested revisions: r213777 - ICE 4_9 r212703 - ICE 4_8 r212702 - OK 4_7 r211571 - OK
[Bug c++/62080] New: Suboptimal code generation with eigen library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62080
Bug ID: 62080
Summary: Suboptimal code generation with eigen library
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: beschindler at gmail dot com
Created attachment 33281
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33281action=edit
Source code used to get the provided assembly
I'm currently optimizing some code using the eigen library and I'm stumbling
over an interesting problem.
I have a function, which I wrote in two different ways (the attributes are
there to provide some optimization barriers, dimEigen is a member variable of
the containing class):
void eigenClamp(Eigen::Vector4i vec) __attribute__((noinline, noclone))
{
vec = vec.array().min(dimEigen.array()).max(Eigen::Array4i::Zero());
}
void eigenClamp2(Eigen::Vector4i vec) __attribute__((noinline, noclone))
{
vec = vec.array().min(dimEigen.array());
vec = vec.array().max(Eigen::Array4i::Zero());
}
I'm compiling this on a core i7 920 using -O2 -fno-exceptions -fno-rtti
-std=c++11 -march=native
The first function generates this assembly, which looks great:
movdqu(%rsi), %xmm1
movdqu(%rdi), %xmm0
pminsd%xmm1, %xmm0
pxor%xmm1, %xmm1
pmaxsd%xmm1, %xmm0
movdqa%xmm0, (%rsi)
The second version does this:
movdqa(%rsi), %xmm0
pminsd(%rdi), %xmm0
movdqa%xmm0, (%rsi) --
pxor%xmm0, %xmm0
movdqu(%rsi), %xmm1 --
pmaxsd%xmm1, %xmm0
movdqa%xmm0, (%rsi)
It seems, because there are two lines in the original source code, the result
of the first expression is written to memory and then two instructions later,
read back from memory. This makes this function almost 50% slower in what I can
measure. As I find the latter code much easier to read as the former, it would
be great if the same assembly would be generated.
Also, I note that in the second version, the pminsd is executed directly from
the memory source, while in the first version, it is read to a register and
then pminsd is called. Thus, I'd love to see this code:
movdqu(%rsi), %xmm1
pminsd(%rdi), %xmm1
pxor%xmm1, %xmm1
pmaxsd%xmm1, %xmm0
movdqa%xmm0, (%rsi)
As a reference, I'm attaching the complete source code and the generated
assembly
[Bug c++/62080] Suboptimal code generation with eigen library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62080 --- Comment #1 from Benjamin Schindler beschindler at gmail dot com --- Created attachment 33282 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33282action=edit Generated assembly in full
[Bug fortran/62076] [4.9/4.10 Regression] testsuite failure in udr2.90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62076 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Summary|[4.10 Regression] testsuite |[4.9/4.10 Regression] |failure in udr2.90 |testsuite failure in ||udr2.90 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org --- Also fails for 4.9.
[Bug tree-optimization/62081] New: [4.10 Regression] ICE: in fix_loop_structure, at loop-init.c:208 with -fno-tree-ch -fno-tree-cselim -fno-tree-dominator-opts -fno-tree-reassoc -fno-tree-sink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62081 Bug ID: 62081 Summary: [4.10 Regression] ICE: in fix_loop_structure, at loop-init.c:208 with -fno-tree-ch -fno-tree-cselim -fno-tree-dominator-opts -fno-tree-reassoc -fno-tree-sink Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 33283 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33283action=edit reduced testcase Compiler output: $ gcc -O -fno-tree-ch -fno-tree-cselim -fno-tree-dominator-opts -fno-tree-reassoc -fno-tree-sink testcase.c testcase.c: In function 'foo': testcase.c:4:1: internal compiler error: in fix_loop_structure, at loop-init.c:208 foo () ^ 0x9defdf fix_loop_structure(bitmap_head*) /mnt/svn/gcc-trunk/gcc/loop-init.c:208 0xcb93fe gate_loop /mnt/svn/gcc-trunk/gcc/tree-ssa-loop.c:62 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. Tested revisions: r213777 - ICE 4_9 r212703 - OK 4_8 r212702 - OK
[Bug fortran/61999] [4.8/4.9/4.10 Regression] `gfc_simplify_dot_product` causes ICE for constant arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61999 --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org --- Author: tkoenig Date: Sun Aug 10 11:25:24 2014 New Revision: 213788 URL: https://gcc.gnu.org/viewcvs?rev=213788root=gccview=rev Log: 2014-08-10 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/61999 * simplify.c (gfc_simplify_dot_product): Convert types of vectors before calculating the result. 2014-08-10 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/61999 * gfortran.dg/dot_product_3.f90: New test case. Added: branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/dot_product_3.f90 Modified: branches/gcc-4_9-branch/gcc/fortran/ChangeLog branches/gcc-4_9-branch/gcc/fortran/simplify.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug c++/62080] Suboptimal code generation with eigen library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62080
--- Comment #2 from Marc Glisse glisse at gcc dot gnu.org ---
(note that a minimal, self-contained testcase would be much better and
shouldn't be hard to produce)
We write to memory with:
(insn 10 8 11 2 (set (mem:V2DI (reg/v/f:DI 97 [ vec ]) [0 MEM[(__m128i *
{ref-all})vec_4(D)]+0 S16 A128])
(subreg:V2DI (reg:V4SI 98) 0))
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.10.0/include/emmintrin.h:706
1147 {*movv2di_internal}
(expr_list:REG_DEAD (reg:V4SI 98)
(nil)))
and then read back with:
(insn 15 12 17 2 (set (reg:V2DF 100)
(vec_concat:V2DF (mem:DF (reg/v/f:DI 97 [ vec ]) [5 MEM[(const double
*)vec_4(D)]+0 S8 A64])
(mem:DF (plus:DI (reg/v/f:DI 97 [ vec ])
(const_int 8 [0x8])) [0 S8 A8])))
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.10.0/include/emmintrin.h:925
2016 {*vec_concatv2df}
(nil))
The vec_concat of the 2 adjacent memory locations is not merged into a single
memory read, although from the previous insn it looks like it is suitably
aligned.
[Bug c++/62080] Suboptimal code generation with eigen library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62080 --- Comment #3 from Benjamin Schindler beschindler at gmail dot com --- I just looked at what gcc-4.9.1 does and it does vary: movdqu(%rsi), %xmm1 movdqu(%rdi), %xmm0 -- pminsd%xmm1, %xmm0 -- pxor%xmm1, %xmm1 pmaxsd%xmm1, %xmm0 movaps%xmm0, (%rsi) So, the first version still has a needless movdqu (for which I don't know how much it hurts). Second version movdqa(%rsi), %xmm0 pminsd(%rdi), %xmm0 -- good pxor%xmm1, %xmm1 movdqu%xmm0, %xmm0 -- bad? pmaxsd%xmm1, %xmm0 movaps%xmm0, (%rsi) So, gcc-4.9 fares better such that it does not go to memory, but it emits an odd mov instruction. May be this is a separate issue?
[Bug fortran/61999] [4.8/4.9/4.10 Regression] `gfc_simplify_dot_product` causes ICE for constant arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61999 --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org --- Author: tkoenig Date: Sun Aug 10 14:19:18 2014 New Revision: 213789 URL: https://gcc.gnu.org/viewcvs?rev=213789root=gccview=rev Log: 2014-08-10 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/61999 * simplify.c (gfc_simplify_dot_product): Convert types of vectors before calculating the result. 2014-08-10 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/61999 * gfortran.dg/dot_product_3.f90: New test case. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/dot_product_3.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/simplify.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/61999] [4.8/4.9/4.10 Regression] `gfc_simplify_dot_product` causes ICE for constant arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61999 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Thomas Koenig tkoenig at gcc dot gnu.org --- Fixed on all open branches, closing. Thanks for the bug report!
[Bug libstdc++/62082] New: cout fails to work with auto variable initialized with curvy brackets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62082
Bug ID: 62082
Summary: cout fails to work with auto variable initialized with
curvy brackets
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: aleksej.penkov at hotmail dot com
This simple code (compiled with -std=c++11 -Wall):
#include iostream
int main()
{
double d = 5.5;
auto a {d};
std::coutd' 'astd::endl;
}
gives this compilation error:
2.cpp: In function ‘int main()’:
2.cpp:8:14: error: cannot bind ‘std::basic_ostreamchar’ lvalue to
‘std::basic_ostreamchar’
std::coutd' 'astd::endl;
^
In file included from /usr/local/include/c++/4.9.1/iostream:39:0,
from 2.cpp:1:
/usr/local/include/c++/4.9.1/ostream:602:5: note: initializing argument 1 of
‘std::basic_ostream_CharT, _Traits
std::operator(std::basic_ostream_CharT, _Traits, const _Tp) [with _CharT
= char; _Traits = std::char_traitschar; _Tp = std::initializer_listdouble]’
operator(basic_ostream_CharT, _Traits __os, const _Tp __x)
^
If i replace
auto a {d};
with
auto a = d;
it works fine.
[Bug libstdc++/62082] cout fails to work with auto variable initialized with curvy brackets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62082 --- Comment #1 from Aleksej aleksej.penkov at hotmail dot com --- Created attachment 33284 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33284action=edit source file with issue
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #1 from Sven C. Dack sven.c.dack at virginmedia dot com --- I have worked around the problem by adding a line to 'bootstrap-lto.mk' and to let it use a script for comparing object files based only on their disassembled code. I assume when the disassembled output of the object files matches then it should not matter much how it got there. It is not perfect, but it is better than not to bootstrap at all. I am going to attach a patch for those who are interested. Sven
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 Sven C. Dack sven.c.dack at virginmedia dot com changed: What|Removed |Added CC||sven.c.dack at virginmedia dot com --- Comment #2 from Sven C. Dack sven.c.dack at virginmedia dot com --- Created attachment 33285 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33285action=edit Changes the way 'bootstrap-lto.mk' compares object files The patch changes how 'bootstrap-lto.mk' compares object files by adding a new script 'compare-disassembly', which only compares the disassembled output of two object files.
[Bug fortran/60661] DO CONCURRENT with MASK: Avoid using a temporary for the mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60661 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-10 Ever confirmed|0 |1 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org --- For do concurrent(i=1:n, a(i)sum(a)/n) we currently evaluate the sum every time. This can definitely be improved, by taking out expressions which do not depend on the index variable out of the mask.
[Bug lto/62083] New: lto1: fatal error: bytecode stream generated with LTO version 2.2 instead of the expected 3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62083 Bug ID: 62083 Summary: lto1: fatal error: bytecode stream generated with LTO version 2.2 instead of the expected 3.0 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org I have binutils-2.24 with https://sourceware.org/ml/binutils/2014-01/msg00213.html patch applied, and libtool 2.4.2.444.30-da30-dirty . export CFLAGS='-pipe -flto -O3 -Wl,-S -Wl,--hash-style=gnu -Wl,-O1 -Wl,-z,relro -Wall -Wextra -Wl,--plugin=/usr/lib/bfd-plugins/liblto_plugin.so -fno-fat-lto-objects' export CXXFLAGS=$CFLAGS When I do: git clone http://mail.aegee.org/cgit/aegee-milter cd aegee-milter autoreconf -i ./configure make I get: lto1: fatal error: bytecode stream generated with LTO version 2.2 instead of the expected 3.0 compilation terminated. lto-wrapper: g++ returned 1 exit status /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status What means generated with v2.2 instead of the expected 3.0 and how can I fix this?
[Bug lto/62083] lto1: fatal error: bytecode stream generated with LTO version 2.2 instead of the expected 3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62083 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- It means that you try to use an archive, that was build with -flto -fno-fat-lto-objects and an older compiler. (The same issue happened to me a few days ago when I tried to build Firefox with -flto and gcc trunk. libcrmf.a from the nss library was build with -flto and gcc-4.9. Therefore libxul link failed with the bytecode stream error.) But the error message could be improved, because the user currently has no idea where the old bytecode stream is coming from.
[Bug target/51534] Bad code gen for vcgtq_u32 NEON intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51534 Ryan Mansfield rmansfield at qnx dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Ryan Mansfield rmansfield at qnx dot com --- Fixed awhile ago.
[Bug libstdc++/62082] cout fails to work with auto variable initialized with curvy brackets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62082
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com ---
The error is not a symptom of a library implementation error. Instead, the
reason for this compile-error is, that
auto a {d};
defines an object a of type
std::initializer_listdouble
and there does not exist any IO inserter for such types. When you declare
auto a = d;
this defines an object a of type
double
Therefore I consider this bug report as invalid.
[Bug c/62084] New: [avr] ICE: in convert_debug_memory_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62084 Bug ID: 62084 Summary: [avr] ICE: in convert_debug_memory_address Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: j at uriah dot heep.sax.de Created attachment 33286 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33286action=edit Preprocessed source triggering the issue When compiling the SVN version of avr-libc, I get the following ICE: % env LANG=C avr-gcc -gdwarf-2 -Wall -W -Wstrict-prototypes -mmcu=avr2 -mcall-prologues -Os -S strftime.i ../../../libc/time/strftime.c: In function 'pgm_copystring': ../../../libc/time/strftime.c:56:1: internal compiler error: in convert_debug_memory_address, at cfgexpand.c:2528 pgm_copystring(const char __memx * p, unsigned char i, char *b, unsigned char l) ^ no stack trace because unwind library not available Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. This can also be observed with GCC 4.8.3. Omitting the -gdwarf-2 option makes the issue go away.
[Bug rtl-optimization/61984] use mr. to remove extra cmp instruction on ppc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61984
Segher Boessenkool segher at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-08-10
CC||segher at gcc dot gnu.org
Component|target |rtl-optimization
Ever confirmed|0 |1
--- Comment #2 from Segher Boessenkool segher at gcc dot gnu.org ---
GCC already does this transformation: the pattern
used for the compare is movmode_internal2.
With -m32, the wanted mr. 3,4 comes out.
With -m64, IRA makes a non-optimal decision: it
gets {r125:CC=(r4=0); r124=r4} as a first insn,
and as a secon insn it gets (in a different BB)
r3=r124, and then it decides assigning r4 to the
pseudo r124 is the best idea.
[Bug lto/62083] lto1: fatal error: bytecode stream generated with LTO version 2.2 instead of the expected 3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62083 --- Comment #2 from Дилян Палаузов dilyan.palauzov at aegee dot org --- Thanks!
[Bug c++/62085] New: SFINAE where specialization parameter class member returns an abstract type fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62085
Bug ID: 62085
Summary: SFINAE where specialization parameter class member
returns an abstract type fails
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jameslyon0 at gmail dot com
The attached code fails to compile with:
sfinae.cpp: In instantiation of ‘struct AC’:
sfinae.cpp:14:8: required from here
sfinae.cpp:3:5: error: invalid abstract return type ‘C’
T f();
^
sfinae.cpp:9:8: note: because the following virtual functions are pure within
‘C’:
struct C {
^
sfinae.cpp:10:11: note: virtual C::~C()
virtual ~C() = 0;
I'm not an expert on the C++ standard, but I would expect the partial
specialization of B to be excluded by SFINAE rather than getting a compiler
error (clang accepts the code).
Looking at previous bugs, it seems that #12672 might be related.
[Bug c++/62085] SFINAE where specialization parameter class member returns an abstract type fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62085 --- Comment #1 from James Lyon jameslyon0 at gmail dot com --- Created attachment 33287 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33287action=edit Test case Seems I messed up attaching the test the first time :)
[Bug target/61948] [ARM] [4.10 regression] ICE with DImode shift by 1 bit (in copyprop_hardreg_forward_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948 --- Comment #4 from yroux at gcc dot gnu.org --- Author: yroux Date: Sun Aug 10 22:59:19 2014 New Revision: 213800 URL: https://gcc.gnu.org/viewcvs?rev=213800root=gccview=rev Log: gcc/ 2014-08-11 Yvan Roux yvan.r...@linaro.org Backport from trunk r213376. 2014-07-31 Charles Baylis charles.bay...@linaro.org PR target/61948 * config/arm/neon.md (ashldi3_neon): Don't emit arm_ashldi3_1bit unless constraints are satisfied. (shiftdi3_neon): Likewise. gcc/testsuite 2014-08-11 Yvan Roux yvan.r...@linaro.org Backport from trunk r213376. 2014-07-31 Charles Baylis charles.bay...@linaro.org PR target/61948 * gcc.target/arm/pr61948.c: New test case. Added: branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr61948.c Modified: branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/config/arm/neon.md branches/linaro/gcc-4_9-branch/gcc/testsuite/ChangeLog.linaro
[Bug target/61713] ICE when building c++ code with atomic functions for thumb1 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61713 --- Comment #6 from yroux at gcc dot gnu.org --- Author: yroux Date: Sun Aug 10 23:03:16 2014 New Revision: 213801 URL: https://gcc.gnu.org/viewcvs?rev=213801root=gccview=rev Log: gcc/ 2014-08-11 Yvan Roux yvan.r...@linaro.org Backport from trunk r213555. 2014-08-04 Kyrylo Tkachov kyrylo.tkac...@arm.com PR target/61713 * gcc/optabs.c (expand_atomic_test_and_set): Do not try to emit move to subtarget in serial version if result is ignored. gcc/testsuite 2014-08-11 Yvan Roux yvan.r...@linaro.org Backport from trunk r213555. 2014-08-04 Kyrylo Tkachov kyrylo.tkac...@arm.com PR target/61713 * gcc.dg/pr61756.c: New test. Added: branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr61756.c Modified: branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/optabs.c branches/linaro/gcc-4_9-branch/gcc/testsuite/ChangeLog.linaro
[Bug preprocessor/62086] New: A bug with option -fextended-identifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62086
Bug ID: 62086
Summary: A bug with option -fextended-identifiers
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: pangbw at gmail dot com
For this simple code, it would compile without -fextended-identifiers but fail
with it:
$cat ~/x.c
int main()
{
#if 0
int \u00A8\u00AA\u00AD\u00AF\u00B2\u00B5 = 7;
#endif
}
$ gcc -c ~/x.c
$ gcc -c -fextended-identifiers ~/x.c
x.c: In function ‘main’:
x.c:4:7: warning: universal character names are only valid in C++ and C99
[enabled by default]
x.c:4:7: error: universal character \u00A8 is not valid in an identifier
x.c:4:7: warning: universal character names are only valid in C++ and C99
[enabled by default]
x.c:4:7: warning: universal character names are only valid in C++ and C99
[enabled by default]
x.c:4:7: error: universal character \u00AD is not valid in an identifier
x.c:4:7: warning: universal character names are only valid in C++ and C99
[enabled by default]
x.c:4:7: error: universal character \u00AF is not valid in an identifier
x.c:4:7: warning: universal character names are only valid in C++ and C99
[enabled by default]
x.c:4:7: error: universal character \u00B2 is not valid in an identifier
x.c:4:7: warning: universal character names are only valid in C++ and C99
[enabled by default]
[Bug preprocessor/62086] A bug with option -fextended-identifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62086 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to baoshan from comment #0) For this simple code, it would compile without -fextended-identifiers but fail with it: I think this is correct behavior as the C standard requires the #if 0 code to be tokenized still. In the case without -fextended-identifiers: /u00A8 are three different tokens, / u and 00A8 (all three different tokens). With -fextended-identifiers \u00A8\u00AA\u00AD\u00AF\u00B2\u00B5 is considered one token (an identifier) but the characters not valid for the identifier.
