[Bug target/64215] -Os misses an opportunity to merge two ret instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64215 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Reproduced with the trunk too. The problem is that during cross-jumping (the jump2 pass), this isn't cheaply cross-jumpable, as the simple_return just using earlier computed %eax comes before the bb with setting %eax to -1 and doing simple_return (so in that case it would be replacement of simple_return with conditional jump, where the conditional jump is larger). It is only in the basic block reordering pass that this is swapped, but that is too late, we don't have any further crossjumping pass.
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888 --- Comment #13 from Yury Gribov y.gribov at samsung dot com --- (In reply to Kostya Serebryany from comment #12) But for this example in C the globals will not get instrumented, unless -fno-common is given. BTW I think everyone already pairs this with -fsanitize=address, otherwise sanitization of globals becomes so weak. If LLVM uses global symbols instead of local aliases, it is more expensive. You can have aliases/weakrefs etc. to symbols, and those still aren't ODR violations. But these again should not be instrumented by asan at all. No? Wouldn't that cause false negatives for internal references to local aliases? Never seen a case like this (registered multiple times for multiple addresses). Can you give an example? How about this: say some global variable xyz is defined both in executable and in shared library. Now 1) if xyz isn't exported from executable, it will not be available to shlib; so exe's internal references will bind to exe's definition but shlib's references will bind to shlib's definition 2) if xyz is exported from executable but shlib is linked with -Bsymbolic, shlib's internal references will bind to shlib's implementation 3) RTLD_DEEPBIND could also alter symbol resolution order in a shlib
[Bug ipa/64218] New: ICE during compilation with -fno-rtti -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64218 Bug ID: 64218 Summary: ICE during compilation with -fno-rtti -O3 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: antoshkka at gmail dot com Following error occurred during compilation of one of the Boost's tests: ../libs/variant/test/recursive_variant_test.cpp:315:1: internal compiler error: Segmentation fault } ^ 0xc9658f crash_signal ?../../gcc/gcc/toplev.c:358 0x8d4280 symtab_node::get_alias_target() ?../../gcc/gcc/cgraph.h:2242 0x8d4280 symtab_node::ultimate_alias_target(availability*) ?../../gcc/gcc/symtab.c:1292 0x12a3b33 cgraph_node::ultimate_alias_target(availability*) ?../../gcc/gcc/cgraph.h:2684 0x12a3b33 want_inline_function_to_all_callers_p ?../../gcc/gcc/ipa-inline.c:840 0x12a3b33 ipa_inline ?../../gcc/gcc/ipa-inline.c:2245 0x12a3b33 execute ?../../gcc/gcc/ipa-inline.c:2558 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. Code was compiled with the following flags: g++ -ftemplate-depth-128 -fno-rtti -O3 -finline-functions -Wno-inline -Wall -fPIC -std=c++11 -march=native -DBOOST_ALL_NO_LIB=1 -DBOOST_NO_RTTI -DBOOST_NO_TYPEID -DNDEBUG -I.. -c -o /home/trippels/results/boost/bin.v2/libs/variant/test/variant_no_rtti_test.test/gcc-5.0.0/release/pch-off/rtti-off/recursive_variant_test.o ../libs/variant/test/recursive_variant_test.cpp Sources can be seen here: https://github.com/boostorg/variant/blob/develop/test/recursive_variant_test.cpp#L315 Exactly the same test compile and pass OK if rtti is on. P.S.: Sorry for no preprocessed and minimized code, I have no access to 5.0.0. I'm trying to contact the test runner, but no success at this point.
[Bug ipa/64218] ICE during compilation with -fno-rtti -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64218 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- The test runner is me. I must have overlooked this ICE in the hundreds of similar ICEs due to PR1558.
[Bug ipa/64218] ICE during compilation with -fno-rtti -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64218 --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- I meant PR61558.
[Bug c++/64216] Function template can access private sub class without being friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64216 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-12-08 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Almost certainly a duplicate of one of the bugs linked to PR59002, it looks nearly identical to PR41437
[Bug libgcj/64219] New: Rename libgcj-5.0.pc to libgcj-5.pc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64219 Bug ID: 64219 Summary: Rename libgcj-5.0.pc to libgcj-5.pc Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj Assignee: unassigned at gcc dot gnu.org Reporter: gcc at ryandesign dot com gcc 4.9.2 installs the file libgcj-4.9.pc. gcc 5-20141130 installs the file libgcj-5.0.pc. Given the change to the gcc version numbering scheme starting with version 5, shouldn't the file be called libgcj-5.pc?
[Bug ipa/64218] [5 Regression] ICE: Segmentation fault (symtab_node::get_alias_target()) running Boost testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64218 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 Target Milestone|--- |5.0 Summary|ICE during compilation with |[5 Regression] ICE: |-fno-rtti -O3 |Segmentation fault ||(symtab_node::get_alias_tar ||get()) running Boost ||testsuite Ever confirmed|0 |1 --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Reducing...
[Bug tree-optimization/14541] [tree-ssa] built-in math functions are not fully optimized at tree level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14541 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #19 from ktkachov at gcc dot gnu.org --- (In reply to Richard Biener from comment #18) Author: rguenth Date: Wed Dec 3 11:55:14 2014 New Revision: 218308 URL: https://gcc.gnu.org/viewcvs?rev=218308root=gccview=rev Log: 2014-12-03 Richard Biener rguent...@suse.de PR middle-end/14541 * builtins.c (fold_builtin_logarithm): Implement simplifications ... * match.pd: ... here as patterns. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/match.pd With this commit the builtin-explog-1.c test stops folding the builtins on aarch64 (and consequently FAILs)
[Bug c++/64216] Function template can access private sub class without being friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64216 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Definitely a dup *** This bug has been marked as a duplicate of bug 41437 ***
[Bug c++/41437] No access control for classes in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||yyc1992 at gmail dot com --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 64216 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/14541] [tree-ssa] built-in math functions are not fully optimized at tree level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14541 --- Comment #20 from rguenther at suse dot de rguenther at suse dot de --- On Mon, 8 Dec 2014, ktkachov at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14541 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #19 from ktkachov at gcc dot gnu.org --- (In reply to Richard Biener from comment #18) Author: rguenth Date: Wed Dec 3 11:55:14 2014 New Revision: 218308 URL: https://gcc.gnu.org/viewcvs?rev=218308root=gccview=rev Log: 2014-12-03 Richard Biener rguent...@suse.de PR middle-end/14541 * builtins.c (fold_builtin_logarithm): Implement simplifications ... * match.pd: ... here as patterns. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/match.pd With this commit the builtin-explog-1.c test stops folding the builtins on aarch64 (and consequently FAILs) Which one exactly? That is, what is the failing link output?
[Bug tree-optimization/14541] [tree-ssa] built-in math functions are not fully optimized at tree level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14541 --- Comment #21 from ktkachov at gcc dot gnu.org --- Created attachment 34215 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34215action=edit Link errors output for aarch64 Which one exactly? That is, what is the failing link output? All of them AFAICS. I'm attaching the link failures log. The test PASSes at -O2 -flto and -O2 -flto -flto-partition=none but FAILs on all other torture options
[Bug preprocessor/64220] New: gcc preprocessor defines outside of the reserved namespace: unix linux AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64220 Bug ID: 64220 Summary: gcc preprocessor defines outside of the reserved namespace: unix linux AVR Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: cameron at tacklind dot com The preprocessor defines names outside of the reserved namespace. Essentially, if I'm not mistaken, the following command should output nothing # gcc -dM -E - /dev/null | grep -v '^#define _[_A-Z]' However, for historical reasons, the preprocessor defines things like unix and linux or AVR (with avr-gcc). I'm sure other show up on other systems that I have not tested. This has been referenced slightly in #2069, but the solution there was to just manually un-define (-U) the extra define. (Which I'll do if I have to) This is also talked about briefly in the documentation where it suggest better alternatives like __unix__ et al. It even says The C standard requires that all system-specific macros be part of the reserved namespace. https://gcc.gnu.org/onlinedocs/cpp/System-specific-Predefined-Macros.html Could these defines outside of the reserved namespace be removed? Or deprecated now (if they aren't already?) and removed in 5.0? Or are those defines here to stay for historical reasons?
[Bug bootstrap/64197] [5 regression] SPARC bootstrap broken: SEGV in tree_estimate_loop_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64197 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Rainer Orth ro at gcc dot gnu.org --- It was indeed: applying Martin's patch restored bootstrap. Thanks for the hin. Rainer *** This bug has been marked as a duplicate of bug 64192 ***
[Bug ipa/64192] [5 Regression] r218369 causes some regressions with -m32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64192 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #8 from Rainer Orth ro at gcc dot gnu.org --- *** Bug 64197 has been marked as a duplicate of this bug. ***
[Bug sanitizer/61591] Undefined behavior sanitizer does not catch builtin_unreachable's from impossible devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61591 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- It appears that devirt changes _4 = this_1(D)-D.2680; OBJ_TYPE_REF(_3;(struct top)_4-0) (_4); into _4 = this_1(D)-D.2680; __builtin_unreachable (_4); but __builtin_unreachable shouldn't have any arguments! Consequently, we fail to sanitize this builtin call, because we call gimple_call_builtin_p on that __builtin_unreachable (_4) stmt, but gimple_call_builtin_p checks gimple_builtin_call_types_compatible_p and that is false, because the arguments don't match. So - is the __builtin_unreachable with an argument expected?
[Bug sanitizer/61591] Undefined behavior sanitizer does not catch builtin_unreachable's from impossible devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61591
--- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org ---
And if it is:
diff --git a/gcc/sanopt.c b/gcc/sanopt.c
index ce9fbcf..77b88f7 100644
--- a/gcc/sanopt.c
+++ b/gcc/sanopt.c
@@ -646,20 +646,21 @@ pass_sanopt::execute (function *fun)
break;
}
}
- else if (gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
+ else
{
tree callee = gimple_call_fndecl (stmt);
- switch (DECL_FUNCTION_CODE (callee))
-{
-case BUILT_IN_UNREACHABLE:
- if (flag_sanitize SANITIZE_UNREACHABLE
- !lookup_attribute (no_sanitize_undefined,
-DECL_ATTRIBUTES (fun-decl)))
-no_next = ubsan_instrument_unreachable (gsi);
- break;
-default:
- break;
-}
+ if (callee DECL_BUILT_IN_CLASS (callee) == BUILT_IN_NORMAL)
+switch (DECL_FUNCTION_CODE (callee))
+ {
+ case BUILT_IN_UNREACHABLE:
+if (flag_sanitize SANITIZE_UNREACHABLE
+ !lookup_attribute (no_sanitize_undefined,
+ DECL_ATTRIBUTES (fun-decl)))
+ no_next = ubsan_instrument_unreachable (gsi);
+break;
+ default:
+break;
+ }
}
if (dump_file (dump_flags TDF_DETAILS))
[Bug sanitizer/61591] Undefined behavior sanitizer does not catch builtin_unreachable's from impossible devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61591 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- I think it is a gimple-fold/ipa-devirt etc. bug. __builtin_unreachable doesn't have any arguments, so pretending it has is broken and also a missed optimization, in the IL we think those arguments are used when they aren't. So IMNSHO we should just never generate such bogus __builtin_unreachable calls.
[Bug testsuite/64221] New: contrib/compare_tests confused by c-c++-common/ubsan/shift-5.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64221 Bug ID: 64221 Summary: contrib/compare_tests confused by c-c++-common/ubsan/shift-5.c Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Comparing a log file to itself fails. I already had to use compare_tests for each sum file separately, since, when I enable all languages, trying to use it on the whole tree gives: $ /data/repos/gcc/trunk/contrib/compare_tests /tmp/testgcc/pristine /tmp/testgcc/pristine [...] comm: file 2 is not in sorted order comm: file 1 is not in sorted order comm: file 2 is not in sorted order New tests that FAIL: [many many lines] comm: file 1 is not in sorted order Old tests that failed, that have disappeared: (Eeek!) [the same many many lines] But now it is getting close to useless: $ /data/repos/gcc/trunk/contrib/compare_tests /tmp/testgcc/pristine/build/gcc/testsuite/gcc/gcc.sum /tmp/testgcc/pristine/build/gcc/testsuite/gcc/gcc.sum Tests that now fail, but worked before: c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 11) c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 14) c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 17) c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 20) c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 34) c-c++-common/ubsan/shift-5.c -O0 (test for errors, line 37) c-c++-common/ubsan/shift-5.c -O1 (test for errors, line 11) c-c++-common/ubsan/shift-5.c -O1 (test for errors, line 14) c-c++-common/ubsan/shift-5.c -O1 (test for errors, line 17) c-c++-common/ubsan/shift-5.c -O1 (test for errors, line 20) c-c++-common/ubsan/shift-5.c -O1 (test for errors, line 34) c-c++-common/ubsan/shift-5.c -O1 (test for errors, line 37) c-c++-common/ubsan/shift-5.c -O2 (test for errors, line 11) c-c++-common/ubsan/shift-5.c -O2 (test for errors, line 14) c-c++-common/ubsan/shift-5.c -O2 (test for errors, line 17) c-c++-common/ubsan/shift-5.c -O2 (test for errors, line 20) c-c++-common/ubsan/shift-5.c -O2 (test for errors, line 34) c-c++-common/ubsan/shift-5.c -O2 (test for errors, line 37) c-c++-common/ubsan/shift-5.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for errors, line 11) c-c++-common/ubsan/shift-5.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for errors, line 14) c-c++-common/ubsan/shift-5.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for errors, line 17) c-c++-common/ubsan/shift-5.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for errors, line 20) c-c++-common/ubsan/shift-5.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for errors, line 34) c-c++-common/ubsan/shift-5.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for errors, line 37) c-c++-common/ubsan/shift-5.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for errors, line 11) c-c++-common/ubsan/shift-5.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for errors, line 14) c-c++-common/ubsan/shift-5.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for errors, line 17) c-c++-common/ubsan/shift-5.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for errors, line 20) c-c++-common/ubsan/shift-5.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for errors, line 34) c-c++-common/ubsan/shift-5.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for errors, line 37) c-c++-common/ubsan/shift-5.c -O3 -fomit-frame-pointer (test for errors, line 11) c-c++-common/ubsan/shift-5.c -O3 -fomit-frame-pointer (test for errors, line 14) c-c++-common/ubsan/shift-5.c -O3 -fomit-frame-pointer (test for errors, line 17) c-c++-common/ubsan/shift-5.c -O3 -fomit-frame-pointer (test for errors, line 20) c-c++-common/ubsan/shift-5.c -O3 -fomit-frame-pointer (test for errors, line 34) c-c++-common/ubsan/shift-5.c -O3 -fomit-frame-pointer (test for errors, line 37) c-c++-common/ubsan/shift-5.c -O3 -g (test for errors, line 11) c-c++-common/ubsan/shift-5.c -O3 -g (test for errors, line 14) c-c++-common/ubsan/shift-5.c -O3 -g (test for errors, line 17) c-c++-common/ubsan/shift-5.c -O3 -g (test for errors, line 20) c-c++-common/ubsan/shift-5.c -O3 -g (test for errors, line 34) c-c++-common/ubsan/shift-5.c -O3 -g (test for errors, line 37) c-c++-common/ubsan/shift-5.c -Os (test for errors, line 11) c-c++-common/ubsan/shift-5.c -Os (test for errors, line 14) c-c++-common/ubsan/shift-5.c -Os (test for errors, line 17) c-c++-common/ubsan/shift-5.c -Os (test for errors, line 20) c-c++-common/ubsan/shift-5.c -Os (test for errors, line 34) c-c++-common/ubsan/shift-5.c -Os (test for
[Bug sanitizer/61591] Undefined behavior sanitizer does not catch builtin_unreachable's from impossible devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61591 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Assignee|mpolacek at gcc dot gnu.org|jamborm at gcc dot gnu.org --- Comment #9 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Marek Polacek from comment #6) So - is the __builtin_unreachable with an argument expected? I'd say that no, it is not and we should verify that somewhere. I'll take over and will try to make sure that IPA does not create __builtin_unreachable calls with arguments (and perhaps Honza might help me with code in ipa-devirt?). Anyway, thanks a lot, I would not have expected this problem.
[Bug c++/64222] New: [5 Regression] error: ‘__FUNCTION__’ was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64222
Bug ID: 64222
Summary: [5 Regression] error: ‘__FUNCTION__’ was not declared
in this scope
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
trippels@gcc20 ~ % cat apply_control_data_updates.ii
class A
{
public:
A (const char *, void *);
};
class B
{
public:
B (A);
};
void
fn1 ()
{
B a (A (__FUNCTION__, 0));
}
trippels@gcc20 ~ % g++ -c apply_control_data_updates.ii
apply_control_data_updates.ii: In function ‘void fn1()’:
apply_control_data_updates.ii:14:11: error: ‘__FUNCTION__’ was not declared in
this scope
B a (A (__FUNCTION__, 0));
^
[Bug pending/64223] New: same warning repeated twice with same line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64223
Bug ID: 64223
Summary: same warning repeated twice with same line number
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: pending
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
gcc (GCC) 4.8.3
Observation:
gcc C compilation outputs same warning twice. Same file and line number
Expectation:
The warning would only be reported once.
$ gcc -Wall -o strstr gcc_warn.c
gcc_warn.c: In function ‘main’:
gcc_warn.c:12:5: warning: format ‘%d’ expects argument of type ‘int’, but
argument 2 has type ‘off_t’ [-Wformat=]
printf(stat: %d\n, statbuf.st_size);
^
gcc_warn.c:12:5: warning: format ‘%d’ expects argument of type ‘int’, but
argument 2 has type ‘off_t’ [-Wformat=]
cat gcc_warn.c
#include stdio.h
#include string.h
#include sys/types.h
#include sys/stat.h
#include unistd.h
int main(void)
{
struct stat statbuf;
printf(stat: %d\n, statbuf.st_size);
return 0;
}
[Bug target/63594] [5 Regression] ICE: in ix86_vector_duplicate_value, at config/i386/i386.c:39831 with -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63594
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 34216
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34216action=edit
gcc5-pr63594.patch
Untested fix for the AVX512{VL,BW} broadcast issues.
[Bug driver/64094] No such file or directory - No such file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64094 --- Comment #5 from Jon Grant jg at jguk dot org --- Hi Manu I like your open_strerror() propopsal. Is this how Bintuils has done it? Note: I realise this problem stems from ENOENT being used by both opendir() and open(). I think you only need to provide two wrappers to handle these cases Note: %m is not ideal in my view as it is a C Library extension that I believe is not widely supported. could it be replaced with %s? http://www.gnu.org/software/libc/manual/html_node/Other-Output-Conversions.html Alternatively, could have a check where files are stat() before they are opened, and then report the error then. Likewise for directories.
[Bug preprocessor/64220] gcc preprocessor defines outside of the reserved namespace: unix linux AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64220 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- What is wrong on this? You are not requesting any strict conformance mode, and with GNU extensions those are acceptable. Retry with -std=c89, -std=c99, -std=c11, -ansi or similar options, then those macros shouldn't be defined.
[Bug driver/64094] No such file or directory - No such file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64094 --- Comment #6 from Jon Grant jg at jguk dot org --- Two more tests where I try to pass directories to GCC. (1) $ mkdir testdir $ gcc -Wall -Werror -o main testdir testdir: file not recognized: Is a directory collect2: error: ld returned 1 exit status (2) $ mkdir testdir.cpp $ gcc -o main testdir.cpp cc1plus: fatal error: testdir.cpp: No such file or directory compilation terminated. Re (1) output reasonable. Although I don't know why it is getting all the way to LD after the error? Re (2) error handling not quite right, appears to have slipped through, because it had .cpp extension? Perhaps each filename could be checked with if (stat(pathname, sb) == 0 S_ISDIR(sb.st_mode))
[Bug driver/64094] No such file or directory - No such file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64094 --- Comment #7 from Andreas Schwab sch...@linux-m68k.org --- In order to be precise trying to open doesnotexist/foo.c should report no such directory.
[Bug fortran/56203] gfortran.dg/minlocval_3.f90 times out on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56203 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to r...@cebitec.uni-bielefeld.de from comment #4) This has become more pronounced with increased gfortran testing parallelism. I'll provide more feedback next week. Maybe post a -ftime-report, I think it might be a compile time hog ? Here, it takes about 4s at -O3, the largest single pass is: alias stmt walking : 1.89 (42%) usr 0.01 (11%) sys 1.95 (42%) wall 46 kB ( 0%) ggc The testcase is really not a large program, a handwritten 300 lines of code, working on small arrays. I've tested on two systems with -O3 -fomit-frame-pointer: * 1.2 GHz UltraSPARC-T2: real1:34.16 user1:33.32 sys0.43 phase opt and generate : 93.17 (99%) usr 0.40 (95%) sys 93.58 (99%) wall 31673 kB (93%) ggc alias stmt walking : 30.76 (33%) usr 0.03 ( 7%) sys 30.84 (33%) wall 25 kB ( 0%) ggc * 1.35 GHz UltraSPARC-IV: real 49.37 user 44.41 sys0.47 phase opt and generate : 44.40 (99%) usr 0.33 (97%) sys 47.62 (99%) wall 31673 kB (93%) ggc alias stmt walking : 12.93 (29%) usr 0.02 ( 6%) sys 13.05 (27%) wall 25 kB ( 0%) ggc Rainer
[Bug c++/64222] [5 Regression] error: ‘__FUNCTION__’ was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64222 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 CC||jason at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Started with r217241.
[Bug c/64223] same warning repeated twice with same line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64223 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-12-08 Component|pending |c Version|unknown |4.8.3 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- It's only reported once for me.
[Bug c++/64222] [5 Regression] error: ‘__FUNCTION__’ was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64222 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Priority|P3 |P1
[Bug preprocessor/64220] gcc preprocessor defines outside of the reserved namespace: unix linux AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64220 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-12-08 Ever confirmed|0 |1
[Bug libgcj/64219] [5 Regression] Rename libgcj-5.0.pc to libgcj-5.pc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64219 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 Target Milestone|--- |5.0 Summary|Rename libgcj-5.0.pc to |[5 Regression] Rename |libgcj-5.pc |libgcj-5.0.pc to ||libgcj-5.pc Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Yes. Should fix this before the release.
[Bug ipa/64218] [5 Regression] ICE: Segmentation fault (symtab_node::get_alias_target()) running Boost testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64218 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug target/64215] -Os misses an opportunity to merge two ret instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64215 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 Ever confirmed|0 |1
[Bug pending/64214] no warning for unused global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64214 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- The global variable is exported to other TUs where we can't see all uses. Declare it 'static' and it works. Warning for non-static unused decls would get too many false positives.
[Bug bootstrap/64213] gimple-match.c:1523:6: error: ‘GIMPLE’ was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64213 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-12-08 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Hmm, it definitely works on x86_64-linux. It is supposed to work via doing cpp_define (r, gimple ? GIMPLE=1: GENERIC=1); cpp_define (r, gimple ? GENERIC=0: GIMPLE=0); in genmatch.c which should cause 'GIMPLE' to lex as '1'. And indeed on x86_64-linux I see in gimple-match.c: /* #line 610 /space/rguenther/src/svn/trunk/gcc/match.pd */ if ((1 useless_type_conversion_p (type, TREE_TYPE (captures[0]))) || (0 type == TREE_TYPE (captures[0]))) which means libcpp is miscompiled...? I notice that stage1 seems to work for you?
[Bug ipa/64190] [4.9 Regression] FAIL: gcc.dg/ipa/pr63551.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64190 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||jamborm at gcc dot gnu.org Summary|FAIL: gcc.dg/ipa/pr63551.c |[4.9 Regression] FAIL: |(test for excess errors)|gcc.dg/ipa/pr63551.c (test ||for excess errors)
[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- I think the message is correct, or at least the case is highly unclear, the OpenMP 4.0 standard has various unclear corner cases. The thing is, the loop iterator is predetermined linear, and the linear clause makes implicit reference to the outer var, but as linear clause is not allowed on the parallel, it can't be specified there and with default(none) you are requesting that everything is specified there explicitly. I can only suggest using non-combined construct in that case if you for some reason need default(none), say: !$omp parallel private (i_ct) default(none) !$omp do simd do i_ct = 1, 10 ... end do !$omp end parallel or so.
[Bug target/64212] [5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64212 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |5.0 Summary|ICE [in |[5 Regression] ICE [in |noninterposable_alias, at |noninterposable_alias, at |symtab.c:1706] |symtab.c:1706]
[Bug target/64210] [5 Regression] FAIL: gcc.target/i386/avx512vl-(vmovdqa64|vpbroadcastd)-1.c ... with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64210 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0 Summary|FAIL: |[5 Regression] FAIL: |gcc.target/i386/avx512vl-(v |gcc.target/i386/avx512vl-(v |movdqa64|vpbroadcastd)-1.c |movdqa64|vpbroadcastd)-1.c |... with -fpic |... with -fpic
[Bug target/64208] [4.9 Regression][iwmmxt] ICE: internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64208 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ra Target||arm-none-linux-gnueabi Component|rtl-optimization|target Target Milestone|--- |4.9.3
[Bug target/64205] [5 Regression] powerpc64-linux --with-cpu=G5 bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64205 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build Target||powerpc64-*-* Target Milestone|--- |5.0 Summary|powerpc64-linux |[5 Regression] |--with-cpu=G5 bootstrap |powerpc64-linux |failure |--with-cpu=G5 bootstrap ||failure
[Bug target/64204] [5 Regression] gcc.dg/c11-atomic-2.c fails on powerpc 64-bit little endian after -mupper-regs patches went in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64204 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0 Summary|gcc.dg/c11-atomic-2.c fails |[5 Regression] |on powerpc 64-bit little|gcc.dg/c11-atomic-2.c fails |endian after -mupper-regs |on powerpc 64-bit little |patches went in |endian after -mupper-regs ||patches went in
[Bug target/64200] ICE: in decide_alg, at config/i386/i386.c:24510 with -mmemcpy-strategy=libcall:-1:align -minline-stringops-dynamically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64200 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/64199] [4.8/4.9/5 Regression] ICE: tree check: expected class 'constant', have 'binary' (plus_expr) in fold_binary_loc, at fold-const.c:10404 with -ffast-math -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64199 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-12-08 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.8.4 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed, mine.
[Bug tree-optimization/64193] [4.8/4.9/5 Regression] Decreased performance after r173250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64193 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-12-08 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.8.4 Summary|Decreased performance after |[4.8/4.9/5 Regression] |r173250 |Decreased performance after ||r173250 Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- I will have a look. Note the rev. was backported to GCC 4.5 and up.
[Bug target/64208] [4.9 Regression][iwmmxt] ICE: internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64208 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 CC||ktkachov at gcc dot gnu.org Known to work||4.8.4, 5.0 Ever confirmed|0 |1 Known to fail||4.9.2 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed. On trunk and 4.8.4 it works fine though. -mno-lra works. Trying other march values didn't trigger this for me. Only iwmmxt and iwmmxt2 triggered this.
[Bug c++/64191] [4.9/5 Regression] -march=native messes up dead code elimination in loop calling dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64191
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2014-12-08
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |4.9.3
Summary|-march=native messes up |[4.9/5 Regression]
|dead code elimination in|-march=native messes up
|loop calling dtor |dead code elimination in
||loop calling dtor
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Hmm, on the 4.9 branch we vectorize the clobber and cannot recover from that
(nor do we remove the loop earlier - because of that as well I guess).
void bar_dtor_loop(Bar*, unsigned int) (struct Bar * p, unsigned int n)
{
...
bb 6:
# e_13 = PHI e_9(5), e_10(8)
e_10 = e_13 + 18446744073709551612;
*e_10 ={v} {CLOBBER};
if (p_4(D) e_10)
goto bb 8;
else
goto bb 7;
bb 8:
goto bb 6;
...
after vectorization:
bb 7:
# e_13 = PHI e_9(6), e_10(14)
# vect_vec_iv_.19_45 = PHI vect_cst_.17_43(6), vect_vec_iv_.19_46(14)
# ivtmp_11 = PHI 0(6), ivtmp_49(14)
vect_vec_iv_.19_46 = vect_vec_iv_.19_45 + vect_cst_.18_44;
vect_e_10.20_48 = vect_vec_iv_.19_45 + vect_cst_.21_47;
e_10 = e_13 + 18446744073709551612;
ivtmp_49 = ivtmp_11 + 1;
if (ivtmp_49 bnd.13_20)
goto bb 14;
else
goto bb 10;
...
bb 8:
# e_24 = PHI e_26(9), e_33(11)
e_26 = e_24 + 18446744073709551612;
*e_26 ={v} {CLOBBER};
if (p_4(D) e_26)
goto bb 9;
else
goto bb 12;
works fine with GCC 4.8.
[Bug c++/64191] [4.9/5 Regression] -march=native messes up dead code elimination in loop calling dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64191 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- I thought we've added handling of gimple_clobber_p in 4.9 - vect_determine_vectorization_factor / vect_analyze_loop_operations / vect_transform_loop should ignore and/or remove the clobber.
[Bug c++/64191] [4.9/5 Regression] -march=native messes up dead code elimination in loop calling dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64191
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
It also seems that DCE cannot remove the empty loop with the clobber, because
it's marked useful and thus its SSA requirements are marked useful (we
explicitely exclude the VDEF but _not_ the SSA uses on the LHS of
*ssa_2 = {} clobbers). Even if we don't make that SSA use necessary we
still have made the clobber itself necessary and thus marked control dependent
edges necessary.
Thus IMHO we shouldn't make clobbers necessary at all but only keep those
live that we can keep live (all uses still live). That makes cddce1
kill bar_dtor_loop:
void bar_dtor_loop(Bar*, unsigned int) (struct Bar * p, unsigned int n)
{
struct Bar * e;
bb 2:
return;
}
but of course it probably will DCE all indirect clobbers on an address
that is otherwise unused. Jakub - do you think this will be a problem?
Index: gcc/tree-ssa-dce.c
===
--- gcc/tree-ssa-dce.c (revision 218479)
+++ gcc/tree-ssa-dce.c (working copy)
@@ -292,8 +292,7 @@ mark_stmt_if_obviously_necessary (gimple
break;
case GIMPLE_ASSIGN:
- if (TREE_CODE (gimple_assign_lhs (stmt)) == SSA_NAME
- TREE_CLOBBER_P (gimple_assign_rhs1 (stmt)))
+ if (gimple_clobber_p (stmt))
return;
break;
@@ -813,8 +812,9 @@ propagate_necessity (bool aggressive)
}
}
- FOR_EACH_SSA_TREE_OPERAND (use, stmt, iter, SSA_OP_USE)
- mark_operand_necessary (use);
+ if (!gimple_clobber_p (stmt))
+ FOR_EACH_SSA_TREE_OPERAND (use, stmt, iter, SSA_OP_USE)
+ mark_operand_necessary (use);
use = gimple_vuse (stmt);
if (!use)
@@ -1362,6 +1362,24 @@ eliminate_unnecessary_stmts (void)
/* If GSI is not necessary then remove it. */
if (!gimple_plf (stmt, STMT_NECESSARY))
{
+ /* Keep clobbers that we can keep live live. */
+ if (gimple_clobber_p (stmt))
+ {
+ ssa_op_iter iter;
+ use_operand_p use_p;
+ bool dead = false;
+ FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, SSA_OP_USE)
+ {
+ gimple def = SSA_NAME_DEF_STMT (USE_FROM_PTR (use_p));
+ if (!gimple_plf (def, STMT_NECESSARY))
+ {
+ dead = true;
+ break;
+ }
+ }
+ if (!dead)
+ continue;
+ }
if (!is_gimple_debug (stmt))
something_changed = true;
remove_dead_stmt (gsi, bb);
[Bug c++/64191] [4.9/5 Regression] -march=native messes up dead code elimination in loop calling dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64191
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
I thought we've added handling of gimple_clobber_p in 4.9 -
vect_determine_vectorization_factor / vect_analyze_loop_operations /
vect_transform_loop should ignore and/or remove the clobber.
Yeah, but appearantly we miss
Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c (revision 218479)
+++ gcc/tree-vect-stmts.c (working copy)
@@ -340,7 +340,8 @@ vect_stmt_relevant_p (gimple stmt, loop_
/* changing memory. */
if (gimple_code (stmt) != GIMPLE_PHI)
-if (gimple_vdef (stmt))
+if (gimple_vdef (stmt)
+!gimple_clobber_p (stmt))
{
if (dump_enabled_p ())
dump_printf_loc (MSG_NOTE, vect_location,
Otherwise we still vectorize an induction (the compute of the address).
Still the DCE of the loop is not happening (see proposed patch).
[Bug c++/64191] [4.9/5 Regression] -march=native messes up dead code elimination in loop calling dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64191 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Yes, I'm afraid it is a bad idea, you'll get rid of too many clobbers and they are really desirable, both for DSE, expansion etc.
[Bug c++/64191] [4.9/5 Regression] -march=native messes up dead code elimination in loop calling dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64191
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
It also seems that DCE cannot remove the empty loop with the clobber, because
it's marked useful and thus its SSA requirements are marked useful (we
explicitely exclude the VDEF but _not_ the SSA uses on the LHS of
*ssa_2 = {} clobbers). Even if we don't make that SSA use necessary we
still have made the clobber itself necessary and thus marked control
dependent
edges necessary.
Thus IMHO we shouldn't make clobbers necessary at all but only keep those
live that we can keep live (all uses still live). That makes cddce1
kill bar_dtor_loop:
void bar_dtor_loop(Bar*, unsigned int) (struct Bar * p, unsigned int n)
{
struct Bar * e;
bb 2:
return;
}
but of course it probably will DCE all indirect clobbers on an address
that is otherwise unused. Jakub - do you think this will be a problem?
Index: gcc/tree-ssa-dce.c
===
--- gcc/tree-ssa-dce.c (revision 218479)
+++ gcc/tree-ssa-dce.c (working copy)
@@ -292,8 +292,7 @@ mark_stmt_if_obviously_necessary (gimple
break;
case GIMPLE_ASSIGN:
- if (TREE_CODE (gimple_assign_lhs (stmt)) == SSA_NAME
- TREE_CLOBBER_P (gimple_assign_rhs1 (stmt)))
+ if (gimple_clobber_p (stmt))
return;
break;
@@ -813,8 +812,9 @@ propagate_necessity (bool aggressive)
}
}
- FOR_EACH_SSA_TREE_OPERAND (use, stmt, iter, SSA_OP_USE)
- mark_operand_necessary (use);
+ if (!gimple_clobber_p (stmt))
+ FOR_EACH_SSA_TREE_OPERAND (use, stmt, iter, SSA_OP_USE)
+ mark_operand_necessary (use);
use = gimple_vuse (stmt);
if (!use)
@@ -1362,6 +1362,24 @@ eliminate_unnecessary_stmts (void)
/* If GSI is not necessary then remove it. */
if (!gimple_plf (stmt, STMT_NECESSARY))
{
+ /* Keep clobbers that we can keep live live. */
+ if (gimple_clobber_p (stmt))
+ {
+ ssa_op_iter iter;
+ use_operand_p use_p;
+ bool dead = false;
+ FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, SSA_OP_USE)
+ {
+ gimple def = SSA_NAME_DEF_STMT (USE_FROM_PTR (use_p));
+ if (!gimple_plf (def, STMT_NECESSARY))
+ {
+ dead = true;
+ break;
+ }
+ }
+ if (!dead)
+ continue;
+ }
if (!is_gimple_debug (stmt))
something_changed = true;
remove_dead_stmt (gsi, bb);
Or rather
/* Keep clobbers that we can keep live live. */
if (gimple_clobber_p (stmt))
{
ssa_op_iter iter;
use_operand_p use_p;
bool dead = true;
FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, SSA_OP_USE)
{
gimple def = SSA_NAME_DEF_STMT (USE_FROM_PTR (use_p));
if (gimple_nop_p (def)
|| gimple_plf (def, STMT_NECESSARY))
{
dead = false;
break;
}
}
so we keep the indirect clobbers in destructors (with use of parameter
SSA default defs).
[Bug c++/64191] [4.9/5 Regression] -march=native messes up dead code elimination in loop calling dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64191 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- The tree-vect-stmts.c change is fine of course. As for loops not being DCEd if they have only clobbers in them that preclude that, isn't that optimized away by RTL optimizers anyway? Or perhaps we could do something about in the loop pipeline, but IMHO changing DCE is too big and too dangerous hammer.
[Bug c++/64191] [4.9/5 Regression] -march=native messes up dead code elimination in loop calling dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64191 --- Comment #8 from rguenther at suse dot de rguenther at suse dot de --- On Mon, 8 Dec 2014, jakub at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64191 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- The tree-vect-stmts.c change is fine of course. As for loops not being DCEd if they have only clobbers in them that preclude that, isn't that optimized away by RTL optimizers anyway? Or perhaps we could do something about in the loop pipeline, but IMHO changing DCE is too big and too dangerous hammer. No, RTL doesn't know how to DCE loops (it would need to prove the loop is not infinite). GIMPLE DCE is where that happens now. So I'm afraid there isn't any other way of fixing that besides making DCE do it. I'm testing the patch to see if we have anything in the testsuite that regresses. Can you think of something? I can only think of using pointer arithmetic to store to a part of a later destructed object. That would require both addresses to be not dependent on each other, like weird_base_1 = ... base_2 = weird_base_1 + 4B; MEM[weird_base_1, 8B] = 4; *base_2 = CLOBBER; like you may get if using placement new / delete on an offsetted address?
[Bug c/64223] same warning repeated twice with same line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64223
Harald van Dijk harald at gigawatt dot nl changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #2 from Harald van Dijk harald at gigawatt dot nl ---
I can reproduce the problem with Cygwin headers, and a reduced standalone
program (no standard library headers) is:
int printf (const char *, ...) __attribute__ ((__format__ (__printf__, 1, 2)));
int main(void)
{
printf(%d\n, 0L);
return 0;
}
One of the warnings is because of the attribute, the other is built-in to GCC:
removing the format attribute gets rid of a warning, passing
-fno-builtin-printf also gets rid of a warning (presumably the other one).
I do not know if the problem is in the headers (that they should not be
specifying the format attribute), or in GCC (that it should be ignoring the
format attribute if it's already known).
[Bug c++/64191] [4.9/5 Regression] -march=native messes up dead code elimination in loop calling dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64191
--- Comment #9 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Richard Biener from comment #6)
(In reply to Richard Biener from comment #3)
It also seems that DCE cannot remove the empty loop with the clobber,
because
it's marked useful and thus its SSA requirements are marked useful (we
explicitely exclude the VDEF but _not_ the SSA uses on the LHS of
*ssa_2 = {} clobbers). Even if we don't make that SSA use necessary we
still have made the clobber itself necessary and thus marked control
dependent
edges necessary.
Thus IMHO we shouldn't make clobbers necessary at all but only keep those
live that we can keep live (all uses still live). That makes cddce1
kill bar_dtor_loop:
void bar_dtor_loop(Bar*, unsigned int) (struct Bar * p, unsigned int n)
{
struct Bar * e;
bb 2:
return;
}
but of course it probably will DCE all indirect clobbers on an address
that is otherwise unused. Jakub - do you think this will be a problem?
Index: gcc/tree-ssa-dce.c
===
--- gcc/tree-ssa-dce.c (revision 218479)
+++ gcc/tree-ssa-dce.c (working copy)
@@ -292,8 +292,7 @@ mark_stmt_if_obviously_necessary (gimple
break;
case GIMPLE_ASSIGN:
- if (TREE_CODE (gimple_assign_lhs (stmt)) == SSA_NAME
- TREE_CLOBBER_P (gimple_assign_rhs1 (stmt)))
+ if (gimple_clobber_p (stmt))
return;
break;
@@ -813,8 +812,9 @@ propagate_necessity (bool aggressive)
}
}
- FOR_EACH_SSA_TREE_OPERAND (use, stmt, iter, SSA_OP_USE)
- mark_operand_necessary (use);
+ if (!gimple_clobber_p (stmt))
+ FOR_EACH_SSA_TREE_OPERAND (use, stmt, iter, SSA_OP_USE)
+ mark_operand_necessary (use);
use = gimple_vuse (stmt);
if (!use)
@@ -1362,6 +1362,24 @@ eliminate_unnecessary_stmts (void)
/* If GSI is not necessary then remove it. */
if (!gimple_plf (stmt, STMT_NECESSARY))
{
+ /* Keep clobbers that we can keep live live. */
+ if (gimple_clobber_p (stmt))
+ {
+ ssa_op_iter iter;
+ use_operand_p use_p;
+ bool dead = false;
+ FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, SSA_OP_USE)
+ {
+ gimple def = SSA_NAME_DEF_STMT (USE_FROM_PTR (use_p));
+ if (!gimple_plf (def, STMT_NECESSARY))
+ {
+ dead = true;
+ break;
+ }
+ }
+ if (!dead)
+ continue;
+ }
if (!is_gimple_debug (stmt))
something_changed = true;
remove_dead_stmt (gsi, bb);
Or rather
/* Keep clobbers that we can keep live live. */
if (gimple_clobber_p (stmt))
{
ssa_op_iter iter;
use_operand_p use_p;
bool dead = true;
FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, SSA_OP_USE)
{
gimple def = SSA_NAME_DEF_STMT (USE_FROM_PTR (use_p));
if (gimple_nop_p (def)
|| gimple_plf (def, STMT_NECESSARY))
{
dead = false;
break;
}
}
so we keep the indirect clobbers in destructors (with use of parameter
SSA default defs).
Or
/* If GSI is not necessary then remove it. */
if (!gimple_plf (stmt, STMT_NECESSARY))
{
+ /* Keep clobbers that we can keep live live. */
+ if (gimple_clobber_p (stmt))
+ {
+ ssa_op_iter iter;
+ use_operand_p use_p;
+ bool dead = false;
+ FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, SSA_OP_USE)
+ {
+ gimple def = SSA_NAME_DEF_STMT (USE_FROM_PTR (use_p));
+ if (!gimple_nop_p (def)
+ !gimple_plf (def, STMT_NECESSARY))
+ {
+ dead = true;
+ break;
+ }
+ }
+ if (!dead)
+ continue;
+ }
to not remove all direct clobbers but still keep indirect clobbers
on default defs.
[Bug target/64224] New: [ARM] -mapcs -marm uses deprecated forms (as of ARMv7-A) of LDM in epilogues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64224 Bug ID: 64224 Summary: [ARM] -mapcs -marm uses deprecated forms (as of ARMv7-A) of LDM in epilogues Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: ktkachov at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org Target: arm* The ARMv7-A specification says on the load-multiple (LDM) instruction: The SP can be in the list. However, ARM deprecates using these instructions with SP in the list. and ARM deprecates using these instructions with both the LR and the PC in the list. However GCC generates both forms in function epilogues when compiling with -mapcs. gas doesn't have a warning for these (I'm working on a patch to add those to gas) which is probably why this hasn't been noticed yet. We should fix GCC so that it doesn't generate deprecated sequences for ARMv7-A and later.
[Bug target/64224] [ARM] -mapcs -marm uses deprecated forms (as of ARMv7-A) of LDM in epilogues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64224 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-12-08 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- I'm working on it.
[Bug middle-end/64225] New: -funsafe-math-optimizations generates call to pow where multiply instruction would do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64225 Bug ID: 64225 Summary: -funsafe-math-optimizations generates call to pow where multiply instruction would do Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: bernie.ogden at linaro dot org Created attachment 34217 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34217action=edit Reproducer Running e.g. ./gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/bin/aarch64-linux-gnu-gcc -S -o - r.i -O1 -funsafe-math-optimizations generates code like this: stpx29, x30, [sp, -32]! addx29, sp, 0 strd8, [sp, 16] fmovd8, d0 fmovd1, 2.0e+0 blpow fmuld8, d8, d8 ldrd0, .LC0 fmuld0, d8, d0 ldrd8, [sp, 16] ldpx29, x30, [sp], 32 ret Removing -funsafe-math-optimizations, or replacing it with -ffast-math, replaces the call to pow with the intuitively more sensible fmul and saves the stacking, e.g.: ldrd1, .LC0 fmuld1, d0, d1 fmuld0, d1, d0 ret A little experimentation shows similar behaviour for AArch32, AArch64 and x86. By binary chopping through Linaro releases I find the behaviour begins with the first 4.8 release (gcc version 4.8.1 20130401 (prerelease)). Attached r.i and the output generated by: ./gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/bin/aarch64-linux-gnu-gcc -v --save-temps -S -o - r.c -O1 -funsafe-math-optimizations output 21 Guessed middle-end for Component, and entered latest version in which I've seen the bug for Version.
[Bug middle-end/64225] -funsafe-math-optimizations generates call to pow where multiply instruction would do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64225 --- Comment #1 from Bernard Ogden bernie.ogden at linaro dot org --- Created attachment 34218 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34218action=edit -v output
[Bug middle-end/64225] -funsafe-math-optimizations generates call to pow where multiply instruction would do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64225 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- (In reply to Bernard Ogden from comment #1) Created attachment 34218 [details] -v output Hmm, I get the good sequence: ldr d1, .LC0 fmuld1, d0, d1 fmuld0, d1, d0 with current FSF 4.8.4, 4.9.3 and latest 5.0 with just -O1 without having to specify -funsafe-math-optimisations or -ffast-math
[Bug middle-end/64225] -funsafe-math-optimizations generates call to pow where multiply instruction would do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64225 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 Ever confirmed|0 |1 --- Comment #3 from ktkachov at gcc dot gnu.org --- (In reply to ktkachov from comment #2) (In reply to Bernard Ogden from comment #1) Created attachment 34218 [details] -v output Hmm, I get the good sequence: ldr d1, .LC0 fmuld1, d0, d1 fmuld0, d1, d0 with current FSF 4.8.4, 4.9.3 and latest 5.0 with just -O1 without having to specify -funsafe-math-optimisations or -ffast-math Ah wait, sorry, I misread the report. The problem is that -funsafe-math-optimisations introduces that call to pow instead of doing the mults. Confirmed.
[Bug middle-end/64225] -funsafe-math-optimizations generates call to pow where multiply instruction would do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64225 --- Comment #4 from ktkachov at gcc dot gnu.org --- Add -fno-math-errno removes the call to pow. We've seen similar issues before with other math builtins. The problem is that the midend/frontend generates the pow call without remembering that by doing so it should assume that the multiplication cannot set errno
[Bug middle-end/64225] -funsafe-math-optimizations generates call to pow where multiply instruction would do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64225
--- Comment #5 from jgreenhalgh at gcc dot gnu.org ---
I've seen similar behavior on an HPC benchmark I was looking at.
The problem here is the interaction between fold-const.c, other passes, and
-fmath-errno.
Take this testcase:
void
foo (double x)
{
x * x;
}
fold-const.c is going to see x *x and canonicalize it to a call to pow. No
other pass will want to touch it, because now it could set errno, so we get as
code generation:
foo:
fmovd1, 2.0e+0
bpow
If we add -fno-math-errno :
foo:
ret
When I looked at this before I convinced myself that fold-const.c shouldn't be
doing the canonicalization to pow if we cared about errno - but I never spun a
patch for it - and I'm not sure I'm right.
[Bug middle-end/64225] -funsafe-math-optimizations generates call to pow where multiply instruction would do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64225 --- Comment #6 from ktkachov at gcc dot gnu.org --- fold-const.c has a comment in the relevant case that says: /* Canonicalize x*x as pow(x,2.0), which is expanded as x*x. */ So we should look at why is it not being expanded as such unless -fno-math-errno
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #47 from Damien Buhl (daminetreg) damien.buhl at lecbna dot org --- So our GCC with the problem has been configured and built by yocto-poky the following way : ``` Using built-in specs. COLLECT_GCC=arm-poky-linux-gnueabi-gcc-4.8.1 COLLECT_LTO_WRAPPER=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.1/lto-wrapper Target: arm-poky-linux-gnueabi Configured with: /home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/work-shared/gcc-4.8.1-r0/gcc-4.8.1/configure --build=i686-linux --host=i686-linux --target=arm-poky-linux-gnueabi --prefix=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr --exec_prefix=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr --bindir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi --sbindir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi --libexecdir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi --datadir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/share --sysconfdir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/etc --sharedstatedir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/com --localstatedir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/var --libdir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/lib/armv7a-vfp-neon-poky-linux-gnueabi --includedir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/include --oldincludedir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/include --infodir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/share/info --mandir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux --enable-clocale=generic --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-poky-linux-gnueabi- --without-local-prefix --enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap --disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no --with-cloog=no --enable-checking=release --enable-cheaders=c_global --with-gxx-include-dir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/ksp-0500/usr/include/c++ --with-sysroot=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/ksp-0500 --with-build-sysroot=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/ksp-0500 --enable-poison-system-directories --disable-libunwind-exceptions --with-mpfr=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr --with-system-zlib --disable-nls Thread model: posix gcc version 4.8.1 (GCC) ``` We have now updated to 4.9.1, I'll tell you the bug still happens with 4.9.1. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #45 from Alexander Varnin --- (In reply to Damien Buhl (daminetreg) from comment #44) While given test works properly with -latomic on my installation, my application doesn't. It fails with segfault in approximately half of launches. Core dump points to some thread execution code. I suppose, it is still broken in some way. Replacing std::thread in my code with pthread_* makes it work properly. So I conclude, that this std::thread and atomic things is broken on my gcc 4.8.2 arm freescale imx53 yocto build. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug middle-end/64225] -funsafe-math-optimizations generates call to pow where multiply instruction would do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64225 --- Comment #7 from ktkachov at gcc dot gnu.org --- (In reply to ktkachov from comment #6) fold-const.c has a comment in the relevant case that says: /* Canonicalize x*x as pow(x,2.0), which is expanded as x*x. */ I think this comment is misleading. In builtins.c the expand_builtin_mathfn_2 handles the expansion of pow and I don't see any code to expand pow (x, 2.0) as x * x. It tries to use the pow optab, so unless the backend explicitly expands the case in such a manner, it will not be converted to x*x. Is there some other place in the compiler that plays a role here?
[Bug target/64226] New: Secondary reload incorrect TOC address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64226
Bug ID: 64226
Summary: Secondary reload incorrect TOC address
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Many of the GCC testsuite VMX tests fail on AIX because secondary reload is
generating an incorrect TOC reference. A MEM is being stripped from a
TOC reference causing GCC to use a pattern for a raw address,
generating a bogus reference.
226r.ira:
(insn 347 346 348 8 (set (reg/f:SI 489)
(mem/u/c:SI (unspec:SI [
(symbol_ref/u:SI (*LC..32) [flags 0x2])
(reg:SI 2 2)
] UNSPEC_TOCREL) [0 S4 A8])) ld.c:83 411 {*movsi_internal1}
(expr_list:REG_EQUIV (symbol_ref/u:SI (*LC..31) [flags 0x2])
(nil)))
(insn 348 347 349 8 (set (reg:V8HI 488)
(mem/u/c:V8HI (reg/f:SI 489) [0 S16 A128])) ld.c:83 972
{*altivec_movv8
hi}
(expr_list:REG_DEAD (reg/f:SI 489)
(expr_list:REG_EQUIV (const_vector:V8HI [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
(const_int 4 [0x4])
(const_int 5 [0x5])
(const_int 6 [0x6])
(const_int 7 [0x7])
])
(nil
(insn 349 348 350 8 (parallel [
(set (reg:CC 74 6)
(unspec:CC [
(eq:CC (reg:V8HI 456)
(reg:V8HI 488))
] UNSPEC_PREDICATE))
(set (reg:V8HI 490)
(eq:V8HI (reg:V8HI 456)
(reg:V8HI 488)))
]) ld.c:83 1206 {*altivec_vcmpequh_p}
(expr_list:REG_DEAD (reg:V8HI 456)
(expr_list:REG_UNUSED (reg:V8HI 490)
(nil
227r.reload:
Reloads for insn # 349
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 1 1)
(const_int 96 [0x60]))
BASE_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1), can't combine
reload_in_reg: (plus:SI (reg/f:SI 1 1)
(const_int 96 [0x60]))
reload_reg_rtx: (reg:SI 7 7)
Reload 1: reload_in (SI) = (symbol_ref/u:SI (*LC..31) [flags 0x2])
BASE_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 2)
reload_in_reg: (symbol_ref/u:SI (*LC..31) [flags 0x2])
reload_reg_rtx: (reg/f:SI 9 9 [489])
Reload 2: reload_in (V8HI) = (mem/c:V8HI (plus:SI (reg/f:SI 1 1)
(const_int 96 [0x60]))
[
0 %sfp+96 S16 A128])
ALTIVEC_REGS, RELOAD_FOR_INPUT (opnum = 1), can't combine
reload_in_reg: (reg:V8HI 456)
reload_reg_rtx: (reg:V8HI 78 1)Reload 3: BASE_REGS,
RELOAD_FOR_INPUT_ADDRESS (opnum = 2), can't combine, second
ary_reload_p
reload_reg_rtx: (reg:SI 7 7)
Reload 4: reload_in (V8HI) = (mem/u/c:V8HI (symbol_ref/u:SI (*LC..31) [flags
0
x2]) [0 S16 A128])
ALTIVEC_REGS, RELOAD_FOR_INPUT (opnum = 2), can't combine
reload_in_reg: (reg:V8HI 488)
reload_reg_rtx: (reg:V8HI 90 13)
secondary_in_reload = 3
secondary_in_icode = reload_v8hi_si_load
(insn 498 497 499 8 (set (reg:SI 7 7)
(unspec:SI [
(symbol_ref/u:SI (*LC..31) [flags 0x2])
(reg:SI 2 2)
] UNSPEC_TOCREL)) ld.c:83 532 {*tocrefsi}
(nil))
(insn 499 498 349 8 (set (reg:V8HI 90 13)
(mem/u/c:V8HI (reg:SI 7 7) [0 S16 A128])) ld.c:83 972
{*altivec_movv8hi
}
(nil))
(insn 349 499 350 8 (parallel [
(set (reg:CC 74 6)
(unspec:CC [
(eq:CC (reg:V8HI 78 1)
(reg:V8HI 90 13))
] UNSPEC_PREDICATE))
(set (reg:V8HI 77 0 [490])
(eq:V8HI (reg:V8HI 78 1)
(reg:V8HI 90 13)))
]) ld.c:83 1206 {*altivec_vcmpequh_p}
(nil))
Pseudo 489 was loaded with (mem:SI (unspec:SI [LC..32]
TOCREL)) but r7 is loaded directly with (unspec:SI [LC..31] TOCREL).
I assume that find_replacement is finding symbol_ref LC..31 and using
that. There is no valid way to reference LC..31 directly on AIX.
It's clearer with -fno-section-anchors. LC..31 is in read-only data:
.csect _ld.rw_[RO],4
.align 4
...
LC..31:
.short 0
.short 1
.short 2
.short 3
.short 4
.short 5
.short 6
.short 7
LC..32 would have been a TOC reference to LC..31
.toc
LC..32:
.tc LC..31[TC],LC..31
but that is deleted and replaced with a direct reference to the RO
data. The final instruction stream is
addi 7,1,96
lvx 1,0,7
la 7,LC..31(2) -
lvx 13,0,7
[Bug target/64226] [5.0 Regression] Secondary reload incorrect TOC address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64226 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 CC||meissner at gcc dot gnu.org, ||uweigand at gcc dot gnu.org Target Milestone|--- |5.0 Summary|Secondary reload incorrect |[5.0 Regression] Secondary |TOC address |reload incorrect TOC ||address Ever confirmed|0 |1 --- Comment #1 from David Edelsohn dje at gcc dot gnu.org --- Confirmed.
[Bug jit/64206] fake.so is unlinked too early for some users
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64206 --- Comment #2 from David Malcolm dmalcolm at gcc dot gnu.org --- Created attachment 34219 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34219action=edit Work-in-progress patch to fix this The attached patch implements the ideas we talked about (needs some comments and a ChangeLog). Uli: does this fix the issue for you?
[Bug target/64226] [5.0 Regression] Secondary reload incorrect TOC address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64226 --- Comment #2 from David Edelsohn dje at gcc dot gnu.org --- Uli mentioned in private email: I think the piece of code quoted above from rs6000_secondary_reload_inner is wrong; it should not call create_TOC_reference unconditionally. Other places that use TOC-relative addressing first verify whether the symbol actually supports that, using use_toc_relative_ref. So this check should probably be done here too. If a symbol cannot be accessed via TOC-relative addressing, we should call rs6000_emit_move, which should do the right thing (forcing the address into the TOC). And the following patch to remove the special call to create_TOC_reference seems to fix the problem. Index: rs6000.c === --- rs6000.c(revision 218484) +++ rs6000.c(working copy) @@ -17379,12 +17379,7 @@ case SYMBOL_REF: case CONST: case LABEL_REF: - if (TARGET_TOC) - emit_insn (gen_rtx_SET (VOIDmode, scratch, - create_TOC_reference (addr, scratch))); - else - rs6000_emit_move (scratch, addr, Pmode); - + rs6000_emit_move (scratch, addr, Pmode); new_addr = scratch; break; I am testing bootstrap.
[Bug c/59491] compiler can't detect if xpression is always fixed value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59491 --- Comment #2 from David Binderman dcb314 at hotmail dot com --- (In reply to Marek Polacek from comment #1) Looks useful. Lots of time has elapsed, but I checked a recent Linux kernel and it would find about three bugs. I also checked about 9,500 packages of Fedora and it would find faults in about four packages. Given that success rate this year, it doesn't look very important to me now.
[Bug c++/64227] New: Forwarding an argument of a function template to a generic lambda causes a compiler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64227
Bug ID: 64227
Summary: Forwarding an argument of a function template to a
generic lambda causes a compiler crash
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
CC: jason at redhat dot com
The problem occurs with forward and move, but not with a static_castT(t).
#include utility
templatetypename T
auto greater_than(T t)
{
return [val = std::forwardT(t)] (const auto arg) { return arg val; };
}
templatetypename Functor
void g(Functor f)
{
for (int i = 0; i 10; i++)
f(i);
}
int main()
{
g(greater_than(10));
}
[ville@localhost ~]$ g++ --std=c++1z -c lambda-bada-boom.cpp
lambda-bada-boom.cpp: In function ‘auto greater_than(T)’:
lambda-bada-boom.cpp:6:36: internal compiler error: Segmentation fault
return [val = std::forwardT(t)] (const auto arg) { return arg val; };
^
0xc954af crash_signal
../../gcc/toplev.c:359
0xf1bb0a tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:2886
0xf1bb0a variably_modified_type_p(tree_node*, tree_node*)
../../gcc/tree.c:8809
0x7d9b79 add_capture(tree_node*, tree_node*, tree_node*, bool, bool)
../../gcc/cp/lambda.c:486
0x6e6f9f cp_parser_lambda_introducer
../../gcc/cp/parser.c:9252
0x6e6f9f cp_parser_lambda_expression
../../gcc/cp/parser.c:8964
0x6e6f9f cp_parser_primary_expression
../../gcc/cp/parser.c:4447
0x6ebe0d cp_parser_postfix_expression
../../gcc/cp/parser.c:6089
0x6eca19 cp_parser_unary_expression
../../gcc/cp/parser.c:7370
0x6ed7a7 cp_parser_binary_expression
../../gcc/cp/parser.c:8104
0x6edd1f cp_parser_assignment_expression
../../gcc/cp/parser.c:8347
0x6f036d cp_parser_expression
../../gcc/cp/parser.c:8501
0x6e60d2 cp_parser_jump_statement
../../gcc/cp/parser.c:10995
0x6e60d2 cp_parser_statement
../../gcc/cp/parser.c:9651
0x6e6842 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:10039
0x6e699b cp_parser_compound_statement
../../gcc/cp/parser.c:9993
0x6f3e8b cp_parser_function_body
../../gcc/cp/parser.c:19093
0x6f3e8b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:19129
0x6fe1ca cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:23369
0x700103 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:23281
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c/64223] same warning repeated twice with same line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64223 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Mon, 8 Dec 2014, harald at gigawatt dot nl wrote: I do not know if the problem is in the headers (that they should not be specifying the format attribute), or in GCC (that it should be ignoring the format attribute if it's already known). GCC is meant to ignore duplicate attributes; maybe the code in decl_attributes is failing to detect this one as duplicate for some reason.
[Bug c++/64227] Forwarding an argument of a function template to a generic lambda causes a compiler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64227 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 Ever confirmed|0 |1
[Bug c++/64227] Forwarding an argument of a function template to a generic lambda causes a compiler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64227 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||maxim.yegorushkin at gmail dot com --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 64085 has been marked as a duplicate of this bug. ***
[Bug c++/64085] ICE on C++14 lambda by-reference capture with an initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64085 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Confirmed, but marking as a dup of PR64227 as that has a slightly simpler reproducer. *** This bug has been marked as a duplicate of bug 64227 ***
[Bug middle-end/64225] -funsafe-math-optimizations generates call to pow where multiply instruction would do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64225 --- Comment #8 from joseph at codesourcery dot com joseph at codesourcery dot com --- Expanding x * x (or any such multiplication) to a call to pow is inherently dubious because the semantics of multiplication never include clobbering errno, though maybe it's OK with -funsafe-math-optimizations to introduce such a clobber. I think it would be useful to have no-errno-setting-needed versions of libm function builtins that users can call explicitly, as well as for internal use by GCC when it generates a built-in function call from code that doesn't set errno. (For example: glibc uses __builtin_fma to expand to an fma instruction when _FP_FAST_FMA indicates one is available. But strictly it's incorrect to expand fma / __builtin_fma calls to such an instruction without considering errno, unless -fno-math-errno. None of those glibc uses require fma to set errno (and glibc fma has its own bug where it fails to do so), so it would be beneficial to have __builtin_fma_noerrno to reflect what's actually required - this function would expand inline if possible, and failing that would call an fma function that might or might not end up settting errno.)
[Bug tree-optimization/63989] tree-ssa-strlen.c doesn't handle constant pointer plus and array refs if constant offset is smaller than known constant string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63989 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34220 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34220action=edit gcc5-pr63989-wip1.patch So, for start, this untested patch deals with #c1 f1 case. Still need to extend handle_char_store etc.
[Bug bootstrap/63787] [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63787 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- So, isn't this fixed now that PR61773 is?
[Bug c++/61754] [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 CC||ville.voutilainen at gmail dot com Ever confirmed|0 |1 Known to fail|4.10.0 |5.0
[Bug c++/64194] [C++14] unresolved overloaded function type for function template with auto return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 CC||ville.voutilainen at gmail dot com Ever confirmed|0 |1
[Bug c++/64178] rejects-valid on variadic operator++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64178 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 CC||ville.voutilainen at gmail dot com Ever confirmed|0 |1
[Bug c++/64169] Partial template specialization of reference-qualified operator templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64169 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 CC||ville.voutilainen at gmail dot com Ever confirmed|0 |1
[Bug c++/64171] Hang whilst printing error message on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64171
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-12-08
CC||ville.voutilainen at gmail dot
com
Ever confirmed|0 |1
--- Comment #1 from Ville Voutilainen ville.voutilainen at gmail dot com ---
The test ICEs on trunk:
[ville@localhost ~]$ g++ --std=c++1y -c 64171.cpp
64171.cpp:12:31: error: conflicting declaration ‘std::unordered_mapint, X
X::var’
std::unordered_mapint, X X::var = {
^
64171.cpp:8:45: note: previous declaration as ‘const std::unordered_mapint, X
X::var’
static const std::unordered_mapint, X var;
^
64171.cpp:12:31: error: declaration of ‘const std::unordered_mapint, X
X::var’ outside of class is not definition [-fpermissive]
std::unordered_mapint, X X::var = {
^
64171.cpp: In static member function ‘static X* X::fromString()’:
64171.cpp:18:55: error: conversion from ‘std::unordered_mapint,
X::const_iterator {aka std::__detail::_Node_const_iteratorstd::pairconst
int, X, false, false}’ to non-scalar type ‘std::unordered_mapint,
X::iterator {aka std::__detail::_Node_iteratorstd::pairconst int, X, false,
false}’ requested
std::unordered_mapint, X::iterator it = var.find(0);
^
At global scope:
cc1plus: internal compiler error: in record_reference, at cgraphbuild.c:87
0x8e28a3 record_reference
../../gcc/cgraphbuild.c:87
0xf1a76d walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_settree_node*, default_hashset_traits*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_settree_node*, default_hashset_traits*))
../../gcc/tree.c:11022
0xf1ad79 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_settree_node*, default_hashset_traits*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_settree_node*, default_hashset_traits*))
../../gcc/tree.c:11309
0x8e3386 record_references_in_initializer(tree_node*, bool)
../../gcc/cgraphbuild.c:426
0xf575b7 varpool_node::analyze()
../../gcc/varpool.c:533
0x8e914f analyze_functions
../../gcc/cgraphunit.c:1032
0x8e9985 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2331
0x6c1fdb cp_write_global_declarations()
../../gcc/cp/decl2.c:4688
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/62212] ICE compiling template function with array reference parameter whose size depends on a template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62212 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 CC||ville.voutilainen at gmail dot com Ever confirmed|0 |1
[Bug go/64198] ICE in gofrontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64198 --- Comment #1 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Mon Dec 8 18:05:30 2014 New Revision: 218485 URL: https://gcc.gnu.org/viewcvs?rev=218485root=gccview=rev Log: PR go/64198 compiler: Don't crash on invalid ++. Modified: trunk/gcc/go/gofrontend/parse.cc
[Bug c++/60372] incorrect destruction order for function parameter objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60372 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2014-12-08 CC||ville.voutilainen at gmail dot com Ever confirmed|0 |1 --- Comment #2 from Ville Voutilainen ville.voutilainen at gmail dot com --- Let's suspend the bug while the Core issue is in progress, then.
[Bug c++/64095] [C++14] Ellipsis at end of generic lambda parameter-declaration-clause should be parsed as a parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 CC||ville.voutilainen at gmail dot com Ever confirmed|0 |1
[Bug c++/64073] Explicit duplicate template instantiation not reported as error when using 'using'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64073 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 CC||ville.voutilainen at gmail dot com Ever confirmed|0 |1
[Bug c++/63996] Infinite loop in invalid C++14 constexpr fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63996 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 CC||ville.voutilainen at gmail dot com Ever confirmed|0 |1
[Bug c++/61971] array subscript is above array bounds [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61971 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 CC||ville.voutilainen at gmail dot com Known to work||4.8.2, 5.0 Ever confirmed|0 |1 Known to fail||4.9.0, 4.9.1
[Bug ipa/64049] [5 Regression] r215898 caused wrong code at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64049 --- Comment #13 from Bernd Edlinger edlinger at gcc dot gnu.org --- Author: edlinger Date: Mon Dec 8 18:30:15 2014 New Revision: 218487 URL: https://gcc.gnu.org/viewcvs?rev=218487root=gccview=rev Log: 2014-12-08 Bernd Edlinger bernd.edlin...@hotmail.de PR ipa/64049 * ipa-polymorphic-call.c (pa_polymorphic_call_context::ipa_polymorphic_call): Allow RESULT_DECL. testsuite/ChangeLog: 2014-12-08 Bernd Edlinger bernd.edlin...@hotmail.de PR ipa/64049 * g++.dg/ipa/pr64049.h: New. * g++.dg/ipa/pr64049-1.C: New. * g++.dg/ipa/pr64049-2.C: New. Added: trunk/gcc/testsuite/g++.dg/ipa/pr64049-1.C trunk/gcc/testsuite/g++.dg/ipa/pr64049-2.C trunk/gcc/testsuite/g++.dg/ipa/pr64049.h Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-polymorphic-call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/63809] Missing warning on extra template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63809 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 CC||ville.voutilainen at gmail dot com Ever confirmed|0 |1
[Bug c/64223] same warning repeated twice with same line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64223
--- Comment #4 from Harald van Dijk harald at gigawatt dot nl ---
Ah, GCC does not treat format(printf) and format(__printf__) as equivalent, and
the built-in declaration uses format(printf). With custom functions, two
warnings can also be generated:
int myprintf (const char *, ...) __attribute__ ((__format__ (printf, 1, 2)));
int myprintf (const char *, ...) __attribute__ ((__format__ (__printf__, 1,
2)));
int main(void)
{
myprintf(%d\n, 0L);
return 0;
}
When combined with gnu_printf and __gnu_printf__, it can become even worse.
[Bug c++/61022] [C++11] Bogus error: parameter packs not expanded with '...'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61022 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-08 CC||ville.voutilainen at gmail dot com Ever confirmed|0 |1
[Bug c++/64228] New: compile error not accurate expected ; before string constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64228
Bug ID: 64228
Summary: compile error not accurate expected ; before string
constant
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Using cygwin gcc (GCC) 4.8.3
Wondering if the missing operator in the following line could be identified
$ g++ -O -Wall -Werror -o main main.cpp
main.cpp: In function ‘int main()’:
main.cpp:10:31: error: expected ‘;’ before string constant
std::cout oops i number endl;
^
#include iostream
int main()
{
int i = 0;
std::cout oops i number endl;
return 0;
}
Perhaps could say:
error: expected ‘;’ or ‘’ before string constant
Although, I realise there may be many things that could be fit in this space.
