[Bug testsuite/63352] New: problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 Bug ID: 63352 Summary: problem with fmt_g0_1.f08 on i386-pc-solaris2.11 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: richard at netbsd dot org Running the testsuite for gcc 4.9.1 I notice the following gfortran failures: === gfortran tests === Running target unix FAIL: gfortran.dg/default_format_1.f90 -O0 execution test FAIL: gfortran.dg/default_format_1.f90 -O1 execution test FAIL: gfortran.dg/default_format_1.f90 -O2 execution test FAIL: gfortran.dg/default_format_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/default_format_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/default_format_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/default_format_1.f90 -O3 -g execution test FAIL: gfortran.dg/default_format_1.f90 -Os execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O0 execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O1 execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O2 execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/fmt_g0_1.f08 -O3 -g execution test FAIL: gfortran.dg/fmt_g0_1.f08 -Os execution test Concerning the fmt_g0_1.f08 cases, I notice in particular that while debugging the following bits are the problem: 10 write(buffer, string) ':',1.0_8/3.0_8,':' │ 11 if (buffer.ne.:.1:) call abort │ after 10, the value of buffer is: (gdb) print buffer $1 = ':.', '3' repeats 16 times, '2:', ' ' repeats 30 times Testsuite problem or no? This is running on SunOS 5.11 (illumos) pkgsrc trunk Compiler version: 4.9.1 (GCC) Platform: i386-sun-solaris2.11 configure flags: --enable-languages='c obj-c++ objc go fortran c++' --enable-shared --enable-long-long --with-local-prefix=/opt/local/gcc49 --enable-libssp --enable-threads=posix --with-boot-ldflags='-static-libstdc++ -static-libgcc -Wl,-R/opt/local/gcc47/lib/gcc/i386-sun-solaris2.11/4.7.3 -Wl,-R/opt/local/gcc47/lib -Wl,-R/opt/local/lib ' --with-system-zlib --disable-nls --with-gmp=/opt/local --with-mpc=/opt/local --with-mpfr=/opt/local --with-isl=/opt/local --disable-isl-version-check --with-cloog=/opt/local --enable-__cxa_atexit --with-gxx-include-dir=/opt/local/gcc49/include/c++/ --with-gnu-as --with-as=/opt/local/bin/gas --without-gnu-ld --with-ld=/usr/bin/ld --with-libiconv-prefix=/opt/local --prefix=/opt/local/gcc49 --build=i386-sun-solaris2.11 --host=i386-sun-solaris2.11 --infodir=/opt/local/gcc49/info --mandir=/opt/local/gcc49/man
[Bug target/56253] fp-contract does not work with SSE and AVX FMAs (neither FMA4 nor FMA3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56253 --- Comment #12 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Agner Fog from comment #11) Thanks for the links Marc. You are right, the discussion in the gcc-patches mailing list ignores integer vectors. You need a solution that also allows optimizations on integer intrinsic functions (perhaps cast the vector type?). If you follow the links, you can find: https://gcc.gnu.org/ml/gcc-patches/2013-04/msg00374.html where I handled some integer vector intrinsics as well (there were some bugs in that patch, but the idea should be fine). The proposed solution of using vector extensions will not work on masked vector intrinsics in AVX512, so it wouldn't enable e.g. constant propagation through a masked intrinsic, but that is probably too much to ask for :) I expect we can get most of the benefits from using vector extensions for very little effort, while handling the esoteric intrinsics would be a lot more work so it gets lower priority.
[Bug c++/63353] New: libstdc++-v3/src/c++11/ios.cc:232: possible typo ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63353 Bug ID: 63353 Summary: libstdc++-v3/src/c++11/ios.cc:232: possible typo ? Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com [libstdc++-v3/src/c++11/ios.cc:232] - [libstdc++-v3/src/c++11/ios.cc:232]: (style) Same expression on both sides of ''. Offending source code is if (!__lhs_local !__lhs_local) Maybe if (!__lhs_local !__rhs_local) or if (!__lhs_local) were intended.
[Bug target/63354] New: -pg -mprofile-kernel creates unused stack frames on leaf functions on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63354
Bug ID: 63354
Summary: -pg -mprofile-kernel creates unused stack frames on
leaf functions on ppc64le
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
The following testcase:
int foo(void)
{
return 1;
}
compiled with:
gcc -O2 -pg -mprofile-kernel -S foo.c
produces an unused stack frame:
foo:
mflr 0
std 0,16(1)
bl _mcount
mflr 0
li 3,1
std 0,16(1)
stdu 1,-32(1)
addi 1,1,32
ori 2,2,0
ld 0,16(1)
mtlr 0
blr
Note that older gcc versions allowed -mprofile-kernel to used on its own. While
there are issues with that (eg ignoring attribute no_instrument_function), it
does show the expected behaviour:
gcc -O2 -mprofile-kernel -S foo.c
foo:
mflr 0
std 0,16(1)
bl _mcount
li 3,1
blr
So it seems to be something to do with -pg.
[Bug rtl-optimization/63210] ira does not select the best register compared with gcc 4.8 for ARM THUMB1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63210 --- Comment #2 from zqchen at gcc dot gnu.org --- Author: zqchen Date: Wed Sep 24 07:00:55 2014 New Revision: 215540 URL: https://gcc.gnu.org/viewcvs?rev=215540root=gccview=rev Log: ChangeLog: 2014-09-24 Zhenqiang Chen zhenqiang.c...@arm.com PR rtl-optimization/63210 * ira-color.c (assign_hard_reg): Ignore conflict cost if the HARD_REGNO is not availabe for CONFLICT_A. testsuite/ChangeLog: 2014-09-24 Zhenqiang Chen zhenqiang.c...@arm.com * gcc.target/arm/pr63210.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr63210.c Modified: trunk/gcc/ChangeLog trunk/gcc/ira-color.c trunk/gcc/testsuite/ChangeLog
[Bug target/62311] Found a potential copy and paste issue on in gcc/config/cr16.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62311 David Binderman dcb314 at hotmail dot com changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #1 from David Binderman dcb314 at hotmail dot com --- Looks like a duplicate of #52124.
[Bug java/63355] New: libjava/classpath/native/jni/gstreamer-peer/gst_native_pipeline.c:180: possible typo ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63355 Bug ID: 63355 Summary: libjava/classpath/native/jni/gstreamer-peer/gst_native _pipeline.c:180: possible typo ? Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com [trunk/libjava/classpath/native/jni/gstreamer-peer/gst_native_pipeline.c:180]: (style) Same expression on both sides of '||'. Source code is if (localGstPipelineClass == NULL || localGstPipelineClass == NULL) I suspect if (localPointerClass == NULL || localGstPipelineClass == NULL) might have been intended, although it's probably better code to have the test of localPointerClass immediately after it is written to, not a few lines later.
[Bug target/63351] Optimization: contract broadcast intrinsics when AVX512 is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63351 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-24 Component|c |target Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Interesting - so AVX512 allows all(?) source operands to be scalars (in vector registers)? In theory combine should be able to handle this if the backend provides proper patterns. But I see that _mm512_set1_epi32 expands to sth like ;; _7 = __builtin_ia32_pbroadcastd512_gpr_mask (b_1(D), _6, -1); (insn 7 6 8 (set (reg:SI 101) (reg/v:SI 99 [ b ])) ./include/avx512fintrin.h:3566 -1 (nil)) (insn 8 7 9 (set (reg:V16SI 102) (subreg:V16SI (reg/v:V8DI 83 [ __Y ]) 0)) ./include/avx512fintrin.h:3566 -1 (nil)) (insn 9 8 10 (set (reg:HI 103) (const_int -1 [0x])) ./include/avx512fintrin.h:3566 -1 (nil)) (insn 10 9 11 (set (reg:V16SI 100) (vec_merge:V16SI (vec_duplicate:V16SI (reg:SI 101)) (reg:V16SI 102) (reg:HI 103))) ./include/avx512fintrin.h:3566 -1 (nil)) (insn 11 10 0 (set (reg:V16SI 85 [ D.15281 ]) (reg:V16SI 100)) ./include/avx512fintrin.h:3566 -1 (nil)) which looks really awkward - or even bogus (insn 10). What's the semantics of _mm512_set1_epi32? It seems that all of the intrinsics expand to sth weird as the above (the vec_merge), even _mm512_add_epi32. I'm quite sure this doesn't make the combiners job easier.
[Bug c++/63349] ICE with template in get_narrower fold-const.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63349 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-checking, ||ice-on-valid-code Target Milestone|4.8.4 |--- Known to fail||4.2.4, 4.4.7 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Also happens with 4.2.x, so indeed pretty old bug. Triggers with checking only. #3 0x0113556e in get_narrower (op=component_ref 0x767d58d0, unsignedp_ptr=0x7fffc3e0) at /space/rguenther/src/svn/trunk/gcc/tree.c:8532 8532 DECL_SIZE (TREE_OPERAND (op, 1)) != 0 (gdb) p debug_tree (op) component_ref 0x767d58d0 type integer_type 0x766c8690 int public type_6 SI size integer_cst 0x766e5030 constant 32 unit size integer_cst 0x766e5048 constant 4 align 32 symtab 0 alias set -1 canonical type 0x766c8690 precision 32 min integer_cst 0x766c4fd8 -2147483648 max integer_cst 0x766e5000 2147483647 pointer_to_this pointer_type 0x766e9738 arg 0 var_decl 0x766d1c60 b type record_type 0x76821f18 timeval type_5 type_6 SI size integer_cst 0x766e5030 32 unit size integer_cst 0x766e5048 4 align 32 symtab 0 alias set -1 canonical type 0x76821f18 fields field_decl 0x768224c0 tv_sec context translation_unit_decl 0x77ff81e0 D.1 full-name struct timeval X() X(constX) this=(X) n_parents=0 use_template=0 interface-unknown chain type_decl 0x76822390 timeval used decl_5 SI file /tmp/t.C line 9 col 24 size integer_cst 0x766e5030 32 unit size integer_cst 0x766e5048 4 align 32 context function_decl 0x76825a20 test chain var_decl 0x766d1bd0 a type record_type 0x76821f18 timeval used decl_5 SI file /tmp/t.C line 9 col 21 size integer_cst 0x766e5030 32 unit size integer_cst 0x766e5048 4 align 32 context function_decl 0x76825a20 test arg 1 identifier_node 0x76831108 tv_sec bindings (nil) local bindings (nil) $2 = void
[Bug rtl-optimization/63348] [5 Regression] gcc.dg/pr43670.c fail on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||mips CC||uros at gcc dot gnu.org Target Milestone|--- |5.0 Summary|regression gcc.dg/pr43670.c |[5 Regression] |fail on MIPS|gcc.dg/pr43670.c fail on ||MIPS
[Bug c++/63349] ICE with template in get_narrower fold-const.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63349 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- That identifier_node in a component_ref is bogus, I'm investigating how it got there.
[Bug tree-optimization/63338] Compiling large amounts of large switch cases takes a large amount of time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63338 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||compile-time-hog Target||x86_64-*-* Status|WAITING |NEW Component|middle-end |tree-optimization Version|unknown |4.9.1 Blocks||47344 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Well, confirmed to some extent. Needs to be pin-pointed to a specific pass still (bah, those infrastructure timevars make that difficult).
[Bug bootstrap/63235] building fails with --disable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63235 David Binderman dcb314 at hotmail dot com changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #12 from David Binderman dcb314 at hotmail dot com --- (In reply to Andi Kleen from comment #0) ../../../gcc/libcilkrts/runtime/config/x86/os-unix-sysdep.c: In function 'restore_x86_fp_state': ../../../gcc/libcilkrts/runtime/config/x86/os-unix-sysdep.c:114:5: internal compiler error: tree check: expected tree_list, have var_decl in get_attribute_name, at attribs.c:679 if (__builtin_cpu_supports(sse)) ^ I also see this one when bootstrapping 20140924, revision 215539. Interestingly, 20140921 was fine.
[Bug rtl-optimization/63348] [5 Regression] gcc.dg/pr43670.c fail on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to baoshan from comment #1) I believe this regression is introduced by the code for cleanup_barriers() in jump.c of patch https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02164.html: The call insn was followed by a barrier insn, the try_split() would emit another barrier insn after call insn for this case( I don't know why, please let me know the reason); after applying that patch and with option -g there would be a note instruction between the call and barrier insns which result no barrier insn is emitted by try_split(). try_split should skip eventual note after the call when looking for barrier. It looks to me that try_split blindly assumes that next insn is the barrier, which is not the case from the introduction of debug locations.
[Bug tree-optimization/63266] [5 Regression] Test regression: gcc.target/sh/pr53568-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63266 --- Comment #1 from thopre01 at gcc dot gnu.org --- Author: thopre01 Date: Wed Sep 24 08:27:21 2014 New Revision: 215546 URL: https://gcc.gnu.org/viewcvs?rev=215546root=gccview=rev Log: 2014-09-24 Thomas Preud'homme thomas.preudho...@arm.com gcc/ PR tree-optimization/63266 * tree-ssa-math-opts.c (struct symbolic_number): Add comment about marker for unknown byte value. (MARKER_MASK): New macro. (MARKER_BYTE_UNKNOWN): New macro. (HEAD_MARKER): New macro. (do_shift_rotate): Mark bytes with unknown values due to sign extension when doing an arithmetic right shift. Replace hardcoded mask for marker by new MARKER_MASK macro. (find_bswap_or_nop_1): Likewise and adjust ORing of two symbolic numbers accordingly. gcc/testsuite/ PR tree-optimization/63266 * gcc.dg/optimize-bswapsi-1.c (swap32_d): New bswap pass test. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/optimize-bswapsi-1.c trunk/gcc/tree-ssa-math-opts.c
[Bug tree-optimization/63266] [5 Regression] Test regression: gcc.target/sh/pr53568-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63266 thopre01 at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from thopre01 at gcc dot gnu.org --- Bug introduced during phase 1 of 5.0 and is now resolved there as of r215546
[Bug c++/61945] [5 Regression] tree check fail with -Woverloaded-virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61945 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Started with r211960.
[Bug c++/63356] New: Compilation failure where clang does not have problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356
Bug ID: 63356
Summary: Compilation failure where clang does not have problems
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
I originally filed this as a boost bug:
https://svn.boost.org/trac/boost/ticket/10531
However, given that clang 3.4.2 has no problems compiling it, I suspect it
might be a gcc issue.
In short, the following code, as of boost 1.56.0, fails to compile with wild
error messages, using 4.9.1 as well as 4.8.3:
#include vector
#include boost/polygon/polygon.hpp
int main()
{
typedef boost::polygon::polygon_dataint Polygon;
typedef boost::polygon::polygon_set_dataint PolygonSet;
PolygonSet ps;
std::vectorPolygon output;
ps.get(output);
}
(It does work with boost = 1.55.0 however!)
[Bug libstdc++/63353] libstdc++-v3/src/c++11/ios.cc:232: possible typo ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63353 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-09-24 Component|c++ |libstdc++ Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Oops, mine.
[Bug sanitizer/63316] [5.0 Regression] False asan positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63316 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Sep 24 09:14:17 2014 New Revision: 215547 URL: https://gcc.gnu.org/viewcvs?rev=215547root=gccview=rev Log: PR sanitizer/63316 * asan.c (asan_expand_check_ifn): Fix up align = 8 optimization. * c-c++-common/asan/pr63316.c: New test. Added: trunk/gcc/testsuite/c-c++-common/asan/pr63316.c Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c trunk/gcc/testsuite/ChangeLog
[Bug c++/63356] Compilation failure where clang does not have problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-09-24 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- I cannot reproduce the issue. Please attach a per-processed testcase.
[Bug c++/63349] ICE with template in get_narrower fold-const.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63349
--- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org ---
In finish_class_member_access_expr we have
expr = build_class_member_access_expr (object, member, access_path,
/*preserve_reference=*/false,
complain);
if (processing_template_decl expr != error_mark_node)
{
if (BASELINK_P (member))
{
if (TREE_CODE (orig_name) == SCOPE_REF)
BASELINK_QUALIFIED_P (member) = 1;
orig_name = member;
}
return build_min_non_dep (COMPONENT_REF, expr,
orig_object, orig_name,
NULL_TREE);
build_class_member_access_expr builds a component_ref that seems to be ok; its
arg1 is a field_decl. But the subsequent build_min_non_dep call changes this
field_decl into ORIG_NAME, which is an identifier_node.
[Bug c++/63356] Compilation failure where clang does not have problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- You should have read https://gcc.gnu.org/bugs/ and attached preprocessed code anyway, not everyone has Boost 1.56 already installed.
[Bug libstdc++/63353] libstdc++-v3/src/c++11/ios.cc:232: possible typo ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63353 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Wed Sep 24 09:40:10 2014 New Revision: 215549 URL: https://gcc.gnu.org/viewcvs?rev=215549root=gccview=rev Log: PR libstdc++/63353 * src/c++11/ios.cc (ios_base::_M_swap): Fix typo. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++11/ios.cc
[Bug libstdc++/63353] libstdc++-v3/src/c++11/ios.cc:232: possible typo ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63353 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Done
[Bug c++/63356] Compilation failure where clang does not have problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356 --- Comment #3 from fiesh at zefix dot tv --- I wanted to, but the problem is that the ii file is 2.7MB, more than the maximum allowed file size of 1000KB. Should I upload it to a different site? Also I just realized that the problem only occurs with -std=c++11. (Clang works with or without.)
[Bug c++/63356] Compilation failure where clang does not have problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356 --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to fiesh from comment #3) I wanted to, but the problem is that the ii file is 2.7MB, more than the maximum allowed file size of 1000KB. Should I upload it to a different site? Also I just realized that the problem only occurs with -std=c++11. (Clang works with or without.) You can use compression. But no need, because I can now reproduce the issue with -std=c++11.
[Bug c/63344] [5 Regression] Linux (makeallyes config) compilation error: error: apic_numachip causes a section type conflict with numachip_system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63344 --- Comment #4 from Martin Liška mliska at suse dot cz --- (In reply to Andi Kleen from comment #3) Yes it's a kernel bug. I hit it earlier too. const always needs to go into separate sections. const __read_mostly is also meaningless. Is there any existing bug in Linux Kernel that can be linked to this thread?
[Bug c++/63356] Compilation failure where clang does not have problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356 --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 33545 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33545action=edit preprocessed testcase Here's the unreduced testcase. I cannot reduce it, because clang doesn't handle all the __builtin_ia32_bsrsi, etc. intrinsics.
[Bug preprocessor/58893] [4.8/4.9/5 Regression] command-line:0:0: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58893
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Comment #10 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Created attachment 33546
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33546action=edit
possible fix
Hi,
I have looked at this issue, and think this is the right fix.
Regarding the hunk in cpp_diagnostic, which is not directly involved
in this bug, but still obviously wrong:
The line src_loc = pfile-cur_run-prev-limit-src_loc
is probably unreachable, but will crash it is ever executed.
see:
_cpp_init_tokenrun (tokenrun *run, unsigned int count)
{
run-base = XNEWVEC (cpp_token, count);
run-limit = run-base + count;
run-next = NULL;
}
limit points at the end of the run, prev is uninitialized.
Comments?
[Bug c/63357] New: Warn for P P and P || P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63357
Bug ID: 63357
Summary: Warn for P P and P || P
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
We probably should warn about (both C/C++):
int
foo (int a, int b)
{
if (a a)
return 1;
if (b || b)
return 2;
if (!a !a)
return 3;
if (!b || !b)
return 4;
return 0;
}
See https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02080.html
I suggest this be called -Wredundant-op. Better names?
[Bug bootstrap/63235] building fails with --disable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63235 Jiong Wang jiwang at gcc dot gnu.org changed: What|Removed |Added CC||jiwang at gcc dot gnu.org --- Comment #13 from Jiong Wang jiwang at gcc dot gnu.org --- I run into this issue also. my code is revision 215549 my configure options: ../gcc/configure --enable-languages=c,c++ svn+ssh://gcc.gnu.org/svn/gcc/trunk@215549
[Bug bootstrap/63235] building fails with --disable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63235 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #14 from Igor Zamyatin izamyatin at gmail dot com --- Seems, started after r215538
[Bug c/63326] pragma GCC causes wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #2 from Dietmar Schindler dietmar.schind...@manroland-web.com --- (In reply to Andrew Pinski from comment #1) #pragma are considered statements. This can't be entirely true, since #pragma can be used where statements cannot (outside of functions), and #pragma STDC certainly isn't considered a statement. At least, this implementation-defined behaviour has to be documented (hasn't it?), and I couldn't find mention of it in the documentation. Would you recommend filing a separate documentation bug report?
[Bug bootstrap/63235] building fails with --disable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63235 --- Comment #15 from Igor Zamyatin izamyatin at gmail dot com --- Sorry, it's r215537
[Bug bootstrap/63235] building fails with --disable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63235 Kirill Yukhin kyukhin at gcc dot gnu.org changed: What|Removed |Added CC||kyukhin at gcc dot gnu.org --- Comment #16 from Kirill Yukhin kyukhin at gcc dot gnu.org --- patch posted here: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02090.html
[Bug testsuite/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352
--- Comment #1 from Richard PALO richard at netbsd dot org ---
This seems to be a bug in the write formatting for g0
Here is the compile with -fdump-parse-tree showing that the constant expression
is calculated exactly as '3.3331e-1_8'
Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = MAIN__
symtree: 'MAIN__' || symbol: 'MAIN__'
type spec : (UNKNOWN 0)
attributes: (PROGRAM PUBLIC SUBROUTINE)
symtree: 'abort' || symbol: 'abort'
type spec : (UNKNOWN 0)
attributes: (PROCEDURE SUBROUTINE)
symtree: 'buffer' || symbol: 'buffer'
type spec : (CHARACTER 50 1)
attributes: (VARIABLE )
symtree: 'string' || symbol: 'string'
type spec : (CHARACTER 25 1)
attributes: (VARIABLE IMPLICIT-SAVE)
value: '(g0,g0,g0) '
code:
WRITE UNIT=MAIN__:buffer FMT='(g0,g0,g0)'
TRANSFER ':'
TRANSFER 12340
TRANSFER ':'
DT_END
IF (/= MAIN__:buffer ':12340:')
CALL _gfortran_abort ()
ENDIF
WRITE UNIT=MAIN__:buffer FMT=MAIN__:string
TRANSFER ':'
TRANSFER 0
TRANSFER ':'
DT_END
IF (/= MAIN__:buffer ':0:')
CALL _gfortran_abort ()
ENDIF
WRITE UNIT=MAIN__:buffer FMT=MAIN__:string
TRANSFER ':'
TRANSFER 3.3331e-1_8
TRANSFER ':'
DT_END
IF (/= MAIN__:buffer ':.1:')
CALL _gfortran_abort ()
ENDIF
WRITE UNIT=MAIN__:buffer FMT='(1x,a,g0,a)'
TRANSFER ':'
TRANSFER 3.3331e-1_8
TRANSFER ':'
DT_END
IF (/= MAIN__:buffer ' :.1:')
CALL _gfortran_abort ()
ENDIF
WRITE UNIT=MAIN__:buffer FMT=MAIN__:string
TRANSFER ':'
TRANSFER 'hello'
TRANSFER ':'
DT_END
IF (/= MAIN__:buffer ':hello:')
CALL _gfortran_abort ()
ENDIF
WRITE UNIT=MAIN__:buffer FMT='(g0,g0,g0,g0)'
TRANSFER ':'
TRANSFER .true.
TRANSFER .false.
TRANSFER ':'
DT_END
IF (/= MAIN__:buffer ':TF:')
CALL _gfortran_abort ()
ENDIF
WRITE UNIT=MAIN__:buffer FMT='(g0,g0,'','',g0,g0)'
TRANSFER '('
TRANSFER (complex 1.2344_8 2.45670001_8)
TRANSFER ')'
DT_END
IF (/= MAIN__:buffer '(1.2344,2.45670001)')
CALL _gfortran_abort ()
ENDIF
[Bug bootstrap/63235] building fails with --disable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63235 --- Comment #17 from Kirill Yukhin kyukhin at gcc dot gnu.org --- Author: kyukhin Date: Wed Sep 24 12:27:30 2014 New Revision: 215552 URL: https://gcc.gnu.org/viewcvs?rev=215552root=gccview=rev Log: PR bootstrap/63235 gcc/ * varpool.c (varpool_node::add): Pass decl attributes to lookup_attribute. Modified: trunk/gcc/ChangeLog trunk/gcc/varpool.c
[Bug c/63358] New: [4.8.3 - 4.9.1] gcc -O2/-O3 wrong assembly code (crash / Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63358 Bug ID: 63358 Summary: [4.8.3 - 4.9.1] gcc -O2/-O3 wrong assembly code (crash / Segmentation fault) Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jean-baptiste.laurent at epitech dot eu Created attachment 33547 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33547action=edit The zip file containing the small code making gcc generate wrong assembly, and both the .s and .i generated by -save-temps. Hi, It appears that gcc, when compiling the code in attachment generate an assembly which is wrong. This code has been tested with gcc 4.7.1 (working), 4.8.3 (crash) on Fedora 18 and Fedora 20, and 4.9.1 (crash) on Ubuntu 14.04. The source file produce a wrong code when compiling with at least -O2. Warning flags (-W -Wall -Wextra) do not influence the result. There are no warning generated. When looking at the assembly directly it look like there is a whole part of the code missing (like the compilation stopped but do not failed).
[Bug c/63358] [4.8.3 - 4.9.1] gcc -O2/-O3 wrong assembly code (crash / Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63358 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- From https://gcc.gnu.org/bugs/: »if compiling with -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations makes a difference, your code probably is not correct.« markus@x4 tmp % gcc -fsanitize=undefined -Wall -Wextra -O2 main.i markus@x4 tmp % ./a.out I = 0, Result = 0 I = 1, Result = 1234567890 main.c:12:11: runtime error: signed integer overflow: 2 * 1234567890 cannot be represented in type 'int'
[Bug c/63358] [4.8.3 - 4.9.1] gcc -O2/-O3 wrong assembly code (crash / Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63358 --- Comment #2 from jean-baptiste.laurent at epitech dot eu --- Thanks for the quick answer. The overflow is not only supposed to alter the result printed out ?
[Bug target/63359] New: aarch64: 32bit registers in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359
Bug ID: 63359
Summary: aarch64: 32bit registers in inline asm
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target: aarch64-linux-gnu
int f(int i){
asm(clz %0, %0:+r(i));
return i;
}
produces:
clz x0, x0
I need to write clz %w0, %w0 to get the expected:
clz w0, w0
What I would like:
1) on x86, the type of i is used to get the right register name. If this can't
be done on aarch64 (did ARM forbid it?), it may be useful to warn when I pass
the wrong type.
2) I need a documented way to get 32bit regs, and %w0 is not documented in the
gcc manual. Besides, clang rejects it, so please find a common syntax...
[Bug c/63358] [4.8.3 - 4.9.1] gcc -O2/-O3 wrong assembly code (crash / Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63358 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Signed integer overflow is undefined behaviour, so anything can happen. Specifically, the compiler is allowed to assume that overflow never happens, and perform optimisations based on that assumption, so if overflow *does* happen the results are unpredictable.
[Bug target/63359] aarch64: 32bit registers in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359 James Molloy james.molloy at arm dot com changed: What|Removed |Added CC||james.molloy at arm dot com --- Comment #1 from James Molloy james.molloy at arm dot com --- Hi, Besides, clang rejects it, so please find a common syntax... It shouldn't. The w modifier should have been supported since clang 3.4, and is certainly supported in clang 3.5. Clang 3.5 has a warning about this: /tmp/test.c:2:27: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths] asm(clz %0, %0:+r(i)); ^ /tmp/test.c:2:14: note: use constraint modifier w asm(clz %0, %0:+r(i)); ^~ %w0 /tmp/test.c:2:27: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths] asm(clz %0, %0:+r(i)); ^ /tmp/test.c:2:18: note: use constraint modifier w asm(clz %0, %0:+r(i)); ^~ %w0 2 warnings generated.
[Bug c++/63356] Compilation failure where clang does not have problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356
--- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
This is what C-reduce came up with:
markus@x4 ~ % cat boost.ii
template typename _Tp
struct integral_constant {
static constexpr _Tp value = 0;
};
template typename...
struct __and_;
template typename _B1
struct __and__B1 : _B1 {};
template typename _Tp
_Tp declval();
template typename _From, typename _To
struct __is_convertible_helper {
template typename _From1, typename _To1,
typename = decltype(_To1(declval_From1()))
static integral_constantint __test(int);
typedef decltype(__test_From, _To(0)) type;
};
template typename _From, typename _To
struct is_convertible : __is_convertible_helper_From, _To::type {};
template int
struct Trans_NS_std_enable_if {};
template class _T1, class
struct pair {
_T1 first;
template class _U1, class _U2,
class = typename Trans_NS_std_enable_if
__and_is_convertible_U1, _T1::value::type
pair(pair_U1, _U2);
template class _U2
pair(_T1 __x, _U2)
: first(__x) {}
};
class point_data;
class vector {
public:
void push_back(pairpairpairpoint_data, point_data, int, int *);
};
template typename _Key
class map {};
class point_data {
public:
template typename PointType
point_data(PointType);
mapint processEvent__iter;
vector processEvent__counts_from_scanline;
template class cT, class iT
void processEvent_(cT, iT, iT) {
processEvent__counts_from_scanline.push_back(
pairpairpairpoint_data, point_data, int, int *(
pairpairpoint_data, point_data, int(
pairpoint_data, point_data(0, 0), processEvent__iter),
0));
}
void get_dispatch() { get_fracture(0, 0, 0); }
template typename output_container, typename concept_type
void get_fracture(output_container, int, concept_type) {
processEvent_(0, 0, 0);
}
};
markus@x4 ~ % icpc -std=c++11 -c boost.ii
markus@x4 ~ % clang++ -std=c++11 -c boost.ii
markus@x4 ~ % g++ -std=c++11 -c boost.ii
boost.ii: In instantiation of ‘struct
__is_convertible_helperpairpairpoint_data, point_data, int,
pairpoint_data, point_data ’:
boost.ii:19:8: required from ‘struct is_convertiblepairpairpoint_data,
point_data, int, pairpoint_data, point_data ’
boost.ii:8:8: required from ‘struct
__and_is_convertiblepairpairpoint_data, point_data, int, pairpoint_data,
point_data ’
boost.ii:52:15: recursively required by substitution of ‘templateclass _U2
pair_T1, template-parameter-1-2 ::pair(_T1, _U2) [with _U2 = missing]’
boost.ii:52:15: required from ‘void point_data::processEvent_(cT, iT, iT)
[with cT = int; iT = int]’
boost.ii:57:26: required from ‘void
point_data::get_fracture(output_container, int, concept_type) [with
output_container = int; concept_type = int]’
boost.ii:54:45: required from here
boost.ii:16:26: error: no matching function for call to
‘__is_convertible_helperpairpairpoint_data, point_data, int,
pairpoint_data, point_data ::__test(int)’
typedef decltype(__test_From, _To(0)) type;
^
boost.ii:16:26: note: candidate is:
boost.ii:15:33: note: templateclass _From1, class _To1, class static
integral_constantint __is_convertible_helper_From, _To::__test(int) [with
_From1 = _From1; _To1 = _To1; template-parameter-2-3 =
template-parameter-1-3; _From = pairpairpoint_data, point_data, int; _To
= pairpoint_data, point_data]
static integral_constantint __test(int);
^
boost.ii:15:33: note: template argument deduction/substitution failed:
boost.ii:14:13: error: no matching function for call to ‘pairpoint_data,
point_data::pair(pairpairpoint_data, point_data, int)’
typename = decltype(_To1(declval_From1()))
^
boost.ii:14:13: note: candidates are:
boost.ii:30:3: note: templateclass _U2 pair_T1, template-parameter-1-2
::pair(_T1, _U2)
pair(_T1 __x, _U2)
^
boost.ii:30:3: note: template argument deduction/substitution failed:
boost.ii:14:13: note: candidate expects 2 arguments, 1 provided
typename = decltype(_To1(declval_From1()))
^
boost.ii:28:3: note: templateclass _U1, class _U2, class pair_T1,
template-parameter-1-2 ::pair(pair_U1, _U2)
pair(pair_U1, _U2);
^
boost.ii:28:3: note: template argument deduction/substitution failed:
boost.ii:26:13: error: no type named ‘type’ in ‘struct
Trans_NS_std_enable_if0’
class = typename Trans_NS_std_enable_if
^
boost.ii:23:8: note: constexpr pairpoint_data, point_data::pair(const
pairpoint_data, point_data)
struct pair {
^
boost.ii:23:8: note: no known conversion for argument 1 from
‘pairpairpoint_data, point_data, int’ to ‘const pairpoint_data,
point_data’
boost.ii:23:8: note: constexpr pairpoint_data,
point_data::pair(pairpoint_data, point_data)
boost.ii:23:8: note: no known conversion for argument 1 from
‘pairpairpoint_data, point_data, int’ to ‘pairpoint_data, point_data’
boost.ii: In
[Bug target/63359] aarch64: 32bit registers in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359 --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to James Molloy from comment #1) Besides, clang rejects it, so please find a common syntax... It shouldn't. The w modifier should have been supported since clang 3.4, and is certainly supported in clang 3.5. Uh, you are right. I have no idea why my earlier tests failed... Sorry. So I would mostly like to see this 'w' modifier documented in the gcc doc, and a warning that includes a hint about 'w'. (For clang I only have 3.5 and svn215195 of 3.6 and the note part is not present yet) Thanks.
[Bug c++/63356] Compilation failure where clang does not have problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356
--- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Or a bit more compact and obfuscated:
template typename _Tp
struct A {
static constexpr _Tp value = 0;
};
template typename...
struct B;
template typename _B1
struct B_B1 : _B1 {};
template typename _Tp
_Tp declval();
template typename _From, typename _To
struct C {
template typename _From1, typename _To1,
typename = decltype(_To1(declval_From1()))
static Aint __test(int);
typedef decltype(__test_From, _To(0)) type;
};
template typename _From, typename _To
struct I : C_From, _To::type {};
template int
struct D {};
template class _T1, class
struct F {
_T1 first;
template class _U1, class _U2,
class = typename DBI_U1, _T1::value::type
F(F_U1, _U2);
template class _U2
F(_T1 p1, _U2)
: first(p1) {}
};
class G;
class H {
public:
void push_back(FFFG, G, int, int *);
};
class G {
public:
template typename PointType
G(PointType);
H processEvent__counts_from_scanline;
template class cT, class iT
void processEvent_(cT, iT, iT) {
processEvent__counts_from_scanline.push_back(
FFFG, G, int, int *(FFG, G, int(FG, G(0, 0), 0), 0));
}
void get_dispatch() { get_fracture(0, 0, 0); }
template typename output_container, typename concept_type
void get_fracture(output_container, int, concept_type) {
processEvent_(0, 0, 0);
}
};
[Bug target/63354] gcc -pg -mprofile-kernel creates unused stack frames on leaf functions on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63354 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Target|powerpc64le-linux |powerpc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-24 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool segher at gcc dot gnu.org --- Confirmed. We need #define TARGET_KEEP_LEAF_WHEN_PROFILED hook_bool_void_true to have it behave as you want.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889
--- Comment #8 from Rainer Emrich rai...@emrich-ebersheim.de ---
(In reply to xur from comment #7)
OK. I'll fix this and submit another patch.
What is the status for that?
On Wed, Aug 20, 2014 at 11:26 AM, ktietz at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889
--- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org ---
Yes, I remember. I didn't comment on it.
The following checks aren't ok.
'#if !defined(_WIN32)'
you should disable those parts *only* if ftw API isn't present. This you
should
check by a HAVE_FTW_H configure-check-macro. To disable it just because
_WIN32
is defined is wrong.
Quoting Kai Tietz:
Issue got fixed on mingw-w64's side by providing on trunk ftw/nftw API.
Nevertheless there is still an issue with the use of mkdir:
g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I.
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/.
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/../include
-I./../intl
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/../libcpp/include
-I/opt/devel/SCRATCH/tmp.Yed3qsDdVp/install/include
-I/opt/devel/SCRATCH/tmp.Yed3qsDdVp/install/include
-I/opt/devel/SCRATCH/tmp.Yed3qsDdVp/install/include
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/../libdecnumber
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/../libdecnumber/bid
-I../libdecnumber
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/../libbacktrace
-DCLOOG_INT_GMP -I/opt/devel/SCRATCH/tmp.Yed3qsDdVp/install/include
-DCLOOG_INT_GMP -I/opt/devel/SCRATCH/tmp.Yed3qsDdVp/install/include -o
gcov-tool.o -MT gcov-tool.o -MMD -MP -MF ./.deps/gcov-tool.TPo
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/gcov-tool.c
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/gcov-tool.c:95:21:
error: macro mkdir requires 2 arguments, but only 1 given
if (mkdir (out) == -1 errno != EEXIST)
^
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/gcov-tool.c:
In function 'void gcov_output_files(const char*, gcov_info*)':
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/gcov-tool.c:95:27:
error: ISO C++ forbids comparison between pointer and integer [-fpermissive]
if (mkdir (out) == -1 errno != EEXIST)
^
This clashes with the macro definition for mkdir in system.h:
/* Some systems have mkdir that takes a single argument. */
#ifdef MKDIR_TAKES_ONE_ARG
# define mkdir(a,b) mkdir (a)
#endif
Removing the wrong #if !defined(_WIN32) solves the issue for gcov-tool.c:
Index: gcc/gcov-tool.c
===
--- gcc/gcov-tool.c(Revision 215554)
+++ gcc/gcov-tool.c(Arbeitskopie)
@@ -89,11 +89,7 @@ gcov_output_files (const char *out, stru
/* Try to make directory if it doesn't already exist. */
if (access (out, F_OK) == -1)
{
-#if !defined(_WIN32)
if (mkdir (out, S_IRWXU | S_IRWXG | S_IRWXO) == -1 errno != EEXIST)
-#else
- if (mkdir (out) == -1 errno != EEXIST)
-#endif
fatal_error (Cannot make directory %s, out);
} else
unlink_profile_dir (out);
At a second point the issue is more complex. In libgcc/libgcov-driver-system.c
there is the following code:
#ifdef TARGET_POSIX_IO
mkdir (filename, 0755) == -1
#else
mkdir (filename) == -1
#endif
libgcov-driver-system.c is used in two places, in the gcc directory and in the
the libgcc directory for libgcov. In the first case the macro for mkdir is
defined in the second it isn't.
An ugly hack solves this issue and lets me at least build gcc-5.0.0 on
x86_64-w64-mingw32.
Index: libgcc/libgcov-driver-system.c
===
--- libgcc/libgcov-driver-system.c(Revision 215554)
+++ libgcc/libgcov-driver-system.c(Arbeitskopie)
@@ -66,6 +66,9 @@ create_file_directory (char *filename)
#ifdef TARGET_POSIX_IO
mkdir (filename, 0755) == -1
#else
+#ifdef mkdir
+#undef mkdir
+#endif
mkdir (filename) == -1
#endif
/* The directory might have been made by another process. */
Someone with more insight should have a look on this, please!
[Bug c/63326] pragma GCC causes wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2014-09-24 CC||manu at gcc dot gnu.org Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- If you use #pragma GCC system_header, you get a different result, so this seems a bug to me (whatever the behavior, it should not depend on the type of #pragma). At the very least, GCC could give a warning if the #pragma is the only statement in a if/else/while/do/for body, since this is probably a bug.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- When compiled with Clang, it returns 0 by the way.
[Bug testsuite/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #2 from Richard PALO richard at netbsd dot org --- FWIW, just checked ... this is a regression introduce after 4.7.3 (where this test seems to work fine...can't test 4.8.3 any more, sorry).
[Bug target/63359] aarch64: 32bit registers in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-24 Ever confirmed|0 |1 --- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Agree that this needs to be documented. I'm not so sure about a warning, however. I could envisage cases where the warning would be incorrect and avoiding it would lead to code pessimisation.
[Bug c++/63356] Compilation failure where clang does not have problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356
--- Comment #8 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
template typename _Tp
struct A {
static constexpr _Tp value = 0;
};
template typename...
struct B;
template typename _B1
struct B_B1 : _B1 {};
template typename _Tp
_Tp declval();
template typename _From, typename _To
struct C {
template typename _From1, typename _To1,
typename = decltype(_To1(declval_From1()))
static Aint __test(int);
typedef decltype(__test_From, _To(0)) type;
};
template typename _From, typename _To
struct I : C_From, _To::type {};
template int
struct D {};
template class _T1, class
struct F {
_T1 first;
template class _U1, class _U2,
class = typename DBI_U1, _T1::value::type
F(F_U1, _U2);
template class _U2
F(_T1 p1, _U2)
: first(p1) {}
};
class G;
class H {
public:
void push_back(FFFG, G, int, int *);
};
class G {
public:
template typename PointType
G(PointType);
H processEvent__counts_from_scanline;
void processEvent_() {
processEvent__counts_from_scanline.push_back(
FFFG, G, int, int *(FFG, G, int(FG, G(0, 0), 0), 0));
}
};
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #9 from Rainer Emrich rai...@emrich-ebersheim.de --- Created attachment 33548 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33548action=edit Proposed patch to fix the mingw case.
[Bug target/63359] aarch64: 32bit registers in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359 --- Comment #4 from James Molloy james.molloy at arm dot com --- Hi Richard, My two-pennyworth for what it's worth - we've had several people with broken code tripped by this bug, and Apple have reported seeing the same thing with their internal codebases. This one seems often to appear in real-world code. Cheers, James
[Bug target/63359] aarch64: 32bit registers in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359
--- Comment #5 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
So consider:
int f(int i){
long x;
asm(lsl %0, %1, 33 : =r(x) : r(i)); // lshift by more than sizeof(int)
return x;
}
We really don't care about the top bits in i, so we don't want to extend the
value to 64 bits before we do the shift. But we can't put w on the second
operand since it has to be a 64-bit register.
[Bug target/63359] aarch64: 32bit registers in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359 --- Comment #6 from James Molloy james.molloy at arm dot com --- Good example, although I might argue slightly pathological. So in this case currently, GCC doesn't even implicitly promote the argument, just uses it as-is. It seems a very dangerous behaviour to have as default. Could there not be a more sensible default and an explicit constraint modifier to allow this instead?
[Bug target/63359] aarch64: 32bit registers in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359 --- Comment #7 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Richard Earnshaw from comment #3) I'm not so sure about a warning, however. I could envisage cases where the warning would be incorrect and avoiding it would lead to code pessimisation. I don't insist on the warning, I might not have needed it with a proper doc (that explains both that r is reserved to 64 bits (gcc won't adapt to the type of the argument) and that there is a 'w' modifier to get 32 bits).
[Bug c++/63249] [OpenMP] Spurious »set but not used« warnings when actually used in OpenMP target's array section's lower-bound and length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63249 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-09-24 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 33549 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33549action=edit gcc5-pr63249.patch Untested fix.
[Bug target/63359] aarch64: 32bit registers in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359 --- Comment #8 from Richard Earnshaw rearnsha at gcc dot gnu.org --- (In reply to James Molloy from comment #6) Good example, although I might argue slightly pathological. Agreed, this is somewhat pathological, but I only need to find one valid counter-example :-) Furthermore, something similar will be quite common on results. Eg: int i, j; unsigned long r; asm(add %w0, %w1, %w2 : =r(r) : r(i), r(j)); // zero-extend result. here we *want* the 64-bit result from the implicit zero-extend of writing the lower 32 bits. So in this case currently, GCC doesn't even implicitly promote the argument, just uses it as-is. It seems a very dangerous behaviour to have as default. Could there not be a more sensible default and an explicit constraint modifier to allow this instead? One of the things I dislike so much about GCC's inline assembly is that it's just an exposure to users of an internal API in the compiler. That makes it very difficult to say precisely what will happen in all cases and *very* hard to fix problems with it when it exposes bugs. I'm not saying I'll never accept a warning for this sort of code; but I'd need convincing that it won't unduly pessimize real code with no acceptable work-arounds.
[Bug target/63359] aarch64: 32bit registers in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359 --- Comment #9 from James Molloy james.molloy at arm dot com --- OK, given your second example I agree that the usecase isn't quite as pathological as I thought. I'm not saying I'll never accept a warning for this sort of code; but I'd need convincing that it won't unduly pessimize real code with no acceptable work-arounds. Clang is committed to this warning as our community feels the error detection rate makes up for the lack of raw power. So unless we actively do something the two compilers will always differ in approach which probably isn't best for our users. Would you be opposed to discussing a constraint modifier to mean implicitly extend to 64-bits?
[Bug c++/63356] Compilation failure where clang does not have problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356
--- Comment #9 from fiesh at zefix dot tv ---
Ever so little simplified:
struct A {};
template typename _B1
struct B : _B1 {};
template typename _Tp
_Tp declval();
template typename _From, typename _To
struct C {
template typename _From1, typename _To1,
typename = decltype(_To1(declval_From1()))
static A __test(int);
typedef decltype(__test_From, _To(0)) type;
};
template typename _From, typename _To
struct I : C_From, _To::type {};
template int
struct D {};
template class _T1, class
struct F {
_T1 first;
template class _U1, class _U2,
class = typename DBI_U1, _T1::value::type
F(F_U1, _U2);
template class _U2
F(_T1 p1, _U2)
: first(p1) {}
};
class G;
class H {
public:
void push_back(FFFG, G, int, int *);
};
class G {
public:
template typename PointType
G(PointType);
H processEvent__counts_from_scanline;
void processEvent_() {
processEvent__counts_from_scanline.push_back(
FFFG, G, int, int *(FFG, G, int(FG, G(0, 0), 0), 0));
}
};
[Bug c++/63356] [4.8/4.9/5 Regression] Compilation failure where clang does not have problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.4 Summary|Compilation failure where |[4.8/4.9/5 Regression] |clang does not have |Compilation failure where |problems|clang does not have ||problems Known to fail||4.8.3, 4.9.1, 5.0
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #4) When compiled with Clang, it returns 0 by the way. So ... Pragma that are not recognized are ignored.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot com --- #pragma STDC is functionally a declaration (it can only occur either outside external declarations or preceding all explicit declarations and statements inside a compound statement - each such pragma has the same wording, including FENV_ROUND in TS 18661-1). Thus, while those pragmas are not currently implemented in GCC, treating them as syntactical entities at the same level as declarations and statements would be fully in accordance with the standard.
[Bug fortran/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-09-24 CC||ro at CeBiTec dot Uni-Bielefeld.DE Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- From (gdb) print buffer $1 = ':.', '3' repeats 16 times, '2:', ' ' repeats 30 times Then I guess that the buffer content is :.2: and not :.1: as expected by the test. Could you print the content of buffer after write(buffer, string) ':',1.0_8/3.0_8,':' and write(buffer, '(1x,a,g0,a)') ':',1.0_8/3.0_8,':' to check this guess? This look like a rounding problem on your platform (CCed Rainer Orth). What is the result if you compile the test with --save-temps (see PR323)?
[Bug c/63344] [5 Regression] Linux (makeallyes config) compilation error: error: apic_numachip causes a section type conflict with numachip_system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63344 --- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org --- I posted a patch here http://permalink.gmane.org/gmane.linux.kernel/1793662 BTW actually I don't agree that the bug is valid. We should probably relax the LTO checking to match what the linker does (which does not error out for this case).
[Bug fortran/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #4 from Richard PALO richard at netbsd dot org --- Just checked with the native omnios gcc 4.8.1 and the problem already exists there. I commented as indicated to be able to get debugger output for 2nd part: diff --git a/gcc/testsuite/gfortran.dg/fmt_g0_1.f08 b/gcc/testsuite/gfortran.dg/fmt_g0_1.f08 index ead6f81..3cceae6 100644 --- a/gcc/testsuite/gfortran.dg/fmt_g0_1.f08 +++ b/gcc/testsuite/gfortran.dg/fmt_g0_1.f08 @@ -8,7 +8,7 @@ write(buffer, string) ':',0,':' if (buffer.ne.:0:) call abort write(buffer, string) ':',1.0_8/3.0_8,':' -if (buffer.ne.:.1:) call abort +!if (buffer.ne.:.1:) call abort write(buffer, '(1x,a,g0,a)') ':',1.0_8/3.0_8,':' if (buffer.ne. :.1:) call abort write(buffer, string) ':',hello,':' with 4.9.1 buffer is as follows for the two writes with 1/3: (gdb) p buffer $1 = ':.', '3' repeats 16 times, '2:', ' ' repeats 30 times (gdb) n (gdb) p buffer $2 = ' :.', '3' repeats 16 times, '2:', ' ' repeats 29 times under 4.7.3: (gdb) p buffer $1 = ':.', '3' repeats 16 times, '1:', ' ' repeats 30 times (gdb) n (gdb) p buffer $2 = ' :.', '3' repeats 16 times, '1:', ' ' repeats 29 times
[Bug fortran/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #5 from Richard PALO richard at netbsd dot org --- Created attachment 33550 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33550action=edit output from --save-temps
[Bug rtl-optimization/63348] [5 Regression] gcc.dg/pr43670.c fail on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-24 Ever confirmed|0 |1 --- Comment #3 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to baoshan from comment #0) 1. Build GCC: $ configure --enable-languages=c --target=mips-linux --with-as=PATH_TO_MIPS_AS (--with-as is needed to set TARGET_CPU_DEFAULT with MASK_EXPLICIT_RELOCS in tm.h) $ make 2. Compile $ ./xgcc -O -fcompare-debug pr43670.c -I. -c xgcc: error: pr43670.c: -fcompare-debug failure (length) You can configure with --enable-languages=c --target=mips-linux only and add -mexplicit-relocs to compile flags: /ssd/uros/gcc-build-mips/gcc/xgcc -B /ssd/uros/gcc-build-mips/gcc -O -ftree-vrp -fcompare-debug -S -mexplicit-relocs pr43670.c xgcc: error: pr43670.c: -fcompare-debug failure (length) Confirmed - my patch just exposed the problem in generic RTL code.
[Bug c/53874] -Wswitch-enum not properly working with bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53874 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Sep 24 17:23:56 2014 New Revision: 215559 URL: https://gcc.gnu.org/viewcvs?rev=215559root=gccview=rev Log: PR c/61405 PR c/53874 gcc/ * asan.c (maybe_instrument_call): Add default case. * ipa-pure-const.c (special_builtin_state): Likewise. * predict.c (expr_expected_value_1): Likewise. * lto-streamer-out.c (write_symbol): Initialize variable. gcc/c-family/ * c-common.h (struct c_common_resword): Don't define CPP_KEYWORD. gcc/c/ * c-parser.c: Don't define CPP_KEYWORD. (c_parser_switch_statement): Pass original type to c_finish_case. * c-tree.h (c_finish_case): Update declaration. * c-typeck.c (c_finish_case): Add TYPE parameter. Pass it conditionally to c_do_switch_warnings. gcc/cp/ * semantics.c (finish_switch_cond): Call unlowered_expr_type. * tree.c (bot_manip): Add default case. * parser.c (cp_parser_primary_expression): Cast the controlling expression of a switch to an int. (cp_parser_unqualified_id): Likewise. gcc/testsuite/ * c-c++-common/pr53874.c: New test. * c-c++-common/pr61405.c: New test. libcpp/ * include/cpplib.h (enum cpp_ttype): Define CPP_KEYWORD. Added: trunk/gcc/testsuite/c-c++-common/pr53874.c trunk/gcc/testsuite/c-c++-common/pr61405.c Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.h trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/c/c-tree.h trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c trunk/gcc/ipa-pure-const.c trunk/gcc/lto-streamer-out.c trunk/gcc/predict.c trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/include/cpplib.h
[Bug c/61405] Not emitting enumeration value not handled in switch warning for bit-field enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61405 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Sep 24 17:23:56 2014 New Revision: 215559 URL: https://gcc.gnu.org/viewcvs?rev=215559root=gccview=rev Log: PR c/61405 PR c/53874 gcc/ * asan.c (maybe_instrument_call): Add default case. * ipa-pure-const.c (special_builtin_state): Likewise. * predict.c (expr_expected_value_1): Likewise. * lto-streamer-out.c (write_symbol): Initialize variable. gcc/c-family/ * c-common.h (struct c_common_resword): Don't define CPP_KEYWORD. gcc/c/ * c-parser.c: Don't define CPP_KEYWORD. (c_parser_switch_statement): Pass original type to c_finish_case. * c-tree.h (c_finish_case): Update declaration. * c-typeck.c (c_finish_case): Add TYPE parameter. Pass it conditionally to c_do_switch_warnings. gcc/cp/ * semantics.c (finish_switch_cond): Call unlowered_expr_type. * tree.c (bot_manip): Add default case. * parser.c (cp_parser_primary_expression): Cast the controlling expression of a switch to an int. (cp_parser_unqualified_id): Likewise. gcc/testsuite/ * c-c++-common/pr53874.c: New test. * c-c++-common/pr61405.c: New test. libcpp/ * include/cpplib.h (enum cpp_ttype): Define CPP_KEYWORD. Added: trunk/gcc/testsuite/c-c++-common/pr53874.c trunk/gcc/testsuite/c-c++-common/pr61405.c Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.h trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/c/c-tree.h trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c trunk/gcc/ipa-pure-const.c trunk/gcc/lto-streamer-out.c trunk/gcc/predict.c trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/include/cpplib.h
[Bug c/61405] Not emitting enumeration value not handled in switch warning for bit-field enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61405 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug c/53874] -Wswitch-enum not properly working with bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53874 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug rtl-optimization/63348] [5 Regression] gcc.dg/pr43670.c fail on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
CC|uros at gcc dot gnu.org|law at redhat dot com,
||ubizjak at gmail dot com
--- Comment #4 from Uroš Bizjak ubizjak at gmail dot com ---
Oh, try_split in emit-rtl.c has this gem:
3616 rtx_insn *after = NEXT_INSN (trial);
...
3640 if (after BARRIER_P (after))
3641{
3642 has_barrier = 1;
3643 after = NEXT_INSN (after);
3644}
...
3798 tem = emit_insn_after_setloc (seq, trial, INSN_LOCATION (trial));
3799
3800 delete_insn (trial);
3801 if (has_barrier)
3802emit_barrier_after (tem);
The code assumes that barrier immediately follows the call_insn (which is not
the case anymore when NOTE_CALL_ARG_LOCATION is emitted).
Adding RTL expert to CC.
[Bug fortran/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Your are not doing what I asked for. Could you compile and run without/with --save-temps the following test: character(25) :: string = (g0,g0,g0) character(50) :: buffer write(buffer, string) ':',1.0_8/3.0_8,':' print *, ', buffer, ' print *, ', :.1:, ' write(buffer, '(1x,a,g0,a)') ':',1.0_8/3.0_8,':' print *, ', buffer, ' print *, ', :.1:, ' end and post the result?
[Bug target/49551] tentative declaration after definition and -fdata-sections cause ICE in C front-end.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49551 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Component|c |target --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Is this still an issue?
[Bug c/48116] -Wreturn-type does not work as advertised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48116 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-09-24 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 #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Mine.
[Bug libstdc++/46151] namespace versioning holes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46151 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Do we need to keep this PR open now we have the abi_tag attribute to solve the problem?
[Bug c/41215] request: option to suppress discarded qualifiers warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41215 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I added -Wdiscarded-qualifiers a while ago.
[Bug target/63360] New: Does not retore f31 at -O0 across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360 Bug ID: 63360 Summary: Does not retore f31 at -O0 across function calls Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: camm at debian dot org Created attachment 33551 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33551action=edit invert.c, invert.cpp, and invert.gdb gdb session Register variable stored in f31 is stored on the stack, but not restored and thus clobbered, after a function call. Compiled with gcc -c -g -Wall -fsigned-char -Wno-unused-but-set-variable -pipe -g -mlongcall
[Bug libstdc++/46151] namespace versioning holes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46151 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- abi_tag does indeed address this issue.
[Bug libstdc++/29988] More stl_tree.h enhancements: improving operator=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29988 --- Comment #2 from François Dumont fdumont at gcc dot gnu.org --- Author: fdumont Date: Wed Sep 24 19:55:35 2014 New Revision: 215568 URL: https://gcc.gnu.org/viewcvs?rev=215568root=gccview=rev Log: 2014-09-24 François Dumont fdum...@gcc.gnu.org PR libstdc++/29988 * include/bits/stl_tree.h (_Rb_tree_reuse_or_alloc_node): New. (_Rb_tree_alloc_node): New. (_Rb_tree::operator=(_Rb_tree)): New. (_Rb_tree::_M_assign_unique): New. (_Rb_tree::_M_assign_equal): New. (_Rb_tree): Adapt to reuse allocated nodes as much as possible. * include/bits/stl_map.h (std::map::operator=(std::map)): Default implementation. (std::map::operator=(initializer_list)): Adapt to use _Rb_tree::_M_assign_unique. * include/bits/stl_multimap.h (std::multimap::operator=(std::multimap)): Default implementation. (std::multimap::operator=(initializer_list)): Adapt to use _Rb_tree::_M_assign_equal. * include/bits/stl_set.h (std::set::operator=(std::set)): Default implementation. (std::set::operator=(initializer_list)): Adapt to use _Rb_tree::_M_assign_unique. * include/bits/stl_multiset.h (std::multiset::operator=(std::multiset)): Default implementation. (std::multiset::operator=(initializer_list)): Adapt to use _Rb_tree::_M_assign_equal. * testsuite/23_containers/map/allocator/copy_assign.cc (test03): New. * testsuite/23_containers/map/allocator/init-list.cc: New. * testsuite/23_containers/map/allocator/move_assign.cc (test03): New. * testsuite/23_containers/multimap/allocator/copy_assign.cc (test03): New. * testsuite/23_containers/multimap/allocator/init-list.cc: New. * testsuite/23_containers/multimap/allocator/move_assign.cc (test03): New. * testsuite/23_containers/multiset/allocator/copy_assign.cc (test03): New. * testsuite/23_containers/multiset/allocator/init-list.cc: New. * testsuite/23_containers/multiset/allocator/move_assign.cc (test03): New. * testsuite/23_containers/set/allocator/copy_assign.cc (test03): New. * testsuite/23_containers/set/allocator/init-list.cc: New. * testsuite/23_containers/set/allocator/move_assign.cc (test03): New. Added: trunk/libstdc++-v3/testsuite/23_containers/map/allocator/init-list.cc trunk/libstdc++-v3/testsuite/23_containers/multimap/allocator/init-list.cc trunk/libstdc++-v3/testsuite/23_containers/multiset/allocator/init-list.cc trunk/libstdc++-v3/testsuite/23_containers/set/allocator/init-list.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_map.h trunk/libstdc++-v3/include/bits/stl_multimap.h trunk/libstdc++-v3/include/bits/stl_multiset.h trunk/libstdc++-v3/include/bits/stl_set.h trunk/libstdc++-v3/include/bits/stl_tree.h trunk/libstdc++-v3/testsuite/23_containers/map/allocator/copy_assign.cc trunk/libstdc++-v3/testsuite/23_containers/map/allocator/move_assign.cc trunk/libstdc++-v3/testsuite/23_containers/multimap/allocator/copy_assign.cc trunk/libstdc++-v3/testsuite/23_containers/multimap/allocator/move_assign.cc trunk/libstdc++-v3/testsuite/23_containers/multiset/allocator/copy_assign.cc trunk/libstdc++-v3/testsuite/23_containers/multiset/allocator/move_assign.cc trunk/libstdc++-v3/testsuite/23_containers/set/allocator/copy_assign.cc trunk/libstdc++-v3/testsuite/23_containers/set/allocator/move_assign.cc
[Bug libstdc++/29988] More stl_tree.h enhancements: improving operator=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29988 François Dumont fdumont at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from François Dumont fdumont at gcc dot gnu.org --- Nodes are now being reused on copy assignment, move assignment, list initialization as long as allocator allows it.
[Bug sanitizer/63361] New: Test case c-c++-common/ubsan/float-cast-overflow-1.c fails on Pentium2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63361 Bug ID: 63361 Summary: Test case c-c++-common/ubsan/float-cast-overflow-1.c fails on Pentium2 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de 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 Rev: 215226 FAIL: c-c++-common/ubsan/float-cast-overflow-1.c -O0 output pattern test, is (/home/ed/gnu/gcc-build/gcc/testsuite/gcc/float-cast-overflow-1.exe+0x8048604): runtime error: value -133 is outside the range of representable values of type 'signed char' FAIL: c-c++-common/ubsan/float-cast-overflow-1.c -O1 output pattern test, is (/home/ed/gnu/gcc-build/gcc/testsuite/gcc/float-cast-overflow-1.exe+0x80485eb): runtime error: value -133 is outside the range of representable values of type 'signed char' FAIL: c-c++-common/ubsan/float-cast-overflow-1.c -O2 output pattern test, is (/home/ed/gnu/gcc-build/gcc/testsuite/gcc/float-cast-overflow-1.exe+0x804f647): runtime error: value -133 is outside the range of representable values of type 'signed char' FAIL: c-c++-common/ubsan/float-cast-overflow-1.c -O3 -fomit-frame-pointer output pattern test, is (/home/ed/gnu/gcc-build/gcc/testsuite/gcc/float-cast-overflow-1.exe+0x804f647): runtime error: value -133 is outside the range of representable values of type 'signed char' FAIL: c-c++-common/ubsan/float-cast-overflow-1.c -O3 -g output pattern test, is /home/ed/gnu/gcc-trunk/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c:17: runtime error: value -133 is outside the range of representable values of type 'signed char' FAIL: c-c++-common/ubsan/float-cast-overflow-1.c -Os output pattern test, is (/home/ed/gnu/gcc-build/gcc/testsuite/gcc/float-cast-overflow-1.exe+0x8048505): runtime error: value -133 is outside the range of representable values of type 'signed char' FAIL: c-c++-common/ubsan/float-cast-overflow-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test, is (/home/ed/gnu/gcc-build/gcc/testsuite/gcc/float-cast-overflow-1.exe+0x804f647): runtime error: value -133 is outside the range of representable values of type 'signed char' FAIL: c-c++-common/ubsan/float-cast-overflow-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test, is (/home/ed/gnu/gcc-build/gcc/testsuite/gcc/float-cast-overflow-1.exe+0x804f657): runtime error: value -133 is outside the range of representable values of type 'signed char' cat /proc/cpuinfo processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 5 model name: Pentium II (Deschutes) stepping: 2 microcode: 0x2a cpu MHz: 448.822 cache size: 512 KB fdiv_bug: no hlt_bug: no f00f_bug: no coma_bug: no fpu: yes fpu_exception: yes cpuid level: 2 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pse36 mmx fxsr bogomips: 897.64 clflush size: 32 cache_alignment: 32 address sizes: 36 bits physical, 32 bits virtual power management: processor: 1 vendor_id: GenuineIntel cpu family: 6 model: 5 model name: Pentium II (Deschutes) stepping: 2 microcode: 0x2a cpu MHz: 448.822 cache size: 512 KB fdiv_bug: no hlt_bug: no f00f_bug: no coma_bug: no fpu: yes fpu_exception: yes cpuid level: 2 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pse36 mmx fxsr bogomips: 897.67 clflush size: 32 cache_alignment: 32 address sizes: 36 bits physical, 32 bits virtual power management:
[Bug sanitizer/63361] Test case c-c++-common/ubsan/float-cast-overflow-1.c fails on Pentium2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63361 --- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 33552 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33552action=edit log file with detailed error information gcc.log, from this command: make -k check-gcc RUNTESTFLAGS=ubsan.exp=c-c++-common/ubsan/float-cast-overflow-1.c first I did not understand, what is wrong with the output. but now I see, that the test does only print 10 x runtime error: value 9.22337e+18 is outside the range of representable values of type 'long long int' but this message is expectet to be print 15 times. likewise for runtime error: value 1.84467e+19 is outside the range of representable values of type 'long long unsigned int' it is only printed 11 times, but expected 15 times. so, it looks like a rounding issue.
[Bug fortran/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #7 from Richard PALO richard at netbsd dot org --- $ cat test.f08 character(25) :: string = (g0,g0,g0) character(50) :: buffer write(buffer, string) ':',1.0_8/3.0_8,':' print *, ', buffer, ' print *, ', :.1:, ' write(buffer, '(1x,a,g0,a)') ':',1.0_8/3.0_8,':' print *, ', buffer, ' print *, ', :.1:, ' end $ gfortran test.f08 -o test $ ./test ':.2: ' ' :.1:' ' :.2: ' ' :.1:' Output the same with/without attached is the .s
[Bug fortran/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #8 from Richard PALO richard at netbsd dot org --- Created attachment 33553 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33553action=edit test.s
[Bug fortran/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #9 from Richard PALO richard at netbsd dot org --- output from 4.7.3: ':.1: ' ' :.1:' ' :.1: ' ' :.1:' and test.s.4.7.3 attached
[Bug fortran/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #10 from Richard PALO richard at netbsd dot org --- Created attachment 33554 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33554action=edit test.s from 4.7.3
[Bug lto/63226] [5 Regression] ICE with -flto-odr-type-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63226 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #9) Tobias, does your big program work now? I have just tested it - and it works now. Thanks! Also if you have testsuite ready testcases, I think we can plug them in with -Wno-odr at least (still lacking way to test LTO time warnings) I don't have any. But marxin has at least commit a test case for the ICE.
[Bug c++/63362] New: The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362 Bug ID: 63362 Summary: The c++11 triviality-traits need front-end help Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ville.voutilainen at gmail dot com CC: jason at redhat dot com Jason wrote in a private email: I think what we need is a compiler hook to say whether a particular expression is trivial or not. and further I'm thinking that parsing would be similar to parsing any other unevaluated context (sizeof/alignof/decltype), and then we would walk_tree through the resulting expression to find any calls and see if any of them are to non-trivial functions. See https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html Table 1.2. C++ 2011 Implementation Status 20.9.4.3Type properties
[Bug libstdc++/56193] ios_base should replace operator void* with explicit operator bool in C++11 onwards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56193 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Wed Sep 24 22:13:35 2014 New Revision: 215571 URL: https://gcc.gnu.org/viewcvs?rev=215571root=gccview=rev Log: PR libstdc++/56193 * config/abi/pre/gnu.ver: Add new exports. * include/bits/basic_ios.h (basic_ios::operator bool): Define. * src/c++98/ios_locale.cc (basic_ios::operator void*): Instantiate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/include/bits/basic_ios.h trunk/libstdc++-v3/src/c++98/ios_locale.cc
[Bug target/63335] GCC:failures for vector double on calls to bif vec_[all|any]_[nge|nle]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63335 Bill Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot gnu.org --- Comment #2 from Bill Schmidt wschmidt at gcc dot gnu.org --- I see the problem. I'll work on a patch.
[Bug target/63360] Does not retore f31 at -O0 across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63360 --- Comment #1 from Peter Bergner bergner at gcc dot gnu.org --- (In reply to camm from comment #0) Created attachment 33551 [details] invert.c, invert.cpp, and invert.gdb gdb session Register variable stored in f31 is stored on the stack, but not restored and thus clobbered, after a function call. Camm and I discussed this offline and I mentioned that the gdb disassembly doesn't show any of the functions called by L2(), so we cannot determine which function is clobbering f31. Camm is going to rerun the debugger and determine which calle is clobbering f31 and get the disassemb;y for that.
[Bug target/63335] GCC:failures for vector double on calls to bif vec_[all|any]_[nge|nle]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63335 --- Comment #3 from Bill Schmidt wschmidt at gcc dot gnu.org --- Proposed patch here: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02201.html
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org Component|fortran |target --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr --- Comment 7 confirms my guess that there is a rounding problem on i386-sun-solaris2.11 (the test is three-year old and succeeds on all the revisions I have used on darwin, and all the tests I have looked at https://gcc.gnu.org/ml/gcc-testresults/2014-09/). This may be related to problems found with solaris during the fix for PR60128. Note that there is no point to post assembly files: the problem is either in libgfortran or (more probably) in the C library.
[Bug libstdc++/56193] ios_base should replace operator void* with explicit operator bool in C++11 onwards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56193 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed.
[Bug target/63354] gcc -pg -mprofile-kernel creates unused stack frames on leaf functions on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63354 --- Comment #2 from Anton Blanchard anton at samba dot org --- Created attachment 33555 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33555action=edit Avoid an unused stack frame for -mprofile-kernel profiling on leaf functions.
