[Bug rtl-optimization/56766] Fails to combine (vec_select (vec_concat ...)) to (vec_merge ...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56766 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- This can be now seen in gfortran.dg/vect/fast-math-pr37021.f90 as well which produces .L14: movupd (%r11), %xmm3 addl$1, %ecx addq%rax, %r11 movupd (%r8), %xmm0 addq%rax, %r8 unpckhpd%xmm3, %xmm3 movupd (%rdi), %xmm2 unpcklpd%xmm0, %xmm0 addq%rsi, %rdi movupd (%rbx), %xmm1 mulpd %xmm3, %xmm2 addq%rsi, %rbx cmpl%ecx, %ebp palignr $8, %xmm1, %xmm1 mulpd %xmm1, %xmm0 movapd %xmm2, %xmm1 addpd %xmm0, %xmm1 subpd %xmm2, %xmm0 shufpd $2, %xmm0, %xmm1 addpd %xmm1, %xmm4 jne .L14 note the addpd %xmm0, %xmm1 subpd %xmm2, %xmm0 shufpd $2, %xmm0, %xmm1 which should be addsubpd %xmm2, %xmm1 it happens to work for v4sf mode. I think the vec_merge RTX code should either go away or we should canonicalize the other variants to vec_merge properly. For a target specific fix a 2nd addsubv2df3 pattern catching the (vec_select:V2DF (vec_merge:V4DF ...)) case could be added.
[Bug c++/66053] openmp target data mappings containing this pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66053 --- Comment #1 from Joseph S. Myers jsm28 at gcc dot gnu.org --- Author: jsm28 Date: Wed Jun 10 11:37:20 2015 New Revision: 224325 URL: https://gcc.gnu.org/viewcvs?rev=224325root=gccview=rev Log: [gomp4] Support C++ this in OpenACC directives. This patch, for gomp-4_0-branch, adds support for C++ this in OpenACC directives. (This patch does not do anything to handle OpenMP differently from OpenACC; that - bug 66053 - will need to be resolved for mainline, either deciding these cases should be accepted for OpenMP or making the parsing only accept them in OpenACC directives and not OpenMP ones.) Apart from parsing, it's necessary to prevent the cannot take the address of 'this', which is an rvalue expression error from appearing when this is used in such contexts. This patch duly adds a new argument to cxx_mark_addressable (default false so callers don't all need to change) to allow disabling that error, passing that argument in all calls that seem relevant to OpenACC directives. Tested for x86_64-none-linux-gnu and applied to gomp-4_0-branch. gcc/cp: 2015-06-10 Joseph Myers jos...@codesourcery.com * parser.c (cp_parser_omp_var_list_no_open): Handle RID_THIS. * typeck.c (cxx_mark_addressable): Add argument ALLOW_THIS. * cp-tree.h (cxx_mark_addressable): Update prototype. * semantics.c (handle_omp_array_sections) (finish_omp_reduction_clause, finish_omp_clauses): Pass ALLOW_THIS to cxx_mark_addressable. libgomp: 2015-06-10 Cesar Philippidis ce...@codesourcery.com * testsuite/libgomp.oacc-c++/this.C: New test. Added: branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c++/this.C Modified: branches/gomp-4_0-branch/gcc/cp/ChangeLog.gomp branches/gomp-4_0-branch/gcc/cp/cp-tree.h branches/gomp-4_0-branch/gcc/cp/parser.c branches/gomp-4_0-branch/gcc/cp/semantics.c branches/gomp-4_0-branch/gcc/cp/typeck.c branches/gomp-4_0-branch/libgomp/ChangeLog
[Bug c/31893] Please provide an inout attribute for function parameters.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31893
Daniel Fruzynski bugzi...@poradnik-webmastera.com changed:
What|Removed |Added
CC||bugzilla@poradnik-webmaster
||a.com
--- Comment #7 from Daniel Fruzynski bugzi...@poradnik-webmastera.com ---
I am looking for something similar - I want to mark function argument as an
output-only. Now when I compile following code with -Wall -O1 (using gcc
4.4.7), I get following waring: 'myVar' may be used uninitialized in this
function. With help of new function or function argument attribute this warning
would go away. This new attribute may also enable additional code optimizations
and warnings. I propose syntax __attribute__((out)).
void __attribute__((const)) func(int* i)
{
*i = 44;
}
int func2()
{
int myVal;
func(myVal);
return myVal;
}
[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Depends on||56766 Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #19 from Richard Biener rguenth at gcc dot gnu.org --- We now vectorize the original testcase with SLP. There is still PR56766 which causes us to fail to use addsubpd on x86_64 with SSE3. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56766 [Bug 56766] Fails to combine (vec_select (vec_concat ...)) to (vec_merge ...)
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
--- Comment #15 from Iain Sandoe iains at gcc dot gnu.org ---
(In reply to Aldy Hernandez from comment #14)
Created attachment 35734 [details]
Patch to ICE on other duplicate DW_AT_ attributes
I can't reproduce any of these with a cross compiler. I'm building a cross
with:
--enable-languages=c,c++ --disable-bootstrap --disable-multilib
--target=i686-darwin
The triple for the platform I'm testing on is : x86_64-apple-darwin12
I doubt that i686/x86_64 is significant since the errors show on both multilib
variants.
However, I'd avoid the default version - and suggest at least
xxx-apple-darwin10.
...but I still can't get cc1plus to trigger any ICE with the attached patch.
me neither - nevertheless...
warning: invalid DWARF generated by the compiler: DIE 0x0176 has
multiple
AT_artificial attributes in
'/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccNJ6qak.o'.
Similarly here.
The attached patch adds ICEs for duplicate
DW_AT_{artificial,decl_line,decl_file} tags. Since I'm flying blind here,
would you mind finding for which files we trigger ICEs and attach the
preprocessed files so I can reproduce with a cc1/cc1plus? I assume just one
of each type will do.
OK. so … the ICEs don't fire - but, nevertheless, the output seems to be
incorrect.
I'll attach the intermediate files in a follow-on post.
for the case of:
./gcc/xgcc -Bgcc
/GCC/gcc-trunk/gcc/testsuite/gcc.c-torture/execute/20020412-1.c -m64 -O3 -g
-o t -save-temps
dwarfdump --verify 20020412-1.o
--
File: 20020412-1.o (x86_64)
--
Verifying Compile Unit Header chain... ok
Verifying .debug_info...
error: Range is not in parent
BLCK {0x01da}: [0x0190 - 0x0204) ERROR
0x020a: contains multiple AT_decl_file attributes.
ERROR 0x020a: contains multiple AT_decl_line attributes.
ERROR 0x020a: contains multiple AT_decl_file attributes.
ERROR 0x020a: contains multiple AT_decl_line attributes.
ERROR 0x028d: contains multiple AT_decl_file attributes.
ERROR 0x028d: contains multiple AT_decl_line attributes.
==
using binutils objdump (which groks mach-o)
… although I realise you don't have a cross-assembler (although I'm working on
that too ;) )
Contents of the .debug_info section:
Compilation Unit @ offset 0x0:
Length:0x39d (32-bit)
Version: 2
Abbrev Offset: 0x0
snip
209 DW_AT_const_value : 5
220a: Abbrev Number: 11 (DW_TAG_structure_type)
20b DW_AT_decl_file : 1
20c DW_AT_decl_line : 43
20d DW_AT_decl_file : 1
20e DW_AT_decl_line : 43
20f DW_AT_decl_file : 1
210 DW_AT_decl_line : 43
211 DW_AT_sibling : 0x222
3215: Abbrev Number: 7 (DW_TAG_member)
so it appears that the tools agree about the binary ..
=
[Bug tree-optimization/60656] [4.8 regression] x86 vectorization produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60656 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||corydoras at ridiculousfish dot co ||m --- Comment #17 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 61108 has been marked as a duplicate of this bug. ***
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448 --- Comment #16 from Iain Sandoe iains at gcc dot gnu.org --- Created attachment 35739 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35739action=edit outputs from -save-temps on 20020412-1.c (-O3 -g) .. of course, we might just have uncovered some latent issue.
[Bug target/61108] [4.8 Regression] gcc 4.8.2 generates incorrect integer arithmetic at O3 (ok at O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61108 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Duplicate (I'm currently backporting the fix for the duplicate). *** This bug has been marked as a duplicate of bug 60656 ***
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 37021, which changed state. Bug 37021 Summary: Fortran Complex reduction / multiplication not vectorized https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/66484] New: Exception specification can declare a pointer to incomplete type, which is against C++ standard section 15.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66484
Bug ID: 66484
Summary: Exception specification can declare a pointer to
incomplete type, which is against C++ standard section
15.1
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bluechristlove at 163 dot com
Target Milestone: ---
In the C++11 standard 15.1.3 Throwing an exception, the standard says that: If
the
type of the exception object would be an incomplete type or a pointer to an
incomplete type other than (possibly cv-qualified) void the program is
ill-formed.
So if we write the code like this:
[code]
class C;
template class ...T void f(T...) throw(T...) {}
void g(C* p) { f(1,p); }
int main()
{
}
[/code]
This should not be passed, because p is a pointer to incomplete type of C, but
gcc can pass this case.
However, if we compile this case using clang, clang will emit error like this:
main.cpp:2:46: error: pointer to incomplete type 'C' is not allowed in
exception specification
template class ...T void f(T...) throw(T...) {}
[Bug target/66428] [6 regression] FAIL: g++.dg/abi/aarch64_guard1.C -std=gnu++98 scan-tree-dump original _ZGVZ3foovE1x 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66428 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-06-10 Assignee|unassigned at gcc dot gnu.org |ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- mine.
[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144 --- Comment #5 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Wed Jun 10 07:50:59 2015 New Revision: 224314 URL: https://gcc.gnu.org/viewcvs?rev=224314root=gccview=rev Log: Add ARM/thumb attribute target PR target/52144 * config/arm/arm.opt (THUMB, arm_restrict_it, inline_asm_unified): Save. * config/arm/arm-protos.h (arm_valid_target_attribute_tree): Declare. (arm_reset_previous_fndecl, arm_change_mode_p): Likewise. * config/arm/arm.h (SWITCHABLE_TARGET): Define. * config/arm/arm.c (arm_reset_previous_fndecl): New functions. (arm_valid_target_attribute_tree, arm_change_mode_p): Likewise. (arm_valid_target_attribute_p): Likewise. (arm_set_current_function, arm_can_inline_p): Likewise. (arm_valid_target_attribute_rec): Likewise. (arm_previous_fndecl): New variable. (TARGET_SET_CURRENT_FUNCTION, TARGET_OPTION_VALID_ATTRIBUTE_P): Define. (TARGET_CAN_INLINE_P): Define. (arm_asm_trampoline_template): Emit mode. (arm_file_start): Don't set unified syntax. (arm_declare_function_name): Set unified syntax and mode. (arm_option_override): Init target_option_default_node. and target_option_current_node. * config/arm/arm.md (*call_value_symbol): Set mode when possible. (*call_symbol): Likewise. * doc/extend.texi: Document ARM/Thumb target attribute. * doc/invoke.texi: Likewise. * gcc.target/arm/attr_arm.c: New test * gcc.target/arm/attr_arm-err.c: New test * gcc.target/arm/attr_thumb.c: New test * gcc.target/arm/attr_thumb-static.c: New test Added: trunk/gcc/testsuite/gcc.target/arm/attr_arm-err.c trunk/gcc/testsuite/gcc.target/arm/attr_arm.c trunk/gcc/testsuite/gcc.target/arm/attr_thumb-static.c trunk/gcc/testsuite/gcc.target/arm/attr_thumb.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-protos.h trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.h trunk/gcc/config/arm/arm.md trunk/gcc/config/arm/arm.opt trunk/gcc/doc/extend.texi trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug target/66483] [4.9 Regression] ICE (in add_stores, at var-tracking.c:6000) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to fail||4.9.3 --- Comment #3 from ktkachov at gcc dot gnu.org --- Reducing...
[Bug target/66428] [6 regression] FAIL: g++.dg/abi/aarch64_guard1.C -std=gnu++98 scan-tree-dump original _ZGVZ3foovE1x 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66428 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Author: ramana Date: Wed Jun 10 07:43:31 2015 New Revision: 224313 URL: https://gcc.gnu.org/viewcvs?rev=224313root=gccview=rev Log: Handle aarch64_guard1.C test Sorry about missing this hunk in the original submission, was in my tree but I hadn't spotted this as I was playing between the original AArch64 TARGET_RELAXED_ORDER and this patch. Applied as obvious. 2015-06-09 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/66200 PR target/66428 PR c++/66192 * g++.dg/abi/aarch64_guard1.C: Adjust test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/abi/aarch64_guard1.C
[Bug c++/66192] C++ static initializer unnecessary __cxa_guard_acquire for TARGET_RELAXED_ORDERING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66192 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Author: ramana Date: Wed Jun 10 07:43:31 2015 New Revision: 224313 URL: https://gcc.gnu.org/viewcvs?rev=224313root=gccview=rev Log: Handle aarch64_guard1.C test Sorry about missing this hunk in the original submission, was in my tree but I hadn't spotted this as I was playing between the original AArch64 TARGET_RELAXED_ORDER and this patch. Applied as obvious. 2015-06-09 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/66200 PR target/66428 PR c++/66192 * g++.dg/abi/aarch64_guard1.C: Adjust test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/abi/aarch64_guard1.C
[Bug target/66200] GCC for ARM / AArch64 doesn't define TARGET_RELAXED_ORDERING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66200 --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Author: ramana Date: Wed Jun 10 07:43:31 2015 New Revision: 224313 URL: https://gcc.gnu.org/viewcvs?rev=224313root=gccview=rev Log: Handle aarch64_guard1.C test Sorry about missing this hunk in the original submission, was in my tree but I hadn't spotted this as I was playing between the original AArch64 TARGET_RELAXED_ORDER and this patch. Applied as obvious. 2015-06-09 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/66200 PR target/66428 PR c++/66192 * g++.dg/abi/aarch64_guard1.C: Adjust test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/abi/aarch64_guard1.C
[Bug target/66483] [4.9 Regression] ICE (in add_stores, at var-tracking.c:6000) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.4
[Bug libstdc++/66485] New: std::string single-character assignment operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66485
Bug ID: 66485
Summary: std::string single-character assignment operator
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: yurivkhan at gmail dot com
Target Milestone: ---
gcc’s implementation of std::basic_string contains a non-standard and very
surprising operator= which accepts a single character or anything that is
implicitly castable thereto.
To reproduce:
===
#include iostream
#include string
int main()
{
std::string s;
s = 42;
std::cout s \n;
}
===
$ g++ --version
g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2[…]
$ g++ test.cpp
(with any of -std= variations, with or without -Wall -pedantic)
Observed behavior: compiles, runs, outputs a single character * (asterisk).
Expected behavior: compilation error, because the standard does not define any
such operator=.
[Bug c++/66487] [6 Regression] Firefox segfault with LTO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug debug/66482] [6 Regression] ICE in gen_formal_parameter_die
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66482 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-10 Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Aldy Hernandez aldyh at gcc dot gnu.org --- Mine.
[Bug target/66473] ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66473 --- Comment #5 from Kirill Yukhin kyukhin at gcc dot gnu.org --- (In reply to Uroš Bizjak from comment #3) Kirill, you have much better facilities for testing, do you want to take the proposed patch from here? Your patch is fine for sure. No AVX-512* tests fail. The only nit is that I that I think we need regtest in patch as well.
[Bug tree-optimization/60656] [4.8 regression] x86 vectorization produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60656 --- Comment #18 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Jun 10 12:53:09 2015 New Revision: 224327 URL: https://gcc.gnu.org/viewcvs?rev=224327root=gccview=rev Log: 2015-06-10 Richard Biener rguent...@suse.de Backport from mainline 2014-04-04 Cong Hou co...@google.com PR tree-optimization/60656 * tree-vect-stmts.c (supportable_widening_operation): Fix a bug that elements in a vector with vect_used_by_reduction property are incorrectly reordered when the operation on it is not consistant with the one in reduction operation. * gcc.dg/vect/pr60656.c: New test. 2014-01-31 Richard Biener rguent...@suse.de PR middle-end/59990 * builtins.c (fold_builtin_memory_op): Make sure to not use a floating-point mode or a boolean or enumeral type for the copy operation. * gcc.dg/torture/pr59990.c: New testcase. * gcc.target/i386/pr49168-1.c: Adjust. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59990.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr60656.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/builtins.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr49168-1.c branches/gcc-4_8-branch/gcc/tree-vect-stmts.c
[Bug middle-end/59990] [4.8 regression] incorrect memcpy optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990 --- Comment #24 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Jun 10 12:53:09 2015 New Revision: 224327 URL: https://gcc.gnu.org/viewcvs?rev=224327root=gccview=rev Log: 2015-06-10 Richard Biener rguent...@suse.de Backport from mainline 2014-04-04 Cong Hou co...@google.com PR tree-optimization/60656 * tree-vect-stmts.c (supportable_widening_operation): Fix a bug that elements in a vector with vect_used_by_reduction property are incorrectly reordered when the operation on it is not consistant with the one in reduction operation. * gcc.dg/vect/pr60656.c: New test. 2014-01-31 Richard Biener rguent...@suse.de PR middle-end/59990 * builtins.c (fold_builtin_memory_op): Make sure to not use a floating-point mode or a boolean or enumeral type for the copy operation. * gcc.dg/torture/pr59990.c: New testcase. * gcc.target/i386/pr49168-1.c: Adjust. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59990.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr60656.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/builtins.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr49168-1.c branches/gcc-4_8-branch/gcc/tree-vect-stmts.c
[Bug rtl-optimization/64164] [4.9/5/6 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 Christophe Lyon clyon at gcc dot gnu.org changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #40 from Christophe Lyon clyon at gcc dot gnu.org --- Created attachment 35740 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35740action=edit ARM testcase This is the testcase that breaks on ARM, when compiled with optimizations: -O0 is OK, -O1, -O2, -O3 crash with: /media/lyon/9be1a707-5b7f-46da-9106-e084a5dbb011/ssd/src/GCC/sources/gcc-fsf/trunk/libgcc/fixed-bit.c: In function '__gnu_addqq3': /media/lyon/9be1a707-5b7f-46da-9106-e084a5dbb011/ssd/src/GCC/sources/gcc-fsf/trunk/libgcc/fixed-bit.c:59:1: internal compiler error: RTL flag check: MEM_VOLATILE_P used with unexpected rtx code 'reg' in set_mem_attributes_minus_bitpos, at emit-rtl.c:1787 FIXED_ADD (FIXED_C_TYPE a, FIXED_C_TYPE b) ^ 0xa6eb52 rtl_check_failed_flag(char const*, rtx_def const*, char const*, int, char const*) /media/lyon/9be1a707-5b7f-46da-9106-e084a5dbb011/ssd/src/GCC/sources/gcc-fsf/trunk/gcc/rtl.c:800 0x771fc7 set_mem_attributes_minus_bitpos(rtx_def*, tree_node*, int, long) /media/lyon/9be1a707-5b7f-46da-9106-e084a5dbb011/ssd/src/GCC/sources/gcc-fsf/trunk/gcc/emit-rtl.c:1787 0x805294 assign_parm_setup_block /media/lyon/9be1a707-5b7f-46da-9106-e084a5dbb011/ssd/src/GCC/sources/gcc-fsf/trunk/gcc/function.c:2977 0x80b65c assign_parms /media/lyon/9be1a707-5b7f-46da-9106-e084a5dbb011/ssd/src/GCC/sources/gcc-fsf/trunk/gcc/function.c:3775 0x80e087 expand_function_start(tree_node*) /media/lyon/9be1a707-5b7f-46da-9106-e084a5dbb011/ssd/src/GCC/sources/gcc-fsf/trunk/gcc/function.c:5215 0x6a77ed execute /media/lyon/9be1a707-5b7f-46da-9106-e084a5dbb011/ssd/src/GCC/sources/gcc-fsf/trunk/gcc/cfgexpand.c:6127 Please submit a full bug report,
[Bug target/66473] ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66473 --- Comment #6 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Kirill Yukhin from comment #5) Your patch is fine for sure. No AVX-512* tests fail. The only nit is that I that I think we need regtest in patch as well. Yep, it will be added when the patch is submitted later today.
[Bug target/66486] New: MMIX code produced is invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66486
Bug ID: 66486
Summary: MMIX code produced is invalid
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ruckert at cs dot hm.edu
Target Milestone: ---
The following c code:
typedef struct node { struct node *next; int i; } node;
void InsertEnd(node *p, node **head)
{ while (*head!=0) head=((*head)-next);
*head=p;
}
compliled with mmix-gcc -O2 -S bug.c
produces:
InsertEnd IS @
LDO $15,$1,0
BZ $15,L:9
L:5 IS @
SET $1,$2
LDO $2,$1,0
PBNZ $2,L:5
L:9 IS @
STOU $0,$1,0
POP 0,0
In the first SET instruction $2 is uninitialized. Probably the $15 in the
first two instructions should be a $2.
[Bug c++/66487] New: [6 Regression] Firefox segfault with LTO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487 Bug ID: 66487 Summary: [6 Regression] Firefox segfault with LTO enabled Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Hi. This if follow-up of PR66163, where I fixed all -fsanitize=null errors and give another build spin. Starting from r222135 Firefox built with -flto and -O2 crashed during start-up. Unfortunately, back-trace looks completely corrupted. Is there any way I can somehow isolate the issue? Thanks, Martin
[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #11 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to nsz from comment #10) Author: nsz Date: Tue Jun 2 16:21:18 2015 New Revision: 224031 URL: https://gcc.gnu.org/viewcvs?rev=224031root=gccview=rev Log: [AArch64][PR 66136] rewrite geniterators.sh in awk 2015-06-02 Szabolcs Nagy szabolcs.n...@arm.com PR target/66136 * config/aarch64/geniterators.sh: Rewrite in awk. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/geniterators.sh Does this also need to go to the release branches , Szabolcs ? Ramana
[Bug target/66428] [6 regression] FAIL: g++.dg/abi/aarch64_guard1.C -std=gnu++98 scan-tree-dump original _ZGVZ3foovE1x 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66428 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- fixed.
[Bug c++/66192] C++ static initializer unnecessary __cxa_guard_acquire for TARGET_RELAXED_ORDERING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66192 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/60656] [4.8 regression] x86 vectorization produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60656 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org --- I'll see if it is backportable easily.
[Bug lto/66394] [4.9/5/6 Regression] ICE in -flto -fmerge-all-constants -fno-use-linker-plugin targetting i686-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66394 --- Comment #8 from Stanisław Halik sthalik at misaki dot pl --- I can confirm all the code builds with LTO and -fmerge-all-constants after applying the patch. LTO with linker plugin results in unresolved symbols, but this is for another time. Best regards.
[Bug target/66483] [4.9 Regression] ICE (in add_stores, at var-tracking.c:6000) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483 --- Comment #1 from Matthias Klose doko at gcc dot gnu.org --- Created attachment 35738 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35738action=edit preprocessed source
[Bug target/66483] New: [4.9 Regression] ICE (in add_stores, at var-tracking.c:6000) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483 Bug ID: 66483 Summary: [4.9 Regression] ICE (in add_stores, at var-tracking.c:6000) on arm-linux-gnueabihf Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- Created attachment 35737 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35737action=edit reduced file seen with the 4.9 branch on arm-linux-gnueabihf. lowering optimization to -O1 or omitting -g works around the issue. works with the 4.8 branch and the trunk. $ g++ -c -std=c++11 -g -O2 -fPIC -fstack-protector-strong -ffunction-sections -fno-exceptions -frandom-seed=0 qxml.ii qxml.ii: In member function 'bool QXmlSimpleReaderPrivate::isExpandedEntityValueTooLarge(QString*)': qxml.ii:268:1: internal compiler error: in add_stores, at var-tracking.c:6000 } ^ Please submit a full bug report, with preprocessed source if appropriate. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-20' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 4.9.2 (Debian 4.9.2-20)
[Bug rtl-optimization/48181] wrong code with -O -fgcse --param ira-max-conflict-table-size=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48181 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.0 Resolution|--- |FIXED Target Milestone|4.8.5 |4.8.0 Summary|[4.8/4.9 Regression] wrong |wrong code with -O -fgcse |code with -O -fgcse --param |--param |ira-max-conflict-table-size |ira-max-conflict-table-size |=0 |=0 --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug target/66483] [4.9 Regression] ICE (in add_stores, at var-tracking.c:6000) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-10 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed on latest 4.9 with command line options: -std=c++11 -g -O2 -fPIC -fstack-protector-strong -ffunction-sections -fno-exceptions -frandom-seed=0 -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -march=armv7-a
[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136 --- Comment #12 from Szabolcs Nagy nszabolcs at gmail dot com --- geniterators.sh was new in gcc-5 and the first version of the script already used \n in the sed replacement pattern (and other gnu extensions too). shall i backport the new script to the gcc-5 branch?
[Bug target/66483] [4.9 Regression] ICE (in add_stores, at var-tracking.c:6000) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483 --- Comment #4 from ktkachov at gcc dot gnu.org --- (In reply to ktkachov from comment #3) Reducing... The initial submission already includes a reduced testcase. Had not noticed that
[Bug lto/66394] [4.9/5/6 Regression] ICE in -flto -fmerge-all-constants -fno-use-linker-plugin targetting i686-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66394 --- Comment #9 from Martin Liška marxin at gcc dot gnu.org --- (In reply to Stanisław Halik from comment #8) I can confirm all the code builds with LTO and -fmerge-all-constants after applying the patch. LTO with linker plugin results in unresolved symbols, but this is for another time. Best regards. Hi. Thanks for testing, I've been running regression tests and will send the patch to mailing list. Martin
[Bug debug/66482] New: ICE in gen_formal_parameter_die
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66482
Bug ID: 66482
Summary: ICE in gen_formal_parameter_die
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jay.foad at gmail dot com
Target Milestone: ---
I've just built gcc from svn r224315 on x86_64-unknown-linux-gnu. I get:
$ cat x.c
void f(int p) {}
int g() {
void f();
g();
return 0;
}
$ ~/gcc/local/bin/gcc -g -O3 -c x.c
x.c: In function 'f':
x.c:6:1: internal compiler error: in gen_formal_parameter_die, at
dwarf2out.c:17995
}
^
0x78f18e gen_formal_parameter_die
/home/jay/svn/gcc/trunk/gcc/dwarf2out.c:17994
0x7957eb gen_decl_die
/home/jay/svn/gcc/trunk/gcc/dwarf2out.c:21491
0x78f8e3 gen_subprogram_die
/home/jay/svn/gcc/trunk/gcc/dwarf2out.c:19093
0x795173 gen_decl_die
/home/jay/svn/gcc/trunk/gcc/dwarf2out.c:21402
0x7965a4 dwarf2out_decl
/home/jay/svn/gcc/trunk/gcc/dwarf2out.c:21875
0x78e9fe dwarf2out_abstract_function
/home/jay/svn/gcc/trunk/gcc/dwarf2out.c:18450
0x79515d gen_decl_die
/home/jay/svn/gcc/trunk/gcc/dwarf2out.c:21359
0x7acc5d process_scope_var
/home/jay/svn/gcc/trunk/gcc/dwarf2out.c:20960
0x7ace9b decls_for_scope
/home/jay/svn/gcc/trunk/gcc/dwarf2out.c:20988
0x7acec2 decls_for_scope
/home/jay/svn/gcc/trunk/gcc/dwarf2out.c:20999
0x7acec2 decls_for_scope
/home/jay/svn/gcc/trunk/gcc/dwarf2out.c:20999
0x78fe6f gen_subprogram_die
/home/jay/svn/gcc/trunk/gcc/dwarf2out.c:19160
0x795173 gen_decl_die
/home/jay/svn/gcc/trunk/gcc/dwarf2out.c:21402
0x7965a4 dwarf2out_decl
/home/jay/svn/gcc/trunk/gcc/dwarf2out.c:21875
0x796a1e dwarf2out_function_decl
/home/jay/svn/gcc/trunk/gcc/dwarf2out.c:21887
0x801d3f rest_of_handle_final
/home/jay/svn/gcc/trunk/gcc/final.c:4498
0x801d3f execute
/home/jay/svn/gcc/trunk/gcc/final.c:4540
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 debug/66482] [6 Regression] ICE in gen_formal_parameter_die
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66482 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0 Summary|ICE in |[6 Regression] ICE in |gen_formal_parameter_die|gen_formal_parameter_die
[Bug target/66470] [4.8/4.9/5/6 Regression] TLS ICE due to ix86_split_long_move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66470 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jun 10 09:16:16 2015 New Revision: 224320 URL: https://gcc.gnu.org/viewcvs?rev=224320root=gccview=rev Log: PR target/66470 * config/i386/i386.c (ix86_split_long_move): For collisions involving direct tls segment refs, move the UNSPEC_TP possibly wrapped in ZERO_EXTEND out of the address for lea, to each of the memory loads. * gcc.dg/tls/pr66470.c: New test. * gcc.target/i386/pr66470.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/tls/pr66470.c branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr66470.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/i386/i386.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug target/66470] [4.8/4.9/5/6 Regression] TLS ICE due to ix86_split_long_move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66470 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jun 10 09:34:21 2015 New Revision: 224322 URL: https://gcc.gnu.org/viewcvs?rev=224322root=gccview=rev Log: PR target/66470 * config/i386/i386.c (ix86_split_long_move): For collisions involving direct tls segment refs, move the UNSPEC_TP possibly wrapped in ZERO_EXTEND out of the address for lea, to each of the memory loads. * gcc.dg/tls/pr66470.c: New test. * gcc.target/i386/pr66470.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/tls/pr66470.c branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr66470.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/64650] std::experimental::bad_optional_access is not default constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64650 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Wed Jun 10 09:42:37 2015 New Revision: 224323 URL: https://gcc.gnu.org/viewcvs?rev=224323root=gccview=rev Log: Backport from mainline 2015-01-20 Jonathan Wakely jwak...@redhat.com PR libstdc++/64650 * include/experimental/optional (bad_optional_access): Add default constructor. * testsuite/experimental/optional/requirements.cc: Test for default constructor. Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/experimental/optional branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/optional/requirements.cc
[Bug bootstrap/66471] BITMAP is a reserved keyword on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66471 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Liška marxin at gcc dot gnu.org --- Fixed in 6.0.
[Bug bootstrap/66471] BITMAP is a reserved keyword on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66471 --- Comment #5 from Martin Liška marxin at gcc dot gnu.org --- Author: marxin Date: Wed Jun 10 07:57:34 2015 New Revision: 224315 URL: https://gcc.gnu.org/viewcvs?rev=224315root=gccview=rev Log: Fix BITMAP identifier clash. PR bootstrap/66471 * mem-stats-traits.h (enum mem_alloc_origin): Add _ORIGIN suffix for all enum values in mem_alloc_origin. * alloc-pool.c (dump_alloc_pool_statistics): Use newly changed enum name. * alloc-pool.h (pool_allocator::pool_allocator): Likewise. * bitmap.c (bitmap_register): Likewise. (dump_bitmap_statistics): Likewise. * ggc-common.c (dump_ggc_loc_statistics): Likewise. (ggc_record_overhead): Likewise. * hash-map.h: Likewise. * hash-set.h: Likewise. * hash-table.c (void dump_hash_table_loc_statistics): Likewise. * hash-table.h: Likewise. * vec.c (vec_prefix::register_overhead): Likewise. (vec_prefix::release_overhead): Likewise. (dump_vec_loc_statistics): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/alloc-pool.c trunk/gcc/alloc-pool.h trunk/gcc/bitmap.c trunk/gcc/ggc-common.c trunk/gcc/hash-map.h trunk/gcc/hash-set.h trunk/gcc/hash-table.c trunk/gcc/hash-table.h trunk/gcc/mem-stats-traits.h trunk/gcc/vec.c
[Bug target/66470] [4.8/4.9/5/6 Regression] TLS ICE due to ix86_split_long_move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66470 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jun 10 09:12:53 2015 New Revision: 224319 URL: https://gcc.gnu.org/viewcvs?rev=224319root=gccview=rev Log: PR target/66470 * config/i386/i386.c (ix86_split_long_move): For collisions involving direct tls segment refs, move the UNSPEC_TP possibly wrapped in ZERO_EXTEND out of the address for lea, to each of the memory loads. * gcc.dg/tls/pr66470.c: New test. * gcc.target/i386/pr66470.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tls/pr66470.c trunk/gcc/testsuite/gcc.target/i386/pr66470.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/64650] std::experimental::bad_optional_access is not default constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64650 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.3 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for 4.9.3
[Bug c++/66481] Implicit lambda capture of variable named closure causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66481 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.5 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Already fixed in the 4.8 branch, and later releases.
[Bug c++/4131] The C++ compiler doesn't place a const class object to .rodata section with non trivial constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131 --- Comment #29 from Kenneth Almquist kalmquist1 at hotmail dot com --- (In reply to Jorg Brown from comment #20) Now, the order of construction is well-defined, and that is why the program produces: podStr = '*' nonpodStr = '' That is, the nonPOD is still zero-filled when the constructor for nonpodStr runs, so nonpodStr ends up empty. Actually, looking at paragraph 2 of section 3.6.2 of the 1997 draft standard, it appears that the order of construction is not entirely well defined. Consider: extern int x, y, z; int z = y + 1; int y = x + 1; int x = 10; As I understand it, x must use static initialization for x, but has the option of using either static or dynamic initialization for y and z. Normally, variables are initialized in program order, so that z would be initialized before y. However, if the compiler choses dynamic initialization for z and static initialization for y, then z will be initialized after y. Similarly, in your example, nonpodStr could be either '' or '*'. There is one special rule in evaluating the initial value of variables when static initialization is used: If the expression contains a variable and the compiler is allowed to use dynamic initialiation for that variable and that variable is initialized later in the program then zero is used as the value of the variable. In the above example, if static initialization is used for z, the initial value will be 1, because zero will be used as the value of y when computing y + 1. On the other hand, if static initialization is used for y, the initial value of y will be 11, because the compiler is require to use static initialization for x and the rule given above doesn't apply. In short, computing the values of initializers at compile time for C++ involves a special rule which, as far as I know, doesn't apply to any other language. For that reason, it might make sense to do this calculation in the C++ front end. I think that the front end already does a bit of this, but only for expressions that are formally constant expressions.
[Bug target/66470] [4.8/4.9/5/6 Regression] TLS ICE due to ix86_split_long_move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66470 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jun 10 09:26:06 2015 New Revision: 224321 URL: https://gcc.gnu.org/viewcvs?rev=224321root=gccview=rev Log: PR target/66470 * config/i386/i386.c (ix86_split_long_move): For collisions involving direct tls segment refs, move the UNSPEC_TP possibly wrapped in ZERO_EXTEND out of the address for lea, to each of the memory loads. * gcc.dg/tls/pr66470.c: New test. * gcc.target/i386/pr66470.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/tls/pr66470.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr66470.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/i386.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/66470] [4.8/4.9/5/6 Regression] TLS ICE due to ix86_split_long_move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66470 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug libstdc++/66485] std::string single-character assignment operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66485 --- Comment #2 from Yuri Khan yurivkhan at gmail dot com --- Right, I somehow missed it. The overload is there. Sorry for the noise.
[Bug lto/66488] New: -fipa-pta -flto segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66488
Bug ID: 66488
Summary: -fipa-pta -flto segfault
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: sthalik at misaki dot pl
Target Milestone: ---
GCC from today's 5-branch segfaults on -fipa-pta -flto with the following
backtrace:
(gdb) bt full
#0 0x00432e87 in ggc_free (p=optimized out) at
../../gcc/ggc-page.c:1645
bit_offset = 4160749604
word = 4290772993
bit = 4
order = 5
size = 32
#1 0x0079b1c1 in releasebasic_block_def*, va_gc (v=@0x20a89418:
0x10afa498) at ../../gcc/vec.h:361
No locals.
#2 vec_freebasic_block_def*, va_gc (v=@0x20a89418: 0x10afa498) at
../../gcc/vec.h:608
No locals.
#3 delete_tree_cfg_annotations () at ../../gcc/tree-cfg.c:2577
No locals.
#4 0x0046ad5b in (anonymous namespace)::pass_expand::execute
(this=optimized out, fun=optimized out)
at ../../gcc/cfgexpand.c:6141
bb = optimized out
init_block = 0x0
blocks = optimized out
ei = optimized out
e = 0x0
var_ret_seq = 0x0
i = optimized out
__FUNCTION__ = execute
#5 0x006cc8a4 in execute_one_pass (pass=pass@entry=0xc3b4160) at
../../gcc/passes.c:2330
todo_after = 0
gate_status = optimized out
__FUNCTION__ = execute_one_pass
#6 0x006cccde in execute_pass_list_1 (pass=0xc3b4160,
pass@entry=0xc3b0720) at ../../gcc/passes.c:2382
No locals.
#7 0x006ccd39 in execute_pass_list (fn=0x1052de70, pass=0xc3b0720) at
../../gcc/passes.c:2393
No locals.
#8 0x0048cf47 in cgraph_node::expand (this=this@entry=0xf041000) at
../../gcc/cgraphunit.c:1895
saved_loc = 0
__FUNCTION__ = expand
#9 0x0048e212 in expand_all_functions () at
../../gcc/cgraphunit.c:2031
node = 0xf041000
order_pos = optimized out
i = optimized out
order = 0x20ffa100
expanded_func_count = 526
profiled_func_count = 2
new_order_pos = optimized out
#10 symbol_table::compile (this=0xc38c000) at ../../gcc/cgraphunit.c:2384
No locals.
#11 0x0048e41e in symbol_table::compile (this=optimized out) at
../../gcc/cgraphunit.c:2417
No locals.
#12 0x0042b329 in lto_main () at ../../gcc/lto/lto.c:3496
No locals.
#13 0x00773680 in compile_file () at ../../gcc/toplev.c:594
No locals.
#14 0x00ffc87c in do_compile () at ../../gcc/toplev.c:2076
i = 1
#15 toplev::main (this=this@entry=0xad6fe30, argc=147, argc@entry=40,
argv=0xaf49740, argv@entry=0xaf46e50)
at ../../gcc/toplev.c:2174
No locals.
#16 0x0102c4b6 in main (argc=40, argv=0xaf46e50) at ../../gcc/main.c:39
toplev = {m_use_TV_TOTAL = true, m_init_signals = true}
All CFLAGS passed are:
-flto -fuse-linker-plugin -flto-partition=none -fno-fat-lto-objects
-ftree-vectorize -ffast-math -mfpmath=both -fipa-pta -march=i686
-mtune=corei7-avx -msse -msse2 -mno-sse3 -mno-avx
[Bug lto/66488] -fipa-pta -flto segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66488 --- Comment #2 from Stanisław Halik sthalik at misaki dot pl --- No, it's invocation of today's 5-branch on my own code.
[Bug tree-optimization/60656] [4.8 regression] x86 vectorization produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60656 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #19 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug c/31893] Please provide an inout attribute for function parameters.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31893
--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Daniel Fruzynski from comment #7)
void __attribute__((const)) func(int* i)
{
*i = 44;
}
You get a warning because you marked this function const, which tells the
compiler it won't modify *i, so you lied to the compiler.
You should not be marking this function const.
[Bug lto/66488] -fipa-pta -flto segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66488 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- You mean you bootstrapped gcc 5 with -fipa-pta -flto?
[Bug rtl-optimization/66489] New: combine fails to merge insns if some are reused later on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66489
Bug ID: 66489
Summary: combine fails to merge insns if some are reused later
on
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Consider code:
int f2(int a, int b, int c, int d)
{
a = -a;
b += a * c;
c += a * d;
return b ^ c;
}
On aarch64 this could be written with to msub instructions, RTL code:
(set (reg/i:SI 0 x0)
(minus:SI
(reg:SI 1 x1 [ b ])
(mult:SI (reg:SI 0 x0 [ a ])
(reg:SI 2 x2 [ c ]
However, combine doesn't merge the neg and the multiply-adds and generates:
f2:
neg w4, w0
maddw0, w4, w2, w1
maddw3, w4, w3, w2
eor w0, w0, w3
ret
If we modify the code to only do a single multiply-accumulate:
int f2(int a, int b, int c, int d)
{
a = -a;
b += a * c;
return b;
}
Then they the expected single msub instruction is generated.
I think this is due to combine being scared of the negated 'a' being used in
two places.
[Bug middle-end/59990] [4.8 regression] incorrect memcpy optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #25 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug lto/66488] -fipa-pta -flto segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66488 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Ah, then please attach preprocessed source of the file where the crash happens.
[Bug libstdc++/66485] std::string single-character assignment operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66485 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- See (4) at http://en.cppreference.com/w/cpp/string/basic_string/operator%3D c.f. http://cplusplus.github.io/LWG/lwg-active.html#2372
[Bug rtl-optimization/64164] [4.9/5/6 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #41 from David Edelsohn dje at gcc dot gnu.org --- Created attachment 35742 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35742action=edit AIX PowerPC testcase
[Bug rtl-optimization/66489] combine fails to merge insns if some are reused later on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66489
--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org ---
For floating point, tree-ssa-math-opts.c handles the FMA and then expand is
supposed to handle the neg inside the FMA_EXPR but for some reason on this
testcase it is not.
def0 = get_def_for_expr (treeop0, NEGATE_EXPR);
/* The multiplication is commutative - look at its 2nd operand
if the first isn't fed by a negate. */
if (!def0)
{
def0 = get_def_for_expr (treeop1, NEGATE_EXPR);
/* Swap operands if the 2nd operand is fed by a negate. */
if (def0)
{
tree tem = treeop0;
treeop0 = treeop1;
treeop1 = tem;
}
}
def2 = get_def_for_expr (treeop2, NEGATE_EXPR);
op0 = op2 = NULL;
if (def0 def2
optab_handler (fnms_optab, mode) != CODE_FOR_nothing)
{
opt = fnms_optab;
op0 = expand_normal (gimple_assign_rhs1 (def0));
op2 = expand_normal (gimple_assign_rhs1 (def2));
}
else if (def0
optab_handler (fnma_optab, mode) != CODE_FOR_nothing)
{
opt = fnma_optab;
op0 = expand_normal (gimple_assign_rhs1 (def0));
}
else if (def2
optab_handler (fms_optab, mode) != CODE_FOR_nothing)
{
opt = fms_optab;
op2 = expand_normal (gimple_assign_rhs1 (def2));
}
So you are going to need to debug why expr.c is not handling this case for
floating point.
Again for integer, it is a different story. And I doubt for integer it shows
up that often and if it did, the neg could most likely schedule with some other
instruction.
[Bug c++/66490] New: [6 Regression] ICE verify_type failed for -g at tree.c:13450 (TYPE_CANONICAL is not compatible)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66490 Bug ID: 66490 Summary: [6 Regression] ICE verify_type failed for -g at tree.c:13450 (TYPE_CANONICAL is not compatible) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: alserkli at inbox dot ru Target Milestone: --- Created attachment 35741 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35741action=edit from root/core/meta/src/TClingCallFunc.cxx (commit e1ef990 in root.cern.ch/git/root.git) g++ (GCC) 6.0.0 20150610 (experimental) $ g++ -std=c++11 -g -c a.ii a.ii: In instantiation of 'class std::vectorllvm::GenericValue': a.ii:156269:29: required from here a.ii:8693:11: error: TYPE_CANONICAL is not compatible class vector : protected _Vector_base_Tp, _Alloc ^ record_type 0x7fb755369b28 GenericValue readonly type_5 type_6 VOID align 8 symtab 1348798416 alias set -1 canonical type 0x7fb755369b28 context namespace_decl 0x7fb764622c78 llvm full-name const struct llvm::GenericValue n_parents=0 use_template=0 interface-unknown pointer_to_this pointer_type 0x7fb754f5adc8 reference_to_this reference_type 0x7fb755369c78 record_type 0x7fb75506eb28 value_type readonly used type_5 type_6 VOID align 8 symtab 1348956800 alias set -1 canonical type 0x7fb755369b28 fields field_decl 0x7fb754bc9e40 IntVal type record_type 0x7fb769453690 APInt addressable asm_written needs-constructing type_1 type_4 type_5 type_6 BLK size integer_cst 0x7fb76a628ea0 constant 128 unit size integer_cst 0x7fb76a628eb8 constant 16 align 64 symtab 1684254464 alias set -1 canonical type 0x7fb769453690 fields field_decl 0x7fb76077b2f8 BitWidth context namespace_decl 0x7fb764622c78 llvm full-name class llvm::APInt needs-constructor needs-destructor X() X(constX) this=(X) sorted-fields 0x7fb76164d958 n_parents=0 use_template=0 interface-unknown pointer_to_this pointer_type 0x7fb76077db28 reference_to_this reference_type 0x7fb7693d3a80 chain type_decl 0x7fb7643ffab0 APInt decl_3 VOID file a.ii line 156268 col 9 align 1 offset_align 1 context record_type 0x7fb762977690 GenericValue chain field_decl 0x7fb754bc9980 D.707620 type union_type 0x7fb754f57930 ._295 VOID file a.ii line 156261 col 3 align 1 offset_align 1 context record_type 0x7fb762977690 GenericValue chain type_decl 0x7fb754bb2720 GenericValue context namespace_decl 0x7fb764622c78 llvm full-name const value_type n_parents=0 use_template=0 interface-unknown reference_to_this reference_type 0x7fb75506ebd0 a.ii:8693:11: internal compiler error: verify_type failed 0xf5e2f4 verify_type(tree_node const*) /gcc/gcc/tree.c:13450 0x962a74 gen_type_die_with_usage /gcc/gcc/dwarf2out.c:20653 0x9631b5 gen_type_die_with_usage /gcc/gcc/dwarf2out.c:20751 0x966057 gen_formal_types_die /gcc/gcc/dwarf2out.c:18198 0x95d4a7 gen_subprogram_die /gcc/gcc/dwarf2out.c:19055 0x96173a gen_decl_die /gcc/gcc/dwarf2out.c:21402 0x9605fa gen_member_die /gcc/gcc/dwarf2out.c:20345 0x9605fa gen_struct_or_union_type_die /gcc/gcc/dwarf2out.c:20429 0x9605fa gen_tagged_type_die /gcc/gcc/dwarf2out.c:20630 0x963545 gen_type_die_with_usage /gcc/gcc/dwarf2out.c:20792 0x96146e gen_decl_die /gcc/gcc/dwarf2out.c:21425 0x96228c dwarf2out_decl /gcc/gcc/dwarf2out.c:21875 0x96260b dwarf2out_type_decl /gcc/gcc/dwarf2out.c:21585 0xc0544f rest_of_type_compilation(tree_node*, int) /gcc/gcc/passes.c:351 0x697cf3 finish_struct_1(tree_node*) /gcc/gcc/cp/class.c:6714 0x66974f instantiate_class_template_1 /gcc/gcc/cp/pt.c:9625 0x66974f instantiate_class_template(tree_node*) /gcc/gcc/cp/pt.c:9665 0x704ceb complete_type(tree_node*) /gcc/gcc/cp/typeck.c:140 0x609b6b grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*, decl_context, int, tree_node**) /gcc/gcc/cp/decl.c:10790 0x6a9cd6 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*, bool, tree_node*, tree_node*) /gcc/gcc/cp/decl2.c:879 compiles OK without -g
[Bug rtl-optimization/66489] combine fails to merge insns if some are reused later on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66489 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This was the reason why the pass on the tree level to fused multiply add was added. Maybe we can do the same. Do you know how often this shows up?
[Bug rtl-optimization/66489] combine fails to merge insns if some are reused later on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66489 --- Comment #2 from ktkachov at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) This was the reason why the pass on the tree level to fused multiply add was added. Maybe we can do the same. Do you know how often this shows up? My understanding is that it occurs in SPEC2006 and leslie3d in particular, but with FP code there (just substitute int for double in the testcase and pick something other than eor). Don't have any numbers on how often or how much of a bottleneck it is to performance...
[Bug rtl-optimization/64164] [4.9/5/6 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #42 from David Edelsohn dje at gcc dot gnu.org --- Created attachment 35743 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35743action=edit PPC64LE Linux Testcase
[Bug c++/66490] [6 Regression] ICE verify_type failed for -g at tree.c:13450 (TYPE_CANONICAL is not compatible)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66490 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- dup. *** This bug has been marked as a duplicate of bug 66214 ***
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||alserkli at inbox dot ru --- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 66490 has been marked as a duplicate of this bug. ***
[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66303 stli at linux dot vnet.ibm.com stli at linux dot vnet.ibm.com changed: What|Removed |Added CC||stli at linux dot vnet.ibm.com --- Comment #11 from stli at linux dot vnet.ibm.com stli at linux dot vnet.ibm.com --- I have created a bug in glibc https://sourceware.org/bugzilla/show_bug.cgi?id=18508 and posted a patch (https://www.sourceware.org/ml/libc-alpha/2015-06/msg00324.html) which omits the cfi_startproc/cfi_endproc directives for __makecontext_ret. Thus backtrace do not find any information about __makecontext_ret in .eh_frame and stops backtrace like it is done with _start and thread_start functions.
[Bug middle-end/66375] [4.8/4.9/5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66375 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||6.0 Summary|[4.8/4.9/5/6 Regression]|[4.8/4.9/5 Regression] |wrong code at -O2 and -O3 |wrong code at -O2 and -O3 |on x86_64-linux-gnu |on x86_64-linux-gnu Known to fail||5.1.0 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- Thanks, I am going to do another round of backporting today or tomorrow.
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #15 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Created attachment 35745 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35745action=edit test case pr66193_3_diverse_new.f90 Better test, replaces pr66193_3_diverse.f90
[Bug rtl-optimization/47582] Combine chains of movl into movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47582 --- Comment #2 from Tony Poppleton tony.poppleton at gmail dot com --- Re-testing this with GCC 5.1, the code appears to be even less efficient, for both cases; DM1: .LFB0: .cfi_startproc movss b(%rip), %xmm0 xorl%eax, %eax movss %xmm0, a(%rip) movss b+4(%rip), %xmm0 movss %xmm0, a+4(%rip) movss b+8(%rip), %xmm0 movss %xmm0, a+8(%rip) movss b+12(%rip), %xmm0 movss %xmm0, a+12(%rip) movss b+16(%rip), %xmm0 movss %xmm0, a+16(%rip) ret .cfi_endproc .LFB0: .cfi_startproc movqb(%rip), %rax movq%rax, a(%rip) movqb+8(%rip), %rax movq%rax, a+8(%rip) movlb+16(%rip), %eax movl%eax, a+16(%rip) xorl%eax, %eax ret .cfi_endproc Why is the xorl appearing in both cases? Should this be logged as a separate bug. Incidentally, compiling with -O1 produces the same code as -O2 on older GCCs (as in the description comment above) My total guess is it is due to a and b not having any initial values, and an optimization that takes into account value ranges is getting confused?
[Bug rtl-optimization/61047] [4.9/5/6 Regression] wrong code at -O1 on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047 --- Comment #23 from Bernd Edlinger bernd.edlinger at hotmail dot de --- sorry, which patch are we discussing here?
[Bug other/66496] New: Static hash_map causes segfault in static constructor of the compiler compilation unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66496 Bug ID: 66496 Summary: Static hash_map causes segfault in static constructor of the compiler compilation unit Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux-gnu Target: x86_64-linux-gnu If you define a static (non-pointer) hash_map in any gcc *.c source code file, for example like this: --- a/gcc/ipa-cp.c +++ b/gcc/ipa-cp.c @@ -139,6 +139,8 @@ along with GCC; see the file COPYING3. If not see #include ipa-inline.h #include ipa-utils.h +static hash_map tree, uint32_t some_hash_map; + template typename valtype class ipcp_value; /* Describes a particular source for an IPA-CP value. */ ligcc will not compile, because the compiler crashes even when compiling an empty main function. Specifically, it segfaults in the static constructor of the unit where you defined the hash_map: (gdb) bt #0 hash_tablehash_mapmem_location*, mem_usage*, mem_alloc_descriptionmem_usage::mem_alloc_hashmap_traits::hash_entry, xcallocator::find_with_hash (this=this@entry=0x0, comparable=@0x7fffe000: 0x1bdc090, hash=2852224967) at /home/mjambor/gcc/small/src/gcc/hash-table.h:1012 #1 0x009f5931 in get (k=@0x7fffe000: 0x1bdc090, this=0x0) at /home/mjambor/gcc/small/src/gcc/hash-map.h:148 #2 register_descriptor (location=0x1bdc090, ptr=0x1bc4020 some_hash_map, this=optimized out) at /home/mjambor/gcc/small/src/gcc/mem-stats.h:391 #3 register_descriptor (function=0x0, line=0, filename=0x0, ggc=optimized out, origin=optimized out, ptr=0x1bc4020 some_hash_map, this=optimized out) at /home/mjambor/gcc/small/src/gcc/mem-stats.h:425 #4 hash_tablehash_maptree_node*, unsigned int, default_hashmap_traits::hash_entry, xcallocator::hash_table (this=0x1bc4020 some_hash_map, size=13, ggc=optimized out, gather_mem_stats=optimized out, origin=optimized out) at /home/mjambor/gcc/small/src/gcc/hash-table.h:798 #5 0x00598470 in hash_map (gather_mem_stats=true, ggc=false, n=13, this=0x1bc4020 some_hash_map) at /home/mjambor/gcc/small/src/gcc/hash-map.h:117 #6 __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/mjambor/gcc/small/src/gcc/ipa-cp.c:142 #7 _GLOBAL__sub_I_ipcp_cst_values_pool () at /home/mjambor/gcc/small/src/gcc/ipa-cp.c:4600 #8 0x012263ed in __libc_csu_init (argc=2, argv=0x7fffe198, envp=0x7fffe1b0) at elf-init.c:88 #9 0x76e4da95 in __libc_start_main () from /lib64/libc.so.6 #10 0x005989d7 in _start () at ../sysdeps/x86_64/start.S:122 I know that use of static hash_maps is unlikely to be a good idea, but it still should not crash.
[Bug c/31893] Please provide an inout attribute for function parameters.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31893 --- Comment #9 from Daniel Fruzynski bugzi...@poradnik-webmastera.com --- My bad, now I see my error. What do you think about adding this new attribute to mark function arguments as out only? I think it would allow to eliminate more dead or unnecessary code (e.g. when value is assigned to variable, and then address of this variable is passed as out argument), plus print warnings like 'not all paths assigns value to out argument' or 'value of out argument is read'.
[Bug c++/66484] Exception specification can declare a pointer to incomplete type, which is against C++ standard section 15.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66484 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-10 Ever confirmed|0 |1
[Bug rtl-optimization/61047] [4.9/5/6 Regression] wrong code at -O1 on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047 --- Comment #21 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I think that the patch is clear in scope, only fixes a specific case unless rtx_addr_can_trap_p_1() was refactored, it should be feasible to apply to trunk, 5.1 and 4.9. No, the patch is way too risky and will very likely introduce more bugs than it fixes, let alone performance regressions. There are dozens of open PRs reported for real-life software that need to be fixed, but this one is _not_ one of them.
[Bug rtl-optimization/61047] [4.9/5/6 Regression] wrong code at -O1 on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047 --- Comment #24 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I agree that this is too risky to backport, but I disagree with the decision not to fix it on the trunk. We have plenty of time to watch for performance regressions and/or bugs it introduces there, and even if this bug is only hit by machine generated code, it would be helpful to all the people that try to report bugs against gcc if they wouldn't have to analyze and then ignore similar cases every few days because we chose to never fix it on the gcc side. As far as I know all the people is just one guy submitting machine-generated testcases and repeatedly running into the issue. I suspended the PR because nobody else reported it, in particular on real-life software. IMO there are far more pressing issues to be addressed than this one. That being said, if you feel strongly about it, then go ahead, I won't oppose.
[Bug fortran/66494] New: ICE on using same name for embedded subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66494 Bug ID: 66494 Summary: ICE on using same name for embedded subroutine Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This ambiguous code ... recursive subroutine s call s contains subroutine s end end yields (with gfortran 5.1.1, 4.9.0, 4.8.3 on SUSE Linux 13.2, 64 bit) internal compiler error: in gfc_generate_function_code, at fortran/trans-decl.c:5722 --- Same issue for this reduction ... subroutine s contains subroutine s end end
[Bug target/66491] x86_64 target cross-compiler generates stack protector code unsuitable for the Linux kernel if the compiler wasn't built against a C library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66491 --- Comment #1 from dhowells at redhat dot com dhowells at redhat dot com --- Configured with: CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \ CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \ AR_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/x86_64-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/x86_64-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/x86_64-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/x86_64-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ranlib \ READELF_FOR_TARGET=/usr/bin/x86_64-linux-gnu-readelf \ STRIP_FOR_TARGET=/usr/bin/x86_64-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/x86_64-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/x86_64-linux-gnu-windmc \ LDFLAGS='-Wl,-z,relro ' \ ../gcc-5.1.1-20150422/configure --bindir=/usr/bin --build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libunwind-exceptions --disable-nls --disable-plugin --disable-shared --disable-silent-rules --disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/x86_64-linux-gnu-ld --enable-__cxa_atexit --enable-checking=release --enable-gnu-indirect-function --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id --enable-nls --enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --prefix=/usr --program-prefix=x86_64-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc --target=x86_64-linux-gnu --with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-default-libstdcxx-abi=c++98 --with-isl --with-linker-hash-style=gnu --with-newlib --with-sysroot=/usr/x86_64-linux-gnu/sys-root --with-system-libunwind --with-system-zlib --without-headers Built with: AR_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/x86_64-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/x86_64-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/x86_64-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/x86_64-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ranlib \ READELF_FOR_TARGET=/usr/bin/x86_64-linux-gnu-readelf \ STRIP_FOR_TARGET=/usr/bin/x86_64-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/x86_64-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/x86_64-linux-gnu-windmc \ make -C x86_64-linux-gnu -j5 tooldir=/usr all-gcc make -C x86_64-linux-gnu DESTDIR=/home/dhowells/rpmbuild/BUILDROOT/cross-gcc-5.1.1-2.fc22.x86_64 install-gcc install-target-libgcc The binutils was 2.25 cross-compiled for x86_64.
[Bug libstdc++/66492] New: std::messageswchar_t unsafe and inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66492 Bug ID: 66492 Summary: std::messageswchar_t unsafe and inefficient Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- The following observations were made in a private conversation with jwak...@redhat.com, after reading the libstdc++ implementation of the messageswchar_t facet. Jonathan asked me to open a bug for the record. I have no test case and not all the points may be accurate or even correct. The messageswchar_t facet in libstdc++ looks like it could be improved. AFAICS, it does three codeset conversions: 1) one in libc (induced by bind_textdomain_codeset), 2) another in do_get to convert the default string to the external encoding (this seems entirely unnecessary), and 3) finally one of the libc text to the internal encoding (this one is unavoidable). It's not clear to me that (1) will do the right thing when the locale argument to messageswchar_t::open has a user-defined codecvt facet. (3) doesn't seem to handle codeset conversion errors correctly (even though the standard doesn't require it, it should probably return the default string instead of an empty or truncated string). Using alloca for what's essentially user-controlled strings also seems risky.
[Bug fortran/66493] New: ICE on alternate return argument for typebound procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66493 Bug ID: 66493 Summary: ICE on alternate return argument for typebound procedure Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This code with an alternate return argument (*) seems to be improper : module p type t contains procedure :: s end type contains subroutine s(*) end end module and yields (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit) : f951: internal compiler error: in resolve_typebound_procedure, at fortran/resolve.c:12210
[Bug fortran/66495] New: [5 Regression] Issue with same name for embedded function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66495 Bug ID: 66495 Summary: [5 Regression] Issue with same name for embedded function Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Another test case : integer function f() contains integer function f() end end yields (gfortran 5.1.1) : f951: internal compiler error: Segmentation fault --- But prints a regular error message with gfortran 4.9.0, 4.8.3 : $ gfortran -c -g -O0 -Wall -fcheck=all -fno-frontend-optimize s.f90 s.f90:3.21: integer function f(y) 1 s.f90:1.18: integer function f(x) 2 Error: Procedure 'f' at (1) has an explicit interface and must not have attributes declared at (2) s.f90:3.24: integer function f(y) 1 Error: Symbol 'f' at (1) already has basic type of INTEGER
[Bug rtl-optimization/47582] Combine chains of movl into movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47582 --- Comment #3 from Tony Poppleton tony.poppleton at gmail dot com --- Ignore the last comment - hadn't spotted the int return value on main... So the code is actually more correct than previous versions, and no change to the status of this bug.
[Bug target/66491] x86_64 target cross-compiler generates stack protector code unsuitable for the Linux kernel if the compiler wasn't built against a C library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66491 --- Comment #2 from dhowells at redhat dot com dhowells at redhat dot com --- Possibly -mcmodel=kernel shouldn't be overloaded, but -fstack-protector should be - perhaps to have a -fstack-protector-gs option or similar.
[Bug rtl-optimization/61047] [4.9/5/6 Regression] wrong code at -O1 on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047 --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Eric Botcazou from comment #21) I think that the patch is clear in scope, only fixes a specific case unless rtx_addr_can_trap_p_1() was refactored, it should be feasible to apply to trunk, 5.1 and 4.9. No, the patch is way too risky and will very likely introduce more bugs than it fixes, let alone performance regressions. There are dozens of open PRs reported for real-life software that need to be fixed, but this one is _not_ one of them. I agree that this is too risky to backport, but I disagree with the decision not to fix it on the trunk. We have plenty of time to watch for performance regressions and/or bugs it introduces there, and even if this bug is only hit by machine generated code, it would be helpful to all the people that try to report bugs against gcc if they wouldn't have to analyze and then ignore similar cases every few days because we chose to never fix it on the gcc side.
[Bug lto/66488] -fipa-pta -flto segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66488 --- Comment #4 from Stanisław Halik sthalik at misaki dot pl --- Line information: ../modules/imgproc/src/filter.cpp: In member function 'operator()': ../modules/imgproc/src/filter.cpp:3084:10: internal compiler error: Segmentation fault This is: templatetypename ST, typename DT, class VecOp struct RowFilter : public BaseRowFilter Attaching the file.
[Bug lto/66488] -fipa-pta -flto segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66488 --- Comment #5 from Stanisław Halik sthalik at misaki dot pl --- Created attachment 35746 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35746action=edit preprocessed filter.cpp
[Bug target/66474] Document the use of %x in powerpc asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66474 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Wed Jun 10 16:51:49 2015 New Revision: 224332 URL: https://gcc.gnu.org/viewcvs?rev=224332root=gccview=rev Log: 2015-06-10 Michael Meissner meiss...@linux.vnet.ibm.com PR target/66474 * doc/md.texi (Machine Constraints): Document that on the PowerPC if you use a constraint that targets a VSX register, you must use %xn in the template. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/md.texi
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
Aldy Hernandez aldyh at gcc dot gnu.org changed:
What|Removed |Added
Attachment #35734|0 |1
is obsolete||
--- Comment #17 from Aldy Hernandez aldyh at gcc dot gnu.org ---
Created attachment 35744
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35744action=edit
Call check_die on type DIEs and avoid DW_AT_aritificial attribs
On 06/10/2015 04:01 AM, iains at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
--- Comment #15 from Iain Sandoe iains at gcc dot gnu.org ---
(In reply to Aldy Hernandez from comment #14)
Created attachment 35734 [details]
Patch to ICE on other duplicate DW_AT_ attributes
I can't reproduce any of these with a cross compiler. I'm building a cross
with:
--enable-languages=c,c++ --disable-bootstrap --disable-multilib
--target=i686-darwin
The triple for the platform I'm testing on is : x86_64-apple-darwin12
As a side note, if *-apple-darwin{10,12} is the more common variant (as opposed
to *-apple-darwin which uses stabs), may I suggest speaking with the SC to put
a more recent darwin on the secondary platform list instead of
i686-apple-darwin which is stabs (and nobody cares bout stabs ;-)).
...but I still can't get cc1plus to trigger any ICE with the attached patch.
me neither - nevertheless...
Well, I was testing stabs apparently, but even so, the reason why the ICE did
not trigger was because the duplicate attributes appear on a type DIE, not a
decl DIE. I was able to reproduce by looking at the assembly.
I added a check for type DIEs and found a slew of problems on Linux as well.
It seems the Linux linker is far more permissive wrt dwarf. The attached patch
fixes all the problems you reported that I could reproduce with a cross
compiler for x86_64-apple-darwin10. It also passes bootstrap and tests on
x86-64 Linux.
Could you test it properly on darwin?
[Bug rtl-optimization/61047] [4.9/5/6 Regression] wrong code at -O1 on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047
Bernhard Kaindl bernhard.kaindl at thalesgroup dot com changed:
What|Removed |Added
CC||bernhard.kaindl@thalesgroup
||.com
--- Comment #20 from Bernhard Kaindl bernhard.kaindl at thalesgroup dot com
---
For people reviewing this, I want to summarize:
Eric submitted a fix for this and explains it [required read]:
https://gcc.gnu.org/ml/gcc-patches/2014-03/msg01200.html
The archive has no objections and Richard Biener said:
Looks reasonable to me.
The basic bug is that gcc does not eliminate the load of e[2837] (which is dead
code) right way - which may never be reached since b is limited to 2:
for (; b 2; b++)
{
a = 0;
if (b == 2837)
a = e[b];
As written in Comment 3:
Note how the load at insn 28 is guarded by comparing ax against #2837. CE3
transforms that into an unconditional load and we blow up reading the
out-of-range stack slot.
As far as I understand: The patch fixes a bug in rtx_addr_can_trap_p_1() which
is called to check if an access can trap, where the bug is that
rtx_addr_can_trap_p_1() does not take the offset of the object (in this case
e[2837]) into account, and returns the info that the access is safe, which it
is not, because it is out of bounds (and out of the stack too)
The patch only fixes the wrong information returned by this function that the
access is safe by returning 1 when the offset causes the access to be outside
of the stack.
So this patch fixes a clear bug which leads to wrong code generated by gcc.
I think that the patch is clear in scope, only fixes a specific case unless
rtx_addr_can_trap_p_1() was refactored, it should be feasible to apply to
trunk, 5.1 and 4.9.
[Bug middle-end/66253] [6 Regression] 459.GemsFDTD in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66253 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from Michael Matz matz at gcc dot gnu.org --- miscompilation must be somewhere in NFT.fppized.
[Bug fortran/66494] [4.9/5/6 Regression] ICE on using same name for embedded subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66494 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-10 Summary|ICE on using same name for |[4.9/5/6 Regression] ICE on |embedded subroutine |using same name for ||embedded subroutine Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- The ICE appeared between revisions r159106 (2010-05-06, no ICE) and r161462 (2010-06-27).
[Bug target/66474] Document the use of %x in powerpc asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66474 --- Comment #4 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Wed Jun 10 17:15:58 2015 New Revision: 224334 URL: https://gcc.gnu.org/viewcvs?rev=224334root=gccview=rev Log: 2015-06-10 Michael Meissner meiss...@linux.vnet.ibm.com Backport from mainline: 2015-06-10 Michael Meissner meiss...@linux.vnet.ibm.com PR target/66474 * doc/md.texi (Machine Constraints): Document that on the PowerPC if you use a constraint that targets a VSX register, you must use %xn in the template. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/doc/md.texi
[Bug rtl-optimization/66489] combine fails to merge insns if some are reused later on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66489 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #4 from Segher Boessenkool segher at gcc dot gnu.org --- Combine does not do this because it would need to combine 2 insns into 2. This *can* be safely done (carefully). As a result combine can do more work (which is good), but lifetime of registers can get longer too (but also shorter in some cases). I don't yet know if it is a win on average. diff --git a/gcc/combine.c b/gcc/combine.c index 9861291..599d383 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -3992,8 +3992,8 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1, rtx_insn *i0, XVECLEN (newpat, 0) == 2 GET_CODE (XVECEXP (newpat, 0, 0)) == SET GET_CODE (XVECEXP (newpat, 0, 1)) == SET - (i1 || set_noop_p (XVECEXP (newpat, 0, 0)) - || set_noop_p (XVECEXP (newpat, 0, 1))) +// (i1 || set_noop_p (XVECEXP (newpat, 0, 0)) +// || set_noop_p (XVECEXP (newpat, 0, 1))) GET_CODE (SET_DEST (XVECEXP (newpat, 0, 0))) != ZERO_EXTRACT GET_CODE (SET_DEST (XVECEXP (newpat, 0, 0))) != STRICT_LOW_PART GET_CODE (SET_DEST (XVECEXP (newpat, 0, 1))) != ZERO_EXTRACT
[Bug fortran/66495] [5 Regression] Issue with same name for embedded function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66495 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||4.9.2, 6.0 Keywords||error-recovery, ||ice-on-invalid-code Last reconfirmed||2015-06-10 CC||burnus at gcc dot gnu.org, ||manu at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||5.1.0 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- The ICE appeared between revisions r218570 (2014-12-10, no ICE) and r218658 (2014-12-12, ICE), likely r218627 (pr44054) or a related commit. This has been fixed between r223447 (2015-05-20, ICE) and r224148 (2015-06-05, no ICE), likely r223614.
[Bug fortran/66480] FPE calling cpu_time() with -ffpe-trap=inexact
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66480 --- Comment #6 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Wed, Jun 10, 2015 at 05:20:58PM +, nicolasbock at gmail dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66480 --- Comment #5 from Nicolas Bock nicolasbock at gmail dot com --- Thanks for the comments. I should have understood this exception better before posting this as a bug. We would rather see a bug report and then simply close it than to get no bug reports at all. It is unlikely that one can avoid an inexact FPE in code involving floating point unless the algorithm is specifically designed to avoid it.
[Bug c++/66484] Exception specification can declare a pointer to incomplete type, which is against C++ standard section 15.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66484 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- This could be a possible compiler extension and you get a warning when using it. What I consider as a defect is that it's not an error even when -pedantic is activated.
