[Bug target/63610] Fixing the libtool bug for Yosemite (darwin14)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610 --- Comment #15 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to howarth from comment #14) You aren't seeing regressions because you're not setting MACOSX_DEPLOYMENT_TARGET during the gcc build. Oh, so that's it! Thanks for puzzling it out. I'll ask RM for permission to backport to all active branches (4.8 and 4.9). Before I do that, can you confirm that the patch works as you expect on trunk, with MACOSX_DEPLOYMENT_TARGET set? Just to be extra sure.
[Bug target/63610] Fixing the libtool bug for Yosemite (darwin14)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610 --- Comment #16 from Iain Sandoe iains at gcc dot gnu.org --- Hmm the patch for __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ has been applied to 4.9 (AFAICT), although not to 4.8, Jack, what does your 4.9 compiler give for: gcc -dM -E -x c /dev/null |grep ENVIRO ? If the __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ is being set correctly, what is causing the need for MACOSX_DEPLOYMENT_TARGET?
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 --- Comment #3 from Lawrence Velázquez larryv at macports dot org --- Created attachment 33968 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33968action=edit patch against trunk for handling deployment targets correctly This is more of a rewrite than just a patch. I've divorced parsing of the version string from assembly of legacy macro values from assembly of modern macro values. It should hopefully be easier to make adjustments in the future, since this code is more than a crude DFA implementation.
[Bug other/51153] OpenACC implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51153 Thomas Schwinge tschwinge at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Version|4.7.0 |5.0 Keywords||openacc Last reconfirmed||2014-11-14 Component|target |other CC||tschwinge at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/63610] Fixing the libtool bug for Yosemite (darwin14)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610 --- Comment #17 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Iain Sandoe from comment #16) Hmm the patch for __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ has been applied to 4.9 (AFAICT) Yes it has. although not to 4.8 You're right. Provided that the patches are simple, maybe it's good enough to document them (as I have in the __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ patch for 4.8) and let distributors apply them.
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 --- Comment #4 from Lawrence Velázquez larryv at macports dot org --- Created attachment 33969 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33969action=edit patch against 4.9 branch for handling deployment targets correctly Patched GCC 4.9.2 matched the behavior of Apple LLVM Compiler 6.0 (clang-600.0.54) over 8,451 out of 8,464 test strings. The 13 mismatches are due to a bug in clang.
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 --- Comment #5 from Lawrence Velázquez larryv at macports dot org --- Created attachment 33970 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33970action=edit patch against 4.8 branch for handling deployment targets correctly This patch incorporates and supersedes attachment 33932 from bug 61407.
[Bug c/63862] New: C frontend converts shift-count to int while standard wants integer promotions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63862
Bug ID: 63862
Summary: C frontend converts shift-count to int while standard
wants integer promotions
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
CC: jsm28 at gcc dot gnu.org
/* Convert the non vector shift-count to an integer, regardless
of size of value being shifted. */
if (TREE_CODE (TREE_TYPE (op1)) != VECTOR_TYPE
TYPE_MAIN_VARIANT (TREE_TYPE (op1)) != integer_type_node)
op1 = convert (integer_type_node, op1);
while C99 6.5.7 says The integer promotions are performed on each of the
operands.
The above pessimizes gcc.c-torture/execute/shiftopt-1.c which does
void
utest (unsigned int x)
{
if (-1 x != -1)
link_error ();
}
and thus expects us to know that the shift amount is nonnegative. But
with the C frontend generating -1 (int)x we don't know that anymore
(and thus if I fix the bogus fold-const.c code which strips sign-changing
conversions on x before asking tree_expr_nonnegative_p it fails to optimize).
[Bug ipa/63814] g++.dg/ipa/pr61160-1.C fails with -m32 on darwin14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 --- Comment #12 from Igor Zamyatin izamyatin at gmail dot com --- So far it seems the issue unlikely caused by PIC-related changes in i686 - test passes with -fno-devirtualize.
[Bug target/62173] [5.0 regression] [AArch64] Performance regression due to r213488
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #5 from Jiong Wang jiwang at gcc dot gnu.org --- The root cause is AArch64's TARGET_LEGITIMIZE_ADDRESS are not doing well when the input is ((reg + reg) + offset). looks like currently we have considered reg + non_normal_offset, and trying to split non_normal_offset to base + offset. while for ((reg1 + reg2) + offset), if reg + offset is valid, then we should legitimize it to reg3 = reg1 + offset return reg3 + reg2 will send out the patch after pass tests and benchmarking.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #52 from Lawrence Velázquez larryv at macports dot org --- Attachment 33932 should be superseded by attachment 33970 from bug 63810.
[Bug target/62173] [5.0 regression] [AArch64] Performance regression due to r213488
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|--- |5.0
[Bug libobjc/63863] New: New warnings in libobjc due to the move over to GNU11 by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63863 Bug ID: 63863 Summary: New warnings in libobjc due to the move over to GNU11 by default Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libobjc Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org /var/lib/jenkins/workspace/GCCupstream/libobjc/sendmsg.c:338:13: warning: ‘get_implementation’ is static but used in inline function ‘get_imp’ which is not static res = get_implementation(nil, class, sel); ^ /var/lib/jenkins/workspace/GCCupstream/libobjc/sendmsg.c:335:15: warning: ‘sarray_get_safe’ is static but used in inline function ‘get_imp’ which is not static void *res = sarray_get_safe (class-dtable, (size_t) sel-sel_id); ^ /var/lib/jenkins/workspace/GCCupstream/libobjc/sendmsg.c:143:21: warning: ‘__objc_word_forward’ is static but used in inline function ‘__objc_get_forward_imp’ which is not static return (IMP)__objc_word_forward; ^ /var/lib/jenkins/workspace/GCCupstream/libobjc/sendmsg.c:141:21: warning: ‘__objc_double_forward’ is static but used in inline function ‘__objc_get_forward_imp’ which is not static return (IMP)__objc_double_forward; ^ /var/lib/jenkins/workspace/GCCupstream/libobjc/sendmsg.c:139:21: warning: ‘__objc_block_forward’ is static but used in inline function ‘__objc_get_forward_imp’ which is not static return (IMP)__objc_block_forward; ^
[Bug libobjc/63863] New warnings in libobjc due to the move over to GNU11 by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63863 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-11-14 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I will try to fix it this weekend.
[Bug target/63724] [AArch64] Inefficient immediate expansion and hoisting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63724 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Fixed by r217546
[Bug tree-optimization/63864] New: Missed optimization, related to SRA(??)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63864
Bug ID: 63864
Summary: Missed optimization, related to SRA(??)
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vermaelen.wouter at gmail dot com
Hi,
In my code I replaced some 'manual' vector/matrix calculations with
(inlined) function calls using vector/matrix types. When using clang
both approaches result in nearly identical generated code. But when
using gcc the code becomes much worse.
I don't know too much about compiler internals, but if I had to make a
guess I'd say that for some reason SRA doesn't work in this case.
See the code below: 'test_ok()' is the original function,
'test_slow()' is the rewritten version. I tried to simplify the code
as much as possible while not making it too simple (so that neither
compiler starts vectorizing the code).
Tested with:
g++ (GCC) 5.0.0 20141114 (experimental)
Wouter
- - - 8 - - - 8 - - - 8 - - - 8 - - - 8 - - - 8 - - - 8 - - -
// Original code with 'manual' matrix multiplication
float test_ok(float m[3][3], float x, float y, float z, float s, float b) {
float p = x*s + b;
float q = y*s + b;
float r = z*s + b;
float u = m[0][0]*p + m[1][0]*q + m[2][0]*r;
float v = m[0][1]*p + m[1][1]*q + m[2][1]*r;
float w = m[0][2]*p + m[1][2]*q + m[2][2]*r;
return u + v + w;
}
// (Much simplified) vec3/mat3 types
struct vec3 {
vec3() {}
vec3(float x, float y, float z) { e[0] = x; e[1] = y; e[2] = z; }
float operator[](int i) const { return e[i]; }
float operator[](int i) { return e[i]; }
private:
float e[3];
};
struct mat3 { vec3 c[3]; };
inline vec3 operator+(const vec3 x, const vec3 y) {
vec3 r;
for (int i = 0; i 3; ++i) r[i] = x[i] + y[i];
return r;
}
inline vec3 operator*(const vec3 x, float y) {
vec3 r;
for (int i = 0; i 3; ++i) r[i] = x[i] * y;
return r;
}
inline vec3 operator*(const vec3 x, const vec3 y) {
vec3 r;
for (int i = 0; i 3; ++i) r[i] = x[i] * y[i];
return r;
}
inline vec3 operator*(const mat3 m, const vec3 v) {
return m.c[0] * v[0] + m.c[1] * v[1] + m.c[2] * v[2];
}
// Rewritten version of the original function
float test_slow(mat3 m, float x, float y, float z, float s, float b) {
vec3 t = m * (vec3(x,y,z) * s + vec3(b,b,b));
return t[0] + t[1] + t[2];
}
[Bug fortran/63865] New: [OpenACC] support acc cache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63865 Bug ID: 63865 Summary: [OpenACC] support acc cache Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: openacc, rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: cesar at codesourcery dot com, tschwinge at gcc dot gnu.org Currently (branch, submitted patches), acc cache is implemented as sorry() - and several existing test cases are disabled. See also: https://gcc.gnu.org/ml/fortran/2014-11/msg00025.html
[Bug target/63724] [AArch64] Inefficient immediate expansion and hoisting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63724 --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Author: ramana Revision: 217546 Modified property: svn:log Modified: svn:log at Fri Nov 14 11:03:00 2014 -- --- svn:log (original) +++ svn:log Fri Nov 14 11:03:00 2014 @@ -1,1 +1,14 @@ -Fix typo in *arith_shift_insn_shiftsi +Fix PR target/63724 + +2014-11-14 Ramana Radhakrishnan ramana.radhakrish...@arm.com + +PR target/63724 +* config/aarch64/aarch64.c (aarch64_expand_mov_immediate): Split out +numerical immediate handling to... +(aarch64_internal_mov_immediate): ...this. New. +(aarch64_rtx_costs): Use aarch64_internal_mov_immediate. +(aarch64_mov_operand_p): Relax predicate. +* config/aarch64/aarch64.md (movmode:GPI): Do not expand CONST_INTs. +(*movsi_aarch64): Turn into define_insn_and_split and new alternative +for 'n'. +(*movdi_aarch64): Likewise.
[Bug sanitizer/63813] [5 Regression][UBSAN] ICE in ubsan_type_descriptor, at ubsan.c:346
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63813 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Jakub tells me this started with r217260.
[Bug sanitizer/63866] New: ICE in C++ printer with -fdump-ipa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63866
Bug ID: 63866
Summary: ICE in C++ printer with -fdump-ipa
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Likely TYPE_NAME/TYPE_STUB_DECL aren't set properly for __ubsan_*_data.
int main () { int i = __INT_MAX__; i++; asm ( : +g (i)); }
$ ./cc1plus -quiet -fsanitize=undefined x.C -fdump-ipa-all
x.C:1:62: internal compiler error: tree check: expected tree that contains
‘decl common’ structure, have ‘identifier_node’ in dump_aggr_type, at
cp/error.c:650
int main () { int i = __INT_MAX__; i++; asm ( : +g (i)); }
^
0x123cf49 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
/home/marek/src/gcc/gcc/tree.c:9365
0x6646b1 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/marek/src/gcc/gcc/tree.h:2871
0x79d47b dump_aggr_type
/home/marek/src/gcc/gcc/cp/error.c:650
0x79c0ed dump_type
/home/marek/src/gcc/gcc/cp/error.c:453
0x79ecd7 dump_type_prefix
/home/marek/src/gcc/gcc/cp/error.c:819
0x79f819 dump_simple_decl
/home/marek/src/gcc/gcc/cp/error.c:971
0x7a0298 dump_decl
/home/marek/src/gcc/gcc/cp/error.c:1072
0x7a8d7f decl_as_string(tree_node*, int)
/home/marek/src/gcc/gcc/cp/error.c:2787
0x7a8e73 lang_decl_name(tree_node*, int, bool)
/home/marek/src/gcc/gcc/cp/error.c:2822
0x8796ed cxx_printable_name_internal
/home/marek/src/gcc/gcc/cp/tree.c:2026
0x879934 cxx_printable_name(tree_node*, int)
/home/marek/src/gcc/gcc/cp/tree.c:2062
0xa186c4 symtab_node::name() const
/home/marek/src/gcc/gcc/symtab.c:475
0xa19150 symtab_node::dump_base(_IO_FILE*)
/home/marek/src/gcc/gcc/symtab.c:787
0x128d1d8 varpool_node::dump(_IO_FILE*)
/home/marek/src/gcc/gcc/varpool.c:224
0xa19c37 symtab_node::dump(_IO_FILE*)
/home/marek/src/gcc/gcc/symtab.c:903
0xa19c88 symtab_node::dump_table(_IO_FILE*)
/home/marek/src/gcc/gcc/symtab.c:914
0xa342c1 symbol_table::compile()
/home/marek/src/gcc/gcc/cgraphunit.c:2276
0xa34401 symbol_table::finalize_compilation_unit()
/home/marek/src/gcc/gcc/cgraphunit.c:2342
0x798258 cp_write_global_declarations()
/home/marek/src/gcc/gcc/cp/decl2.c:4677
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 sanitizer/63866] ICE in C++ printer with -fdump-ipa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63866 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-11-14 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Mine.
[Bug sanitizer/63866] ICE in C++ printer with -fdump-ipa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63866 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r205684.
[Bug target/63610] Fixing the libtool bug for Yosemite (darwin14)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610 --- Comment #18 from howarth at bromo dot med.uc.edu --- (In reply to Francois-Xavier Coudert from comment #17) (In reply to Iain Sandoe from comment #16) Hmm the patch for __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ has been applied to 4.9 (AFAICT) Yes it has. although not to 4.8 You're right. Provided that the patches are simple, maybe it's good enough to document them (as I have in the __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ patch for 4.8) and let distributors apply them. There is nothing in the gcc build that *needs* to have MACOSX_DEPLOYMENT_TARGET set, however some packaging environments, like fink and MacPorts, happen to set MACOSX_DEPLOYMENT_TARGET by default and thus triggers the configure/libtool.m4 bug... https://trac.macports.org/ticket/44596#comment:35 The Apple programmers told of the libtool.m4 bug so far all are of the view that configure/libtool.m4 shouldn't really be defaulting to -undefined dynamic_lookup as that can mask undefined symbols in release code (but should be default -undefined error). https://trac.macports.org/ticket/44596#comment:48 However that is a really libtool bug.
[Bug tree-optimization/63864] Missed late memory CSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63864 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-11-14 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Summary|Missed optimization,|Missed late memory CSE |related to SRA(??) | Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed - mine. Note that SRA cannot decompose arrays but I see a lot of missed CSE opportunities here which is because we unroll the loops completely only very late and the only memory CSE pass after that is DOM which is somewhat very limited here... I'll try to improve that. Related to some other PR.
[Bug sanitizer/63839] ICE: tree check: expected ssa_name, have var_decl in simplify_builtin_call, at tree-ssa-forwprop.c:1441 with -fsanitize=unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63839 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Fri Nov 14 11:22:12 2014 New Revision: 217553 URL: https://gcc.gnu.org/viewcvs?rev=217553root=gccview=rev Log: PR sanitizer/63839 * asan.c (ATTR_CONST_NORETURN_NOTHROW_LEAF_LIST, ATTR_COLD_CONST_NORETURN_NOTHROW_LEAF_LIST): Define. * builtin-attrs.def (ATTR_COLD_CONST_NORETURN_NOTHROW_LEAF_LIST): Define. * builtins.c (fold_builtin_0): Don't include ubsan.h. Don't instrument BUILT_IN_UNREACHABLE here. * sanitizer.def (BUILT_IN_UBSAN_HANDLE_BUILTIN_UNREACHABLE): Make const. * sanopt.c (pass_sanopt::execute): Instrument BUILT_IN_UNREACHABLE. * tree-ssa-ccp.c (optimize_unreachable): Bail out if SANITIZE_UNREACHABLE. * ubsan.c (ubsan_instrument_unreachable): Rewrite for GIMPLE. * ubsan.h (ubsan_instrument_unreachable): Adjust declaration. testsuite/ * c-c++-common/ubsan/pr63839.c: New test. * c-c++-common/ubsan/unreachable-2.c: New test. Added: trunk/gcc/testsuite/c-c++-common/ubsan/pr63839.c trunk/gcc/testsuite/c-c++-common/ubsan/unreachable-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c trunk/gcc/builtin-attrs.def trunk/gcc/builtins.c trunk/gcc/sanitizer.def trunk/gcc/sanopt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c trunk/gcc/ubsan.c trunk/gcc/ubsan.h
[Bug sanitizer/63839] ICE: tree check: expected ssa_name, have var_decl in simplify_builtin_call, at tree-ssa-forwprop.c:1441 with -fsanitize=unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63839 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug ipa/63856] [5 Regression] ICE: verify_gimple failed: invalid argument to gimple call with -O2 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63856 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build Priority|P3 |P1 Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug ipa/63851] [5 Regression] ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target||x86_64-apple-darwin14 Priority|P3 |P1 Target Milestone|--- |5.0 Summary|ipa-icf miscompiles |[5 Regression] ipa-icf |gfortran.dg/assumed_rank_(8 |miscompiles ||9|10).f90 at -O2 and above |gfortran.dg/assumed_rank_(8 |||9|10).f90 at -O2 and above
[Bug target/60580] aarch64 generates wrong code for __attribute__ ((optimize(no-omit-frame-pointer)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60580 Jiong Wang jiwang at gcc dot gnu.org changed: What|Removed |Added CC||jiwang at gcc dot gnu.org --- Comment #7 from Jiong Wang jiwang at gcc dot gnu.org --- I'd take this for long term, hopefully could find a acceptable solution. X86 is default with -fomit-frame-pointer which makes the logic a little bit simpler, and thus X86 could survive in more normal case, but still fail in some corner cases. the fundamental problem is aarch64 and also x86 want to implement a finer control of frame pointer which let leaf function be possible without setting up frame record even under -fno-omit-frame-pointer. While gcc generic code is not aware of that.
[Bug middle-end/60580] aarch64 generates wrong code for __attribute__ ((optimize(no-omit-frame-pointer)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60580 Jiong Wang jiwang at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Component|target |middle-end Version|4.8.3 |5.0 Severity|normal |minor
[Bug fortran/63867] New: LEN is lost for a CHARACTER variable inside SELECT TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63867 Bug ID: 63867 Summary: LEN is lost for a CHARACTER variable inside SELECT TYPE Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mrestelli at gmail dot com Consider the following code: program p implicit none character(len=5) :: str str = 'abcde' call checklen1(str) call checklen2(str) contains subroutine checklen1(s) character(len=*), intent(in) :: s call checklen2(s) end subroutine checklen1 subroutine checklen2(s) class(*), intent(in) :: s select type(s) type is(character(len=*)) write(*,*) Len is ,len(s) write(*,*) s is ,s end select end subroutine checklen2 end program p When compiled with gfortran it prints $ ./test Len is0 s is Len is5 s is abcde while the expected output is twice the same, i.e. $ ./test Len is5 s is abcde Len is5 s is abcde I.e., inside the SELECT TYPE the lenght of the string is lost, but only when the actual argument is itself a dummy argument with LEN=* . $ gfortran --version GNU Fortran (GCC) 5.0.0 20141114 (experimental) Marco
[Bug target/63848] [5.0 regression] FAIL: c-c++-common/torture/builtin-arith-overflow-17.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63848 Matthew Fortune matthew.fortune at imgtec dot com changed: What|Removed |Added CC||matthew.fortune at imgtec dot com --- Comment #1 from Matthew Fortune matthew.fortune at imgtec dot com --- I am seeing multiple failures for the builtin-arith-overflow tests on MIPS64 as well. I have not yet had time to investigate much but it may be due to some missing sign extension and/or performing a range test using bitwise comparison.
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853 --- Comment #14 from Dominique d'Humieres dominiq at lps dot ens.fr --- Thanks for the commit. Any plan to take into account the Jakub's remarks in comment 11?
[Bug fortran/63867] LEN is lost for a CHARACTER variable inside SELECT TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63867 --- Comment #1 from mrestelli mrestelli at gmail dot com --- Also, I should add that changing type is(character(len=*)) to type is(character(len=:)) given an internal compiler error (anyway, the code then is invalid) Marco
[Bug bootstrap/63853] [5.0 Regression] The use of strchrnul breaks bootstrap on x86_64-apple-darwin14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63853 --- Comment #15 from Ilya Verbin iverbin at gmail dot com --- (In reply to Dominique d'Humieres from comment #14) Thanks for the commit. Any plan to take into account the Jakub's remarks in comment 11? Yes, I added them to my TODO list.
[Bug libgomp/63868] New: [5 Regression] Multiple failures in the libgomp test suite between r217458 and r217501.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63868 Bug ID: 63868 Summary: [5 Regression] Multiple failures in the libgomp test suite between r217458 and r217501. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: jakub at gcc dot gnu.org Multiple failures appeared in the libgomp test suite between r217458 and r217501, see for instance https://gcc.gnu.org/ml/gcc-regression/2014-11/msg00309.html. On x86_64-apple-darwin14, all the failures are UNRESOLVED and the errors are of the kind [Book15] f90/bug% gfc -fopenmp /opt/gcc/work/libgomp/testsuite/libgomp.fortran/target1.f90 /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccH5c7Zy.s:1940:Expected comma after segment-name /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccH5c7Zy.s:1940:Rest of line ignored. 1st junk character valued 32 ( ). /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccH5c7Zy.s:1944:Expected comma after segment-name /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccH5c7Zy.s:1944:Rest of line ignored. 1st junk character valued 32 ( ). /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccH5c7Zy.s:2290:Expected comma after segment-name /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccH5c7Zy.s:2290:Rest of line ignored. 1st junk character valued 32 ( ). /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccH5c7Zy.s:2293:Expected comma after segment-name /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccH5c7Zy.s:2293:Rest of line ignored. 1st junk character valued 32 ( ). /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccH5c7Zy.s:2332:Expected comma after segment-name /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccH5c7Zy.s:2332:Rest of line ignored. 1st junk character valued 32 ( ). /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccH5c7Zy.s:2332:Junk character 48 (0). /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccH5c7Zy.s:2332:Rest of line ignored. 1st junk character valued 111 (o). /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccH5c7Zy.s:2427:Expected comma after segment-name ... with the default as and [Book15] f90/bug% gfc -fopenmp /opt/gcc/work/libgomp/testsuite/libgomp.fortran/target1.f90 -Wa,-q /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccrwTRRF.s:1940:28: error: unexpected token in '.section' directive .section .gnu.offload_vars ^ /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccrwTRRF.s:1945:29: error: unexpected token in '.section' directive .section .gnu.offload_funcs ^ /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccrwTRRF.s:2292:52: error: unexpected token in '.section' directive .section .gnu.offload_lto_.inline.7a3ca29239cf7041 ^ /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccrwTRRF.s:2296:72: error: unexpected token in '.section' directive .section .gnu.offload_lto___target1_MOD_foo._omp_fn.2.7a3ca29239cf7041 ^ ... withe the clang one.
[Bug target/63848] [5.0 regression] FAIL: c-c++-common/torture/builtin-arith-overflow-17.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63848 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 --- Seeing these on aarch64-none-elf as well btw
[Bug libgomp/63868] [5 Regression] Multiple failures in the libgomp test suite between r217458 and r217501.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63868 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||iverbin at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Perhaps we should just disable all offloading for Darwin, at least unless some Darwin maintainer steps up and adds the needed support for that.
[Bug libgomp/63868] [5 Regression] Multiple failures in the libgomp test suite between r217458 and r217501.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63868 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Perhaps we should just disable all offloading for Darwin, at least unless some Darwin maintainer steps up and adds the needed support for that. Well, this won't solve the failures on linux!
[Bug driver/63869] New: gcc-4.9.2 make failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63869 Bug ID: 63869 Summary: gcc-4.9.2 make failed Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: atsushi.nishizawa at iar dot nagoya-u.ac.jp Created attachment 33971 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33971action=edit log file which may be written during the compilation I tried to build gcc-4.9.2 from the source. configure is successfully finished and I tried to make but it failed with following message. configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching */config.log attached please find the config.log
[Bug libgomp/63868] [5 Regression] Multiple failures in the libgomp test suite between r217458 and r217501.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63868 Ilya Verbin iverbin at gmail dot com changed: What|Removed |Added CC||iverbin at gmail dot com --- Comment #3 from Ilya Verbin iverbin at gmail dot com --- (In reply to Dominique d'Humieres from comment #2) Perhaps we should just disable all offloading for Darwin, at least unless some Darwin maintainer steps up and adds the needed support for that. Well, this won't solve the failures on linux! Failures on linux ( https://gcc.gnu.org/ml/gcc-regression/2014-11/msg00309.html ) are caused by another issue (not by errors during assembling), I'm investigating them. I agree to disable generation of offload IR sections temporary for darwin.
[Bug target/63870] New: [Aarch64] [ARM] Errors in use of NEON instrinsics are reported incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870 Bug ID: 63870 Summary: [Aarch64] [ARM] Errors in use of NEON instrinsics are reported incorrectly Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: cbaylis at gcc dot gnu.org Reporter: cbaylis at gcc dot gnu.org CC: alan.lawrence at arm dot com Target: arm-unknown-linux-gnueabi, aarch64-linux-gnu Created attachment 33972 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33972action=edit Example tests Several NEON intrinsics have arguments which must be a constant integer in a fixed range. At present, these constraints are enforced for most intrinsics during assembly output, or, in some cases, not checked at all. This can be fixed by using the %K format specifier to the error message. See https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01248.html for a proposed patch and explanation. Once that patch is applied, it is necessary to rework the expansion of the builtins so that the constraints are checked during expansion. Some of this work has been started for Aarch64 (https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00421.html) Example demonstration of incorrect error messages using attached test cases on an ARM target. Note that the error message is reported at the end of each function, rather than the line where the error occurs. $ arm-unknown-linux-gnueabihf-gcc -c neon_const_range_tests/* -mfpu=neon neon_const_range_tests/vld1.c: In function ‘f_vld1_lane’: neon_const_range_tests/vld1.c:10:1: error: lane out of range } ^ neon_const_range_tests/vld4.c: In function ‘f_vld4_lane’: neon_const_range_tests/vld4.c:10:1: error: lane out of range } ^ neon_const_range_tests/vmul_lane.c: In function ‘f_vmul_lane’: neon_const_range_tests/vmul_lane.c:10:1: error: lane out of range } ^ neon_const_range_tests/vshl.c: In function ‘f_vshl’: neon_const_range_tests/vshl.c:10:1: error: constant out of range } ^ neon_const_range_tests/vshrn_n.c: In function ‘f_vshrn_n’: neon_const_range_tests/vshrn_n.c:10:1: error: constant out of range } ^ neon_const_range_tests/vst1.c: In function ‘f_vst1_lane’: neon_const_range_tests/vst1.c:9:1: error: lane out of range } ^ neon_const_range_tests/vst4.c: In function ‘f_vst4_lane’: neon_const_range_tests/vst4.c:9:1: error: lane out of range } ^
[Bug go/63816] internal compiler error: in expand_expr_addr_expr_1 on gcc version 5.0.0 20141109 (experimental)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63816 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-14 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- I'm seeing the same ICE on ppc64 with a modified libstdc++
[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||tekaev at kth dot se --- Comment #19 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 63816 has been marked as a duplicate of this bug. ***
[Bug go/63816] internal compiler error: in expand_expr_addr_expr_1 on gcc version 5.0.0 20141109 (experimental)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63816 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- ipa-icf related. dup. *** This bug has been marked as a duplicate of bug 63573 ***
[Bug c++/63871] New: -Weffc++ does not understand type deduction for return types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63871
Bug ID: 63871
Summary: -Weffc++ does not understand type deduction for return
types
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at doublewise dot net
Source file:
class C {};
auto operator++(C c) {
return c;
}
int main() {
}
gcc-4.9 source/main.cpp -Weffc++ -std=c++1y
source/main.cpp:112:25: warning: prefix ‘auto operator++(C)’ should return
‘C’ [-Weffc++]
auto operator++(C c) {
I get the same error with the return type specified as `auto ` or
`decltype(auto)`.
[Bug c++/63871] -Weffc++ does not understand type deduction for return types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63871 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- -Weffc++ hasn't been updated or maintained in years, it still uses the rules form the 1st edition of Effective C++ ... I wish people would stop using it. PR 16166 is the place where -Weffc++ PRs go to die. *** This bug has been marked as a duplicate of bug 16166 ***
[Bug c++/16166] -Weffc++ finer granularity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16166 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 63871 has been marked as a duplicate of this bug. ***
[Bug c/59984] OpenMP and Cilk Plus SIMD pragma makes loop incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59984
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC||jamborm at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Assignee|jakub at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Stupachenko Evgeny from comment #12)
Created attachment 33963 [details]
test case where pragma simd disable vectorization
The following test case compiled with -Ofast vectorize the loop in the
GetXsum function.
Adding -fopenmp leads to failed vectorization due to:
simd_issue.cpp:26:18: note: not vectorized: data ref analysis failed
D.2329[_7].x = _12;
It looks like before the patch in this Bug loop was vectorized with -fopenmp.
The testcase is invalid, you need reduction(+:sim) clause, otherwise the loop
has invalid inter-iteration dependencies.
That said, even with that, with C it vectorizes fine, while with C++ it
doesn't.
In *.einline the C - C++ difference is (before that I don't see such):
- D.1856[_19].x = _24;
- _26 = D.1856[_19];
- _27 = MEM[(const struct XY *)_26].x;
+ D.2352[_19].x = _24;
+ _26 = D.2352[_19];
+ _40 = MEM[(float *)_26];
In *.ealias the C - C++ difference is:
- D.1856[_19].x = _24;
- _27 = MEM[(const struct XY *)D.1856][_19].x;
+ D.2352[_19].x = _24;
+ _26 = D.2352[_19];
+ _40 = MEM[(float *)_26];
and apparently FRE1 handles the former but not the latter. Richard?
As the struct contains float at that offset, I don't see why FRE1 shouldn't
optimize that to _40 = _24.
Shorter testcase for the FRE1 missed-optimization:
struct S { float a, b; };
float
foo (int x, float y)
{
struct S z[1024];
z[x].a = y;
struct S *p = z[x];
float *q = (float *) p;
return *q;
}
(dunno why the inliner handles things differently between C and C++ on the #c12
testcase). Now, as for vectorizing it even if FRE isn't able to optimize it,
we currently don't support interleaved accesses to the omp simd array
attributed arrays, perhaps we could at least some easy cases thereof, and
supposedly we should teach SRA about those too (like, if the arrays aren't
addressable and aren't accesses as whole, but just individual fields, split it
into separate omp simd array accesses instead. In this particular case due
to the FRE missed optimization it is addressable though.
Or perhaps teach fold to gimple folding to fold that:
q_5 = z[x_2(D)];
_6 = *q_5;
back into:
_6 = z[x_2(D)].x;
?
[Bug go/63731] Fallback to netgo does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731 --- Comment #3 from Ian Lance Taylor ian at airs dot com --- The gc linker does not use the external linker merely because you link against the net package. You need to also pass -linkmode external in ldflags.
[Bug c++/63779] g++ 4.9 generates invalid object provoking a GOT relative relocation must reference a local symbol linker error on SunOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63779 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #1 from Rainer Orth ro at gcc dot gnu.org --- (In reply to Richard PALO from comment #0) It would be far more useful to see the relocations ld is complaining about, not just the symbols. I attach the .ii and .s temps for both gcc48 and gcc49 Unfortunately, you didn't. Rainer
[Bug c++/63872] New: -Wunused-local-typedefs warns incorrectly on a typedef that's referenced from a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63872
Bug ID: 63872
Summary: -Wunused-local-typedefs warns incorrectly on a typedef
that's referenced from a template
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thakis at chromium dot org
$ cat test2.cc
typedef char YesType;
struct NoType { YesType dummy[2]; };
template typename T
struct ShouldAbortOnSelfReset {
template typename U
static NoType Test(const typename U::AllowSelfReset*);
template typename U
static YesType Test(...);
static const bool value = sizeof(TestT(0)) == sizeof(YesType);
};
templateclass T
struct Foo {
void reset() {
ShouldAbortOnSelfResetT::value;
}
};
void f() {
struct NoOpDeleter {
typedef void AllowSelfReset;
inline void operator()(int*) {}
};
FooNoOpDeleter f;
f.reset();
}
$ ~/gcc482prefix/bin/gcc -c test2.cc -std=c++11 -Wall
test2.cc: In function ‘void f()’:
test2.cc:24:18: warning: typedef ‘f()::NoOpDeleter::AllowSelfReset’ locally
defined but not used [-Wunused-local-typedefs]
typedef void AllowSelfReset;
^
test2.cc: In instantiation of ‘void FooT::reset() [with T =
f()::NoOpDeleter]’:
test2.cc:29:11: required from here
Warning on this is very dangerous, since removing the typedef will change the
meaning of the code but it's still going to compile.
This is with 4.8.2, but it also happens in gcc 4.9.
[Bug c++/63779] g++ 4.9 generates invalid object provoking a GOT relative relocation must reference a local symbol linker error on SunOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63779 --- Comment #2 from Richard PALO richard at netbsd dot org --- Sorry. Given the size, I'll use the following directory for any information needed: http://www.netbsd.org/~richard/xulrunner31-g++-issue/ Index of /~richard/xulrunner31-g++-issue Parent Directory MediaDecoderReader.cpp MediaDecoderReader.h MediaDecoderReader.ii MediaDecoderReader.o MediaDecoderReader.o.gkd MediaDecoderReader.s ld-debug.txt.gz I included the gzip'd output of the link with: LD_OPTIONS=-Dfiles,detail,reloc,got,sections,output=ld-debug.txt Anything else useful to provide?
[Bug c++/63872] -Wunused-local-typedefs warns incorrectly on a typedef that's referenced from a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63872 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-14 Version|unknown |4.8.2 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- That's just a bug, a typedef defined at class scope is not a local typedef, even if it's in a local class.
[Bug web/63873] New: target links in Concepts Index in gccint do not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63873 Bug ID: 63873 Summary: target links in Concepts Index in gccint do not work Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: manu at gcc dot gnu.org CC: dmalcolm at gcc dot gnu.org From https://gcc.gnu.org/onlinedocs/gccint/Concept-Index.html#Concept-Index we get https://gcc.gnu.org/onlinedocs/gccint/Unary-and-Binary-Expressions.html#index-INIT_005fEXPR-1907 which does not exist because this description list does not have any ids. Texinfo bug? or GCC bug? Also, compare https://gcc.gnu.org/onlinedocs/gccint/Concept-Index.html#Concept-Index with https://dmalcolm.fedorapeople.org/gcc/libgccjit-api-docs/genindex.html Can we move into the 21st century already?
[Bug target/63874] New: vtable address generation goes through memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63874
Bug ID: 63874
Summary: vtable address generation goes through memory
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target: aarch64
Take:
struct a
{
virtual void f(void);
virtual ~a();
};
struct b : a
{
virtual void f(void);
virtual ~b();
};
void b::f(void){}
b::~b(void){}
Currently b::~b() produces:
_ZN1bD2Ev:
.LFB2:
.cfi_startproc
ldrx1, .LC0
strx1, [x0]
b_ZN1aD2Ev
.cfi_endproc
This really should be:
_ZN1bD2Ev:
.LFB1:
.cfi_startproc
adrpx1, _ZTV1b+16
addx1, x1, :lo12:_ZTV1b+16
strx1, [x0]
b_ZN1aD2Ev
Which is produced if I don't have a definition of b::f() in the same TU causing
the vtable not to be defined weak in this TU.
[Bug c++/63875] New: Bogus unused-but-set-parameter warning when expanding a variadic template argument pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63875
Bug ID: 63875
Summary: Bogus unused-but-set-parameter warning when expanding
a variadic template argument pack
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tejohnson at google dot com
The following test case warns about a variable that is set but unused. The
parameter is unused when the argument pack has nothing in it, but it is never
set.
% cat b.cc
template class... Ts
void Sink(Ts...) {}
struct S {
int Get(int) { return 0; }
};
template int... Is
void F(S s) {
Sink(s.Get(Is)...);
}
int main() {
F({});
}
$ g++ -c -O b.cc -std=c++11 -Wall -Wunused-but-set-parameter
b.cc: In instantiation of 'void F(S) [with int ...Is = {}]':
b.cc:14:9: required from here
b.cc:9:10: warning: parameter 's' set but not used [-Wunused-but-set-parameter]
void F(S s) {
Google ref b/10709546.
^
[Bug c++/63872] -Wunused-local-typedefs warns incorrectly on a typedef that's referenced from a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63872 --- Comment #2 from thakis at chromium dot org --- I think warning on unused typedefs in local classes is generally a useful feature, not a bug. The bug here is that it's warning on a typedef in a local class that is being used.
[Bug c/63862] C frontend converts shift-count to int while standard wants integer promotions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63862 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- If the middle-end handles arbitrary integer types for shift counts, it should be fine to remove this conversion (but check that the ubsan code will handle arbitrary integer types). I suspect this is also visible as an ubsan bug (that is, that these conversions will cause shifts by e.g. 0x1ULL not to be detected as undefined).
[Bug c/63862] C frontend converts shift-count to int while standard wants integer promotions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63862 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-11-14 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- I'll give this a try in stage3 then.
[Bug c++/63876] New: static data members of template classes w/ default ctors gives undefined reference error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63876 Bug ID: 63876 Summary: static data members of template classes w/ default ctors gives undefined reference error Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: aleaverfay at gmail dot com Created attachment 33973 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33973action=edit .cc, .hh, and .ii files along with the compilation command Static data members of template classes that use default constructors don't seem to get symbols emitted for them. I have a case where I cannot use anything besides the default constructor for this static data member: std::mutex. I've created a small test case that gives me the same problem. gcc version: 4.8.2 (Ubuntu 4.8.2-19ubuntu1) system type: Ubuntu 14.04.1 (I don't know what options were given to g++ when it was built; how do I find that out?) command line: (also in attachment) g++ -std=c++0x main.cc test.cc -I. compiler output: /tmp/cci1VgZe.o: In function `Foo::set_bar(int)': test.cc:(.text+0x86): undefined reference to `CRTP_classFoo::mutex_' collect2: error: ld returned 1 exit status
[Bug ipa/63814] g++.dg/ipa/pr61160-1.C fails with -m32 on darwin14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 --- Comment #13 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Igor Zamyatin from comment #11) Will take a look. Thanks! On Linux, the 32-bit PIC regression was introduced by r202145.
[Bug ipa/63814] g++.dg/ipa/pr61160-1.C fails with -m32 on darwin14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 --- Comment #14 from H.J. Lu hjl.tools at gmail dot com --- (In reply to H.J. Lu from comment #13) (In reply to Igor Zamyatin from comment #11) Will take a look. Thanks! On Linux, the 32-bit PIC regression was introduced by r202145. It is a -fdevirtualize-speculatively bug.
[Bug ipa/63814] [4.9/5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target|x86_64-apple-darwin14 |i686 Host|x86_64-apple-darwin14 | Version|5.0 |4.9.3 Target Milestone|--- |4.9.3 Summary|g++.dg/ipa/pr61160-1.C |[4.9/5 Regression] |fails with -m32 on darwin14 |g++.dg/ipa/pr61160-1.C ||fails with -m32 -fPIC Build|x86_64-apple-darwin14 |
[Bug c++/63876] static data members of template classes w/ default ctors gives undefined reference error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63876
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
Severity|major |normal
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
You've only declared a specialization, this is not a definition:
template std::mutex CRTP_class Foo ::mutex_;
You can make it a definition with an initializer:
template std::mutex CRTP_class Foo ::mutex_{};
[Bug ipa/63814] [4.9/5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 --- Comment #15 from H.J. Lu hjl.tools at gmail dot com --- (In reply to H.J. Lu from comment #14) (In reply to H.J. Lu from comment #13) (In reply to Igor Zamyatin from comment #11) Will take a look. Thanks! On Linux, the 32-bit PIC regression was introduced by r202145. It is a -fdevirtualize-speculatively bug. It only happens when --param ipa-cp-eval-threshold is used.
[Bug ipa/63814] [4.9/5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 --- Comment #16 from H.J. Lu hjl.tools at gmail dot com --- -fdevirtualize-speculatively doesn't work well with IPA-CP cloning under 32-bit PIC.
[Bug java/61552] Unneeded check for libart
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61552 --- Comment #1 from Arfrever Frehtes Taifersar Arahesis Arfrever.FTA at GMail dot Com --- Created attachment 33974 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33974action=edit gcc_delete_libart_check.patch
[Bug c/63877] New: - -Wmissing-declarations produces false alarms for C99 inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63877
Bug ID: 63877
Summary: - -Wmissing-declarations produces false alarms for C99
inline functions
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
This is a followup to PR c/54113, which was about -Wmissing-prototypes. This
followup bug report is the same, except it is about -Wmissing-declarations.
-Wmissing-declarations produces false alarms for C99-style
inline functions. We can use the same example as for PR c/54113.
Suppose foo.h contains this:
inline float square(float x) {return x*x;}
inline float cube(float x) {return x*x*x;}
and foo.c contains this:
#include foo.h
extern float square(float x);
extern float cube(float x);
Then the command:
gcc -c -Wmissing-declarations foo.c
outputs:
In file included from foo.c:1:0:
foo.h:1:14: warning: no previous declaration for 'square'
[-Wmissing-declarations]
inline float square(float x) {return x*x;}
^
foo.h:2:14: warning: no previous declaration for 'cube'
[-Wmissing-declarations]
inline float cube(float x) {return x*x*x;}
^
The diagnostics should not be output, as this is the normal
way to use inline functions in C.
To fix this, I suggest that the diagnostic be suppressed
for inline functions, at least for C99 mode.
[Bug c/63877] - -Wmissing-declarations produces false alarms for C99 inline functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63877 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-11-14 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Mine.
[Bug c/63878] New: Variables of incomplete type can be defined with -fno-fat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63878 Bug ID: 63878 Summary: Variables of incomplete type can be defined with -fno-fat-lto-objects Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mustrumr97 at gmail dot com a.c: struct a x; gcc -flto -fno-fat-lto-objects -c a.c # ok gcc -flto -ffat-lto-objects -c a.c # fail I think this should always be rejected.
[Bug ipa/63814] [4.9/5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 --- Comment #17 from H.J. Lu hjl.tools at gmail dot com --- Without -fPIC, r202145 gave pr63814.C:44:1: error: edge points to wrong declaration: } ^ function_decl 0x7f56f87c6400 MixinFunc.constprop type method_type 0x7f56f87bdf18 type pointer_type 0x7f56f8643c78 type void_type 0x7f56f8643bd0 void public unsigned SI size integer_cst 0x7f56f8627fc0 constant 32 unit size integer_cst 0x7f56f8627fe0 constant 4 align 32 symtab 0 alias set 4 canonical type 0x7f56f8643c78 pointer_to_this pointer_type 0x7f56f8652888 QI size integer_cst 0x7f56f8645180 constant 8 unit size integer_cst 0x7f56f86451a0 constant 1 align 8 symtab 0 alias set -1 canonical type 0x7f56f87bdf18 method basetype record_type 0x7f56f87a0738 CExample arg-types tree_list 0x7f56f87c86b8 value pointer_type 0x7f56f87a09d8 chain tree_list 0x7f56f8636aa0 value void_type 0x7f56f8643bd0 void addressable used static autoinline decl_5 QI defer-output file pr63814.C line 24 col 9 align 16 context record_type 0x7f56f87a0738 CExample full-name void* CExample::MixinFunc.constprop() pending-inline-info 0x7f56f87aa880 Instead of: function_decl 0x7f56f8783900 _ZThn4_N8CExample9MixinFuncEiPv type method_type 0x7f56f87a0bd0 type pointer_type 0x7f56f8643c78 type void_type 0x7f56f8643bd0 void public unsigned SI size integer_cst 0x7f56f8627fc0 constant 32 unit size integer_cst 0x7f56f8627fe0 constant 4 align 32 symtab 0 alias set 4 canonical type 0x7f56f8643c78 pointer_to_this pointer_type 0x7f56f8652888 QI size integer_cst 0x7f56f8645180 constant 8 unit size integer_cst 0x7f56f86451a0 constant 1 align 8 symtab 0 alias set -1 canonical type 0x7f56f87a0bd0 method basetype record_type 0x7f56f87a0738 CExample arg-types tree_list 0x7f56f879f5a0 value pointer_type 0x7f56f87a09d8 chain tree_list 0x7f56f879f1e0 value integer_type 0x7f56f86435e8 int chain tree_list 0x7f56f879f208 value pointer_type 0x7f56f8643c78 chain tree_list 0x7f56f8636aa0 value void_type 0x7f56f8643bd0 void pointer_to_this pointer_type 0x7f56f87a7150 addressable asm_written used public weak virtual decl_5 QI file pr63814.C line 24 col 9 align 8 context record_type 0x7f56f87a0738 CExample arguments parm_decl 0x7f56f87aaa80 this type pointer_type 0x7f56f87a0a80 type record_type 0x7f56f87a0738 CExample readonly unsigned SI size integer_cst 0x7f56f8627fc0 32 unit size integer_cst 0x7f56f8627fe0 4 align 32 symtab 0 alias set -1 canonical type 0x7f56f87a0a80 readonly used unsigned SI file pr63814.C line 24 col 39 size integer_cst 0x7f56f8627fc0 32 unit size integer_cst 0x7f56f8627fe0 4 align 32 context function_decl 0x7f56f8783900 _ZThn4_N8CExample9MixinFuncEiPv arg-type pointer_type 0x7f56f87a0a80 chain parm_decl 0x7f56f87aab00 arg type integer_type 0x7f56f86435e8 int used SI file pr63814.C line 24 col 24 size integer_cst 0x7f56f8627fc0 32 unit size integer_cst 0x7f56f8627fe0 4 align 32 context function_decl 0x7f56f8783900 _ZThn4_N8CExample9MixinFuncEiPv arg-type integer_type 0x7f56f86435e8 int chain parm_decl 0x7f56f87aab80 arg2 full-name virtual void* CExample::_ZThn4_N8CExample9MixinFuncEiPv(int, void*) main/14 (int main()) @0x7f56f87b1390 Type: function definition analyzed Visibility: externally_visible public References: _ZTV5CBase/17 (addr)_ZTV6MMixin/16 (addr)_ZTV8CExample/15 (addr)_ZTV8CExample/15 (addr) Referring: Availability: available Function flags: body only_called_at_startup Called by: Calls: _ZN8CExample9MixinFuncEiPv.constprop.0/36 (1.00 per call) (can throw external) pr63814.C:44:1: internal compiler error: verify_cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c/63878] Variables of incomplete type can be defined with -fno-fat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63878 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-14 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- The problem is the error message is emitted way too late and not by the front-end but by the middle-end. Confirmed.
[Bug c++/63876] static data members of template classes w/ default ctors gives undefined reference error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63876 --- Comment #2 from Andrew Leaver-Fay aleaverfay at gmail dot com --- Thank you!
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 --- Comment #6 from howarth at bromo dot med.uc.edu --- The proposed patch for gcc trunk fails to build here against r217590 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/xg++ -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc5.0/x86_64-apple-darwin14.0.0/bin/ -nostdinc++ -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs -I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/include/x86_64-apple-darwin14.0.0 -I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/include -I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20141114/libstdc++-v3/libsupc++ -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-5-20141114/gcc -I../../gcc-5-20141114/gcc/. -I../../gcc-5-20141114/gcc/../include -I../../gcc-5-20141114/gcc/../libcpp/include -I/sw/include -I/sw/include -I../../gcc-5-20141114/gcc/../libdecnumber -I../../gcc-5-20141114/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-5-20141114/gcc/../libbacktrace -DCLOOG_INT_GMP -I/sw/include -I/sw/include -o darwin-c.o -MT darwin-c.o -MMD -MP -MF ./.deps/darwin-c.TPo -DGCC_INCLUDE_DIR=\/sw/lib/gcc5.0/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/include\ -DFIXED_INCLUDE_DIR=\/sw/lib/gcc5.0/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/include-fixed\ -DGPLUSPLUS_INCLUDE_DIR=\/sw/lib/gcc5.0/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/../../../../include/c++/5.0.0\ -DGPLUSPLUS_INCLUDE_DIR_ADD_SYSROOT=0 -DGPLUSPLUS_TOOL_INCLUDE_DIR=\/sw/lib/gcc5.0/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/../../../../include/c++/5.0.0/x86_64-apple-darwin14.0.0\ -DGPLUSPLUS_BACKWARD_INCLUDE_DIR=\/sw/lib/gcc5.0/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/../../../../include/c++/5.0.0/backward\ -DLOCAL_INCLUDE_DIR=\/usr/local/include\ -DCROSS_INCLUDE_DIR=\/sw/lib/gcc5.0/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/../../../../x86_64-apple-darwin14.0.0/sys-include\ -DTOOL_INCLUDE_DIR=\/sw/lib/gcc5.0/lib/gcc/x86_64-apple-darwin14.0.0/5.0.0/../../../../x86_64-apple-darwin14.0.0/include\ -DNATIVE_SYSTEM_HEADER_DIR=\/usr/include\ -DPREFIX=\/sw/lib/gcc5.0/\ -DSTANDARD_EXEC_PREFIX=\/sw/lib/gcc5.0/lib/gcc/\ ../../gcc-5-20141114/gcc/config/darwin-c.c ../../gcc-5-20141114/gcc/config/darwin-c.c: In function ‘const char* version_as_modern_macro(const long unsigned int*)’: ../../gcc-5-20141114/gcc/config/darwin-c.c:711:7: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] != ((major 9) ? sizeof 99 : sizeof 9) - 1) ^ cc1plus: all warnings being treated as errors ../../gcc-5-20141114/gcc/config/t-darwin:26: recipe for target 'darwin-c.o' failed make[3]: *** [darwin-c.o] Error 1 make[3]: Leaving directory '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc' Makefile:4368: recipe for target 'all-stage2-gcc' failed make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir' Makefile:20616: recipe for target 'stage2-bubble' failed make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir' Makefile:906: recipe for target 'all' failed make: *** [all] Error 2
[Bug c/63878] Variables of incomplete type can be defined with -fno-fat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63878 --- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot com --- This is probably essentially the same as bug 24293 (reporting such an issue with -fsyntax-only).
[Bug c/24293] Undefined behaviour not diagnosed with -fsyntax-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24293 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Known to fail|| --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #3) Sorry for my ignorance, what is syntactically wrong with that? It is semantically incorrect and not syntactically incorrect. Basically -fsyntax-only includes most of the semantics analysis, why not this one too.
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 --- Comment #7 from Lawrence Velázquez larryv at macports dot org --- (In reply to howarth from comment #6) ../../gcc-5-20141114/gcc/config/darwin-c.c: In function ‘const char* version_as_modern_macro(const long unsigned int*)’: ../../gcc-5-20141114/gcc/config/darwin-c.c:711:7: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] != ((major 9) ? sizeof 99 : sizeof 9) - 1) ^ Seriously?
[Bug c/63878] Variables of incomplete type can be defined with -fno-fat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63878 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Depends on||24293 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Depends on bug 24293 then. Funny how I said the same thing in the previous bug and I even redid the analysis for this one and I forgot about the previous one too :).
[Bug rtl-optimization/60079] [LRA] ICE when compiling attached case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60079 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- I can reproduce it but I have other changes in my toolchain which could be exposing it.
[Bug rtl-optimization/60079] [LRA] ICE when compiling attached case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60079 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- /data1/src/gcc-cavium/toolchain-thunder/scripts/../src/newlib/libc/stdlib/strtol.c: In function ‘_strtol_r’: /data1/src/gcc-cavium/toolchain-thunder/scripts/../src/newlib/libc/stdlib/strtol.c:213:1: internal compiler error: in update_reg_eliminate, at lra-eliminations.c:1202 } ^
[Bug rtl-optimization/60079] [LRA] ICE when compiling attached case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60079 --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org --- Note my testcase is with -mabi=ilp32 too.
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 Lawrence Velázquez larryv at macports dot org changed: What|Removed |Added Attachment #33968|0 |1 is obsolete|| --- Comment #8 from Lawrence Velázquez larryv at macports dot org --- Created attachment 33975 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33975action=edit updated trunk patch that satisfies -Werror=sign-compare
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810
Lawrence Velázquez larryv at macports dot org changed:
What|Removed |Added
Attachment #33975|updated trunk patch that|patch against trunk for
description|satisfies |handling deployment targets
|-Werror=sign-compare|correctly
--- Comment #9 from Lawrence Velázquez larryv at macports dot org ---
Comment on attachment 33975
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33975
patch against trunk for handling deployment targets correctly
diff --git a/gcc/config/darwin-c.c b/gcc/config/darwin-c.c
index ffefa37..311cdd4 100644
--- a/gcc/config/darwin-c.c
+++ b/gcc/config/darwin-c.c
@@ -590,42 +590,167 @@ find_subframework_header (cpp_reader *pfile, const char
*header, cpp_dir **dirp)
return 0;
}
-/* Return the value of darwin_macosx_version_min suitable for the
- __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ macro, so '10.4.2'
- becomes 1040 and '10.10.0' becomes 101000. The lowest digit is
- always zero, as is the second lowest for '10.10.x' and above.
- Print a warning if the version number can't be understood. */
+/* Given a version string, return the version as a statically-allocated
+array of three non-negative integers. If the version string is
+invalid, return null.
+
+Version strings must consist of one, two, or three tokens, each
+separated by a single period. Each token must contain only the
+characters '0' through '9' and is converted to an equivalent
+integer. Omitted tokens are treated as zeros. For example:
+
+10 becomes {10,0,0}
+10.10 becomes {10,10,0}
+10.10.1 becomes {10,10,1}
+10.10.1 becomes {10,10,1}
+10.010.001 becomes {10,10,1}
+10.10.1 becomes {10,10,1} */
+
+enum version_components { MAJOR, MINOR, TINY };
+
+static const unsigned long *
+parse_version (const char *version_str)
+{
+ size_t version_len;
+ char *end;
+ static unsigned long version_array[3];
+
+ if (! version_str)
+return NULL;
+
+ version_len = strlen (version_str);
+ if (version_len 1)
+return NULL;
+
+ /* Version string must consist of digits and periods only. */
+ if (strspn (version_str, 0123456789.) != version_len)
+return NULL;
+
+ if (! ISDIGIT (version_str[0]) || ! ISDIGIT (version_str[version_len - 1]))
+return NULL;
+
+ version_array[MAJOR] = strtoul (version_str, end, 10);
+ version_str = end + ((*end == '.') ? 1 : 0);
+
+ /* Version string must not contain adjacent periods. */
+ if (*version_str == '.')
+return NULL;
+
+ version_array[MINOR] = strtoul (version_str, end, 10);
+ version_str = end + ((*end == '.') ? 1 : 0);
+
+ version_array[TINY] = strtoul (version_str, end, 10);
+
+ /* Version string must contain no more than three tokens. */
+ if (*end != '\0')
+return NULL;
+
+ return version_array;
+}
+
+/* Given a three-component version represented as an array of
+non-negative integers, return a statically-allocated string suitable
+for the legacy __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ macro.
+If the version is invalid and cannot be coerced into a valid form,
+return null.
+
+The legacy format is a four-character string -- two chars for the
+major number and one each for the minor and tiny numbers. Major
+numbers are zero-padded if necessary. Minor and tiny numbers from
+10 through 99 are permitted but are clamped to 9 (for example,
+{10,9,10} produces 1099). Versions containing numbers greater
+than 99 are rejected. */
+
static const char *
-version_as_macro (void)
+version_as_legacy_macro (const unsigned long *version)
{
- static char result[7] = 1000;
- int minorDigitIdx;
+ unsigned long major = version[MAJOR];
+ unsigned long minor = version[MINOR];
+ unsigned long tiny = version[TINY];
+ static char result[sizeof ];
- if (strncmp (darwin_macosx_version_min, 10., 3) != 0)
+ if (major 99 || minor 99 || tiny 99)
+return NULL;
+
+ minor = ((minor 9) ? 9 : minor);
+ tiny = ((tiny 9) ? 9 : tiny);
+
+ /* NOTE: Cast result of sizeof so that result of sprintf is not
+ converted to an unsigned type. */
+ if (sprintf (result, %02lu%lu%lu, major, minor, tiny)
+ != (int) sizeof - 1)
+return NULL;
+
+ return result;
+}
+
+/* Given a three-component version represented as an array of
+non-negative integers, return a statically-allocated string suitable
+for the modern __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ macro
+or the __ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__ macro. If the
+version is invalid, return null.
+
+The modern format is a five- or six-character string -- one or two
+chars for the major number and two each for the minor and tiny
+
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 Lawrence Velázquez larryv at macports dot org changed: What|Removed |Added Attachment #33969|0 |1 is obsolete|| --- Comment #10 from Lawrence Velázquez larryv at macports dot org --- Created attachment 33976 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33976action=edit patch against 4.9 branch for handling deployment targets correctly New 4.9 patch that should satisfy -Werror=sign-compare.
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 Lawrence Velázquez larryv at macports dot org changed: What|Removed |Added Attachment #33970|0 |1 is obsolete|| --- Comment #11 from Lawrence Velázquez larryv at macports dot org --- Created attachment 33977 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33977action=edit patch against 4.8 branch for handling deployment targets correctly Updated patch that should satisfy -Werror=sign-compare.
[Bug rtl-optimization/60079] [LRA] ICE when compiling attached case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60079 --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #7) Note my testcase is with -mabi=ilp32 too. And the reduced testcase needs -mcpu=thunderx too. I am trying to see if this fails on the trunk or only with my code changes.
[Bug c/63760] Support __func__ in PROGMEM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63760
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Target|AVR |avr
Priority|P3 |P5
--- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #1)
Why aren't read-only data being placed in progmem by default?
Suppose
char func (const char *X)
{
return *X;
}
Just that func does not alter *X does /not/ mean *X won't change in the
program. It is completely legal for a program to use func like so:
void foo (char c)
{
func (c);
c++;
func (c);
}
Hence the default linker description file locates .rodata in RAM and the
compiler may not assume data is located in flash just because a particular
function does not change it.
With a different ABI that reserved, e.g., Bit 15 of the address to tag whether
the object lives in .rodata or not, it would be possible to achieve this, but
it would also add quite some overhead to runtime and flash usage and pressure
on Z register like address space __memx does.
[Bug c/63879] New: ICE compiling Linux Kernel fs/ext3/namei.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63879
Bug ID: 63879
Summary: ICE compiling Linux Kernel fs/ext3/namei.c
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sasha.levin at oracle dot com
CC: mpolacek at gcc dot gnu.org
Created attachment 33978
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33978action=edit
Preprocessed source
I'm seeing very high memory usage followed by:
{standard input}: Assembler messages:
{standard input}:2183: Warning: end of file not at end of a line; newline
inserted
{standard input}:4163: Error: number of operands mismatch for `movq'
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
gcc: internal compiler error: Killed (program cc1)
0x40c3cc execute
../../gcc/gcc.c:2912
0x410917 driver::do_spec_on_infiles() const
../../gcc/gcc.c:7674
0x40322b driver::main(int, char**)
../../gcc/gcc.c:6911
I've bisected this issue down to:
commit 1043013c91c08e3d8cd665b3f960f658918d69fe
Author: mpolacek mpolacek@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Fri Nov 14 11:57:05 2014 +
* fold-const.c (fold_negate_expr): Don't fold INTEGER_CST if
that overflows when SANITIZE_SI_OVERFLOW is on. Guard -(-A)
folding with TYPE_OVERFLOW_SANITIZED.
* c-c++-common/ubsan/overflow-negate-3.c: New test.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@217556
138bc75d-0d04-0410-961f-82ee7
Preprocessed fs/ext3/namei.c attached.
[Bug rtl-optimization/60079] [LRA] ICE when compiling attached case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60079 --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org --- I can't get a testcase that fails with the non-modified trunk.
[Bug c/63760] Support __func__ in PROGMEM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63760 --- Comment #4 from mojo at world3 dot net --- I agree, a separate __funcP__is the best option.
[Bug ipa/63814] [4.9/5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 --- Comment #18 from H.J. Lu hjl.tools at gmail dot com --- Igor, Kirill, I confirmed r216154 is the cause of this bug. You can checkout both r216153 and r216154. You build 2 compilers and compare results. You can build a cross compiler with .../gcc/configure --enable-languages=c,c++ --disable-bootstrap --target=x86_64-apple-darwin you will see ICE. If you build the native Linux compiler, you will see run-time failure. The difference between good and bad assembly code is --- good.s2014-11-14 14:54:54.362696443 -0800 +++ bad.s2014-11-14 15:12:54.608434347 -0800 @@ -84,12 +84,12 @@ _ZN8CExample9MixinFuncEiPv: .weak_ZThn4_N8CExample9MixinFuncEiPv .type_ZThn4_N8CExample9MixinFuncEiPv, @function _ZThn4_N8CExample9MixinFuncEiPv: -.LFB13: +.LFB15: .cfi_startproc subl$4, 4(%esp) jmp.LTHUNK0 .cfi_endproc -.LFE13: +.LFE15: .size_ZThn4_N8CExample9MixinFuncEiPv, .-_ZThn4_N8CExample9MixinFuncEiPv .section .text.unlikely._ZThn4_N8CExample9MixinFuncEiPv,axG,@progbits,_ZN8CExample9MixinFuncEiPv,comdat .LCOLDE2: @@ -105,20 +105,52 @@ _ZThn4_N8CExample9MixinFuncEiPv: _Z4testR6MMixin: .LFB11: .cfi_startproc -subl$16, %esp -.cfi_def_cfa_offset 20 -movl20(%esp), %eax +pushl%ebx +.cfi_def_cfa_offset 8 +.cfi_offset 3, -8 +call__x86.get_pc_thunk.bx +addl$_GLOBAL_OFFSET_TABLE_, %ebx +subl$8, %esp +.cfi_def_cfa_offset 16 +movl16(%esp), %eax movl(%eax), %edx +movl(%edx), %edx +cmpl_ZThn4_N8CExample9MixinFuncEiPv@GOT(%ebx), %edx +jne.L10 +cmpl$48879, 12(%eax) +jne.L14 +addl$8, %esp +.cfi_remember_state +.cfi_def_cfa_offset 8 +popl%ebx +.cfi_restore 3 +.cfi_def_cfa_offset 4 +ret +.p2align 4,,10 +.p2align 3 +.L10: +.cfi_restore_state +subl$4, %esp +.cfi_def_cfa_offset 20 pushl$0 .cfi_def_cfa_offset 24 pushl$1 .cfi_def_cfa_offset 28 pushl%eax .cfi_def_cfa_offset 32 -call*(%edx) -addl$28, %esp +call*%edx +addl$16, %esp +.cfi_def_cfa_offset 16 +addl$8, %esp +.cfi_remember_state +.cfi_def_cfa_offset 8 +popl%ebx +.cfi_restore 3 .cfi_def_cfa_offset 4 ret +.L14: +.cfi_restore_state +callabort@PLT .cfi_endproc .LFE11: .size_Z4testR6MMixin, .-_Z4testR6MMixin @@ -265,11 +297,11 @@ _ZTV8CExample: .hidden__x86.get_pc_thunk.bx .type__x86.get_pc_thunk.bx, @function __x86.get_pc_thunk.bx: -.LFB14: +.LFB16: .cfi_startproc movl(%esp), %ebx ret .cfi_endproc -.LFE14: +.LFE16: .identGCC: (GNU) 5.0.0 20141013 (experimental) .section.note.GNU-stack,,@progbits Please find out why PIC register change caused this.
[Bug ipa/63814] [4.9/5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 --- Comment #19 from H.J. Lu hjl.tools at gmail dot com --- r216154 is supposed to be RTL change. But it generates quite different gimples.
[Bug ipa/63814] [5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Version|4.9.3 |5.0 Target Milestone|4.9.3 |5.0 Summary|[4.9/5 Regression] |[5 Regression] |g++.dg/ipa/pr61160-1.C |g++.dg/ipa/pr61160-1.C |fails with -m32 -fPIC |fails with -m32 -fPIC
[Bug ipa/63814] [5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814
--- Comment #20 from H.J. Lu hjl.tools at gmail dot com ---
It may be easier to debug this with a MacOS cross compiler. Where do
extra gimple statements:
@@ -96,3 +96,31 @@ MMixin::MMixin() (struct MMixin * const
}
+built-in (struct CExample * const this)
+{
+ struct CExample * const adjusted_this.8;
+ void * retval.7;
+
+ bb 2:
+ this_2 = this_1(D) + 4294967292;
+ adjusted_this.8_3 = this_2;
+ retval.7_6 = CExample::MixinFunc.constprop (adjusted_this.8_3); [tail call]
+ return retval.7_6;
+
+}
+
+
+built-in (struct CExample * const this)
+{
+ struct CExample * const adjusted_this.10;
+ void * retval.9;
+
+ bb 2:
+ this_2 = this_1(D) + 4294967292;
+ adjusted_this.10_3 = this_2;
+ retval.9_6 = CExample::MixinFunc.constprop (adjusted_this.10_3); [tail call]
+ return retval.9_6;
+
+}
+
+
come from?
[Bug ipa/63814] [5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814
--- Comment #21 from Jan Hubicka hubicka at ucw dot cz ---
+built-in (struct CExample * const this)
+{
+ struct CExample * const adjusted_this.8;
+ void * retval.7;
+
+ bb 2:
+ this_2 = this_1(D) + 4294967292;
+ adjusted_this.8_3 = this_2;
+ retval.7_6 = CExample::MixinFunc.constprop (adjusted_this.8_3); [tail call]
+ return retval.7_6;
+
+}
+
+
+built-in (struct CExample * const this)
+{
+ struct CExample * const adjusted_this.10;
+ void * retval.9;
+
+ bb 2:
+ this_2 = this_1(D) + 4294967292;
+ adjusted_this.10_3 = this_2;
+ retval.9_6 = CExample::MixinFunc.constprop (adjusted_this.10_3); [tail
call]
+ return retval.9_6;
+
+}
+
+
come from?
This is expanded thunk produce dby cgraph_node::expand_thunk
Did not look into the testcase if it should be there or not.
Honza
[Bug c/63880] New: GCC overoptimization on local arrays of size 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63880
Bug ID: 63880
Summary: GCC overoptimization on local arrays of size 1
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: petzke at teltarif dot de
Created attachment 33979
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33979action=edit
Overoptimized C code: The loop is unrolled to a single iteration, which the
compiler should not rely on, at least not in C.
In general, C code may rely on the fact, that structs are allocated
sequentially, even, if this is considered a somewhat bad coding practice. So,
if one has the following structures in C:
typedef struct {
int nargs;
char * data[1];
} arglist;
struct {
arglist args;
char * moredata[1000];
} par;
it is actually safe to access par.args.data[2] through par.args.data[1000], as
they get basically mapped onto par.moredata[0] through par.moredata[999].
However, GCC version 4.8.2 seems to believe, that this access is off limits,
and actually optimizes a simple loop:
for(i = args-nargs; --i = 0; ) {
if(args-data[i][0]) { cnt++; }
}
to run at most once, when optimizing option -O3 is used. An example of a thus
over-optimized code snippet (compile with -m64 -Wall -O3 -S on Intel x86_64 -
cannot compile into an executable though) is attached as overoptimized.c.
It suffices to introduce a pointer to arglist to turn off that
overoptimization and actually get working code again. An exmpale is added as
works.c.
I assume, that this array size optimization is not applied on pointers to
structs, as these may be malloc()ed with the well-known trick of requesting
extra space to increase the array size of the last element. However, that trick
is not reserved to malloc(), it is also available to local vars via the
combined struct shown for par above. Of course, this is only true for *C*.
C++ may rip structs apart, but C may not.
Having said that:
* The loop optimization based on array size should still be applied, if the
above example arglist is *directly* defined as a local var.
* But if that arglist is part of another struct, that defines extra data
items at the end, the compiler should not assume, that the array won't be
accessed out of bounds. I know, that this out-of-bounds access is a somewhat
bad coding style, but there is code, that still relies on these dirty old C
tricks.
[Bug c/63880] GCC overoptimization on local arrays of size 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63880 --- Comment #1 from Kai Petzke petzke at teltarif dot de --- Created attachment 33980 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33980action=edit A file with small modifications from overoptimized.c, that compiles correctly.
[Bug ipa/63814] [5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63814 --- Comment #22 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #21) This is expanded thunk produce dby cgraph_node::expand_thunk Did not look into the testcase if it should be there or not. Indeed. expand_thunk creates this when targetm.asm_out.can_output_mi_thunk returns false. Therefore a change in the back-end can cause this difference. The back-end changes might be OK, we have had a bug like this in IPA before. Do I understand correctly that this bug is an ICE with checking compiler and miscompilation with release-checking one?
