[Bug lto/50351] An internal compiler error when building gcc4.6 using -flto -fuse-linker-plugin on Win7 mingw64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50351 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org --- No reply. Seems to be solved. So I close this bug
[Bug bootstrap/60244] GCC-trunk rev.207809, Segmentation fault when executing .../xgcc -dumpspecs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60244 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org --- Hmm, I don't assume so. I stay in contact to reporter and didn't got this issue reported anymore. So I close it. Please don't hesitate to open a new bug with more details to reproduce, if issue still exists.
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #16 from Kai Tietz ktietz at gcc dot gnu.org --- Hmm, this issue seems to be fixed. I close this bug. Please don't hesitate to open new bug for it, iff issue still exists.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #36 from Kai Tietz ktietz at gcc dot gnu.org --- Well, I guess that you missed to reconfigure gcc. By checking current source is the include of ftw.h guarded by HAVE_FTW_H check, which get defined by configure if header is found.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #37 from Kai Tietz ktietz at gcc dot gnu.org --- I confirm that in libgcc we still have an issue ... Could you please make a new report for libgcc's libgcov-util.c for it. Thanks in advance
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #30 from Kai Tietz ktietz at gcc dot gnu.org --- Yes, this patch slipped under my radar. It would be good if you - Rainer - would have pinged on it. As far as I recalled I awaited at that time a full patch by Rong on this subject. (See comment #16 and after that). Nevertheless patch looks ok. I will give it some testing and will apply it after that. The change to undef mkdir in libgcc's part of the patch looks to me being the real patch. The patch in gcc's part is more cosmetic part getting rid of this (also mentioned to Rong too) wrong _WIN32 check.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #27 from Kai Tietz ktietz at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #26) Instead of the #undef mkdir you'd IMHO better just use (mkdir) (filename) in the second case. Anyway, if you've posted your patch to gcc-patches, you should be pinging it until it is reviewed. Kai, can you please have a look? Sure, I will have a look. Was this patch sent to ML? If so I am sorry for not noticing it. Could you please ping it?
[Bug libquadmath/58327] Problem of quadmath in connection with SDL2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58327 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org --- This sounds a bit like an issue with OP-specific invocation of ld. How are you invoke the linker?
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #33 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Tue Feb 10 14:14:58 2015 New Revision: 220584 URL: https://gcc.gnu.org/viewcvs?rev=220584root=gccview=rev Log: 2015-02-10 Rainer Emrich rai...@emrich-ebersheim.de PR gcov-profile/61889 * gcov-tool.c: Remove wrong #if !defined(_WIN32) Modified: trunk/gcc/ChangeLog trunk/gcc/gcov-tool.c
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #34 from Kai Tietz ktietz at gcc dot gnu.org --- Fixed.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #32 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Tue Feb 10 14:13:13 2015 New Revision: 220582 URL: https://gcc.gnu.org/viewcvs?rev=220582root=gccview=rev Log: 2015-02-10 Rainer Emrich rai...@emrich-ebersheim.de PR gcov-profile/61889 * libgcc/libgcov-driver-system.c: undefine clashing macro for mkdir. Modified: trunk/libgcc/ChangeLog trunk/libgcc/libgcov-driver-system.c
[Bug c++/65390] ICE in strip_typedefs, at cp/tree.c:1361
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65390 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code CC||ktietz at gcc dot gnu.org --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- This sample is undefined behavior. It will use delete on the allocated memory, and not delete [] as it would need. Additionally the type 'int [n]' is no valid type for template argument.
[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-17 Ever confirmed|0 |1 --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org --- This patch is clear stage 1 material. Patch itself looks ok, but raises a completely different question. Modern versions of mingw provides all Interlocked-functions, so we might want to use this instead. The argument about Win95/98 compatibility is actually pretty borged, as we have already in some of gcc's target-libraries strong requirements of using at least NT 4.0, and/or even more modern.
[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109 --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org --- I agree that we change it to #define __GTHR_W32_InterlockedCompareExchange InterlockedCompareExchange not sure if we actually should error out here at all. We might want to remove instead the use of __GTHREAD_I486_INLINE_LOCK_PRIMITIVES completely.
[Bug c++/56636] strange interaction of dynamic_cast and unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56636 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org --- So tested it for 4.8 (branch), 4.9 (branch), and 5.0 (trunk). I can't reproduce this ICE, so I close this bug as fixed worksforme.
[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109 --- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org --- (In reply to David from comment #8) (In reply to Kai Tietz from comment #7) The first code block in comment #6 is what is in the code now. As you can see, it already has the #define you are describing. I don't understand what you mean by change it to this, since it is already there. Are you suggesting we delete the entire #ifdef __GTHREAD_I486_INLINE_LOCK_PRIMITIVES block and replace it with the single #define? Right, this I suggest. I would be ok with that. Using the #error (the second code block in comment #6) seemed like a more backward-compatible way to do this, since it would tell people what has happened and what to do to fix it rather than (silently) assuming we know what they want to do. If a target doesn't provide the Interlocked-API, build with fail caused by it. I don't think we need to error out on such cases. (We don't try to cover win 3.14 incompatibilities, so why we should start for Windows 9X?) But I am ok with either of these two solutions.
[Bug c++/17729] [4.8/4.9/5 Regression] Duplicate __attribute__((deprecated)) warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||ktietz at gcc dot gnu.org --- Comment #32 from Kai Tietz ktietz at gcc dot gnu.org --- We call function warn_deprecated_use twice within finish_id_expression. Once indirectly via mark_used, and the second time directly. So by checking if TREE_USED (t) is false this double-warning should be omitted. Testing right now following patch: Index: semantics.c === --- semantics.c (Revision 221533) +++ semantics.c (Arbeitskopie) @@ -3649,7 +3668,7 @@ finish_id_expression (tree id_expression, /* Handle references (c++/56130). */ tree t = REFERENCE_REF_P (decl) ? TREE_OPERAND (decl, 0) : decl; - if (TREE_DEPRECATED (t)) + if (TREE_DEPRECATED (t) !TREE_USED (t)) warn_deprecated_use (t, NULL_TREE); return decl;
[Bug middle-end/61207] [4.9 Regression] Win64 gcc 4.9.0: ICE in in expand_expr_addr_expr_1 at -Os compiling some C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61207 --- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org --- well, it might be same issue, but on x64 target the testcase of comment #6 works without issues. As SRA seems to be involved here, the changes on trunk for DOM might be the solution.
[Bug preprocessor/65238] [5 Regression] __has_attribute is not handled properly with -traditional-cpp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65238 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org --- Well, the new ICE (with your patch applied) is a call off free on a damaged/wrong pointer for macro. For testing I disabled free for mc-pointer in question, but this leads to new issues about too big text-buffer containing random values. So I guess we have here an inconsistency about traditional whitespace-handling and none-traditional one.
[Bug c++/65323] [4.8/4.9/5 Regression] duplicate -Wzero-as-null-pointer-constant warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65323 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- Hmm, the issue seems to be that we emit within check_default_argument () two times the call to maybe_warn_zero_as_null_pointer_constant (). Once indirectly via perform_implicit_conversion_flags () call, and then later on directly within if-condition for returning nullptr_node. It seems that second call is superflous in terms of warning. So I suggest the following patch: Index: decl.c === --- decl.c (Revision 221277) +++ decl.c (Arbeitskopie) @@ -11231,7 +11233,8 @@ check_default_argument (tree decl, tree arg, tsub TYPE_PTR_OR_PTRMEM_P (decl_type) null_ptr_cst_p (arg) (complain tf_warning) - maybe_warn_zero_as_null_pointer_constant (arg, input_location)) + c_inhibit_evaluation_warnings == 0 + !NULLPTR_TYPE_P(TREE_TYPE (arg))) return nullptr_node; /* [dcl.fct.default]
[Bug libgcj/52579] [4.8/4.9/5 regression] i386_w32_fallback_frame_state should care ffi raw-closure stub function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52579 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-03-12 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org --- This issue seems to be fixed in 5.0 by Richard's work on libffi. Could you please check, if issue is fixed for you?
[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972 --- Comment #10 from Kai Tietz ktietz at gcc dot gnu.org --- I agree that suggested patch changes here behavior on non LP64 targets. Nevertheless it would be something to live by until we reach stage 1 to address this more accurate. To us uintptr_t is by idea ok, just have the weakness that size_t not necessarily has same precision as uintptr_t. If gomp maintainer will say that inttypes.h header use and casting to uintptr_t would be ok for them, I agree. A real solution would be to add in configure a test for used size_t printf-formatter sign, and then use it in source. For gnu-style width-specifier is 'z', for ms-style it is 'I'.
[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972 --- Comment #17 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Wed Mar 25 15:05:02 2015 New Revision: 221665 URL: https://gcc.gnu.org/viewcvs?rev=221665root=gccview=rev Log: PR libgomp/64972 * oacc-parallel.c (GOACC_parallel): Use PRIu64 if available. (GOACC_data_start): Likewise. * target.c (gomp_map_vars): Likewise. Modified: trunk/libgomp/ChangeLog trunk/libgomp/oacc-parallel.c trunk/libgomp/target.c
[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Kai Tietz ktietz at gcc dot gnu.org --- Fixed on trunk.
[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-25 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- Yeah, I noticed such failures too. AFAI researched them, they are related to out-of-stack issues. The problem seems to be that within lto a lot of vec-s are passed on stack and lead for stack-limited targets easily to out-of-stack issues. Not sure if this is here really the reason, but my gut feeling would say so. Nevertheless I can confirm this ice
[Bug target/65560] [Regression 5] pr24683.c:11:1: internal compiler error: in extract_insn, at recog.c:2343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65560 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-25 CC||ktietz at gcc dot gnu.org Summary|pr24683.c:11:1: internal|[Regression 5] |compiler error: in |pr24683.c:11:1: internal |extract_insn, at|compiler error: in |recog.c:2343|extract_insn, at ||recog.c:2343 Ever confirmed|0 |1 --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- confirmed.
[Bug target/65564] [Regression 5] builtin-bnd-narrow-ptr-bounds-2-nov.c:15:1: internal compiler error: in simplify_subreg, at simplify-rtx.c:5745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65564 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-25 CC||ktietz at gcc dot gnu.org Target Milestone|--- |5.0 Summary|builtin-bnd-narrow-ptr-boun |[Regression 5] |ds-2-nov.c:15:1: internal |builtin-bnd-narrow-ptr-boun |compiler error: in |ds-2-nov.c:15:1: internal |simplify_subreg, at |compiler error: in |simplify-rtx.c:5745 |simplify_subreg, at ||simplify-rtx.c:5745 Ever confirmed|0 |1 --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- Confirmed. Backtrace: #1 0x010771df in fancy_abort ( file=file@entry=0x12d0e80 inchash::add_rtx(rtx_def const*, inchash::hash): :__FUNCTION__+8 ../../gcc/gcc/simplify-rtx.c, line=line@entry=5745, function=function@entry=0x12d170a simplify_subreg(machine_mode, rtx_def*, m achine_mode, unsigned int)::__FUNCTION__ simplify_subreg) at ../../gcc/gcc/diagnostic.c:1291 #2 0x008fa8dd in simplify_subreg (outermode=outermode@entry=BLKmode, op=op@entry=0xfff5b2c0, innermode=innermode@entry=DImode, byte=byte@entry=0) at ../../gcc/gcc/simplify-rtx.c:5745 #3 0x008fac8f in simplify_gen_subreg (outermode=BLKmode, op=0xfff5b2c0, innermode=DImode, byte=byte@entry=0) at ../../gcc/gcc/simplify-rtx.c:5967 #4 0x006ffb7f in ix86_delegitimize_address (x=optimized out) at ../../gcc/gcc/config/i386/i386.c:14914 #5 0x00ead454 in adjust_mems (loc=0xfff5b7f0, old_rtx=0x0, data=0xc1aa890) at ../../gcc/gcc/var-tracking.c:1057 #6 0x008fe4fc in simplify_replace_fn_rtx (x=0xfff5b7f0, old_rtx=old_rtx@entry=0x0, fn=fn@entry=0xead280 adjust_mems(rtx, const_rtx, void*), data=data@entry=0xc1aa890) at ../../gcc/gcc/simplify-rtx.c:467 #7 0x008fe038 in simplify_replace_fn_rtx (x=0xfff5b800, assert happens due on call of simplify_subreg the outermode is a BLKmode. I think we should check within simplify_get_subreg for outermode == BLKmode and avoid calling of simplify_subreg for it.
[Bug target/65561] avx512fintrin.h:5344:1: internal compiler error: in curr_insn_transform, at lra-constraints.c:3494
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65561 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- Hmm, this failure I can't reproduce. But I have right now some local changes in tree, so I will retry without them.
[Bug target/65564] [Regression 5] builtin-bnd-narrow-ptr-bounds-2-nov.c:15:1: internal compiler error: in simplify_subreg, at simplify-rtx.c:5745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65564 --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- As more I look as more I guess it is related to recent pic-code changes in i386.c for Darwin. I will check at what places we now assume that for PIC (especially for UNSPEC UNSPEC_PCREL) we assume that x64-code only uses path with GOT-table for PIC.
[Bug target/65568] ptrmem8.C:9:9: internal compiler error: in build_ptrmemfunc, at cp/typeck.c:7940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65568
--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org ---
Issue is related to -fms-extensions. This option is for mingw targets on by
default. By the following patch issue in testsuite gets solved (it makes sense
to apply this patch for such testcases, as here indeed -fno-ms-extensions is
tested).
The point - as already noticed and spoken with Jason - that some C++-extensions
are buggy in C++-FE.
Index: ptrmem8.C
===
--- ptrmem8.C (Revision 221690)
+++ ptrmem8.C (Arbeitskopie)
@@ -1,5 +1,6 @@
// PR c++/33844
// { dg-do compile }
+// { dg-additional-options -fno-ms-extensions { target *-*-mingw* } }
struct A {};
[Bug target/65562] chkp-lifetime-1.c:17:1: internal compiler error: in size_binop_loc, at fold-const.c:1761
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65562 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||ktietz at gcc dot gnu.org --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- Backtrace is: Can be reproduced manually with: gcc.exe -S -o t.s chkp-lifetime-1.c -O2 -fcheck-pointer-bounds -mmpx #0 internal_error ( gmsgid=gmsgid@entry=0x155babe void va_heap::reservefcache::line_info(vec fcache::line_info, va_heap, vl_embed*, unsigned int, bool)::__FUNCTION__+187 in %s, at %s:%d) at ../../gcc/gcc/diagnostic.c:1217 #1 0x01077daf in fancy_abort ( file=file@entry=0x12b9f2c void va_heap::reserveggc_root_tab const*(vecgg c_root_tab const*, va_heap, vl_embed*, unsigned int, bool)::__FUNCTION__+1854 ../../gcc/gcc/fold-const.c, line=line@entry=1761, function=function@entry=0x12bd002 size_binop_loc(unsigned int, tree_code, t ree_node*, tree_node*)::__FUNCTION__ size_binop_loc) at ../../gcc/gcc/diagnostic.c:1291 #2 0x007e554c in size_binop_loc (loc=loc@entry=0, code=code@entry=MINUS_EXPR, arg0=arg0@entry=0xffe4c300, arg1=0xffef0420) at ../../gcc/gcc/fold-const.c:1760 #3 0x006765ef in chkp_output_static_bounds (stmts=0xc1baac8, var=optimized out, bnd_var=0xffe60580) at ../../gcc/gcc/tree-chkp.c:1024 #4 chkp_finish_file () at ../../gcc/gcc/tree-chkp.c:3735 #5 0x0077df4b in compile_file () at ../../gcc/gcc/toplev.c:627 #6 0x01199823 in do_compile () at ../../gcc/gcc/toplev.c:2076 #7 toplev::main (this=this@entry=0xc1bab8e, argc=argc@entry=8, argv=argv@entry=0xc1babbc) at ../../gcc/gcc/toplev.c:2174 #8 0x012096d2 in main (argc=8, argv=0xc1babbc) at ../../gcc/gcc/main.c:39
[Bug c++/65573] 13908.C:20:33: internal compiler error: in cp_build_addr_expr_1, at cp/typeck.c:5527
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65573
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
CC||ktietz at gcc dot gnu.org
--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org ---
Confirmed.
#0 internal_error (
gmsgid=gmsgid@entry=0x1763f5e lang_independent_params+3774 in %s, at
%s:%
d) at ../../gcc/gcc/diagnostic.c:1217
#1 0x0125459f in fancy_abort (
file=file@entry=0x141add5 gt_ggc_r_gt_cp_rtti_h+437
../../gcc/gcc/cp/type
ck.c, line=line@entry=5531,
function=function@entry=0x141da23 cp_build_addr_expr_1(tree_node*, bool,
in
t)::__FUNCTION__ cp_build_addr_expr_1) at ../../gcc/gcc/diagnostic.c:1291
#2 0x0057ef13 in cp_build_addr_expr_1 (arg=optimized out,
strict_lvalue=optimized out, complain=3)
at ../../gcc/gcc/cp/typeck.c:5531
#3 0x0057f34c in cp_build_addr_expr_strict (complain=3, arg=0xffc90eb8)
at ../../gcc/gcc/cp/typeck.c:5628
#4 build_x_unary_op (loc=loc@entry=2582, code=code@entry=ADDR_EXPR,
xarg=0xffc90eb8, complain=complain@entry=3)
at ../../gcc/gcc/cp/typeck.c:5265
#5 0x005418b2 in cp_parser_unary_expression (parser=parser@entry=0xffeb04b0,
pidk=optimized out, address_p=address_p@entry=22, cast_p=true,
decltype_p=false) at ../../gcc/gcc/cp/parser.c:7418
#6 0x005420e4 in cp_parser_cast_expression (parser=parser@entry=0xffeb04b0,
address_p=address_p@entry=false, cast_p=cast_p@entry=true,
decltype_p=true, decltype_p@entry=false, pidk=pidk@entry=0x0)
at ../../gcc/gcc/cp/parser.c:8083
#7 0x00542193 in cp_parser_cast_expression (parser=parser@entry=0xffeb04b0,
address_p=address_p@entry=false, cast_p=cast_p@entry=false,
decltype_p=decltype_p@entry=false, pidk=pidk@entry=0x0)
at ../../gcc/gcc/cp/parser.c:8051
#8 0x00542459 in cp_parser_binary_expression (
parser=parser@entry=0xffeb04b0, cast_p=optimized out,
no_toplevel_fold_p=no_toplevel_fold_p@entry=false,
decltype_p=decltype_p@entry=false, prec=prec@entry=PREC_NOT_OPERATOR,
pidk=pidk@entry=0x0) at ../../gcc/gcc/cp/parser.c:8185
#9 0x00542d60 in cp_parser_assignment_expression (
parser=parser@entry=0xffeb04b0, pidk=pidk@entry=0x0,
cast_p=cast_p@entry=false, decltype_p=decltype_p@entry=false)
at ../../gcc/gcc/cp/parser.c:8442
#10 0x005431e6 in cp_parser_constant_expression (parser=0xffeb04b0,
allow_non_constant_p=optimized out, non_constant_p=0xd60a63f)
at ../../gcc/gcc/cp/parser.c:8688
#11 0x00542ef0 in cp_parser_assignment_expression (
parser=parser@entry=0xffeb04b0, pidk=pidk@entry=0x0,
cast_p=cast_p@entry=false, decltype_p=decltype_p@entry=false)
at ../../gcc/gcc/cp/parser.c:8461
#12 0x00545a56 in cp_parser_expression (parser=parser@entry=0xffeb04b0,
pidk=pidk@entry=0x0, cast_p=cast_p@entry=false,
decltype_p=decltype_p@entry=false) at ../../gcc/gcc/cp/parser.c:8596
#13 0x00546267 in cp_parser_expression_statement (
in_statement_expr=in_statement_expr@entry=0x0)
at ../../gcc/gcc/cp/parser.c:10005
#14 0x0055e123 in cp_parser_statement (parser=parser@entry=0xffeb04b0,
in_statement_expr=in_statement_expr@entry=0x0,
in_compound=in_compound@entry=true, if_p=if_p@entry=0x0)
at ../../gcc/gcc/cp/parser.c:9854
#15 0x0055f0c1 in cp_parser_statement_seq_opt (
parser=parser@entry=0xffeb04b0,
in_statement_expr=in_statement_expr@entry=0x0)
at ../../gcc/gcc/cp/parser.c:10128
#16 0x0055f1ff in cp_parser_compound_statement (
parser=parser@entry=0xffeb04b0,
in_statement_expr=in_statement_expr@entry=0x0, in_try=in_try@entry=false,
function_body=function_body@entry=true) at ../../gcc/gcc/cp/parser.c:10082
#17 0x0055f45c in cp_parser_function_body (in_function_try_block=false,
parser=0xffeb04b0) at ../../gcc/gcc/cp/parser.c:19223
#18 cp_parser_ctor_initializer_opt_and_function_body (
parser=parser@entry=0xffeb04b0,
in_function_try_block=in_function_try_block@entry=false)
at ../../gcc/gcc/cp/parser.c:19259
#19 0x00560480 in cp_parser_function_definition_after_declarator (
parser=parser@entry=0xffeb04b0, inline_p=inline_p@entry=false)
at ../../gcc/gcc/cp/parser.c:23501
#20 0x00561224 in cp_parser_function_definition_from_specifiers_and_declarator
...
Another case related to -fms-extensions switch. Testcase assume that option is
off. so following patch papers over this issue:
Index: 13908.C
===
--- 13908.C (Revision 221690)
+++ 13908.C (Arbeitskopie)
@@ -1,4 +1,5 @@
// { dg-do assemble }
+// { dg-additional-options -fno-ms-extensions -pedantic { target *-*-mingw*
} }
// 981203 bkoz
// g++/13908
[Bug target/65572] ptrmem5.C:7:26: internal compiler error: in gimplify_expr, at gimplify.c:8629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65572
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
CC||ktietz at gcc dot gnu.org
--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org ---
Confirmed.
Backtrace is:
#0 internal_error (
gmsgid=gmsgid@entry=0x1763f5e lang_independent_params+3774 in %s, at
%s:%
d) at ../../gcc/gcc/diagnostic.c:1217
#1 0x0125459f in fancy_abort (
file=file@entry=0x14c6840 tls_model_names+40 ../../gcc/gcc/gimplify.c,
l
ine=line@entry=8629,
function=function@entry=0x14c8288 gimplify_expr(tree_node**,
gimple_stateme
nt_base**, gimple_statement_base**, bool (*)(tree_node*), int)::__FUNCTION__
g
implify_expr) at ../../gcc/gcc/diagnostic.c:1291
#2 0x009fedcc in gimplify_expr (expr_p=expr_p@entry=0xffc90e68,
pre_p=pre_p@entry=0xd60a7e8, post_p=0xd60a6d0, post_p@entry=0x0,
gimple_test_f=gimple_test_f@entry=0x9f0be0 is_gimple_stmt(tree),
fallback=fallback@entry=0) at ../../gcc/gcc/gimplify.c:8629
#3 0x00a0149a in gimplify_stmt (stmt_p=0xffc90e68,
seq_p=seq_p@entry=0xd60a7e8) at ../../gcc/gcc/gimplify.c:5514
#4 0x009fc559 in gimplify_cleanup_point_expr (pre_p=0xd60a89c,
expr_p=0xffe75cf0) at ../../gcc/gcc/gimplify.c:5290
#5 gimplify_expr (expr_p=expr_p@entry=0xffe75cf0,
pre_p=pre_p@entry=0xd60a89c, post_p=0xd60a7c0, post_p@entry=0x0,
gimple_test_f=gimple_test_f@entry=0x9f0be0 is_gimple_stmt(tree),
fallback=fallback@entry=0) at ../../gcc/gcc/gimplify.c:8260
#6 0x00a0149a in gimplify_stmt (stmt_p=stmt_p@entry=0xffe75cf0,
seq_p=seq_p@entry=0xd60a89c) at ../../gcc/gcc/gimplify.c:5514
#7 0x00a030af in gimplify_body (fndecl=fndecl@entry=0xffe75c80,
This is once again an issue related to -fms-extensions switch. By turning this
option off, ICE disappears.
So suggested patch for the testcase (as again we are assuming here
-fno-ms-extensions):
Index: ptrmem5.C
===
--- ptrmem5.C (Revision 221690)
+++ ptrmem5.C (Arbeitskopie)
@@ -1,4 +1,5 @@
// PR c++/15696
+// { dg-additional-options -fno-ms-extensions { target *-*-mingw* } }
[Bug target/65566] thread-local-var-1-lbv.c:34:1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65566 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||ktietz at gcc dot gnu.org --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- Confirmed. We see an segfault (caused by cfun being NULL). Program received signal SIGSEGV, Segmentation fault. 0x00cee933 in lower_emutls_function_body (node=optimized out) at ../../gcc/gcc/tree-emutls.c:644 644 FOR_EACH_BB_FN (d.bb, cfun) (gdb) print cfun $1 = (function *) 0x0 (gdb) bt #0 0x00cee933 in lower_emutls_function_body (node=optimized out) at ../../gcc/gcc/tree-emutls.c:644 #1 ipa_lower_emutls () at ../../gcc/gcc/tree-emutls.c:810 #2 (anonymous namespace)::pass_ipa_lower_emutls::execute (this=0x800524b0) at ../../gcc/gcc/tree-emutls.c:850 #3 0x007354b5 in execute_one_pass (pass=pass@entry=0x800524b0) at ../../gcc/gcc/passes.c:2330 #4 0x00736010 in execute_ipa_pass_list (pass=0x800524b0) at ../../gcc/gcc/passes.c:2729 #5 0x0074253d in ipa_passes () at ../../gcc/gcc/cgraphunit.c:2154 #6 symbol_table::compile (this=this@entry=0xfff2) at ../../gcc/gcc/cgraphunit.c:2295 #7 0x007447af in symbol_table::finalize_compilation_unit (this=0xfff2) at ../../gcc/gcc/cgraphunit.c:2444 #8 0x0041fbbc in c_write_global_declarations () at ../../gcc/gcc/c/c-decl.c:10801 #9 0x0077dd37 in compile_file () at ../../gcc/gcc/toplev.c:608 #10 0x01199823 in do_compile () at ../../gcc/gcc/toplev.c:2076 #11 toplev::main (this=this@entry=0xc1bab8e, argc=argc@entry=7, argv=argv@entry=0xc1babbc) at ../../gcc/gcc/toplev.c:2174 #12 0x012096d2 in main (argc=7, argv=0xc1babbc) at ../../gcc/gcc/main.c:39
[Bug target/65581] [5 Regression] testsuite lto issue: multiple definition of `main', undefined reference to `WinMain'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65581 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- This issue is related to building of crt. so it doesn't have something to do with gcc's lto in first hand.
[Bug target/65523] ICE: in gimple_op, at gimple.h:2270 with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65523 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-23 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- Confirmed
[Bug bootstrap/15212] [4.8/4.9/5 Regression] bootstrap fails on interix3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #48 from Kai Tietz ktietz at gcc dot gnu.org --- The Interix target got obsoleted at 4.6 (see https://gcc.gnu.org/gcc-4.6/changes.html ). Therefore I close this bug as WONTFIX. If status for Interix changes in future, feel free to reopen this bug.
[Bug c++/65277] [5 Regression] ice in get_untransformed_body with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65277 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-02 CC||ktietz at gcc dot gnu.org, ||maxim at trivialbugs dot com Ever confirmed|0 |1 --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- Issue seems to be happend in expand_all_functions. In prior versions we called expand_function, but now we are calling directly expand (). Expand () itself makes use of function get_untransformed_body, which checks for in-LTO-mode, which of course fails. Anyway the most funny thing here is that this change is not mentioned in any ChangeLog. It is caused by r214422
[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65130 --- Comment #12 from Kai Tietz ktietz at gcc dot gnu.org --- I confirm that bug is fixed with that patch. Only for the case that trying to link with objects created with prior revision will still fail. Later might be acceptable.
[Bug ipa/61916] Internal compiler error in symtab_nonoverwritable_alias with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61916 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org --- Already fixed. A dup of 64212 *** This bug has been marked as a duplicate of bug 64212 ***
[Bug target/64212] [4.9/5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64212 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||timothygu99 at gmail dot com --- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org --- *** Bug 61916 has been marked as a duplicate of this bug. ***
[Bug c++/65277] [5 Regression] ice in get_untransformed_body with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65277 --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- (In reply to Marek Polacek from comment #2) 221040(In reply to Kai Tietz from comment #1) It is caused by r214422 No, I think this started with r221040. Yes, it got shown with r221040. Nevertheless code-change mentioned before happend in r214256 (svn blame lied). So I am testing right now: Index: cgraphunit.c === --- cgraphunit.c(Revision 221103) +++ cgraphunit.c(Arbeitskopie) @@ -1847,7 +1847,8 @@ cgraph_node::expand (void) announce_function (decl); process = 0; gcc_assert (lowered); - get_untransformed_body (); + if (in_lto_p) +get_untransformed_body (); /* Generate RTL for the body of DECL. */
[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038 --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Fri Feb 27 13:19:38 2015 New Revision: 221059 URL: https://gcc.gnu.org/viewcvs?rev=221059root=gccview=rev Log: PR target/65038 * config.in: Regenerated. * configure: Likewise. * configure.ac (AC_HEADER_STDC): Added explicit. (AC_CHECK_HEADERS): Check for default headers plus for ftw.h header. * libgcov-util.c (gcov_read_profile_dir): Disable use of ftw-function, if header is not found. (ftw_read_file): Likewise. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config.in trunk/libgcc/configure trunk/libgcc/configure.ac trunk/libgcc/libgcov-util.c
[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org --- Now fixed without regression. Problem was that header-checks were done before gcc-no-execution.
[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org --- I had to revert patch as on boostrap libgcc now tries to test ability to compile, which is of course not possible. Other miracle is that configure.ac and actual present configure seem to be divergent ...
[Bug c/35330] [4.8/4.9/5 regression] ICE with invalid pragma weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35330 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Kai Tietz ktietz at gcc dot gnu.org --- I don't intend to backport this change. therefore I close as fixed.
[Bug tree-optimization/65216] [5 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65216 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||madars+gccbug at gmail dot com --- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org --- *** Bug 65307 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/65307] [4.9 Regression] Incorrect optimization breaks basic arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- This is a duplicate of PR/65216. Underlying issue is in reassoc1-pass. This issue is fixed for 5.0 *** This bug has been marked as a duplicate of bug 65216 ***
[Bug tree-optimization/65307] [4.9 Regression] Incorrect optimization breaks basic arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307
--- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org ---
Well, it looked like the same issue by inspection dumps, as folding issue
happens in reassoc-pass. Of course it might be that forward-prop patch is the
actual issue.
I noticed for -O3 on 4.9.x that valid computation (dse1):
...
g (const unsigned int from_f)
{
const unsigned int thirty_four;
unsigned int _3;
unsigned int _4;
unsigned int global.0_8;
unsigned int _9;
unsigned int _10;
bb 2:
global.0_8 = global;
_9 = global.0_8 * 2;
_3 = _9 * 2;
_10 = _9 * 3;
_4 = _10 * 5;
thirty_four_5 = _3 + _4;
...
Shows after reassoc1 pass:
...
g (const unsigned int from_f)
{
const unsigned int thirty_four;
unsigned int _3;
unsigned int _4;
unsigned int global.0_8;
unsigned int _9;
unsigned int _10;
bb 2:
global.0_8 = global;
_9 = global.0_8 * 2;
_4 = 15;
_3 = _4 + 2;
_10 = _9 * _3;
thirty_four_5 = _10;
...
so it seems to be the forward-propagate patch.
Sorry for the noise
[Bug target/57982] GetModuleHandle in __register_frame_info causes abort on unload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57982 --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- The problem here is the use of weak on pe-coff. The change you see on gcc is just addressing the fact that for 64-bit the weak symbol never can get 0 due relocation-limitations. We try to address this. On the other hand we have here to work-a-round a binutils quirk that default-implementation of a weak is used in its definition TU always, even if a none-weak symbol is present in a different TU. This can be worked-a-round by moving default-implementation into different TU. Hope this answered some of your questions. (anyway IMHO, in general we should have used here a variant without any weak-symbol)
[Bug c/35330] [4.8/4.9/5 regression] ICE with invalid pragma weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35330 --- Comment #13 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Fri Feb 27 10:44:43 2015 New Revision: 221053 URL: https://gcc.gnu.org/viewcvs?rev=221053root=gccview=rev Log: 2015-02-27 Kai Tietz kti...@redhat.com PR c/35330 * c-pragma.c (handle_pragma_weak): Do not try to create weak/alias of declarations not being function, or variable declarations. 2015-02-27 Kai Tietz kti...@redhat.com PR c/35330 * gcc.dg/weak/weak-17.c: New file. Added: trunk/gcc/testsuite/gcc.dg/weak/weak-17.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-pragma.c trunk/gcc/testsuite/ChangeLog
[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038 --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Fri Feb 27 12:05:02 2015 New Revision: 221055 URL: https://gcc.gnu.org/viewcvs?rev=221055root=gccview=rev Log: PR target/65038 * config.in: Regenerated. * configure: Likewise. * configure.ac (AC_HEADER_STDC): Add explicit. (AC_CHECK_HEADERS): Check for default headers plus for ftw.h one. * libgcov-util.c (gcov_read_profile_dir): Disable use of ftw-function, if header not found. (ftw_read_file): Don't translate if ftw header isn't present. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config.in trunk/libgcc/configure trunk/libgcc/configure.ac trunk/libgcc/libgcov-util.c
[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- Bootstrap fixed
[Bug target/65288] [5 Regression] ICE (in address_matters_p, at symtab.c:1908) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65288 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- This looks a bit like a duplicate of PR/65287
[Bug middle-end/63608] [4.8/4.9 Regression] error: type mismatch in binary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63608 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- Issue is fixed on 5.0 gcc. But confirm that issue still exists on 4.9 branch.
[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61917 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Kai Tietz ktietz at gcc dot gnu.org --- Fixed on trunk and 4.9
[Bug tree-optimization/61917] [4.9/5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61917 --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Wed Feb 25 13:36:00 2015 New Revision: 220966 URL: https://gcc.gnu.org/viewcvs?rev=220966root=gccview=rev Log: 2015-02-25 Richard Biener rguent...@suse.de Kai Tietz kti...@redhat.com PR tree-optimization/61917 * tree-vect-loop.c (vectorizable_reduction): Allow vect_internal_def without reduction to exit graceful. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/61917] [4.9/5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61917 --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Wed Feb 25 13:42:12 2015 New Revision: 220967 URL: https://gcc.gnu.org/viewcvs?rev=220967root=gccview=rev Log: PR tree-optimization/61917 * gcc.dg/vect/vect-pr61917.c: New file. Added: trunk/gcc/testsuite/gcc.dg/vect/vect-pr61917.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61917 --- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Wed Feb 25 14:12:46 2015 New Revision: 220968 URL: https://gcc.gnu.org/viewcvs?rev=220968root=gccview=rev Log: 2015-02-25 Richard Biener rguent...@suse.de Kai Tietz kti...@redhat.com Backport from mainline PR tree-optimization/61917 * tree-vect-loop.c (vectorizable_reduction): Allow vect_internal_def without reduction to exit graceful. ChangeLog testsuite/ 2015-02-25 Kai Tietz kti...@redhat.com Backport from mainline PR tree-optimization/61917 * gcc.dg/vect/vect-pr61917.c: New file. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/vect-pr61917.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-vect-loop.c
[Bug target/64212] [4.9/5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64212 --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org --- Tested patch posted at https://gcc.gnu.org/ml/gcc-patches/2015-02/msg01502.html
[Bug target/64212] [4.9/5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64212 --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #5) Well, can someone overwrite dllimport symbol by different definition? If not, it is a bug of decl_binds_to_current_def_p to return false here. If it can be inteprposed, I think the function symtab_node::noninterposable_alias should remove dllimport attribute on the alias created and so should symtab_node::make_decl_local Thanks Honza, well, dllimport symbol can be interposed ... well their function-stub can. So variant two seems to be the right thing to do. I am about to prepare a patch for this ...
[Bug target/64212] [4.9/5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64212 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Kai Tietz ktietz at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/65204] Aligned address optimization not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65204 --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Wed Feb 25 16:28:28 2015 New Revision: 220981 URL: https://gcc.gnu.org/viewcvs?rev=220981root=gccview=rev Log: Precommit code-change of patch by Richard Biener for gcc 6.0 2015-02-25 Richard Biener rguent...@suse.de PR tree-optimization/65204 * tree-ssa-ccp.c (evaluate_stmt): Always evaluate address takens for bit-CCP. Modified: branches/c++-delayed-folding/gcc/tree-ssa-ccp.c
[Bug target/64212] [4.9/5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64212 --- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Wed Feb 25 16:44:26 2015 New Revision: 220982 URL: https://gcc.gnu.org/viewcvs?rev=220982root=gccview=rev Log: PR target/64212 * symtab.c (symtab::make_decl_local): Set DECL_IMPORT_P explicit to 0. (symtab::noninterposable_alias): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/symtab.c
[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61917 --- Comment #12 from Kai Tietz ktietz at gcc dot gnu.org --- Hmm, just retested it for gcc's trunk. Can't reproduce it. I will retest with current trunk, I might have a different patch in tree, which makes the difference here. Additionally, what target you are using?
[Bug target/64212] [4.9/5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64212 --- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Wed Feb 25 16:46:34 2015 New Revision: 220983 URL: https://gcc.gnu.org/viewcvs?rev=220983root=gccview=rev Log: Merged from mainline PR target/64212 * symtab.c (symtab::make_decl_local): Set DECL_IMPORT_P explicit to 0. (symtab::noninterposable_alias): Likewise. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/symtab.c
[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61917 --- Comment #14 from Kai Tietz ktietz at gcc dot gnu.org --- (In reply to H.J. Lu from comment #13) (In reply to Kai Tietz from comment #12) Hmm, just retested it for gcc's trunk. Can't reproduce it. I will retest with current trunk, I might have a different patch in tree, which makes the difference here. Additionally, what target you are using? Also happened on 4.9 branch: So for me it doesn't happen on trunk, so the Also seems to me something special for you. I will recheck 4.9, as here we might have a regression I didn't caught ...
[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61917 --- Comment #19 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Wed Feb 25 18:21:37 2015 New Revision: 220987 URL: https://gcc.gnu.org/viewcvs?rev=220987root=gccview=rev Log: PR tree-optimization/61917 * tree-vect-loop.c (vectorizable_reduction): Handle obvious case that reduc_def_stmt is null. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61917 --- Comment #17 from Kai Tietz ktietz at gcc dot gnu.org --- Just posted a fix. For the 4.9 branch I could finally reproduce this error. It is caused by the PHI-check for a vector-constant, which obviously has no valid statment ...
[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61917 --- Comment #18 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Wed Feb 25 18:20:34 2015 New Revision: 220986 URL: https://gcc.gnu.org/viewcvs?rev=220986root=gccview=rev Log: 2015-02-25 Kai Tietz kti...@redhat.com PR tree-optimization/61917 * tree-vect-loop.c (vectorizable_reduction): Handle obvious case that reduc_def_stmt is null. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/tree-vect-loop.c
[Bug tree-optimization/61917] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61917 --- Comment #20 from Kai Tietz ktietz at gcc dot gnu.org --- HJ: Does recent patch fixes issue for you too?
[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65130 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- Created attachment 34876 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34876action=edit Suggested patch avoiding endless-recursing by hash_set for visted edges The patch solves the reported issue for me on x86_64-unknown-linux-gnu. It avoids that we recurse within functions we already visited. While working on this I noticed that code uses pretty much stack due passing vecs' as copy on stack. This makes especially on targets with fixed amount of stack seriously troubles. But well, this is nothing to address by this patch
[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65130 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ktietz at gcc dot gnu.org --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org --- Mine, for now
[Bug tree-optimization/61917] [4.9/5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vectorizable_reduction, at tree-vect-loop.c:4913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61917 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org --- It is the same bug. All is related to the issue that 'dt' might become 'vect_internal_def' with 'orig_stmt' being NULL. By extending the assert at line 4993 as 'gcc_assert (orig_stmt || dt == vect_internal_def);' solves the issue for me for both provided samples. Index: tree-vect-loop.c === --- tree-vect-loop.c(Revision 220748) +++ tree-vect-loop.c(Arbeitskopie) @@ -4990,7 +4990,7 @@ vectorizable_reduction (gimple stmt, gimple_stmt_i /* For pattern recognized stmts, orig_stmt might be a reduction, but some helper statements for the pattern might not, or might be COND_EXPRs with reduction uses in the condition. */ - gcc_assert (orig_stmt); + gcc_assert (orig_stmt || dt == vect_internal_def); return false; } if (!found_nested_cycle_def)
[Bug c++/65127] [5 Regression] internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'addr_expr' in parsing_nsdmi, at cp/parser.c:18311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65127 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- Hmm, this issue seems to be fixed by delayed folding. By it I get the following error-message: t3.cpp: In function 'int main()': t3.cpp:13:16: error: expected primary-expression before ')' token make_item0(); ^ So there is still a parser-error, if this piece of code is considered to be valid code
[Bug c/35330] [4.8/4.9/5 regression] ICE with invalid pragma weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35330 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ktietz at gcc dot gnu.org --- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org --- Mine.
[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038 --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- Suggested patch send at https://gcc.gnu.org/ml/gcc-patches/2015-02/msg01615.html
[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-26 Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- Confirmed. I have a patch for it
[Bug target/43701] [4.8/4.9/5 Regression] ICE: SIGSEGV (too deep recursion) with -mno-sse and __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43701 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||ktietz at gcc dot gnu.org Known to work|| Known to fail|| --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org --- Can't reproduce the segmentation-fault anymore on 4.8, 4.9, and 5.0. Testcase is fixed for 5.0, just 4.8, and 4.9 are still reporting SE register return with SSE disabled. So I would suggest to close bug, as it is unlikely that 5.0 changes getting backmerged for this to older branches
[Bug c/35330] [4.8/4.9/5 regression] ICE with invalid pragma weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35330
--- Comment #12 from Kai Tietz ktietz at gcc dot gnu.org ---
issue seems to be that in declare_weak we don't check that DECL is actually
either a function, or a variable declaration.
Fix would be to add an error-message in declare_weak ().
Index: varasm.c
===
@@ -5398,6 +5399,12 @@ void
declare_weak (tree decl)
{
gcc_assert (TREE_CODE (decl) != FUNCTION_DECL || !TREE_ASM_WRITTEN (decl));
+ if (TREE_CODE (decl) != FUNCTION_DECL TREE_CODE (decl) != VAR_DECL)
+{
+ error (weak declaration of %q+D has to be either a function,
+ or a variable declaration, decl);
+ return;
+}
if (! TREE_PUBLIC (decl))
error (weak declaration of %q+D must be public, decl);
else if (!TARGET_SUPPORTS_WEAK)
[Bug tree-optimization/65216] [5 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65216 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug tree-optimization/65216] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65216 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-25 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- Confirmed. The 1 gets lost by pass vrp2
[Bug middle-end/64162] ICE: in emit_library_call_value_1, at calls.c:3779
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64162 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- Hmm, issue might be here the use of LTO on pe-coff. It could be that OP simply ran out of stack-space. You could try to enlarge the amount of stack (see objcopy / ld options for this). Otherwise I have no real idea what the issue is. I don't build a cross-compiler for ppc on native-windows, so it is hard to tell.
[Bug tree-optimization/65204] New: Aligned address optimization not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65204
Bug ID: 65204
Summary: Aligned address optimization not detected
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktietz at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
By testing on c++-delayed-folding branch I noticed that gcc doesn't optimize
issues as tested in 'c-c++-common/fold-bitand4.c' anymore.
By looking deeper into it it shows that CCP doesn't simplify this because it
doesn't track about copy-of.
The testcase demonstrates this:
typedef char char4[4] __attribute__ ((aligned (4)));
char4 c4[4] __attribute__ ((aligned (16)));
int f (int i)
{
__SIZE_TYPE__ h = (__SIZE_TYPE__)c4[i];
/* 0 */
return 3 h;
}
[Bug ipa/64641] ICE in get_polymorphic_call_info with C-cast to (polymorphic) object-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64641 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-25 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- Confirmed.
[Bug debug/47308] Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47308 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Kai Tietz ktietz at gcc dot gnu.org --- Yes, issue got fixed beginning with 4.8.2 (and higher) as verified by testing through versions. So close this bug.
[Bug target/39947] Shared libgcc getting clobbered for multilib builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947 --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org --- Just as note: This issue got partial addressed for 4.8 gcc for cross-compiler version. We place bitness-version into specific lib folder for bitness. Just for native mode - for being compatible with existing build-scenarios of native compiler - we still place target's libgcc's DLL into host's bin-folder. This issue is just present for native multilib-version.
[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972 --- Comment #13 from Kai Tietz ktietz at gcc dot gnu.org --- Rainer: does following patch works for you? Index: oacc-parallel.c === --- oacc-parallel.c(Revision 221640) +++ oacc-parallel.c(Arbeitskopie) @@ -31,6 +31,9 @@ #include libgomp_g.h #include gomp-constants.h #include oacc-int.h +#ifdef HAVE_INTTYPES_H +# include inttypes.h /* For PRIu64. */ +#endif #include string.h #include stdarg.h #include assert.h @@ -99,9 +102,14 @@ GOACC_parallel (int device, void (*fn) (void *), gomp_fatal (num_workers (%d) different from one is not yet supported, num_workers); +#ifdef HAVE_INTTYPES_H + gomp_debug (0, %s: mapnum=%PRIu64, hostaddrs=%p, size=%p, kinds=%p, + async = %d\n, + __FUNCTION__, (uint64_t) mapnum, hostaddrs, sizes, kinds, async); +#else gomp_debug (0, %s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p, async=%d\n, __FUNCTION__, mapnum, hostaddrs, sizes, kinds, async); - +#endif select_acc_device (device); thr = goacc_thread (); @@ -178,8 +186,13 @@ GOACC_data_start (int device, size_t mapnum, bool host_fallback = device == GOMP_DEVICE_HOST_FALLBACK; struct target_mem_desc *tgt; +#ifdef HAVE_INTTYPES_H + gomp_debug (0, %s: mapnum=%PRIu64, hostaddrs=%p, size=%p, kinds=%p\n, + __FUNCTION__, (uint64_t) mapnum, hostaddrs, sizes, kinds); +#else gomp_debug (0, %s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p\n, __FUNCTION__, mapnum, hostaddrs, sizes, kinds); +#endif select_acc_device (device); Index: target.c === --- target.c(Revision 221640) +++ target.c(Arbeitskopie) @@ -33,6 +33,9 @@ #include limits.h #include stdbool.h #include stdlib.h +#ifdef HAVE_INTTYPES_H +# include inttypes.h /* For PRIu64. */ +#endif #include string.h #include assert.h @@ -438,9 +441,16 @@ gomp_map_vars (struct gomp_device_descr *devicep, /* We already looked up the memory region above and it was missing. */ size_t size = k-host_end - k-host_start; +#ifdef HAVE_INTTYPES_H gomp_fatal (present clause: !acc_is_present (%p, + PRIu64 (0xPRIx64)), + (void *) k-host_start, + (uint64_t) size, (uint64_t) size); +#else + gomp_fatal (present clause: !acc_is_present (%p, %zd (0x%zx)), (void *) k-host_start, size, size); +#endif } break; case GOMP_MAP_FORCE_DEVICEPTR:
[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972 --- Comment #15 from Kai Tietz ktietz at gcc dot gnu.org --- Ok, I am fine. So patch should be something like: Index: oacc-parallel.c === --- oacc-parallel.c(Revision 221640) +++ oacc-parallel.c(Arbeitskopie) @@ -31,6 +31,9 @@ #include libgomp_g.h #include gomp-constants.h #include oacc-int.h +#ifdef HAVE_INTTYPES_H +# include inttypes.h /* For PRIu64. */ +#endif #include string.h #include stdarg.h #include assert.h @@ -99,9 +102,15 @@ GOACC_parallel (int device, void (*fn) (void *), gomp_fatal (num_workers (%d) different from one is not yet supported, num_workers); - gomp_debug (0, %s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p, async=%d\n, - __FUNCTION__, mapnum, hostaddrs, sizes, kinds, async); - +#ifdef HAVE_INTTYPES_H + gomp_debug (0, %s: mapnum=%PRIu64, hostaddrs=%p, size=%p, kinds=%p, + async = %d\n, + __FUNCTION__, (uint64_t) mapnum, hostaddrs, sizes, kinds, async); +#else + gomp_debug (0, %s: mapnum=%lu, hostaddrs=%p, sizes=%p, kinds=%p, async=%d\n, + __FUNCTION__, (unsigned long) mapnum, hostaddrs, sizes, kinds, + async); +#endif select_acc_device (device); thr = goacc_thread (); @@ -178,8 +187,13 @@ GOACC_data_start (int device, size_t mapnum, bool host_fallback = device == GOMP_DEVICE_HOST_FALLBACK; struct target_mem_desc *tgt; - gomp_debug (0, %s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p\n, - __FUNCTION__, mapnum, hostaddrs, sizes, kinds); +#ifdef HAVE_INTTYPES_H + gomp_debug (0, %s: mapnum=%PRIu64, hostaddrs=%p, size=%p, kinds=%p\n, + __FUNCTION__, (uint64_t) mapnum, hostaddrs, sizes, kinds); +#else + gomp_debug (0, %s: mapnum=%lu, hostaddrs=%p, sizes=%p, kinds=%p\n, + __FUNCTION__, (unsigned long) mapnum, hostaddrs, sizes, kinds); +#endif select_acc_device (device); Index: target.c === --- target.c(Revision 221640) +++ target.c(Arbeitskopie) @@ -33,6 +33,9 @@ #include limits.h #include stdbool.h #include stdlib.h +#ifdef HAVE_INTTYPES_H +# include inttypes.h /* For PRIu64. */ +#endif #include string.h #include assert.h @@ -438,9 +441,16 @@ gomp_map_vars (struct gomp_device_descr *devicep, /* We already looked up the memory region above and it was missing. */ size_t size = k-host_end - k-host_start; +#ifdef HAVE_INTTYPES_H gomp_fatal (present clause: !acc_is_present (%p, - %zd (0x%zx)), (void *) k-host_start, - size, size); + PRIu64 (0xPRIx64)), + (void *) k-host_start, + (uint64_t) size, (uint64_t) size); +#else + gomp_fatal (present clause: !acc_is_present (%p, + %lu (0x%lx)), (void *) k-host_start, + (unsigned long) size, (unsigned long) size); +#endif } break; case GOMP_MAP_FORCE_DEVICEPTR:
[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.3 Known to fail||5.0 --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- Issue is that libgomp uses gnu-style printf formatters without checking, if formatter is available on that platform. Due it operates on size_t, the defines provided by inttypes.h are of not much help.
[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug target/65581] [5 Regression] testsuite lto issue: multiple definition of `main', undefined reference to `WinMain'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65581 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at ucw dot cz --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org --- As far as I understand this issue does LTO now handle stuff used from object file different to prior versions. I add Jan. He might be able to give us some more points
[Bug preprocessor/8270] [4.8/4.9/5 Regression] back-slash white space newline with comments, no warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270 --- Comment #57 from Kai Tietz ktietz at gcc dot gnu.org --- (In reply to doug mcilroy from comment #56) (In reply to Kai Tietz from comment #55) Comment #55 overlooks the Standard's translation phase 1, which replaces an implementation-defined end-of-line indicator with a new-line character. GCC's convention of including in the end-of-line indicator any white space that is preceded by a backslash conforms, though it may be a surprise. Sure, sorry for omitting that. Common understanding of multibyte (this term is indeed misleading here) newline characters are in common the combination of '\r' and '\n'. So by interpreting any whitespace + new-line being seen as a single-character is valid, but has indeed semantic differences. The surprise is perversely out of sympathy with the raison d'etre of the standard--maximal portability. It is incompatible with the most direct (and historically prior) implementations, wherein the end-of-line indicator is simply a new-line character. Agreed, and we should at least consider to provide an option - beside the necessary warning - to not strip whitespaces from right-handside of lines containing a backslash at line's end. Should we use an existing option (like -ansi), or introduce new option for this? A suitable fix is to warn when white space occurs in an end-of-line indicator. This will break no code that GCC currently compiles, yet draw attention to the nonportable construct. Well, in general we are warning, but within comments. For C-style comments there is indeed not much reason to warn, as there is no semantic difference. But for C++-style comments we should, as here indeed a semantic difference can occure for gnu-style end-of-line treating
[Bug target/65867] [5/6 Regression] bootstrap fails for mingw32 due to missing header in ssp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65867 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-25 Ever confirmed|0 |1 --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- Well, that this include is required seems to me like a bug in mingw.org, as wincrypt.h should be auto-included by windows.h. Nevertheless this is a trivial patch, so it is ok. Please post it to ML, and I will take care to apply. Thanks
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
--- Comment #18 from Kai Tietz ktietz at gcc dot gnu.org ---
Does the following patch fixes your problem?
Index: lto-wrapper.c
===
--- lto-wrapper.c (Revision 69)
+++ lto-wrapper.c (Arbeitskopie)
@@ -934,7 +934,7 @@ run_gcc (unsigned argc, char *argv[])
filename[p - argv[i]] = '\0';
file_offset = (off_t) loffset;
}
- fd = open (argv[i], O_RDONLY);
+ fd = open (argv[i], O_RDONLY|O_BINARY);
if (fd == -1)
{
lto_argv[lto_argc++] = argv[i];
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
--- Comment #22 from Kai Tietz ktietz at gcc dot gnu.org ---
I will be able to test this tomorrow (or this evening) for a linux bootstrap.
Patch tested is:
Index: lto-wrapper.c
===
--- lto-wrapper.c (Revision 69)
+++ lto-wrapper.c (Arbeitskopie)
@@ -934,7 +934,7 @@ run_gcc (unsigned argc, char *argv[])
filename[p - argv[i]] = '\0';
file_offset = (off_t) loffset;
}
- fd = open (argv[i], O_RDONLY);
+ fd = open (filename, O_RDONLY | O_BINARY);
if (fd == -1)
{
lto_argv[lto_argc++] = argv[i];
Honza, Jakub, when regression-test passes is it ok to apply?
The O_BINARY change is pretty obvious, but the filename vs argv[i] change
should indeed affect other targets using the @n decoration, too.
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 --- Comment #31 from Kai Tietz ktietz at gcc dot gnu.org --- (In reply to Richard Biener from comment #23) The patch looks pretty obvious to me - though I wonder if archives still work on x86_64-linux after it (or rather I wonder how they worked before...). I'm not aware of @ doing any magic for filenames - do they? No, me neither. So - please test this with boostrap-lto on x86_64-linux as well. I did bootstrap for all languages (including lto) for x86_64-unknown-linux-gnu without any new regressions. Ok to apply to trunk? Ok for release-branch 5, too?
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 --- Comment #35 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Mon May 4 10:16:23 2015 New Revision: 222759 URL: https://gcc.gnu.org/viewcvs?rev=222759root=gccview=rev Log: PR target/65559 * lto-wrapper.c (run_gcc): Open filename with in binary-mode. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-wrapper.c
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 --- Comment #36 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Mon May 4 10:23:55 2015 New Revision: 222761 URL: https://gcc.gnu.org/viewcvs?rev=222761root=gccview=rev Log: Backmerge from trunk. PR lto/65559 * lto-wrapper.c (run_gcc): Open filename in binary-mode. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/lto-wrapper.c
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #37 from Kai Tietz ktietz at gcc dot gnu.org --- Fixed on trunk and on 5-branch.
