[Bug fortran/59662] New: [OOP] TBP subroutine call rejected in contained subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59662 Bug ID: 59662 Summary: [OOP] TBP subroutine call rejected in contained subroutine Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sfilippone at uniroma2 dot it Created attachment 31565 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31565&action=edit testcase The attached code fails with current trunk with what appears to be an overzealous check. The code compiles and works fine with 4.8.1. Commenting the BIND(C) routine call or moving the foobar subroutine outside of foo masks the problem. --- [sfilippo@jacobi bug36]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu/4.9/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu/4.9 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu/4.9 --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu/4.9 --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 4.9.0 20140102 (experimental) (GCC) [sfilippo@jacobi bug36]$ gfortran -c testcase.f90 testcase.f90:59.22: call a%mv_to(acsc) 1 Error: 'mv_to_base' at (1) is not a function
[Bug target/59663] New: [4.9 Regression] config/darwin.c:3665:1: error: control reaches end of non-void function [-Werror=return-type]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59663
Bug ID: 59663
Summary: [4.9 Regression] config/darwin.c:3665:1: error:
control reaches end of non-void function
[-Werror=return-type]
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin.liska at gmail dot com
Target: *-*-darwin*
Cf. https://trac.macports.org/ticket/41964 and PR59654 comment 20.
gcc/config/darwin.c: In function 'section* darwin_function_section(tree,
node_frequency, bool, bool)':
gcc/config/darwin.c:3665:1: error: control reaches end of non-void function
[-Werror=return-type]
}
I think the culprit is Martin's patch r206070 - as there is no return after the
"switch":
@@ -3642,6 +3649,11 @@ darwin_function_section (tree decl, enum node_frequency
case NODE_FREQUENCY_HOT:
- return (weak)
- ? darwin_sections[text_hot_coal_section]
- : darwin_sections[text_hot_section];
- break;
+ {
+ /* If we do have a profile or(and) LTO phase is executed, we do not need
+ these ELF section. */
+if (!in_lto_p || !flag_profile_values)
+ return (weak)
+ ? darwin_sections[text_hot_coal_section]
+ : darwin_sections[text_hot_section];
+break;
+ }
[Bug fortran/59654] [4.8/4.9 Regression] [OOP] Broken function table with complex OO use case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #21 from Tobias Burnus --- (In reply to Damian Rouson from comment #20) > FYI, the current port of gcc49 via macports is broken > (https://trac.macports.org/ticket/41964) Why doesn't anyone report this issue? It's now tracked as PR59663
[Bug fortran/59662] [4.9 Regression] [OOP] TBP subroutine call rejected in connection with BIND(C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59662 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.8.1 Keywords||rejects-valid Last reconfirmed||2014-01-03 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 Summary|[OOP] TBP subroutine call |[4.9 Regression] [OOP] TBP |rejected in contained |subroutine call rejected in |subroutine |connection with BIND(C) Known to fail||4.9.0 --- Comment #1 from janus at gcc dot gnu.org --- Confirmed. There is some strange interaction with BIND(C). Reduced test case: module base_mod implicit none type outer contains procedure, nopass :: mv_to_base end type contains subroutine mv_to_base end subroutine subroutine foobar type(outer) :: a integer :: info interface integer function try() bind(c) end function end interface call a%mv_to_base() info = try() end subroutine end module
[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519 --- Comment #8 from Jakub Jelinek --- (In reply to bin.cheng from comment #7) > (In reply to Jakub Jelinek from comment #6) > > Created attachment 31562 [details] > > gcc49-pr59519.patch > > > > I wonder if this isn't just a checking issue, the two PHI nodes created in > > *new_exit_bb have the same argument, so I think it is just fine if the two > > PHI results are used interchangeably, later optimization passes should > > hopefully coalesce them into a single IV. > > I tested one similar patch before. It passed x86_64 bootstrap and normal > regression test. It failed some ada (also one go) cases if I ran regression > test with "-O3" option. The failures look like noise to me, which I am not > sure about. What's your test results? I admit I haven't performed -O3 bootstrap but normal, saw no bootstrap failures nor testsuite regressions. I'll try to run make check with RUNTESTFLAGS='--target_board=unix/-O3'.
[Bug bootstrap/57125] Build not SMP safe; fails to build bconfig.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57125 Vladimír Čunát changed: What|Removed |Added CC||vcunat at gmail dot com --- Comment #2 from Vladimír Čunát --- In this matter I'm quite confused by the intentions of http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00273.html It states that host object files depend on CONFIG_H, but these seem to get in fact built with -DGENERATOR_FILE (according to build log), so through gentype.c, they include bconfig.h instead of config.h. I don't see that reflected in build dependencies, and more importantly, I'm not even sure this consequence was intended/correct.
[Bug fortran/59662] [4.9 Regression] [OOP] TBP subroutine call rejected in connection with BIND(C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59662 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org --- This PR is fixed by the patch for PR 59023 posted at: http://gcc.gnu.org/ml/fortran/2013-12/msg00139.html
[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519 --- Comment #9 from Jakub Jelinek --- BTW, the patch can hardly regress anything, it only affects cases that ICEd before the patch.
[Bug middle-end/59630] [4.7/4.8/4.9 Regression] ICE converting the return type of a builtin function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59630 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- Mine (next week).
[Bug middle-end/59630] [4.7/4.8/4.9 Regression] ICE converting the return type of a builtin function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59630
--- Comment #4 from Richard Biener ---
(In reply to Jakub Jelinek from comment #2)
> Started with my r182761 but say:
> _Bool foo (int x)
> {
> _Bool (*f)(int) = __builtin_abs;
> return f(x);
> }
> ICEs at -O2 already since the gimple_call_fntype introduction in r172310.
> Since the r172310 change we also without any warnings happily inline:
> inline int fn1 (int x, int y) { return x + y; }
> int
> fn2 (void)
> {
> int (*fn) (long long) = (void *) fn1;
> return fn (5LL);
> }
> inline int fn3 (long long x) { return x; }
> int
> fn4 (void)
> {
> int (*fn) (int x, int y) = (void *) fn3;
> return fn (5, 6);
> }
> (well, for fn1 into fn2 we complain about uninitialized y).
> This is also related to PR59622. Even with gimple_call_fntype, I'd say we
> should never propagate an indirect call into a gimple_call_fndecl if it
> doesn't satisfy some minimal consistency predicate (something along the
> lines of what I wrote in PR59622, basically if the stmt has lhs, then the
> return types need to be compatible, and TYPE_ARG_TYPES should be compatible
> (perhaps an exception can be made for the C () vs. (void) arguments).
> Because if the conversion between fn return type and/or arguments types is
> non-useless, I'm afraid tons of issues can happen everywhere. At minimum we
> should disallow it if the fndecl we want to propagate is a builtin, and we
> should not inline it, or perhaps clone.
Not at all. The bug is how we identify a call stmt to be a builtin call
vs. a call to a builtin function. gimple_call_arg_fn specifies the
function address we call and gimple_call_fntype specifies the function
signature the caller expects.
There shouldn't be many places to fix, and in most cases a proper
predicate can be used / introduced. useless_type_conversion_p
(TREE_TYPE (fndecl), fntype) should work here to guard the builtins.c
folding.
We really want to aggressively make indirect calls direct ones.
[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519 --- Comment #10 from bin.cheng --- (In reply to Jakub Jelinek from comment #9) > BTW, the patch can hardly regress anything, it only affects cases that ICEd > before the patch. Em, I am worried if vectorization can handle peeled phi correctly for each scenario before, because I barely know the implementation. That's why I looked for your guys' suggestions in the first place. Thanks.
[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #11 from Jakub Jelinek ---
I've tried even:
struct S { int f0; } d;
int a[8] = { 0 }, b, c, e, f;
void
foo (void)
{
for (; e < 1; e++)
{
for (b = 0; b < 7; b++)
{
c |= (a[b + 1] != 0);
if (d.f0)
break;
}
f += b;
}
}
where I've hoped get_current_def would be called on the problematic loop_arg,
but apparently it isn't (the only calls are the one changed in the patch).
[Bug c++/58950] [4.9 Regression] Missing "statement has no effect"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950 --- Comment #11 from Marc Glisse --- (In reply to Jason Merrill from comment #10) > (In reply to Marc Glisse from comment #7) > > The __builtin_shuffle part of the patch seems fine. > > Yes, that looks right. That fixes the bug, yes? It fixes this half of the bug, yes. I'll regtest it separately.
[Bug tree-optimization/59651] [4.9 Regression] Vectorizer failing to spot dependence causes incorrect code generation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59651 --- Comment #7 from Tejas Belagod --- AArch64 regressions came back OK. Thanks!
[Bug tree-optimization/59303] [4.9 Regression] uninit-pred-8_b.c and uninit-pred-9_b.c fail after better optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek --- Author: davidxl Date: Fri Jan 3 00:40:57 2014 New Revision: 206309 URL: http://gcc.gnu.org/viewcvs?rev=206309&root=gcc&view=rev Log: Fix PR/59303 -- uninit analysis enhancement Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-uninit.c
[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 --- Comment #44 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #43 from Hin-Tak Leung --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #40) >> Please try this on your system and tell us how you end up with >> bootstrap-debug instead of none. > > Hmm, sorry, redherring. I think I found the difference - it depends on which > strip I am using - the one in /usr/local/bin/ gives bootstrap-debug, while the > one in /sbin/ gives none. (problem of having some GNU variety of utilities in > /usr/local/bin, and whethe that's in front of $PATH). Makes sense: binutils support for Tru64 UNIX is known to be harmful (as you just discovered) or broken (gas cannot even assemble hello world compiler output), so nobody else every even tried binutils or parts thereof. Given that GCC 4.7 is the last release to support Tru64 UNIX, the release branch will soon be closed with the advent of GCC 4.9, and you're the only one ever to report this issue, I'll leave the bug as WONTFIX. Thanks for your detective work. Rainer
[Bug c++/59165] gcc looks up begin(), end() for for-range loops for ints in namespace std
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59165 --- Comment #6 from paolo at gcc dot gnu.org --- Author: paolo Date: Fri Jan 3 11:11:31 2014 New Revision: 206313 URL: http://gcc.gnu.org/viewcvs?rev=206313&root=gcc&view=rev Log: /cp 2014-01-03 Paolo Carlini Core DR 1442 PR c++/59165 * parser.c (cp_parser_perform_range_for_lookup): Don't pass true as include_std to perform_koenig_lookup. (cp_parser_postfix_expression): Adjust. * pt.c (tsubst_copy_and_build): Likewise. * semantics.c (perform_koenig_lookup): Remove bool parameter. (omp_reduction_lookup): Adjust. * name-lookup.c (lookup_arg_dependent_1): Remove bool parameter. (lookup_arg_dependent): Likewise. (lookup_function_nonclass): Adjust. * name-lookup.h: Adjust declaration. * cp-tree.h: Likewise. /testsuite 2014-01-03 Paolo Carlini Core DR 1442 PR c++/59165 * g++.dg/cpp0x/range-for28.C: New. * g++.dg/cpp0x/range-for3.C: Update. Added: trunk/gcc/testsuite/g++.dg/cpp0x/range-for28.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/name-lookup.c trunk/gcc/cp/name-lookup.h trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/range-for3.C
[Bug c++/59165] gcc looks up begin(), end() for for-range loops for ints in namespace std
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59165 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Paolo Carlini --- Done.
[Bug other/59661] documentation: __builtin_FUNCTION / _FILE listed as returning int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59661 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug fortran/59298] ICE when initialising PARAMETER array of derived-type (containing an array) using array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) > The test compiles with gfortran 4.4.7, but ICE with revision 154654 > (2009-11-25). Segfaults here with gcc version 4.4.7 (Ubuntu/Linaro 4.4.7-2ubuntu2) (not sure from which revision this is built)
[Bug fortran/59298] ICE when initialising PARAMETER array of derived-type (containing an array) using array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298 --- Comment #4 from janus at gcc dot gnu.org --- Slightly reduced test case: implicit none type Plane integer :: M(1,1) end type type(Plane), parameter :: planes(1) = [ Plane(1) ] integer:: f(1,1) f = (planes(1)%M) end
[Bug c++/53822] spell out typedefs in ambiguous call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53822
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Marc Glisse from comment #6)
> Probably depends on cases. Sometimes it is good to have the explanation
> right next to the type, other times it takes up all the space and you can't
> even find the commas separating the arguments anymore (maybe if the whole
> {aka ...} block was a different color?).
That could be possible. On the other hand, the "{aka ...}" thing is not really
ideal (in general). Currently,
1) It is not translated
2) You need to know what "aka" means (not obvious relation with 'typedef')
3) It is not correctly quoted, that is, instead of "`NT {aka int}'", we should
print "`NT' {aka `int'}".
4) The "aka" should not be colored in the same way as the types. Fixing the
quoting will fix this.
5) Complex declarations lead to many repetitions of "aka": "`f(NT {aka int},UT
{aka unsigned int},DT {aka double int})'".
[Bug target/59625] asm goto and TARGET_FOUR_JUMP_LIMIT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59625 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Fri Jan 3 12:22:17 2014 New Revision: 206314 URL: http://gcc.gnu.org/viewcvs?rev=206314&root=gcc&view=rev Log: PR target/59625 * config/i386/i386.c (ix86_avoid_jump_mispredicts): Don't consider asm goto as jump. * gcc.target/i386/pr59625.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr59625.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/59252] wrong code generation for allocatable character component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59252 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||janus at gcc dot gnu.org Summary|wrong code generation for |wrong code generation for |allocatable dummy arguments |allocatable character ||component --- Comment #2 from janus at gcc dot gnu.org --- Unrelated to dummy arguments. Reduced test case: implicit none type branch_plot_results_ppv_type character, allocatable :: label end type type(branch_plot_results_ppv_type), allocatable :: appv(:) allocate(appv(2)) end
[Bug other/59661] documentation: __builtin_FUNCTION / _FILE listed as returning int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59661 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Fri Jan 3 12:28:31 2014 New Revision: 206315 URL: http://gcc.gnu.org/viewcvs?rev=206315&root=gcc&view=rev Log: PR other/59661 * doc/extend.texi: Fix the return value of __builtin_FUNCTION and __builtin_FILE. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi
[Bug other/59661] documentation: __builtin_FUNCTION / _FILE listed as returning int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59661 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug fortran/59252] wrong code generation for allocatable character component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59252
--- Comment #3 from janus at gcc dot gnu.org ---
-fdump-tree-orginial shows that some code for the initialization of the
component 'label' is inserted:
{
struct branch_plot_results_ppv_type branch_plot_results_ppv_type.0;
if (appv != 0B) goto L.1;
appv = (struct branch_plot_results_ppv_type *) __builtin_calloc (1, 8);
L.1:;
__builtin_memcpy ((void *) branch_plot_results_ppv_type.0.label, (void
*) &0B, 1);
*appv = branch_plot_results_ppv_type.0;
}
This is clearly wrong and apparently causes the segfault.
[Bug middle-end/56791] [4.8/4.9 Regression] Segmentation fault in stage2 gengenrtl -- Incorrect instruction sequence generated by reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56791 --- Comment #10 from Bernd Schmidt --- (In reply to John David Anglin from comment #9) > Any chance the candidate patch can be submitted? I guess this means you've tested it and it works?
[Bug target/59625] asm goto and TARGET_FOUR_JUMP_LIMIT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59625 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Fri Jan 3 12:59:42 2014 New Revision: 206316 URL: http://gcc.gnu.org/viewcvs?rev=206316&root=gcc&view=rev Log: PR target/59625 * config/i386/i386.c (ix86_avoid_jump_mispredicts): Don't consider asm goto as jump. * gcc.target/i386/pr59625.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr59625.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug target/59625] asm goto and TARGET_FOUR_JUMP_LIMIT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59625 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-03 Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek --- Fixed for 4.8+ so far.
[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519 --- Comment #12 from Jakub Jelinek --- --target_board=unix/-O3 testing showed no changes (except for the testcases in the patch), on both x86_64-linux and i686-linux (on the former one including ada testing).
[Bug target/59664] New: avx512f-ceil-sfix-vec-2.c and avx512f-floor-sfix-vec-2.c FAIL on Solaris9/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59664 Bug ID: 59664 Summary: avx512f-ceil-sfix-vec-2.c and avx512f-floor-sfix-vec-2.c FAIL on Solaris9/x86 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: ubizjak at gmail dot com Host: i386-pc-solaris2.9 Target: i386-pc-solaris2.9 Build: i386-pc-solaris2.9 Two new avx512f tests FAIL on Solaris 9/x86 (only, Solaris 10+ is fine) irrespective of configured assembler (as or gas 2.24): FAIL: gcc.target/i386/avx512f-ceil-sfix-vec-2.c scan-assembler vrndscalepd[^\\n]*zmm[0-9] FAIL: gcc.target/i386/avx512f-ceil-sfix-vec-2.c scan-assembler vcvttpd2dq[^\\n]*zmm[0-9] FAIL: gcc.target/i386/avx512f-floor-sfix-vec-2.c scan-assembler vrndscalepd[^\\n]*zmm[0-9] FAIL: gcc.target/i386/avx512f-floor-sfix-vec-2.c scan-assembler vcvttpd2dq[^\\n]*zmm[0-9] I've tried to add options present on Solaris 10/x86 to change this, but to no avail. I'm attaching the assembler output for the first case with -fverbose-asm. Rainer
[Bug target/59664] avx512f-ceil-sfix-vec-2.c and avx512f-floor-sfix-vec-2.c FAIL on Solaris9/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59664 --- Comment #1 from Rainer Orth --- Created attachment 31566 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31566&action=edit assembler output with as and -fverbose-asm
[Bug target/59664] avx512f-ceil-sfix-vec-2.c and avx512f-floor-sfix-vec-2.c FAIL on Solaris9/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59664 Rainer Orth changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug c/57773] -Wpedantic incorrect warning for enum bit-field
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57773 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- After all, I think it'd be wise to keep the warning for ISO C, but turn if off for C99/C11. I have a patch for that.
[Bug libstdc++/59665] New: User code can cause ambiguous references to "std" in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59665
Bug ID: 59665
Summary: User code can cause ambiguous references to "std" in
libstdc++
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fanael4 at gmail dot com
The following PURE EVIL but legal code:
namespace foo { namespace std {} }
using namespace foo;
#include
causes the compiler to spew out lots of "error: reference to 'std' is
ambiguous" errors deep in the bowels of libstdc++, for rather obvious reasons.
Granted, this is code is worse than reload, but it's legal, and as such
shouldn't break the standard library.
[Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535 --- Comment #15 from Richard Earnshaw --- Another testcase where the thumb1 code is poor is gcc.c-torture/execute/pr28982b.c With LRA we often get sequences such as: mov r3, sp ldr r2, .L8+16 add r3, r3, r2 // r2 dead. str r0, [r3] Instead of: ldr r2, .L8+16 add r2, r2, sp str r0, [r2] Which is both shorter and needs fewer registers.
[Bug tree-optimization/59651] [4.9 Regression] Vectorizer failing to spot dependence causes incorrect code generation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59651 --- Comment #8 from meibf at gcc dot gnu.org --- Author: meibf Date: Fri Jan 3 15:40:57 2014 New Revision: 206319 URL: http://gcc.gnu.org/viewcvs?rev=206319&root=gcc&view=rev Log: 2014-01-03 Bingfeng Mei PR tree-optimization/59651 * tree-vect-loop-manip.c (vect_create_cond_for_alias_checks): Addressrange for negative step should be added by TYPE_SIZE_UNIT. PR tree-optimization/59651 * gcc.dg/torture/pr59651.c: New test. * gcc.dg/vect/pr59651.c: Ditto. Added: trunk/gcc/testsuite/gcc.dg/torture/pr59651.c trunk/gcc/testsuite/gcc.dg/vect/pr59651.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop-manip.c
[Bug middle-end/56791] [4.8/4.9 Regression] Segmentation fault in stage2 gengenrtl -- Incorrect instruction sequence generated by reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56791 --- Comment #11 from dave.anglin at bell dot net --- On 3-Jan-14, at 7:46 AM, bernds at gcc dot gnu.org wrote: > I guess this means you've tested it and it works? Yes, I have tested it and it works fine. Dave -- John David Anglindave.ang...@bell.net
[Bug ipa/59008] [4.9 Regression] ICEs in try_make_edge_direct_simple_call / propagate_controlled_uses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59008 --- Comment #5 from Martin Jambor --- IPA-CP is decrementing reference count of parameter 1 instead of parameter 2. That happens because the variable param_index in ipcp_discover_new_direct_edges has type bool instead of int. What a stupid mistake. I'll prepare a patch.
[Bug target/59666] New: IBM long double arithmetic results invalid in non-default rounding modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59666
Bug ID: 59666
Summary: IBM long double arithmetic results invalid in
non-default rounding modes
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jsm28 at gcc dot gnu.org
CC: dje at gcc dot gnu.org
Target: powerpc*-*-linux*
The IBM long double functions in ibm-ldouble.c, when called in rounding modes
other than round-to-nearest, can produce results that are invalid (do not
satisfy the requirements in ibm-ldouble-format on what pairs of doubles make a
valid long double value, in particular as regards the high part being equal to
the sum of the two parts rounded to nearest). For example:
#include
#include
#include
volatile long double a = LDBL_MAX;
int
main (void)
{
fesetround (FE_TOWARDZERO);
union u { long double ld; double d[2]; } x;
volatile long double r = a * a;
x.ld = a;
printf ("LDBL_MAX: %a %a\n", x.d[0], x.d[1]);
x.ld = r;
printf ("LDBL_MAX * LDBL_MAX: %a %a\n", x.d[0], x.d[1]);
return 0;
}
prints
LDBL_MAX: 0x1.fp+1023 0x1.ep+969
LDBL_MAX * LDBL_MAX: 0x1.fp+1023 0x1.fp+1023
where the value for LDBL_MAX * LDBL_MAX is not a valid long double at all.
(This isn't limited to overflow cases, although they may produce the greatest
errors; e.g. 0x1.fp-1L * 0x1.fp-1L in FE_UPWARD mode
produces (0x1.fp-1, -0x1.fp-54), where the high part is
not the sum of the two parts rounded to nearest.)
ISO C does not allow for arithmetic operations simply not working - producing
invalid results - for some types and rounding modes, although for non-IEEE
types they need not be correctly rounding.
I think the right approach for a fix will probably involve setting
round-to-nearest temporarily within the functions, then adjusting overflowing
and underflowing results based on the original rounding mode. I don't know
what performance impact that might have, and whether it might be best to avoid
that performance impact in the common case by having separate __gcc_*_round
functions that deal with saving / restoring the rounding mode and are only used
if -frounding-math, with the existing functions (not handling rounding modes)
being used otherwise.
[Bug target/59609] [4.9 Regression] LRA generates bad code for libgcc function udivmoddi4 on thumb1 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59609 Richard Earnshaw changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #3 from Richard Earnshaw --- The patterns were carefully written to handle all the needed output-reload situations. I don't know why LRA doesn't make use of them.
[Bug sanitizer/59667] New: ubsan: ICE ubsan_type_descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59667
Bug ID: 59667
Summary: ubsan: ICE ubsan_type_descriptor
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
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
This is with gcc --version
gcc (GCC) 4.9.0 20140103 (experimental) as of r206313
This snippet:
void foo()
{
unsigned int len = 1;
float (*P)[len][len];
(*P)[0][0] = 1;
}
compiled with gcc -c -fsanitize=undefined snippet.c
Gives:
snippet.c: In function ‘foo’:
snippet.c:1:6: internal compiler error: Segmentation fault
void foo()
^
0x87abff crash_signal
../../gcc/gcc/toplev.c:336
0x890f2d ubsan_type_descriptor(tree_node*, bool)
../../gcc/gcc/ubsan.c:319
0x891b44 ubsan_expand_null_ifn(gimple_stmt_iterator)
../../gcc/gcc/ubsan.c:584
0x888de1 execute_sanopt
../../gcc/gcc/asan.c:2574
0x888de1 execute
../../gcc/gcc/asan.c:2624
[Bug rtl-optimization/59652] [4.8 Regression] ICE: in reload_cse_simplify_operands, at postreload.c:411
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59652
--- Comment #3 from John David Anglin ---
With
dave@mx3210:~/gnu/gcc/objdir/prev-gcc$ ./xgcc -B./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: hppa-linux-gnu
Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared
--enable-multiarch --enable-linker-build-id --build=hppa-linux-gnu
--host=hppa-linux-gnu --target=hppa-linux-gnu
--prefix=/home/dave/opt/gnu/gcc/gcc-4.9 --with-local-prefix=/home/dave/opt/gnu
--enable-threads=posix --enable-__cxa_atexit --build=hppa-linux-gnu
--enable-clocale=gnu --enable-java-gc=boehm
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada,lto
Thread model: posix
gcc version 4.8.3 20140103 (prerelease) [gcc-4_8-branch revision 206321] (GCC)
I see the following backtrace when the insn was emitted:
Breakpoint 1, pa_emit_move_sequence (operands=0xfaf02e8c, mode=SImode,
scratch_reg=0x0) at ../../gcc/gcc/config/pa/pa.c:1583
1583 register rtx operand0 = operands[0];
(gdb) p debug_rtx(operands[0])(reg:SI 28 %r28)
$5 = void
(gdb) p debug_rtx(operands[1])
(reg/f:SI 2442)
$6 = void
(gdb) bt
#0 pa_emit_move_sequence (operands=0xfaf02e8c, mode=SImode, scratch_reg=0x0)
at ../../gcc/gcc/config/pa/pa.c:1583
#1 0x00bf77bc in gen_movsi (operand0=0xfaf02e8c, operand1=0x7)
at ../../gcc/gcc/config/pa/pa.md:2157
#2 0x00bf77bc in gen_movsi (operand0=0x4022c030, operand1=0x40a0d040)
at ../../gcc/gcc/config/pa/pa.md:2157
#3 0x00446334 in insn_gen_fn::operator() (this=0xf9e720 ,
a0=0x4022c030, a1=0x40a0d040) at ../../gcc/gcc/recog.h:284
#4 0x00424864 in emit_move_insn_1 (x=0x4022c030, y=0x40a0d040)
at ../../gcc/gcc/expr.c:3441
#5 0x006e6278 in gen_move_insn (x=0x4022c030, y=0x40a0d040)
at ../../gcc/gcc/optabs.c:4812
#6 0x006e6278 in gen_move_insn (x=0x4022c030, y=0x40a0d040)
at ../../gcc/gcc/optabs.c:4812
#7 0x007a5794 in gen_reload (out=0x4022c030, in=0x40a0d040, opnum=1,
type=RELOAD_FOR_INPUT_ADDRESS) at ../../gcc/gcc/reload1.c:8708
(gdb) c
Continuing.
Breakpoint 1, pa_emit_move_sequence (operands=0xfaf02e8c, mode=SImode,
scratch_reg=0x0) at ../../gcc/gcc/config/pa/pa.c:1583
1583 register rtx operand0 = operands[0];
(gdb) p debug_rtx(operands[0])
(reg:SI 19 %r19)
$7 = void
(gdb) c
Continuing.
Breakpoint 1, pa_emit_move_sequence (operands=0xfaf02e8c, mode=SImode,
scratch_reg=0x0) at ../../gcc/gcc/config/pa/pa.c:1583
1583 register rtx operand0 = operands[0];
(gdb) p debug_rtx(operands[0])
(reg:SI 19 %r19)
$8 = void
(gdb) c
Continuing.
../../../texk/xdvik/xdvi.c: In function ‘run_dvi_file’:
../../../texk/xdvik/xdvi.c:3398:1: error: insn does not satisfy its
constraints:
(insn 5859 3068 5860 249 (set (reg:SI 28 %r28)
(reg/f:SI 2442)) ../../../texk/xdvik/xdvi.c:2722 40 {*pa.md:2211}
(nil))
../../../texk/xdvik/xdvi.c:3398:1: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:411
0x7b8797 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:109
0x7b880f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:120
0x70d52b reload_cse_simplify_operands
../../gcc/gcc/postreload.c:411
0x70c753 reload_cse_simplify
../../gcc/gcc/postreload.c:123
0x70cb7b reload_cse_regs_1
../../gcc/gcc/postreload.c:220
0x70c4f3 reload_cse_regs
../../gcc/gcc/postreload.c:68
0x71484f rest_of_handle_postreload
../../gcc/gcc/postreload.c:2287
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.
[Inferior 1 (process 6751) exited with code 04]
[Bug target/59664] avx512f-ceil-sfix-vec-2.c and avx512f-floor-sfix-vec-2.c FAIL on Solaris9/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59664 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I guess it is problematic to include in the test, because then you rely on whatever the vendor math.h does. Does it still FAIL if you remove the #include and instead add say #define floor(x) __builtin_floor (x) #define ceil(x) __builtin_ceil (x) #define M_PI __builtin_acos (-1.0) ?
[Bug c++/58567] [4.8/4.9 Regression] ICE with invalid loop variable in template using openmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58567 --- Comment #4 from Tobias Burnus --- Author: burnus Date: Fri Jan 3 20:24:50 2014 New Revision: 206322 URL: http://gcc.gnu.org/viewcvs?rev=206322&root=gcc&view=rev Log: 2014-01-03 Tobias Burnus PR c++/58567 * pt.c (tsubst_omp_for_iterator): Early return for * error_mark_node. 2014-01-03 Tobias Burnus PR c++/58567 * g++.dg/gomp/pr58567.C: New. Added: trunk/gcc/testsuite/g++.dg/gomp/pr58567.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c/59668] New: extraneous error messages at -O1, -O2 and -O3 for valid code with string library functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668 Bug ID: 59668 Summary: extraneous error messages at -O1, -O2 and -O3 for valid code with string library functions Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu The current trunk and older GCC versions reject the following code with odd error messages at -O1, -O2 and -O3 (but not -O0 and -Os). $ gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk --enable-languages=c,c++ --disable-werror --enable-multilib Thread model: posix gcc version 4.9.0 20140103 (experimental) [trunk revision 206321] (GCC) $ $ gcc-trunk -Wall -Wextra -pedantic -std=c99 -c small.c $ $ gcc-trunk -O0 -c small.c $ gcc-trunk -Os -c small.c $ $ gcc-trunk -O1 -c small.c In file included from /usr/include/string.h:637:0, from small.c:1: small.c:3:5: error: expected identifier or ‘(’ before ‘__extension__’ int strcmp(const char *, const char *); ^ small.c:3:5: error: expected identifier or ‘(’ before ‘)’ token int strcmp(const char *, const char *); ^ $ --- #include int strcmp(const char *, const char *);
[Bug c/59668] extraneous error messages at -O1, -O2 and -O3 for valid code with string library functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668 --- Comment #1 from Marc Glisse --- Well, that's a glibc issue, isn't it? Btw, you need to provide the preprocessed code.
[Bug c++/58950] [4.9 Regression] Missing "statement has no effect"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950
--- Comment #12 from Marc Glisse ---
Author: glisse
Date: Fri Jan 3 21:12:48 2014
New Revision: 206325
URL: http://gcc.gnu.org/viewcvs?rev=206325&root=gcc&view=rev
Log:
2014-01-03 Marc Glisse
PR c++/58950
gcc/cp/
* cvt.c (convert_to_void): Handle VEC_PERM_EXPR and VEC_COND_EXPR.
gcc/testsuite/
* g++.dg/pr58950.C: New file.
Added:
trunk/gcc/testsuite/g++.dg/pr58950.C (with props)
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cvt.c
trunk/gcc/testsuite/ChangeLog
Propchange: trunk/gcc/testsuite/g++.dg/pr58950.C
('svn:eol-style' added)
Propchange: trunk/gcc/testsuite/g++.dg/pr58950.C
('svn:keywords' added)
[Bug middle-end/59669] New: ICE: SIGSEGV with #pragma omp declare simd linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59669 Bug ID: 59669 Summary: ICE: SIGSEGV with #pragma omp declare simd linear Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 31567 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31567&action=edit reduced testcase Compiler output: $ gcc -fopenmp testcase.c ==16645== Invalid read of size 2 ==16645==at 0xA2AEDB: simd_clone_adjust(cgraph_node*) (tree.h:2916) ==16645==by 0xA3C2FD: (anonymous namespace)::pass_omp_simd_clone::execute() (omp-low.c:11727) ==16645==by 0xA58859: execute_one_pass(opt_pass*) (passes.c:2226) ==16645==by 0xA590DA: execute_ipa_pass_list(opt_pass*) (passes.c:2604) ==16645==by 0x79797A: compile() (cgraphunit.c:2200) ==16645==by 0x7986A4: finalize_compilation_unit() (cgraphunit.c:2319) ==16645==by 0x6482A3: c_write_global_declarations() (c-decl.c:10400) ==16645==by 0xB4DE6C: compile_file() (toplev.c:561) ==16645==by 0xB4FDF7: toplev_main(int, char**) (toplev.c:1887) ==16645==by 0x5A439B4: (below main) (in /lib64/libc-2.16.so) ==16645== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==16645== testcase.c: In function 'foo.simdclone.0': testcase.c:5:1: internal compiler error: Segmentation fault } ^ Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. $ gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-206310-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-206310-lto-fortran-checking-yes-rtl-df/ --without-cloog --without-ppl Thread model: posix gcc version 4.9.0 20140103 (experimental) (GCC) Tested revisions: r206310 - crash 4.8 - ignoring #pragma omp declare
[Bug c++/58950] Missing "statement has no effect"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950
Marc Glisse changed:
What|Removed |Added
Summary|[4.9 Regression] Missing|Missing "statement has no
|"statement has no effect" |effect"
--- Comment #13 from Marc Glisse ---
Testcase for the remaining part of the PR:
void f(){
int i=2;
(i+i); // should warn with -Wall
}
[Bug c/59668] extraneous error messages at -O1, -O2 and -O3 for valid code with string library functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- Actually this is neither a bug in GCC or glibc. In C, strcmp can be defined as a macro and that is what you are getting a macro. You can fix your code by doing: int (strcmp)(const char *, const char *); Instead.
[Bug ada/58151] "conflict of writable function parameter in construct with arbitrary order of evaluation" is often a spurious error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58151 Patrick Kelly changed: What|Removed |Added CC||p-kell at live dot com --- Comment #3 from Patrick Kelly --- I've faced an almost identical problem. Compilation under -gnat2012 fails with this error. Fallback to -gnat2005, and it reports that functions can only have an "in" parameter, which is correct for -gnat2005; however, they can be used in -gnat2012. Removing the "out" parameter and compiling with -gnat2005 resulted in a correct build. Immediately compiling with -gnat2012 resulted in a correct build. I was lucky in that I didn't actually need the "out" on those parameters. The current behavior is not following the ARM2012. Occurred on GCC 4.8.2.
[Bug c/59668] extraneous error messages at -O1, -O2 and -O3 for valid code with string library functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668 --- Comment #3 from Zhendong Su --- (In reply to Andrew Pinski from comment #2) > Actually this is neither a bug in GCC or glibc. In C, strcmp can be defined > as a macro and that is what you are getting a macro. Huh, that's interesting; thanks. Could you give a pointer where this is described? But again, how come the inconsistent behaviors at different optimization levels? > You can fix your code by doing: > int (strcmp)(const char *, const char *); > > Instead.
[Bug middle-end/59670] New: ICE: expected gimple_call(error_mark), have gimple_assign(plus_expr) in gimple_call_internal_p, at gimple.h:2432
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59670 Bug ID: 59670 Summary: ICE: expected gimple_call(error_mark), have gimple_assign(plus_expr) in gimple_call_internal_p, at gimple.h:2432 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 31568 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31568&action=edit reduced testcase Compiler output: $ gcc -O -fopenmp testcase.c testcase.c: In function 'foo': testcase.c:4:1: internal compiler error: gimple check: expected gimple_call(error_mark), have gimple_assign(plus_expr) in gimple_call_internal_p, at gimple.h:2432 foo (int j, int b) ^ 0x90792c gimple_check_failed(gimple_statement_base const*, char const*, int, char const*, gimple_code, tree_code) /mnt/svn/gcc-trunk/gcc/gimple.c:1132 0x62b077 gimple_call_internal_p /mnt/svn/gcc-trunk/gcc/gimple.h:2432 0x1409ded gimple_call_internal_p /mnt/svn/gcc-trunk/gcc/tree-vect-data-refs.c:3328 0x1409ded vect_analyze_data_refs(_loop_vec_info*, _bb_vec_info*, int*) /mnt/svn/gcc-trunk/gcc/tree-vect-data-refs.c:3323 0xd347a7 vect_analyze_loop_2 /mnt/svn/gcc-trunk/gcc/tree-vect-loop.c:1636 0xd347a7 vect_analyze_loop(loop*) /mnt/svn/gcc-trunk/gcc/tree-vect-loop.c:1846 0xd4b6c8 vectorize_loops() /mnt/svn/gcc-trunk/gcc/tree-vectorizer.c:430 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. $ gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-206310-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-206310-lto-fortran-checking-yes-rtl-df/ --without-cloog --without-ppl Thread model: posix gcc version 4.9.0 20140103 (experimental) (GCC) Tested revisions: r206310 - crash 4.8 - ignoring #pragma omp simd
[Bug ada/59671] New: Improper Ada behavior under -gnat2012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59671 Bug ID: 59671 Summary: Improper Ada behavior under -gnat2012 Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: p-kell at live dot com Compilation under -gnat2012 fails with this error: "conflict of writable function parameter in construct with arbitrary order of evaluation" Fallback to -gnat2005, and it reports that functions can only have an "in" parameter, which is correct for -gnat2005; however, they can be used in -gnat2012. Removing the "out" parameter and compiling with -gnat2005 resulted in a correct build. Immediately compiling with -gnat2012 resulted in a correct build. I was lucky in that I didn't actually need the "out" on those parameters. (note: an unused "out" doesn't cause problems in an of itself) The current behavior is not following the ARM2012, which is why I've labeled this as a "blocker". "in out" parameters on functions is one of the major enhancements to Ada 2012. Other compilation flags: "-O2 -gnato -gnatE -fstack-check" Error still occurs without "-O2"
[Bug c/59668] extraneous error messages at -O1, -O2 and -O3 for valid code with string library functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #4 from Andrew Pinski --- (In reply to Zhendong Su from comment #3) > (In reply to Andrew Pinski from comment #2) > > Actually this is neither a bug in GCC or glibc. In C, strcmp can be defined > > as a macro and that is what you are getting a macro. > > Huh, that's interesting; thanks. Could you give a pointer where this is > described? It is described in the C standard but I don't have the exact reference number for it though. > But again, how come the inconsistent behaviors at different optimization > levels? Because glibc decides only to implement the macro at -O and above but not when optimizing for size. > > > You can fix your code by doing: > > int (strcmp)(const char *, const char *); > > > > Instead. Anyways this is really a dup of bug 32449. *** This bug has been marked as a duplicate of bug 32449 ***
[Bug c/32449] declaring “strcmp()” as an extern function with inclusion of “string.h” is causing compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32449 Andrew Pinski changed: What|Removed |Added CC||su at cs dot ucdavis.edu --- Comment #2 from Andrew Pinski --- *** Bug 59668 has been marked as a duplicate of this bug. ***
[Bug c/59668] extraneous error messages at -O1, -O2 and -O3 for valid code with string library functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668 --- Comment #5 from Zhendong Su --- > Because glibc decides only to implement the macro at -O and above but not > when optimizing for size. I see; thanks Andrew. BTW, is strcmp the only one like this, or there are others?
[Bug c/59668] extraneous error messages at -O1, -O2 and -O3 for valid code with string library functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668 --- Comment #6 from Andrew Pinski --- (In reply to Zhendong Su from comment #5) > BTW, is strcmp the only one like this, or there are others? Almost (if not all) all standard C functions are like this.
[Bug c/59668] extraneous error messages at -O1, -O2 and -O3 for valid code with string library functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668 --- Comment #7 from Andreas Schwab --- 7.1.3 Reserved identifiers
[Bug target/59672] New: Add -m16 support for x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59672 Bug ID: 59672 Summary: Add -m16 support for x86 Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hpa at zytor dot com It would be a very good thing to have an official way to generate 16-bit binaries on x86 (i386), even if all that is provided is a command-line flag that issues a .code16gcc assembly directive first in the generated assembly file. In the Linux kernel, we currently have to do a bunch of hacks to make sure that gcc doesn't issue any instructions *before* the .code16gcc directive: $(call cc-option, -fno-toplevel-reorder,\ $(call cc-option, -fno-unit-at-a-time)) \ $(call cc-option, -fno-stack-protector) \ ... and the list is likely to grow, which is why providing an actually supported compiler flag for this would be desirable.
[Bug target/59672] Add -m16 support for x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59672 --- Comment #1 from Andrew Pinski --- Note GCC does not even support real 16bit code for x86. So pretending GCC's output is 16bit code is a joke. Why can't you just write the 16bit binary support in assembly for the kernel?
[Bug target/59672] Add -m16 support for x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59672 --- Comment #2 from H. Peter Anvin --- It is much cleaner to have it in C. We converted the assembly code to C back in 2007 and it has been much easier to maintain ever since. It works fine, thankyouverymuch; it isn't *optimal* 16-bit code, but it is real and valid 16-bit code and we use it as such. Sure, optimization would be nice. Do we care? Not a lot.
[Bug rtl-optimization/50180] insn does not satisfy constraints for 444.namd when generating profile data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50180 Bill Schmidt changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Bill Schmidt --- This appears to have been resolved some time ago. Closing.
[Bug target/50181] insn does not satisfy constraints for 481.wrf when generating profile data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50181 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Bill Schmidt --- This appears to have been resolved some time ago. Closing.
[Bug c++/59673] New: wrong specialization used when a partial specialization of a member template is explicitly specialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59673
Bug ID: 59673
Summary: wrong specialization used when a partial
specialization of a member template is explicitly
specialized
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
GCC rejects this:
template struct X {
template struct Y;
template struct Y { int x; }; // #1
template struct Y { int y; };
};
template<> template struct X::Y { int z; }; // #2
int a = X::Y().z;
... because it uses #1, not #2, when instantiating X::Y.
[Bug middle-end/36109] GET_MODE_SIZE is inefficient for constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36109 Andrew Pinski changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |NEW URL||http://gcc.gnu.org/ml/gcc-p ||atches/2014-01/msg00140.htm ||l Last reconfirmed||2014-01-04 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug middle-end/14840] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|NEW Resolution|WONTFIX |--- --- Comment #11 from Andrew Pinski --- Reopening due to GET_MODE_SIZE getting the same attention.
[Bug c/59674] New: On m68k and vax variables stack variables with > MAX_STACK_ALIGNMENT make ssp fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674
Bug ID: 59674
Summary: On m68k and vax variables stack variables with >
MAX_STACK_ALIGNMENT make ssp fail
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: christos at zoulas dot com
Thie simple example:
struct foo {
const char *place;
long long time;
};
extern int goo(struct foo *);
int foo(void);
int foo(void) {
struct foo f;
f.time = 1;
f.place = "foo";
return goo(&f);
}
When compiled, produces:
/usr/obj/x86_64/tools/bin/m68k--netbsdelf-gcc -Os -fstack-protector
-Wstack-protector --param ssp-buffer-size=1 -c foo.c
foo.c: In function 'foo':
foo.c:9:5: warning: stack protector not protecting local variables: variable
length buffer [-Wstack-protector]
There are no variable length buffers on the stack. The problem is that we end
up calling in cfgexpand.c:
/* If there were any, allocate space. */
if (large_size > 0)
large_base = allocate_dynamic_stack_space (GEN_INT (large_size), 0,
large_align, true);
Changing long long to int, works just fine. It is a serious limitation not to
be able to protect stacks that contain long long or double. Here's the gcc
version:
$ /usr/obj/x86_64/tools/bin/m68k--netbsdelf-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/obj/x86_64/tools/bin/m68k--netbsdelf-gcc
COLLECT_LTO_WRAPPER=/usr/obj/x86_64/tools/libexec/gcc/m68k--netbsdelf/4.8.3/lto-wrapper
Target: m68k--netbsdelf
Configured with:
/p/netbsd/cvsroot/src/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=m68k--netbsdelf --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD
nb1 20120916' --with-system-zlib --enable-__cxa_atexit
--with-sysroot=/usr/obj/sun3/release --with-mpc=/usr/obj/x86_64/tools
--with-mpfr=/usr/obj/x86_64/tools --with-gmp=/usr/obj/x86_64/tools
--disable-nls --disable-multilib --program-transform-name=s,^,m68k--netbsdelf-,
--enable-languages='c c++ objc' --prefix=/usr/obj/x86_64/tools
Thread model: posix
gcc version 4.8.3 20131213 (prerelease) (NetBSD nb1 20120916)
[Bug fortran/59252] wrong code generation for allocatable character component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59252
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
--- Comment #4 from janus at gcc dot gnu.org ---
Created attachment 31569
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31569&action=edit
patch
This patch gets rid of the segfault and is free of regressions. However, the
dump still shows a double nullification of the 'label' component:
appv->label = 0B;
{
struct branch_plot_results_ppv_type branch_plot_results_ppv_type.0;
if (appv != 0B) goto L.1;
appv = (struct branch_plot_results_ppv_type *) __builtin_calloc (1, 8);
L.1:;
branch_plot_results_ppv_type.0.label = 0B;
*appv = branch_plot_results_ppv_type.0;
}
