[Bug debug/63342] [5 Regression] ICE in loc_list_from_tree, at dwarf2out.c:14698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63342 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Should be fixed now.
[Bug sanitizer/63369] many asan test cases fail on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63369 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Bernd Edlinger bernd.edlinger at hotmail dot de --- confirmed, fixed in current GCC snap shot. Thanks.
[Bug c++/63438] New: conditional operator deducing lvalues incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63438 Bug ID: 63438 Summary: conditional operator deducing lvalues incorrectly Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric.niebler at gmail dot com Target: i686-pc-cygwin Problem is with the following code: int i = 0; const int j = 0; static_assert(std::is_samedecltype(true? i : j), int const ::value, ); I expect the static_assert to pass. It doesn't. It does with clang. Compiled with -std=gnu++11. $ gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-4.9.0/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-4.9.0/libexec/gcc/i686-pc-cygwin/4.9.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ../gcc-4.9.0/configure --prefix=/usr/local/gcc-4.9.0 --disable-bootstrap --enable-languages=c,c++ Thread model: single gcc version 4.9.0 (GCC)
[Bug c++/63438] conditional operator deducing lvalues incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63438 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-02 Depends on||34075 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This was DR #587 against the C++98 standard and GCC has not been fixed to implement this for C++11. See bug 34075 of the reference to this defect report.
[Bug target/61153] [ARM] vbic vorn tests fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #9 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Hi, these tests are still failing. what are we gonna do about it?
[Bug target/62128] Use vpalignr for AVX2 rotation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62128 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Oct 2 07:29:49 2014 New Revision: 215796 URL: https://gcc.gnu.org/viewcvs?rev=215796root=gccview=rev Log: PR target/62128 * config/i386/i386.c (expand_vec_perm_1): Try expand_vec_perm_palignr if it expands to a single insn only. (expand_vec_perm_palignr): Add SINGLE_INSN_ONLY_P argument. If true, fail unless in_order is true. Add forward declaration. (expand_vec_perm_vperm2f128): Fix up comment about which permutation is useful for one_operand_p. (ix86_expand_vec_perm_const_1): Adjust expand_vec_perm_palignr caller. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug c++/63437] [4.9/5 regression][C++14] Parenthesized movable but not copyable object doesn't compile in return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63437 --- Comment #2 from Kohei Takahashi flast at flast dot jp --- (In reply to Andrew Pinski from comment #1) in C++14 (a) means the same as static_casttypeof(a) (a). So it is a reference at this point which means const is better than . Or at least that is how I understand this. Does clang implement the C++11 () rule correctly? n3376 12.8 [class.copy] paragraph 32 says: When the criteria for elision of a copy operation are met or would be met save for the fact that the source object is a function parameter, and the object to be copied is designated by an lvalue, overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue. And latest draft says more clearly. https://github.com/cplusplus/draft/blob/master/source/special.tex#L3021-L3062 Therefore, I think move should be performed even if parenthesized.
[Bug target/63439] New: FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect Alignment of access forced using peeling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63439 Bug ID: 63439 Summary: FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect Alignment of access forced using peeling Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de Obtained from SVN: trunk revision 215672 Configured with: ../gcc-5-20140928/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf --enable-languages=all,ada,go,obj-c++ --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard Thread model: posix gcc version 5.0.0 20140928 (experimental) (GCC) FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect Alignment of access forced using peeling FAIL: gcc.dg/vect/vect-33.c -flto -ffat-lto-objects scan-tree-dump vect Alignment of access forced using peeling
[Bug libgcc/63436] libgcc2.c:273:1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63436 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-10-02 Ever confirmed|0 |1 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- GCC 4.7 is no longer maintained. Please try a newer version.
[Bug libstdc++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #11) Jonathan, what should we do about this? Is this implementation better than the one in libstdc++? I don't know, I haven't looked. Agustin, do you have a copyright assignment?
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Can be closed now.
[Bug c++/63437] [4.9/5 regression][C++14] Parenthesized movable but not copyable object doesn't compile in return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63437 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-02 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, the new wording is clear that parenthesized names are OK.
[Bug c++/63438] conditional operator deducing lvalues incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63438 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE Target Milestone|--- |5.0 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- This is PR 51317 which is fixed on trunk. *** This bug has been marked as a duplicate of bug 51317 ***
[Bug c++/51317] [C++0x] [DR 587] Wrong value category of conditional expression where lvalue operands differ only in cv-qualification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51317 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||eric.niebler at gmail dot com --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 63438 has been marked as a duplicate of this bug. ***
[Bug c++/61736] Conditional expression yields wrong value category
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61736 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-02 Ever confirmed|0 |1
[Bug other/63440] New: -Og does enable -fmerge-constants too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63440 Bug ID: 63440 Summary: -Og does enable -fmerge-constants too Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: rdiezmail-gcc at yahoo dot de The documentation for -fmerge-constants does not mention that the new optimization level -Og does enable -fmerge-constants too. Or at least it seems to do, judging by the generated code size in my tests.
[Bug c++/63438] conditional operator deducing lvalues incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63438 Bug 63438 depends on bug 34075, which changed state. Bug 34075 Summary: [DR 587] temporary used in ?: expression tho second and third expr. lvalues https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34075 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/34075] [DR 587] temporary used in ?: expression tho second and third expr. lvalues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34075 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- This is a dup of 51317 which has now been fixed on the trunk. *** This bug has been marked as a duplicate of bug 51317 ***
[Bug c++/51317] [C++0x] [DR 587] Wrong value category of conditional expression where lvalue operands differ only in cv-qualification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51317 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||james.kanze at gmail dot com --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 34075 has been marked as a duplicate of this bug. ***
[Bug go/61877] [5 Regression]: reflect: cannot use []string as type string in Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877 --- Comment #6 from Michael Hudson-Doyle michael.hudson at linaro dot org --- Created attachment 33640 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33640action=edit my test cases I think the patch works because when the compiler sees a call to a variadic function, it generates a regular call with a slice as the last parameter. I'm attaching a test case that I wrote -- it passes with my patch and fails without it, so I think my patch has at last something going for it... It also seems the intel case is broken on this test case on mainline. If I hack it to take the ffi case, it works with my patch. Also 4.9 works, which confuses me a little -- I didn't think the intel code path had changed here (but haven't actually checked).
[Bug c/63441] New: incorrect array subscript is below/above array bounds diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63441
Bug ID: 63441
Summary: incorrect array subscript is below/above array
bounds diagnostic
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rschiele at gmail dot com
I found a case where gcc diagnostic array subscript is below/above array
bounds is wrong in my opinion. I simplified the test case as much as possible
and got it down to:
typedef struct {
int a[2];
int b;
} c;
int f(c *d, int e)
{
int r = 0;
int p;
int i;
switch(e) {
case 0:
i = 0;
break;
default:
i = -1;
break;
};
p = d-a[i];
if (p 0)
r = 0;
else {
switch(e) {
case 0:
r = 1;
break;
}
}
return r;
}
The basic idea of the function f was that the parameter e is only allowed to
get a certain set of permitted values. In that example the set was reduced to
only 0 being the permitted value (which obviously does no longer make a lot of
sense but the original code with a larger set did show the same problem). Based
on that value a specific action is taken in the first switch statement and a
default case is given, which sets the value i to an invalid one (-1). I agree
this is not particularly intelligent error handling but was found with that
pattern in real code.) Later this value i is used for indexing an array. This
is diagnosed by gcc to be below array bounds (or above for a value too high),
which would obviously make sense for (i == -1) but on the other hand I don't
see any reason gcc should assume this default case to ever happen.
Further analysis reveals that this behavior appeared in the development phase
of gcc 4.8 with this commit:
commit 78b7a67520737f2e029383dd5a89ba8c1c4a3ef9
Author: steven steven@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Mon Jul 2 18:50:51 2012 +
gcc/
* stmt.c (emit_case_bit_tests): Remove.
(expand_case): Remove expand_switch_using_bit_tests_p code.
* tree-switch-conversion.c (hoist_edge_and_branch_if_true): New.
(MAX_CASE_BIT_TESTS): Moved from stmt.c to here.
(lshift_cheap_p): Likewise.
(expand_switch_using_bit_tests_p): Likewise.
(struct case_bit_test): Likewise.
(case_bit_test_cmp): Likewise.
(emit_case_bit_tests): New implementation for GIMPLE.
(gen_inbound_check): Do not release post-dominator info here.
(process_switch): Reorder code. Expand as bit tests if it
looks like a win.
(do_switchconv): Release post-dominator info here if something
changed.
(struct gimple_opt_pass): Verify more.
* tree.h (expand_switch_using_bit_tests_p): Remove prototype.
testsuite/
* gcc.dg/tree-ssa/pr36881.c: Fix test case to not expand as bit tests.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@189173
138bc75d-0d04-0410-961f-82ee72b054a4
This obviously does not necessarily mean that it was introduced here since this
could have been just the trigger for that.
Another interesting observation is that if I replace the second, not directly
related switch statement with an if statement with the same semantics the
obscure diagnostic goes away.
It seems that this problem is independent of the architecture but I actually
tested this on arm-*-linux-gnueabihf and i686-*-linux-gnu.
Do people here agree this is a bug in diagnostics or do people think that it is
legitimate to assume that the default case actually can happen?
[Bug c/63441] incorrect array subscript is below/above array bounds diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63441 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- I think it is just fine to diagnose this.
[Bug middle-end/63247] fortran array alignment in omp target map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63247 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug fortran/62131] [4.9/5 Regression] OpenMP: Subobject of an allocatable array not allowed in OMP ATOMIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62131 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- The OpenMP 4.1 wording seems to be to allow this. Thus fixed.
[Bug go/63172] gccgo testcase cplx2.go execution provides incorrect answers on trunk for powerpc64, powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63172 boger at us dot ibm.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from boger at us dot ibm.com --- This is the same problem as described in 60181. *** This bug has been marked as a duplicate of bug 60181 ***
[Bug target/60181] constant folding of complex number incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181 boger at us dot ibm.com changed: What|Removed |Added CC||boger at us dot ibm.com --- Comment #5 from boger at us dot ibm.com --- *** Bug 63172 has been marked as a duplicate of this bug. ***
[Bug go/61877] [5 Regression]: reflect: cannot use []string as type string in Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877 --- Comment #7 from Alexander Shopov lists at kambanaria dot org --- It also seems the intel case is broken on this test case on mainline. If I hack it to take the ffi case, it works with my patch. Also 4.9 works, which Not sure how relevant this would be, but makefuncgo_amd64.go seems quite changed between 4.9 and master/trunk
[Bug tree-optimization/63381] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63381 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-02 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Works with -fno-tree-vrp. Seems to have started with r211904.
[Bug tree-optimization/63381] [5 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63381 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Ugh, ignore Comment 1, that was for PR63380.
[Bug tree-optimization/63380] [5 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63380 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-02 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Summary|Wrong constant folding |[5 Regression] Wrong ||constant folding Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Works with -fno-tree-vrp. Seems to have started with r211904.
[Bug tree-optimization/63381] [5 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63381 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Actually, Comment 1 applies here as well, so these two could be dups.
[Bug go/63172] gccgo testcase cplx2.go execution provides incorrect answers on trunk for powerpc64, powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63172 boger at us dot ibm.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from boger at us dot ibm.com --- Comments for this bug will appear in 60181.
[Bug target/63442] New: [AArch64] ICE with ubsan/overflow-int128.c test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63442 Bug ID: 63442 Summary: [AArch64] ICE with ubsan/overflow-int128.c test Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org testsuite/c-c++-common/ubsan/overflow-int128.c causes an ICE on AArch64: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/gcc/xgcc -B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/gcc/ /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/c-c++-common/ubsan/overflow-int128.c gcc_tg.o -B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/./libsanitizer/ -B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/./libsanitizer/ubsan/ -L/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/./libsanitizer/ubsan/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never-O0 -fsanitize=signed-integer-overflow -DSTACK_SIZE=16384 -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm-o ./overflow-int128.exe (timeout = 800) /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/c-c++-common/ubsan/overflow-int128.c: In function 'main': /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/c-c++-common/ubsan/overflow-int128.c:14:27: internal compiler error: in copy_to_mode_reg, at explow.c:635 0x728188 copy_to_mode_reg(machine_mode, rtx_def*) /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/explow.c:635 0x95cafb prepare_cmp_insn /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/optabs.c:4206 0x95d863 emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*, machine_mode, int, rtx_def*, int) /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/optabs.c:4381 0x86b8e6 ubsan_expand_si_overflow_addsub_check(tree_code, gimple_statement_base*) /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/internal-fn.c:303 0x65da05 expand_gimple_stmt_1 /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/cfgexpand.c:3218 0x65df3f expand_gimple_stmt /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/cfgexpand.c:3370 0x65e7df expand_gimple_basic_block /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/cfgexpand.c:5209 0x661a93 execute /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/cfgexpand.c:5815 Please submit a full bug report, Where GCC is confired with --target aarch64-none-linux-gnu
[Bug go/61877] [5 Regression]: reflect: cannot use []string as type string in Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877 --- Comment #8 from Ian Lance Taylor ian at airs dot com --- I see only minor changes to makefuncgo_amd64.go between 4.9 and mainline--are you sure you are looking at the right files?
[Bug debug/63342] [5 Regression] ICE in loc_list_from_tree, at dwarf2out.c:14698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63342 --- Comment #6 from Julian Taylor jtaylor.debian at googlemail dot com --- thanks, head (and branches) work fine now
[Bug target/60181] constant folding of complex number incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181 --- Comment #6 from boger at us dot ibm.com --- If the last comment is true, does that mean the fold_const.c file in gcc should be built in a way so that it doesn't use the fma, like using some kind of option during the build of gcc at least for this file on the s390 and Power?
[Bug target/60181] constant folding of complex number incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target|ppc64-ibm-linux,|s390x-ibm-linux, |s390x-ibm-linux |powerpc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-02 CC||dje at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from David Edelsohn dje at gcc dot gnu.org --- confirmed.
[Bug middle-end/63443] New: copyrename2 introducing bogus profile counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63443 Bug ID: 63443 Summary: copyrename2 introducing bogus profile counts Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: tejohnson at google dot com This problem showed up in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422, where a new assert introduced in jump threading triggered because of insane profile counts coming in. The LTO test case attached to that bug has profile data, but the affected routine did not have profile counts and only frequencies (main() from mozilla-xremote-client.ii which does not have a gcda file). However, copyrename2 introduced some non-zero profile counts, which should not happen. To duplicate: % g++ -flto -fprofile-use -fno-exceptions -std=gnu++0x -O2 mozilla-xremote-client.ii XRemoteClient.ii I've attached the input files to this bug report as well.
[Bug target/60181] constant folding of complex number incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181 --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to boger from comment #6) If the last comment is true, does that mean the fold_const.c file in gcc should be built in a way so that it doesn't use the fma, like using some kind of option during the build of gcc at least for this file on the s390 and Power? No it is fma usage in the runtime sources and not in the fold-const case.
[Bug c++/63306] [4.9 Regression] ICE: Segmentation fault in analyze_functions()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63306 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed. Thanks.
[Bug tree-optimization/63375] [4.8/4.9/5 Regression] reordering of reads across fences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63375 --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Thu Oct 2 16:49:14 2014 New Revision: 215804 URL: https://gcc.gnu.org/viewcvs?rev=215804root=gccview=rev Log: 2014-10-02 Martin Jambor mjam...@suse.cz PR tree-optimization/63375 * tree-sra.c (build_access_from_expr_1): Disqualify volatile references. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-sra.c
[Bug libstdc++/63199] Inserting std::wregex to std::vector loses some std::wregex values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63199 --- Comment #4 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Thu Oct 2 16:50:39 2014 New Revision: 215805 URL: https://gcc.gnu.org/viewcvs?rev=215805root=gccview=rev Log: PR libstdc++/63199 * include/bits/regex.h (basic_regex::basic_regex, basic_regex::assign, basic_regex::swap): Fix dangling _M_traits reference problem. * testsuite/28_regex/algorithms/regex_match/ecma/wchar_t/63199.cc: New test case. Added: branches/gcc-4_9-branch/libstdc++-v3/testsuite/28_regex/algorithms/regex_match/ecma/wchar_t/63199.cc Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex.h
[Bug tree-optimization/63375] [4.8/4.9/5 Regression] reordering of reads across fences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63375 --- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Thu Oct 2 17:11:24 2014 New Revision: 215806 URL: https://gcc.gnu.org/viewcvs?rev=215806root=gccview=rev Log: 2014-10-02 Martin Jambor mjam...@suse.cz PR tree-optimization/63375 * tree-sra.c (build_access_from_expr_1): Disqualify volatile references. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/tree-sra.c
[Bug tree-optimization/63375] [4.8/4.9/5 Regression] reordering of reads across fences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63375 --- Comment #8 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Thu Oct 2 17:13:30 2014 New Revision: 215807 URL: https://gcc.gnu.org/viewcvs?rev=215807root=gccview=rev Log: 2014-10-02 Martin Jambor mjam...@suse.cz PR tree-optimization/63375 * tree-sra.c (build_access_from_expr_1): Disqualify volatile references. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/tree-sra.c
[Bug go/61880] Linking with external functions in C does not work in GO when using gccgo, while it works in gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880 --- Comment #2 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Thu Oct 2 17:56:50 2014 New Revision: 215810 URL: https://gcc.gnu.org/viewcvs?rev=215810root=gccview=rev Log: PR go/61880 compiler: symbol names should have '.' replaced with '_' Package and symbol names issued by the cgo tool and compiler should be the same for the object files to link. A minimal change to fix only: https://code.google.com/p/gofrontend/issues/detail?id=36 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880 Modified: trunk/gcc/go/gofrontend/gogo.cc
[Bug go/61880] Linking with external functions in C does not work in GO when using gccgo, while it works in gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880 --- Comment #3 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Thu Oct 2 18:00:01 2014 New Revision: 215812 URL: https://gcc.gnu.org/viewcvs?rev=215812root=gccview=rev Log: PR go/61880 compiler: symbol names should have '.' replaced with '_' Package and symbol names issued by the cgo tool and compiler should be the same for the object files to link. A minimal change to fix only: https://code.google.com/p/gofrontend/issues/detail?id=36 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880 Modified: branches/gcc-4_9-branch/gcc/go/gofrontend/gogo.cc
[Bug go/61880] Linking with external functions in C does not work in GO when using gccgo, while it works in gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.2 --- Comment #4 from Ian Lance Taylor ian at airs dot com --- Fixed on mainline and 4.9 branch.
[Bug c++/53025] [C++11] noexcept operator depends on copy-elision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53025 --- Comment #7 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Thu Oct 2 18:05:55 2014 New Revision: 215813 URL: https://gcc.gnu.org/viewcvs?rev=215813root=gccview=rev Log: /cp 2014-10-02 Paolo Carlini paolo.carl...@oracle.com PR c++/53025 * cp-tree.h (struct saved_scope): Add noexcept_operand. (cp_noexcept_operand): Define. * call.c (build_over_call): Use it. * parser.c (cp_parser_unary_expression, [RID_NOEXCEPT]): Likewise. * pt.c (tsubst_copy_and_build, [NOEXCEPT_EXPR]): Likewise. /testsuite 2014-10-02 Paolo Carlini paolo.carl...@oracle.com PR c++/53025 * g++.dg/cpp0x/noexcept23.C: New. * g++.dg/cpp0x/noexcept24.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/noexcept23.C trunk/gcc/testsuite/g++.dg/cpp0x/noexcept24.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/63444] New: Compilation consumes 2.5G memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63444 Bug ID: 63444 Summary: Compilation consumes 2.5G memory Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bobby.prani at gmail dot com Created attachment 33641 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33641action=edit pre-processed file The compilation of the attached pre-processed file takes 2.5G memory. Not exactly a regression since both 4.8 and 4.9 do the same. But may be an interesting test case for optimizations. $ g++ -std=c++11 -c -fPIC -DNDEBUG -O3 -fno-strict-aliasing -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_FILE_OFFSET_BITS=64 test.i -o test.o
[Bug tree-optimization/63302] [4.9 Regression] Code with 64-bit long long constants is miscompiled on 32-bit host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302 --- Comment #16 from dave.anglin at bell dot net --- On 9/29/2014 9:02 AM, dave.anglin at bell dot net wrote: I've started a full build and check with 4.9 branch. I'll also test it on hpux starting this evening. I see no regressions with the change on 4.9 and trunk. Tested on hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.11 and hppa-unknown-linux-gnu on 4.9. Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux1.11 on trunk. Dave
[Bug c/63445] New: request: make -Wstrict-overflow avoid a class of false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445
Bug ID: 63445
Summary: request: make -Wstrict-overflow avoid a class of false
positives
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jim at meyering dot net
Thanks for tending and continually improving gcc.
I see some surprising new warnings when using built-from-git (an hour ago) gcc
to compile coreutils. Here is a reduced test case:
In this example, the code ensures j - i will be positive before assigning
that value to an unsigned int n. Can gcc be taught to avoid this obvious
false positive?
$ cat f.c
int
f (int i, int j)
{
unsigned int c = 0;
if (i j)
{
unsigned int n = j - i;
for (unsigned int i = 0; i n; i++)
{
c++;
}
}
return c;
}
$ gcc -O2 -std=c99 -Wstrict-overflow -c f.c
f.c: In function ‘f’:
f.c:9:7: warning: assuming signed overflow does not occur when simplifying
conditional [-Wstrict-overflow]
for (unsigned int i = 0; i n; i++)
^
$ gcc -v 21|tail -2
gcc version 5.0.0 20141002 (experimental) (GCC)
[Bug middle-end/63422] [5.0 Regression] ICE in freqs_to_counts_path, at tree-ssa-threadupdate.c:981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422 --- Comment #7 from tejohnson at gcc dot gnu.org --- Author: tejohnson Date: Thu Oct 2 20:30:11 2014 New Revision: 215822 URL: https://gcc.gnu.org/viewcvs?rev=215822root=gccview=rev Log: 2014-10-01 Teresa Johnson tejohn...@google.com PR middle-end/63422 * tree-ssa-threadupdate.c (freqs_to_counts_path): Remove asserts to handle incoming insanities. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-threadupdate.c
[Bug c++/57248] string parameter to constexpr functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57248 --- Comment #7 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to Paolo Carlini from comment #6) However, it's true that all the up to date compilers I have at hand reject it with the same kind of error about get at: return std::getindex(array)(t1); like for my reduced testcase in Comment #5. Ouch, you are right - I overlooked the very important fact that *within* function extract the expression index(array) cannot be a constant expression, because we have an argument value involved! In the context of a constexpr function any argument value itself cannot be a constant expression, because the decision for something being a constant expression is always context-independent. I'm very sorry for having mislead Paolo with my original remark, indeed the original test case is *invalid* because it is based on the assumption that a constexpr function argument itself could be a constant expression.
[Bug c++/57460] [C++11] Sfinae doesn't respect dependent context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57460 --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to Jason Merrill from comment #1) But there is no T that would cause check(EXPR,T()) to be valid, so no valid specialization can be generated for the template, so the program is ill-formed (no diagnostic required). After rethinking about it, I agree.
[Bug c++/57460] [C++11] Sfinae doesn't respect dependent context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57460 --- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com --- I tried to close the issue as INVALID, but it seems that I cannot do that by myself.
[Bug c++/57460] [C++11] Sfinae doesn't respect dependent context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57460 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Daniel Krügler from comment #3) I tried to close the issue as INVALID, but it seems that I cannot do that by myself. Strange, as the reporter you should be able to.
[Bug c++/57460] [C++11] Sfinae doesn't respect dependent context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57460 --- Comment #5 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to Marc Glisse from comment #4) (In reply to Daniel Krügler from comment #3) I tried to close the issue as INVALID, but it seems that I cannot do that by myself. Strange, as the reporter you should be able to. Thanks Marc, for your help. I might have been looking at the wrong place, because when trying to do it now, it would seem to work.
[Bug fortran/37131] inline matmul for small matrix sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2008-08-16 22:55:22 |2014-10-2 --- Comment #15 from Thomas Koenig tkoenig at gcc dot gnu.org --- Hi Mikael, do you think you can do this using the scalarizer? If not, I might try to do it using front-end optimization, because I don't know what the scalarizer is really about :-)
[Bug target/63435] Bad code with weak vs localalias on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63435 --- Comment #2 from Jan Hubicka hubicka at ucw dot cz --- Yes, good to remind me. The aliases are quite broken on AIX pre 4.9 and becasue some of them are now auto generated, we probably ought to fix it. One solution would be to disable generation of aliases, other would be to backport this patch. David, I think we did not encounter any issues with the new code? Honza
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #9 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Ouch. The test snippet is extracted from an attempt to implement
is_trivially_constructible.
#include type_traits
template typename T, class... Args
struct mytrait : public std::__and_std::is_constructibleT, Args...,
std::integral_constantbool,
__is_trivially_constructible(T, Args...)::type
{
}
trivial_trait.cpp:5:43: internal compiler error: tree check: expected class
‘type’, have ‘exceptional’ (tree_list) in strip_typedefs, at cp/tree.c:1204
__is_trivially_constructible(T, Args...)::type
^
0xe02687 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.c:9226
0x735d28 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:2856
0x735d28 strip_typedefs(tree_node*)
../../gcc/cp/tree.c:1204
0x734c40 strip_typedefs_expr(tree_node*)
../../gcc/cp/tree.c:1396
0x5fe7d7 convert_template_argument
../../gcc/cp/pt.c:6658
0x5e125b coerce_template_parms
../../gcc/cp/pt.c:7080
0x5e92de lookup_template_class_1
../../gcc/cp/pt.c:7661
0x5e92de lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:7979
0x6ffd62 finish_template_type(tree_node*, tree_node*, int)
../../gcc/cp/semantics.c:2981
0x692bf9 cp_parser_template_id
../../gcc/cp/parser.c:13664
0x692f08 cp_parser_class_name
../../gcc/cp/parser.c:19491
0x68707a cp_parser_qualifying_entity
../../gcc/cp/parser.c:5571
0x68707a cp_parser_nested_name_specifier_opt
../../gcc/cp/parser.c:5296
0x69f3a0 cp_parser_simple_type_specifier
../../gcc/cp/parser.c:14871
0x67ae55 cp_parser_type_specifier
../../gcc/cp/parser.c:14617
0x67c0ab cp_parser_type_specifier_seq
../../gcc/cp/parser.c:18359
0x691362 cp_parser_type_id_1
../../gcc/cp/parser.c:18231
0x69145e cp_parser_template_type_arg
../../gcc/cp/parser.c:18281
0x691692 cp_parser_template_argument
../../gcc/cp/parser.c:14044
0x691692 cp_parser_template_argument_list
../../gcc/cp/parser.c:13954
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #10 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Reduced:
template bool b
struct bool_
{
};
template typename T, class... Args
struct mytrait : bool___is_trivially_constructible(T, Args...)
{
}
trivial_trait2.cpp:7:64: internal compiler error: tree check: expected class
‘type’, have ‘exceptional’ (tree_list) in strip_typedefs, at cp/tree.c:1204
struct mytrait : bool___is_trivially_constructible(T, Args...)
^
0xe02687 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.c:9226
0x735d28 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:2856
0x735d28 strip_typedefs(tree_node*)
../../gcc/cp/tree.c:1204
0x734c40 strip_typedefs_expr(tree_node*)
../../gcc/cp/tree.c:1396
0x5fe7d7 convert_template_argument
../../gcc/cp/pt.c:6658
0x5e125b coerce_template_parms
../../gcc/cp/pt.c:7080
0x5e92de lookup_template_class_1
../../gcc/cp/pt.c:7661
0x5e92de lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:7979
0x6ffd62 finish_template_type(tree_node*, tree_node*, int)
../../gcc/cp/semantics.c:2981
0x692bf9 cp_parser_template_id
../../gcc/cp/parser.c:13664
0x692f08 cp_parser_class_name
../../gcc/cp/parser.c:19491
0x68707a cp_parser_qualifying_entity
../../gcc/cp/parser.c:5571
0x68707a cp_parser_nested_name_specifier_opt
../../gcc/cp/parser.c:5296
0x67a1bb cp_parser_base_specifier
../../gcc/cp/parser.c:21239
0x67a1bb cp_parser_base_clause
../../gcc/cp/parser.c:21088
0x67a1bb cp_parser_class_head
../../gcc/cp/parser.c:20297
0x67a1bb cp_parser_class_specifier_1
../../gcc/cp/parser.c:19571
0x67b0c0 cp_parser_class_specifier
../../gcc/cp/parser.c:19863
0x67b0c0 cp_parser_type_specifier
../../gcc/cp/parser.c:14539
0x6961c1 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:11780
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/63446] New: dangling reference results in confusing diagnostic from -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
Bug ID: 63446
Summary: dangling reference results in confusing diagnostic
from -Wuninitialized
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: M8R-ynb11d at mailinator dot com
struct foo {
int ref;
foo(int i) : ref(i) {}
};
foo make_foo()
{
int x = 42;
return foo(x);
}
int func()
{
foo f = make_foo();
return f.ref;
}
This code is obviously broken due to the dangling reference, so I'm glad gcc
gives a warning (clang is silent) but the warning is a bit confusing:
$ g++ -O2 -Wall -c wuninit.cpp
wuninit.cpp: In function ‘int func()’:
wuninit.cpp:15:14: warning: ‘x’ is used uninitialized in this function
[-Wuninitialized]
return f.ref;
^
I get that the diagnostic is generated after inlining has moved x into func(),
but it's still rather confusing as the person that wrote func() might have no
knowledge of the internals of make_foo(), and this would be a real head
scratcher for them. Additionally, it mentions x being used uninitialized, but
x is initialized. (I understand that the initialization becomes dead code and
is removed, but that's not immediately obvious.)
In an ideal world gcc would warn about the last line of make_foo() instead of
func(), and it would mention a dangling reference instead of an uninitialized
use.
[Bug target/13423] sh-elf: V4SFmode passed in integer registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13423
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #3)
Although this is an ABI issue, passing float vector by reference should not
actually suffer from this problem, but it does:
typedef float v4sf __attribute__ ((vector_size (16)));
void test00 (v4sf a, const v4sf b)
{
a += b;
}
The reason for that are missing various vec_* patterns, in particular
vec_extractv4sf, vec_setv4sf, movv4sf, etc. If those are not specified
fallback options will be used by the RTL expansion, which loads/stores the
vectors as SImode subregs.
Adding vector arithmetic patterns such as addv4sf3 is not necessary, but might
simplify a thing or two.
[Bug go/61877] [5 Regression]: reflect: cannot use []string as type string in Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877 --- Comment #9 from Ian Lance Taylor ian at airs dot com --- Thanks for the test case. I wrote a completely different test case that is more like the existing reflect tests: https://codereview.appspot.com/151280043/ . This test passes with gc but fails with gccgo at present on amd64: --- FAIL: TestVariadicMethodValue (0.00 seconds) panic: reflect: cannot use []reflect_test.Point as type reflect_test.Point in Call [recovered] panic: reflect: cannot use []reflect_test.Point as type reflect_test.Point in Call
[Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-10-03
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
In an ideal world gcc would warn about the last line of make_foo() instead
of func(), and it would mention a dangling reference instead of an
uninitialized use.
Hum, yes, but I'm not even sure if GCC realizes that there is a dangling
reference. However, it should since the code looks like:
foo make_foo() ()
Eh tree:
1 cleanup
2 cleanup
{
intD.9 SR.1D.2273;
intD.9 xD.2244;
struct fooD.2226 D.2254;
struct fooD.2226 D.2260;
;; basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE)
;;pred: ENTRY (FALLTHRU,EXECUTABLE)
;; starting at line 10
[test.c : 10:11] # .MEM_2 = VDEF .MEM_1(D)
xD.2244 = 42;
[test.c : 11:15] # .MEM_4 = VDEF .MEM_2
[test.c : 11] MEM[(struct fooD.2226 *)D.2260] = xD.2244;
# .MEM_6 = VDEF .MEM_4
xD.2244 ={v} {CLOBBER};
[test.c : 11:15] # VUSE .MEM_6
return D.2260;
;;succ: EXIT (EXECUTABLE)
}
which is just before x = 42 is removed. But for the same reason that it is
removed, perhaps also the dangling reference could be detected.
[Bug c++/63444] Compilation consumes 2.5G memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63444 --- Comment #1 from Pranith Kumar bobby.prani at gmail dot com --- Just FYI, clang compiles the same file using 1G memory.
[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Assignee|jvdelisle at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #8 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Unasigning myself.
[Bug go/61877] [5 Regression]: reflect: cannot use []string as type string in Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877 --- Comment #10 from Michael Hudson-Doyle michael.hudson at linaro dot org --- I've proposed a fix https://codereview.appspot.com/152840043
[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298 --- Comment #9 from Damian Rouson damian at sourceryinstitute dot org --- Oh boy. I'm guessing that's an indication that there won't be any movement on this anytime soon. It seems this is one of only two major features missing for full Fortran 2003 compliance -- the other being derived type parameters. One of the Fortran committee members recently suggested that derived type parameters be deprecated. I wonder if the same is true of derived type I/O. If the leading open-source Fortran compiler already supports some features of Fortran 2008 and Fortran 2015 but has major features of Fortran 2003 missing a decade after the publication of the standard, maybe that's a sign that the feature should be removed from the language. Thoughts?
[Bug middle-end/63422] [5.0 Regression] ICE in freqs_to_counts_path, at tree-ssa-threadupdate.c:981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- fixed in trunk
[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #10 from kargl at gcc dot gnu.org --- (In reply to Damian Rouson from comment #9) Oh boy. I'm guessing that's an indication that there won't be any movement on this anytime soon. It seems this is one of only two major features missing for full Fortran 2003 compliance -- the other being derived type parameters. One of the Fortran committee members recently suggested that derived type parameters be deprecated. I wonder if the same is true of derived type I/O. If the leading open-source Fortran compiler already supports some features of Fortran 2008 and Fortran 2015 but has major features of Fortran 2003 missing a decade after the publication of the standard, maybe that's a sign that the feature should be removed from the language. Thoughts? It's a sign that those who contribute code, do it for free and when they have time. No one or entity has stepped forward to implement DTIO or provide sufficient funding. Cray pointers got implemented because someone at LBNL hired a summer intern. ISO C binding got done because someone at Argonne funded a graduate student/intern. Almost all of my contributions came about because I needed the feature to work. I don't use or need DTIO, so it's well down my list of things to hack on.
[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298 --- Comment #11 from Damian Rouson damian at sourceryinstitute dot org --- Thanks for the quick response. In recent times, I’ve had the impression that it’s harder to find developers than to find money (not that it’s all that easy to find money). I’ve attempted to fund gfortran development at least twice — once successfully and once unsuccessfully. Damian On Oct 2, 2014, at 10:15 PM, kargl at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #10 from kargl at gcc dot gnu.org --- (In reply to Damian Rouson from comment #9) Oh boy. I'm guessing that's an indication that there won't be any movement on this anytime soon. It seems this is one of only two major features missing for full Fortran 2003 compliance -- the other being derived type parameters. One of the Fortran committee members recently suggested that derived type parameters be deprecated. I wonder if the same is true of derived type I/O. If the leading open-source Fortran compiler already supports some features of Fortran 2008 and Fortran 2015 but has major features of Fortran 2003 missing a decade after the publication of the standard, maybe that's a sign that the feature should be removed from the language. Thoughts? It's a sign that those who contribute code, do it for free and when they have time. No one or entity has stepped forward to implement DTIO or provide sufficient funding. Cray pointers got implemented because someone at LBNL hired a summer intern. ISO C binding got done because someone at Argonne funded a graduate student/intern. Almost all of my contributions came about because I needed the feature to work. I don't use or need DTIO, so it's well down my list of things to hack on. -- You are receiving this mail because: You are on the CC list for the bug.
