[Bug target/53110] GCC-4.7 generates stupid x86_64 asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53110 Jakub Jelinek changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #11 from Jakub Jelinek 2012-04-26 05:36:00 UTC --- CCing Vlad for the RA decision.
[Bug target/53120] [4.5, 4.6, 4.7, 4.8 Regression]: ICE exposing strict_low_part / in/out operand thinko -fno-tree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53120 Hans-Peter Nilsson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.2 --- Comment #7 from Hans-Peter Nilsson 2012-04-25 23:26:21 UTC --- Fixed 4.7 and trunk, no further backport planned.
[Bug target/53120] [4.5, 4.6, 4.7, 4.8 Regression]: ICE exposing strict_low_part / in/out operand thinko -fno-tree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53120 --- Comment #6 from Hans-Peter Nilsson 2012-04-25 23:24:53 UTC --- Author: hp Date: Wed Apr 25 23:24:48 2012 New Revision: 186849 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186849 Log: PR target/53120 * gcc.dg/torture/pr53120.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr53120.c Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug target/53120] [4.5, 4.6, 4.7, 4.8 Regression]: ICE exposing strict_low_part / in/out operand thinko -fno-tree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53120
--- Comment #5 from Hans-Peter Nilsson 2012-04-25
23:23:37 UTC ---
Author: hp
Date: Wed Apr 25 23:23:34 2012
New Revision: 186848
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186848
Log:
PR target/53120
* config/cris/cris.md ("*andhi_lowpart_v32")
("*andqi_lowpart_v32"): Change first input-only operand from
a (match_operand ...) to (match_dup 0). Drop alternatives with
const_int-matching constraints for redundancy.
("*andhi_lowpart_non_v32", "*andqi_lowpart_non_v32"): Ditto. Drop
three-operand alternative.
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/cris/cris.md
[Bug go/52357] 64bit-out.go and go.test/test/cmplxdivide.go time out on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52357 Ian Lance Taylor changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from Ian Lance Taylor 2012-04-25 22:48:54 UTC --- The 64bit-out.go case appears to be similar. It is also a generated file, and it also takes a long time to compile. The register allocator is not quite as dominant, only 43% of compilation time. In any case I will revisit 64bit-out when and if cmplxdivide is fixed.
[Bug libstdc++/52689] static linking with libstdc++ fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689 --- Comment #21 from Benjamin Kosnik 2012-04-25 22:48:03 UTC --- Author: bkoz Date: Wed Apr 25 22:47:52 2012 New Revision: 186845 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186845 Log: 2012-04-25 Benjamin Kosnik PR libstdc++/52689 * testsuite/17_intro/static.cc: Fix. * testsuite/lib/dg-options.exp (dg-require-static-libstdcxx): New. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/17_intro/static.cc trunk/libstdc++-v3/testsuite/lib/dg-options.exp trunk/libstdc++-v3/testsuite/lib/libstdc++.exp
[Bug rtl-optimization/53125] Very slow register allocation on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125 --- Comment #1 from Ian Lance Taylor 2012-04-25 22:34:17 UTC --- Out of curiousity I tried compiling the test case with -O2. On x86_64 it took 57.4 seconds, on SPARC it took 20 minutes 33 seconds.
[Bug target/53120] [4.5, 4.6, 4.7, 4.8 Regression]: ICE exposing strict_low_part / in/out operand thinko -fno-tree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53120 --- Comment #4 from Hans-Peter Nilsson 2012-04-25 22:33:33 UTC --- Author: hp Date: Wed Apr 25 22:33:30 2012 New Revision: 186844 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186844 Log: PR target/53120 * gcc.dg/torture/pr53120.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr53120.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/53120] [4.5, 4.6, 4.7, 4.8 Regression]: ICE exposing strict_low_part / in/out operand thinko -fno-tree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53120
--- Comment #3 from Hans-Peter Nilsson 2012-04-25
22:31:40 UTC ---
Author: hp
Date: Wed Apr 25 22:31:36 2012
New Revision: 186843
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186843
Log:
PR target/53120
* config/cris/cris.md ("*andhi_lowpart_v32")
("*andqi_lowpart_v32"): Change first input-only operand from
a (match_operand ...) to (match_dup 0). Drop alternatives with
const_int-matching constraints for redundancy.
("*andhi_lowpart_non_v32", "*andqi_lowpart_non_v32"): Ditto. Drop
three-operand alternative.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/cris/cris.md
[Bug go/52357] 64bit-out.go and go.test/test/cmplxdivide.go time out on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52357 --- Comment #2 from Ian Lance Taylor 2012-04-25 22:15:19 UTC --- SPARC register allocator slowness filed as PR 53125.
[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
Manuel López-Ibáñez changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
CC||jsm28 at gcc dot gnu.org
Ever Confirmed|1 |0
Severity|normal |enhancement
--- Comment #5 from Manuel López-Ibáñez 2012-04-25
22:13:11 UTC ---
It seems to me you are right. However, I cannot see how to check for ={0} at
the point of the warning.
Joseph, any ideas? This part of the C FE is ancient.
[Bug rtl-optimization/53125] New: Very slow register allocation on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125 Bug #: 53125 Summary: Very slow register allocation on SPARC Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: i...@airs.com CC: r...@gcc.gnu.org, vmaka...@redhat.com Target: sparc-sun-solaris2.11 Created attachment 27244 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27244 Test case The attached test case is a conversion to C of a machine generated test case in Go (the machine generated Go source is in gcc/testsuite/go.test/test/cmpldivide1.go). When I compile this test case without optimization on an x86_64 GNU/Linux system, it takes 5.8 seconds. When I compile it without optimization on a SPARC Solaris 2.11 system, it takes 2 minutes 32.8 seconds. The SPARC machine is slower than the x86_64 machine. But it's not that much slower. According to -ftime-report on the SPARC system, 45% of the time is "register information" and 41% of the time is "integrated RA." Since the file is machine generated, I would be willing to accept a 2 1/2 minute compilation time with optimization. But without optimization it is just too slow. And the discrepancy with x86_64 is extreme.
[Bug target/53120] [4.5, 4.6, 4.7, 4.8 Regression]: ICE exposing strict_low_part / in/out operand thinko -fno-tree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53120 --- Comment #2 from Hans-Peter Nilsson 2012-04-25 21:38:14 UTC --- Forgot to quote the ICE message (here from 4.7 r186809): /tmp/ph2.i: In function 'f': /tmp/ph2.i:109:1: internal compiler error: in find_reloads, at reload.c:4069 >From testing on the 4.7 branch (passed) and closer inspection of log files on trunk, it seems this bug is also the reason for gcc.c-torture/execute/vector-compare-1.c never passing since its introduction (thus not blipping on my radar), a test-case that doesn't require -fno-tree-sra.
[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52428 --- Comment #8 from Janne Blomqvist 2012-04-25 21:15:57 UTC --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01637.html
[Bug target/53124] Arm NEON narrowing right shift instructions impose incorrect operand bounds (intrinsic and asm)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53124 --- Comment #1 from Kostya Sebov 2012-04-25 20:54:50 UTC --- Note: 0 also not allowed even though it should be according to the docs.
[Bug fortran/53035] ICE with deferred-length module variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53035 Tobias Burnus changed: What|Removed |Added Keywords||ice-on-valid-code Status|WAITING |NEW Summary|Internal Compiler Error |ICE with deferred-length ||module variable
[Bug fortran/53035] Internal Compiler Error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53035 --- Comment #5 from Tobias Burnus 2012-04-25 20:45:26 UTC --- Reduced test case: module SysPars implicit none character (len = :), allocatable :: lens_dir end module SysPars Related: PR 45170 (plus a few others) * * * (In reply to comment #2) > Sorry that I forgot to attach the file. It is attached here. I have greatly > reduced the number of the files I could reduce it even more - see above. I am not sure whether fixing will be that straight forward, though. > I could make it a full-time job submitting bugs. And I could make it a full-time job fixing bugs ;-) > Permit me to add that the lack of deferred length, allocatable characters in > gfortran represents, for me, a major obstacle. I concur that the bugs related to deferred-length (incl. this PR) and the lack of deferred-length components is of some importance. Unfortunately, it is not that trivial. As bug fixing and some other projects currently rank higher, it might take a while. (Though, sometimes even larger features can get implemented rather quickly.) As gfortran is developed by volunteers, it is a bit unpredictable when a certain feature gets implemented and how quickly the development progresses.
[Bug target/53110] GCC-4.7 generates stupid x86_64 asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53110 --- Comment #10 from H. Peter Anvin 2012-04-25 20:32:29 UTC --- There still seems to be a redundant copy in there, but that's pretty common in gcc-generated code; the movl %esi, %esi could get completely elided and the zero extend folded into "movq %rsi, %rdx" by changing it to movl %esi, %edx. This is a second-order issue though...
[Bug fortran/38894] c_f_procpointer/c_f_pointer - add missing argument checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38894 --- Comment #9 from janus at gcc dot gnu.org 2012-04-25 20:19:42 UTC --- Combining comments #2 and #8 still produces testsuite failures: FAIL: gfortran.dg/c_ptr_tests_14.f90 -O0 (test for excess errors) FAIL: gfortran.dg/c_ptr_tests_15.f90 -O (test for excess errors) c_ptr_tests_14.f90:33.18: if(c_associated(file%gsl_func)) call abort() 1 Error: Type mismatch in argument 'c_ptr_1' at (1); passed TYPE(c_funptr) to TYPE(c_ptr) c_ptr_tests_14.f90:39.18: if(c_associated(file%gsl_func)) call abort() 1 Error: Type mismatch in argument 'c_ptr_1' at (1); passed TYPE(c_funptr) to TYPE(c_ptr) The problem seems to be that C_ASSOCIATED's formal args are TYPE(c_ptr), although c_ptr and c_funptr are allowed. We already build two versions of C_ASSOCIATED (with one and two arguments, respectively). Probably we need two more with c_funptr arguments.
[Bug fortran/53035] Internal Compiler Error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53035 --- Comment #4 from kargl at gcc dot gnu.org 2012-04-25 20:15:40 UTC --- Here's a reduced testcase (15 minutes to reduce!). module syspars implicit none character (len = :), allocatable :: lens_dir contains function get_lens_dir () result (return_lens_dir) character (:), allocatable :: return_lens_dir return_lens_dir = lens_dir end function get_lens_dir end module syspars This is most likely a duplicate of one of the other PRs about deferred type parameters.
[Bug middle-end/17308] nonnull attribute not as useful as it could
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308 --- Comment #9 from Manuel López-Ibáñez 2012-04-25 20:00:44 UTC --- (In reply to comment #8) > Even if you decide that you are unable to warn about a call to foo(var) > because > the only way to analyze that var might be NULL is in the middle end but the > warning is only emitted by the front end, AT LEAST you could have warned that > the 'if (!bar)' conditional is assumed to be dead code based on the attribute > placed on var. GCC does not warn about unreachable code anymore: http://gcc.gnu.org/ml/gcc-help/2011-05/msg00360.html Someone would have to contribute a new -Wunreachable-code implementation. I honestly don't know what kind of implementation would be acceptable by GCC maintainers. Maybe one implemented in the FE? If so, it would require exactly the same infrastructure necessary to implement what Ulrich asks for above. Sorry, comment #7 still applies.
[Bug target/53087] [powerpc] Poor code from cstore expander
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53087 --- Comment #9 from Paolo Bonzini 2012-04-25 20:00:57 UTC --- The handling of this code sequence in fold-const changed back and forth many times, and this is likely the reason why GCC 4.1 produced straight-line code while GCC 4.3 produced branchy code. I think the best fix is to add support for expanding "x != 0" using the cntlzw trick---either in the cstore expander or in emit_store_flag. In fact, emit_store_flag already has code for a similar trick: /* For EQ or NE, one way to do the comparison is to apply an operation that converts the operand into a positive number if it is nonzero or zero if it was originally zero. Then, for EQ, we subtract 1 and for NE we negate. This puts the result in the sign bit. Then we normalize with a shift, if needed. Two operations that can do the above actions are ABS and FFS, so try them. If that doesn't work, and MODE is smaller than a full word, we can use zero-extension to the wider mode (an unsigned conversion) as the operation. */ So another thing to do is to investigate why this doesn't work.
[Bug c/53124] New: Arm NEON narrowing right shift instructions impose incorrect operand bounds (intrinsic and asm)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53124
Bug #: 53124
Summary: Arm NEON narrowing right shift instructions impose
incorrect operand bounds (intrinsic and asm)
Classification: Unclassified
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kse...@rim.com
The following code produces "Constant out of range" compiler error, even though
it's supposed to allow any immediate up to (size(datatype) - 1), or 31 in this
case. See
http://infocenter.arm.com/help/topic/com.arm.doc.dui0489c/CIHGJIHA.html
Using inline assembly implementation doesn't work either resulting in "Error:
immediate out of range for narrowing operation".
int16x4_t rshift8_and_saturate_uint12( int32x4_t arg )
{
uint32x4_t saturated_at32 = vqshluq_n_s32( arg, 32-(8+12) );
#if 1
return vshrn_n_s32( vreinterpretq_s32_u32( saturated_at32 ), 32-12 );
#else
int16x4_t result;
asm volatile( "VSHRN.I32 %P0, %q1, #20" : "=w"(result) :
"w"(saturated_at32));
return result;
#endif
}
It appears similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41196
although in this case the ssembler code will probably need to be fixed as well.
Also, by looking at /gcc/config/arm/neon.md it seems all V[Q]SHR[U]N are
affected.
[Bug c/53123] New: Double return statement in c-omp.c source file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53123 Bug #: 53123 Summary: Double return statement in c-omp.c source file Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: guy_vaes...@hotmail.com /pub/gcc/snapshots/4.8-20120422/ Sourcefile gcc\c-family\c-omp.c Contains a second return statement on line 174 (first one on line 172) Orriginal code: line 170 x = build1 (OMP_ATOMIC_READ, type, addr); line 171 SET_EXPR_LOCATION (x, loc); line 172 return build_modify_expr (loc, v, NULL_TREE, NOP_EXPR, line 173 loc, x, NULL_TREE); line 174 return x; What I would expect (modified line 172): line 170 x = build1 (OMP_ATOMIC_READ, type, addr); line 171 SET_EXPR_LOCATION (x, loc); line 172 x = build_modify_expr (loc, v, NULL_TREE, NOP_EXPR, line 173 loc, x, NULL_TREE); line 174 return x; The second return statement will never be reached and should be eliminated.
[Bug fortran/53035] Internal Compiler Error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53035 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Severity|major |normal --- Comment #3 from kargl at gcc dot gnu.org 2012-04-25 19:51:18 UTC --- (In reply to comment #2) > In this particular case, I do not think you should have difficulty > reproducing the problem and determining its cause. > laptop:kargl[230] ./configure configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.." laptop:kargl[232] rm -rf * laptop:kargl[233] tar xf ../focus11-bug1-4.7.1.tar.gz laptop:kargl[234] gmake numrutil.f90:78: Error: Can't open included file 'back_substitution_a.f90' gmake[1]: *** [numrutil.o] Error 1 gmake[1]: Leaving directory `/usr/home/kargl/tmp/doh/src' gmake: *** [all-recursive] Error 1 > Norm Clerman > > Permit me to add that the lack of deferred length, allocatable characters in > gfortran represents, for me, a major obstacle. The other three compilers I use > support them, and I use them in all but one of my major applications. gfortran has support for a deferred type parameter. She unfortunately also has some nasty bugs associated with deferred type parameters, and if those bugs were trivial to fix then the bugs would have been fixed by now. Permit me to add that gfortran development is currently experiencing a lack of volunteers to help fix her. Any particular bug is fixed because (a) a developer is already working in that area of the compiler; (b) the bug affects a developer's own project; (c) someone sends in a patch; or (d) someone is willing to pay to have the bug fixed.
[Bug fortran/38894] c_f_procpointer/c_f_pointer - add missing argument checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38894 --- Comment #8 from janus at gcc dot gnu.org 2012-04-25 19:47:52 UTC --- The errors in comment #5 - #7 can be fixed by the following patch: Index: gcc/fortran/interface.c === --- gcc/fortran/interface.c(revision 186596) +++ gcc/fortran/interface.c(working copy) @@ -404,6 +404,13 @@ gfc_compare_derived_types (gfc_symbol *derived1, g && strcmp (derived1->module, derived2->module) == 0) return 1; + /* Types from intrinsinc modules (like ISO_C_BINDING) might be renamed, + but can still be identified via their 'intmod_sym_id'. */ + if (derived1->from_intmod != INTMOD_NONE + && derived1->from_intmod == derived2->from_intmod + && derived1->intmod_sym_id == derived2->intmod_sym_id) +return 1; + /* Compare type via the rules of the standard. Both types must have the SEQUENCE or BIND(C) attribute to be equal. */
[Bug target/53110] GCC-4.7 generates stupid x86_64 asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53110 --- Comment #9 from Jakub Jelinek 2012-04-25 19:40:39 UTC --- Author: jakub Date: Wed Apr 25 19:40:31 2012 New Revision: 186839 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186839 Log: PR target/53110 * config/i386/i386.md (and3): For andq $0x, reg instead expand it as zero extension. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md
[Bug middle-end/17308] nonnull attribute not as useful as it could
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
--- Comment #8 from Eric Blake 2012-04-25 19:31:59
UTC ---
I hit this again today, and I'm still upset that gcc is doing such a poor job
with (not) using this attribute as a way to improve code quality via decent
warnings.
Basically, libvirt had an issue where we accidentally misused the nonnull
attribute marker; we had added the marker in a header file, then later changed
the C file to work with a NULL argument but without updating the header file to
match: https://bugzilla.redhat.com/show_bug.cgi?id=815270
The calling code managed to pass in a NULL pointer to a parameter based on the
semantics we saw in the .c file, but the NULL check in our function in question
was "helpfully" elided by gcc since the attribute was still present, all
without ever warning us that we were losing the NULL check. As a result, the
code misbehaved when it dereferenced NULL. If gcc is smart enough to elide
code based on the attribute, it should be smart enough to issue a warning that
we have dead code, and the only reason the code is assumed to be dead is
because of a suspicious attribute. Had we had the warning, we would have known
to either remove our dead NULL check, or to fix the header to no longer have
the (now-inappropriate) attribute.
In other words, with a header like:
void foo(void *bar) __attribute__((nonnull(1)));
and a C file like:
void foo(void *bar) { if (!bar) abort(); }
Even if you decide that you are unable to warn about a call to foo(var) because
the only way to analyze that var might be NULL is in the middle end but the
warning is only emitted by the front end, AT LEAST you could have warned that
the 'if (!bar)' conditional is assumed to be dead code based on the attribute
placed on var.
[Bug debug/52857] DW_OP_GNU_regval_type is generated with INVALID_REGNUM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52857 --- Comment #6 from hjl at gcc dot gnu.org 2012-04-25 19:08:29 UTC --- Author: hjl Date: Wed Apr 25 19:08:23 2012 New Revision: 186837 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186837 Log: Assert dbx_reg_number doesn't return INVALID_REGNUM PR debug/52857 * dwarf2out.c (dbx_reg_number): Assert return value != INVALID_REGNUM. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug c++/53122] New: internal compiler error: in unify, at cp/pt.c:15750
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53122
Bug #: 53122
Summary: internal compiler error: in unify, at cp/pt.c:15750
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jaredhober...@gmail.com
Created attachment 27243
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27243
Zip file containing reproducer code and preprocessed soruce.
The following code:
template
void foo(Args&&... args)
{
}
template
void bar(Args&&...)
{
auto fn = foo;
}
int main()
{
return 0;
}
produces the following output when compiled with g++ 4.6.1:
$ g++ -std=c++0x repro.cpp
repro.cpp: In function ‘void bar(Args&& ...)’:
repro.cpp:9:13: internal compiler error: in unify, at cp/pt.c:15750
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/cclt2kKy.out file, please attach this to
your bugreport.
Compiler & system details:
$ g++ --version ; uname -a
g++-4.6.real (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Linux jhoberock-dt 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:28:43 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux
Example code and preprocessed source attached.
[Bug tree-optimization/52979] [4.7 Regression] likely wrong code bug w/packed bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52979 Jakub Jelinek changed: What|Removed |Added Known to work||4.8.0 Summary|[4.7/4.8 Regression] likely |[4.7 Regression] likely |wrong code bug w/packed |wrong code bug w/packed |bitfields |bitfields Known to fail|4.8.0 | --- Comment #10 from Jakub Jelinek 2012-04-25 18:36:10 UTC --- Should be fixed on the trunk. On the 4.7 branch it needs PR48124 backport.
[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 --- Comment #4 from Rich Felker 2012-04-25 18:32:08 UTC --- Created attachment 27242 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27242 minimal test case Glibc's mbstate_t is defined as a struct whose first element is an int (not another struct/union/array), so the warning does not happen there. I'm uploading a minimal example case with an explicitly defined struct.
[Bug c++/53121] New: Allow static_cast from pointer-to-vector to pointer-to-object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53121
Bug #: 53121
Summary: Allow static_cast from pointer-to-vector to
pointer-to-object
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
Hello,
casting a __m128d* to a double* currently requires an ugly C cast. However,
this pointer cast is the official way to access the elements of the vector, so
I believe it should be allowed in a static_cast. Whether that should extend to
casts with references and arrays is a harder question, but the answer is
probably yes. Casts to sub-vectors (__m256d* to __m128d*) would be a bonus.
#include
double* f(__m128d* x){
return static_cast(x);
// return (double*)(x);
}
v.cc: In function ‘double* f(__m128d*)’:
v.cc:3:32: error: invalid static_cast from type ‘__m128d* {aka __vector(2)
double*}’ to type ‘double*’
[Bug fortran/53035] Internal Compiler Error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53035 --- Comment #2 from Norman S. Clerman 2012-04-25 18:13:03 UTC --- Created attachment 27241 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27241 see original submittal Hello Tobias, Sorry that I forgot to attach the file. It is attached here. I have greatly reduced the number of the files - most in the program were not needed to reproduce the problem. The error message remains the one I sent in the original submittal. I currently have eight outstanding issues with Intel and a similar number with PGI. I have a few with NAG, and this one with you. I could make it a full-time job submitting bugs. But I don't have the time from my work to reduce every problem, or to spend hours and hours trying to create a simple test case. In this particular case, I do not think you should have difficulty reproducing the problem and determining its cause. Please don't hesitate to send me a message if something is still missing or if you require additional information. Thanks for your efforts. Yours, Norm Clerman Permit me to add that the lack of deferred length, allocatable characters in gfortran represents, for me, a major obstacle. The other three compilers I use support them, and I use them in all but one of my major applications.
[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 --- Comment #3 from Manuel López-Ibáñez 2012-04-25 18:12:29 UTC --- I can't get reproduce this. Could you provide a small reproducible testcase? Plus the info asked here: http://gcc.gnu.org/bugs/#need
[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 --- Comment #2 from Rich Felker 2012-04-25 18:01:41 UTC --- Sorry, I wrote the bug report without GCC in front of me. The correct name for the warning option is -Wmissing-braces.
[Bug fortran/38894] c_f_procpointer/c_f_pointer - add missing argument checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38894 --- Comment #7 from janus at gcc dot gnu.org 2012-04-25 17:57:11 UTC --- (In reply to comment #6) > Here is a maximally reduced test case, which yields the same error as > iso_c_binding_rename_1.f90 (if the code from comment #2 is removed): Another variant: program p use iso_c_binding, only: c_ptr, c_associated, & my_cptr_1 => c_ptr, my_cptr_2 => c_ptr implicit none type(c_ptr) :: my_ptr type(my_cptr_1) :: my_ptr_1 type(my_cptr_2) :: my_ptr_2 print *, c_associated (my_ptr)! passed TYPE(c_ptr) to TYPE(my_cptr_2) print *, c_associated (my_ptr_1) ! passed TYPE(my_cptr_1) to TYPE(my_cptr_2) print *, c_associated (my_ptr_2) ! works end The problem is apparently that the type of c_associated's argument is being renamed to 'my_cptr_2'. I also constructed an analogous test case with a derived type instead of c_ptr, which works correctly: module m type :: t end type contains logical function test(x) type(t) :: x end function end module program p use m, only: t, test, t1 => t, t2 => t implicit none type(t) :: y type(t1) :: y1 type(t2) :: y2 print *, test (y) ! works print *, test (y1) ! works print *, test (y2) ! works end This means the problem is special to ISO_C_BINDING.
[Bug c/53119] -Wbraces wrongly warns about universal zero initializer {0}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-04-25 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez 2012-04-25 17:53:25 UTC --- Where did you get your compiler? -Wbraces is not a valid option in the original GCC. http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options
[Bug go/52357] 64bit-out.go and go.test/test/cmplxdivide.go time out on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52357 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-25 Ever Confirmed|0 |1 --- Comment #1 from Ian Lance Taylor 2012-04-25 17:39:35 UTC --- Interestingly, the time for cmpldivide.go on SPARC appears to be primarily in the register allocator while compiling. This is true even though no -O option is used. Actually running the program after it has been compiled takes less than a second. Execution times (seconds) phase setup : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 109 kB ( 0%) ggc phase parsing : 0.72 ( 1%) usr 0.04 ( 6%) sys 0.77 ( 1%) wall 8 kB ( 0%) ggc phase generate : 118.51 (99%) usr 0.67 (93%) sys 119.17 (99%) wall 54226 kB (100%) ggc callgraph construction : 0.09 ( 0%) usr 0.01 ( 1%) sys 0.09 ( 0%) wall 1806 kB ( 3%) ggc callgraph optimization : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 3 kB ( 0%) ggc cfg cleanup : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc trivially dead code : 0.42 ( 0%) usr 0.00 ( 0%) sys 0.43 ( 0%) wall 0 kB ( 0%) ggc df scan insns : 0.39 ( 0%) usr 0.08 (11%) sys 0.47 ( 0%) wall 0 kB ( 0%) ggc df live regs: 0.32 ( 0%) usr 0.00 ( 0%) sys 0.31 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 0.39 ( 0%) usr 0.02 ( 3%) sys 0.41 ( 0%) wall 1261 kB ( 2%) ggc register information: 52.00 (44%) usr 0.00 ( 0%) sys 52.00 (43%) wall 0 kB ( 0%) ggc alias analysis : 0.20 ( 0%) usr 0.01 ( 1%) sys 0.21 ( 0%) wall 1026 kB ( 2%) ggc rebuild jump labels : 0.18 ( 0%) usr 0.00 ( 0%) sys 0.17 ( 0%) wall 0 kB ( 0%) ggc parser (global) : 0.72 ( 1%) usr 0.04 ( 6%) sys 0.77 ( 1%) wall 8 kB ( 0%) ggc inline heuristics : 0.09 ( 0%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall 4 kB ( 0%) ggc tree gimplify : 0.38 ( 0%) usr 0.02 ( 3%) sys 0.41 ( 0%) wall 5832 kB (11%) ggc tree eh : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 5 kB ( 0%) ggc tree CFG construction : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 10 kB ( 0%) ggc tree find ref. vars : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 548 kB ( 1%) ggc tree PHI insertion : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 1 kB ( 0%) ggc tree SSA rewrite: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 1131 kB ( 2%) ggc tree SSA other : 0.15 ( 0%) usr 0.05 ( 7%) sys 0.13 ( 0%) wall 0 kB ( 0%) ggc tree operand scan : 0.07 ( 0%) usr 0.02 ( 3%) sys 0.17 ( 0%) wall 673 kB ( 1%) ggc tree STMT verifier : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc out of ssa : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall 0 kB ( 0%) ggc expand vars : 0.08 ( 0%) usr 0.03 ( 4%) sys 0.10 ( 0%) wall 1535 kB ( 3%) ggc expand : 1.24 ( 1%) usr 0.04 ( 6%) sys 1.29 ( 1%) wall 12793 kB (24%) ggc post expand cleanups: 0.10 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 5 kB ( 0%) ggc integrated RA : 50.16 (42%) usr 0.20 (28%) sys 50.35 (42%) wall 12377 kB (23%) ggc reload : 8.03 ( 7%) usr 0.17 (24%) sys 8.19 ( 7%) wall 13804 kB (25%) ggc thread pro- & epilogue : 0.20 ( 0%) usr 0.00 ( 0%) sys 0.20 ( 0%) wall 4 kB ( 0%) ggc final : 2.48 ( 2%) usr 0.02 ( 3%) sys 2.50 ( 2%) wall 9 kB ( 0%) ggc rest of compilation : 0.98 ( 1%) usr 0.00 ( 0%) sys 1.02 ( 1%) wall 31 kB ( 0%) ggc unaccounted todo: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc TOTAL : 119.24 0.72 119.96 54344 kB real2m2.183s user2m0.976s sys 0m1.074s
[Bug c++/29131] [DR 225] Bad name lookup for templates due to fundamental types namespace for ADL.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29131
Nikos Platis changed:
What|Removed |Added
CC||nplatis at freemail dot gr
--- Comment #20 from Nikos Platis 2012-04-25
17:33:24 UTC ---
I am having a problem using code similar to the one in comment #5, but using
glm::vec3, from the glm library (http://glm.g-truc.net/), as the type used to
instanciate the template.
Then I get an error message that "‘f’ was not declared in this scope, and no
declarations were found by argument-dependent lookup at the point of
instantiation"
glm::vec3 does not seem like a fundamental type.
#include "glm/glm.hpp"
template
int t(T i)
{
return f (i);
}
int
f (glm::vec3 i)
{
return 0;
}
int
main()
{
glm::vec3 b;
return t(b);
}
[Bug target/53120] [4.5, 4.6, 4.7, 4.8 Regression]: ICE exposing strict_low_part / in/out operand thinko -fno-tree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53120 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords||ice-on-valid-code Last reconfirmed||2012-04-25 AssignedTo|unassigned at gcc dot |hp at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Summary|[4.5, 4.6, 4.7, 4.8 |[4.5, 4.6, 4.7, 4.8 |Regression]: ICE building |Regression]: ICE exposing |driver, exposing|strict_low_part / in/out |strict_low_part / in/out|operand thinko |operand thinko |-fno-tree-sra |-fno-tree-sra | --- Comment #1 from Hans-Peter Nilsson 2012-04-25 17:07:25 UTC --- No intention to backport further than 4.7.
[Bug middle-end/53093] [4.8 Regression]: tls/alias-1.c ICE, emutls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53093
--- Comment #2 from Jan Hubicka 2012-04-25 17:06:41 UTC
---
Hi,
the problem seems to be quite easy. We have variable and alias.
The code first counts number of variables and allocated vectors, then it
inserts
aliases, too, and the length of vector is not enough anymore.
Can you, please, test the following patch? I will try to work out why this
did not ICE before.
Honza
Index: tree-emutls.c
===
--- tree-emutls.c (revision 186831)
+++ tree-emutls.c (working copy)
@@ -706,7 +706,7 @@ create_emultls_var (struct varpool_node
cdecl = new_emutls_decl (var->symbol.decl, var->alias_of);
cvar = varpool_get_node (cdecl);
- VEC_quick_push (varpool_node_ptr, control_vars, cvar);
+ VEC_safe_push (varpool_node_ptr, heap, control_vars, cvar);
if (!var->alias)
{
[Bug target/53120] New: [4.5, 4.6, 4.7, 4.8 Regression]: ICE building driver, exposing strict_low_part / in/out operand thinko -fno-tree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53120
Bug #: 53120
Summary: [4.5, 4.6, 4.7, 4.8 Regression]: ICE building driver,
exposing strict_low_part / in/out operand thinko
-fno-tree-sra
Classification: Unclassified
Product: gcc
Version: 4.5.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: h...@gcc.gnu.org
Target: cris-*-*, crisv32-*-*
Created attachment 27240
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27240
./cc1 -O2 -fno-tree-sra
The attached test-case, intended for gcc.dg/torture, exposes a thinko in the
CRIS port: a read/write output operand (the "+" constraint modifier) is
specified to match an input operand ("0"). Reload cannot cope, and thinking
about it, it's not possible (with the current hooks and macros). According to
a comment in m68k.md, this is to be expected, supported by a gdb session. The
m68k comment (grep MATCH_DUP m68k.md) is from revision 372 (!) which according
to the (artificially mapped) svn revision numbers are about 10 revisions from
the introduction of reload.c (!!). Patch in testing. The observation was from
an import of the 4.7 branch; also confirmed on branches for 4.5, 4.6, 4.7 and
trunk, but not for 4.3. The use of "+" was introduced with revision r134236
(2008-04-13 02:51:51 UTC), before the 4.4 branch. The bug is of course there
but just not trigging for 4.4 but nevertheless observed as a regression of 4.5,
therefore labelled as such. Note the requirement to turn off tree-sra.
[Bug c/53119] New: -Wbraces wrongly warns about universal zero initializer {0}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
Bug #: 53119
Summary: -Wbraces wrongly warns about universal zero
initializer {0}
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bug...@aerifal.cx
In C, {0} is the universal zero initializer equivalent to C++'s {} (the latter
being invalid in C). It is necessary to use whenever you want a
zero-initialized object of a complete but conceptually-opaque or
implementation-defined type. The classic example in the C standard library is
mbstate_t:
mbstate_t state = { 0 }; /* correctly zero-initialized */
versus the common but nonportable:
mbstate_t state;
memset(&state, 0, sizeof state);
In this case, gcc -Wbraces (which is included in -Wall) actively discourages
the programmer from writing the correct form of the code by throwing ugly
warnings.
Note that if you want to eliminate warnings and write portable code, the *only*
way to zero-initialize an object like this is:
static const mbstate_t zero_state;
mbstate_t state = zero_state;
(i.e. creating an extra object of static storage duration to be implicitly zero
initialized).
The same reasoning applies to any structures provided by third-party libraries
which must be allocated by the calling application and zero-initialized, but
whose definitions are intended to be considered as opaque.
To fix the issue, GCC should simply special-case {0} as always-valid and
suppress warnings for it, while leaving in effect all other behaviors of
-Wbraces.
[Bug fortran/40039] Procedures as actual arguments: Check intent of arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40039 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from janus at gcc dot gnu.org 2012-04-25 17:00:20 UTC --- (In reply to comment #8) > > the remaining ToDo item for this PR is: Fixing the intents of non-std > > intrinsics (which are currently all intent(in)). > > I just went through the whole list and identified a few which apparently need > fixing (hopefully complete): Actually it seems that all of them were already fixed by r164052 (for PR43665). So we can finally close this one.
[Bug middle-end/53106] [4.8 Regression] Benchmarks in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53106
--- Comment #7 from Jan Hubicka 2012-04-25
16:21:03 UTC ---
Actually we make the node unanalyzed in this case. There is one misupdated
place. I am testing the following patch.
Index: ipa.c
===
--- ipa.c (revision 186827)
+++ ipa.c (working copy)
@@ -262,7 +262,8 @@ cgraph_remove_unreachable_nodes (bool be
for (next = cgraph (node->symbol.same_comdat_group);
next != node;
next = cgraph (next->symbol.same_comdat_group))
- if (!pointer_set_insert (reachable, next))
+ if (!next->global.inlined_to
+ && !pointer_set_insert (reachable, next))
enqueue_cgraph_node (next, &first, reachable);
}
}
@@ -276,7 +277,7 @@ cgraph_remove_unreachable_nodes (bool be
{
bool noninline = node->clone_of->symbol.decl !=
node->symbol.decl;
node = node->clone_of;
- if (noninline && !pointer_set_insert (reachable, node) &&
!node->symbol.aux)
+ if (noninline && !pointer_set_contains (reachable, node) &&
!node->symbol.aux)
{
enqueue_cgraph_node (node, &first, reachable);
break;
[Bug middle-end/53106] [4.8 Regression] Benchmarks in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53106 --- Comment #6 from Jan Hubicka 2012-04-25 16:11:43 UTC --- This is previously latent bug in frequency verification. We check that frequencies of edges match frequencies of basic block. This check is disabled when function is inline, because then the frequencies of edges are scaled to the same base as in the outer function. Now what happens is that the function gets cloned, then the original version gets fully inlined and finally becomes unreachable. We however need to keep function body around and thus remove_unreachable_nodes turns the inline clone back to offline re-enabling the check that finally fires. I am not sure how we got around this problem previously. I am doiuble checking.
[Bug c++/53116] protected member access from derived template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53116 --- Comment #4 from Filippov Aleksey 2012-04-25 16:09:07 UTC --- I haven't noticed that this behavior is related to lazy instantiation. But sometimes if template code does not depend on template argument, it can be checked. If it is not such case, it probably is not a bug.
[Bug target/53117] missed-optimization: worse code for 'x <= 0' compared to 'x < 0'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53117 --- Comment #3 from Wouter Vermaelen 2012-04-25 15:30:42 UTC --- @Jakub: At first I was puzzled by your comment. But after some investigation I found out that this 'optimization' is indeed not possible when the subtraction would underflow. So you can close this bug report as invalid. (OTOH signed overflow is anyway undefined behavior in C).
[Bug fortran/40039] Procedures as actual arguments: Check intent of arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40039 --- Comment #8 from janus at gcc dot gnu.org 2012-04-25 15:24:13 UTC --- (In reply to comment #7) > the remaining ToDo item for this PR is: Fixing the intents of non-std > intrinsics (which are currently all intent(in)). I just went through the whole list and identified a few which apparently need fixing (hopefully complete): * ALARM * CHDIR * CHMOD * CTIME * DTIME * ETIME * FDATE * FGET * FGETC * FPUT * FPUTC * FSEEK * FSTAT * FTELL * GERROR * GETARG * GETCWD * GETENV * GETLOG * GMTIME * HOSTNM * IDATE * ITIME * KILL * LINK * LSTAT * LTIME * RENAME * SECOND * SIGNAL * STAT * SYMLINK * SYSTEM * TTYNAM * UMASK * UNLINK
[Bug debug/53118] New: [4.5/4.6/4.7 regression] -feliminate-dwarf2-dups is broken for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53118
Bug #: 53118
Summary: [4.5/4.6/4.7 regression] -feliminate-dwarf2-dups is
broken for C++
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
As noted in http://gcc.gnu.org/ml/gcc-help/2010-09/msg00081.html ,
-feliminate-dwarf2-dups has been broken for C++ ever since GCC 4.0; the front
end now tokenizes the entire input before doing any parsing, so the calls to
dwarf2out_{start,end}_source_file are all clustered at the beginning rather
than properly wrapping the contents of headers.
Testcase from that message:
-- source file bar.c:
#include "foo.h"
#include "bar.h"
struct Foo myfoo;
struct Bar mybar;
--
-- header file foo.h:
struct Foo {
double d_foo;
int i_foo;
};
--
-- header file bar.h:
struct Bar {
double d_bar;
int i_bar;
char c_bar;
};
--
[Bug libstdc++/53115] [4.7/4.8 Regression] _Hashtable::_M_rehash_aux(false_type) is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53115 --- Comment #4 from Paolo Carlini 2012-04-25 15:14:41 UTC --- I have no idea what they are doing, definitely FSF 4.7.0 is not affected.
[Bug go/52583] Several new go testsuite failues on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 --- Comment #21 from Ian Lance Taylor 2012-04-25 14:56:56 UTC --- I no longer see any failures on i386 Solaris. I see a few failures on x86_64 Solaris. They are all crashing in x86_64_fallback_frame_state when trying to unwind through a signal handler. The x86_64_fallback_frame_state function assumes, quite reasonably, that context->pc is a valid memory address. Unfortunately, many Go stacks begin with a stack passed to makecontext. The implementation of makecontext in the Solaris libc does not seem to have appropriate unwind information. Ideally it should specifically set the return address unwind column to be undefined, as described by DWARF. Right now, an attempt to unwind the stack frame up to the point of makecontext will sometimes produce an invalid value for the PC of the (nonexistent) frame that called makecontext. And that leads to the crash. I think the only fixes are for Solaris to correct makecontext so that it sets up proper unwind information, or for libgo to implement a version of makecontext specific for its purposes. The latter will not happen for 4.7.
[Bug c++/53116] protected member access from derived template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53116 --- Comment #3 from mattipee at yahoo dot co.uk 2012-04-25 14:57:14 UTC --- I thought lazy instantiation made this expected behaviour.
[Bug c/53064] -Wsequence-point behaves inconsistently
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53064 --- Comment #3 from Wenbin Lv 2012-04-25 14:56:48 UTC --- (In reply to comment #1) > > a + (++a ? 0 : 0); > > Hmm, I don't think there is a sequence point issue here compared to the other > case where it might cause an undefined code. > > (++a ? 0 : 0) is all in done in one sequence point so that is defined and then > added to a. a might be accessed before or after the sequence point where a is > modified but there is a sequence point between the access and the > modification. Sorry I don't quite understand your reply. Did you mean there are sequence points before and after evaluation of (++a ? 0 : 0) (my best guess)? If so, please note that extra parentheses do not import extra sequence points; the C standard only guarantees that there is a sequence point between the evaluations of the first and the second (or third) operands of the conditional operator. And what confuses me is that the first expression seems to have all the sequence points that the second have, plus another one between the evaluation of argument and the function call, but is said to be undefined.
[Bug libstdc++/53115] [4.7/4.8 Regression] _Hashtable::_M_rehash_aux(false_type) is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53115 --- Comment #3 from Timothy Tenebekov 2012-04-25 14:55:33 UTC --- I got this revision of bits/hashtable.h while upgrading gcc to version 4.7.0 on Debian using http://packages.dotdeb.org repository.
[Bug middle-end/53089] [4.8 Regression] gfortran.dg/coarray/atomic_1.f90 and gfortran.dg/coarray/registering_1.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53089 --- Comment #4 from Jan Hubicka 2012-04-25 14:54:35 UTC --- Author: hubicka Date: Wed Apr 25 14:54:21 2012 New Revision: 186820 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186820 Log: PR middle-end/53089 * cgraphunit.c (referred_to_p): Move ahead in file to avoid forward declaration. (cgraph_finalize_function): Finalize them here. * symtab.c (dump_symtab): Dump ctors and dtors. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/symtab.c
[Bug c++/53116] protected member access from derived template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53116 --- Comment #2 from Paolo Carlini 2012-04-25 14:47:02 UTC --- Are you sure this issue isn't a duplicate? We have a couple of rather old PRs in this area (access control vs templates)
[Bug middle-end/53106] [4.8 Regression] Benchmarks in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53106 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|UNCONFIRMED Ever Confirmed|1 |0 --- Comment #5 from H.J. Lu 2012-04-25 14:38:47 UTC --- On Linux/x86-64, with -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin 403.gcc, 483.xalancbmk, 447.dealII, 453.povray, 454.calculix and 465.tonto fail with similar error message.
[Bug fortran/51267] loop optimization error using LOC function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267 Oliver changed: What|Removed |Added CC||godeezy at gmail dot com --- Comment #9 from Oliver 2012-04-25 14:37:08 UTC --- Is there any progress with this? The issue persists with gcc 4.7.0 final and the workaround with -fno-tree-dse stopped working.
[Bug libstdc++/53115] [4.7/4.8 Regression] _Hashtable::_M_rehash_aux(false_type) is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53115 Paolo Carlini changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-25 Version|4.7.0 |4.7.1 Target Milestone|--- |4.7.1 Summary|_Hashtable::_M_rehash_aux(f |[4.7/4.8 Regression] |alse_type) is broken|_Hashtable::_M_rehash_aux(f ||alse_type) is broken Ever Confirmed|0 |1 Severity|critical|normal --- Comment #2 from Paolo Carlini 2012-04-25 14:36:19 UTC --- But to be clear, this is a 4.7.1 *not* 4.7.0 issue. The released 4.7.0 is not affected, we can fix the issue in time for 4.7.1.
[Bug middle-end/53106] [4.8 Regression] Benchmarks in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53106 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-25 AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Jan Hubicka 2012-04-25 14:34:15 UTC --- Thanks for the testcase!
[Bug libstdc++/53115] _Hashtable::_M_rehash_aux(false_type) is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53115 Paolo Carlini changed: What|Removed |Added CC||fdumont at gcc dot gnu.org --- Comment #1 from Paolo Carlini 2012-04-25 14:30:49 UTC --- Francois, can you have a look ASAP? The issue seems pretty serious. Thanks.
[Bug c++/53116] protected member access from derived template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53116
mattipee at yahoo dot co.uk changed:
What|Removed |Added
CC||mattipee at yahoo dot co.uk
--- Comment #1 from mattipee at yahoo dot co.uk 2012-04-25 14:28:47 UTC ---
With "int main() { Di<1>().k(); }":
bad.cpp: In instantiation of ‘void Di::k() [with int size = 1]’:
bad.cpp:32:15: required from here
bad.cpp:4:10: error: ‘void B::f()’ is protected
void f();
^
bad.cpp:24:9: error: within this context
static_cast(this)->f(); // no error here, BUG
^
[Bug target/53117] missed-optimization: worse code for 'x <= 0' compared to 'x < 0'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53117 Richard Guenther changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-25 Component|rtl-optimization|target Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-04-25 14:28:09 UTC --- Confirmed.
[Bug tree-optimization/52979] [4.7/4.8 Regression] likely wrong code bug w/packed bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52979 --- Comment #9 from Jakub Jelinek 2012-04-25 14:27:15 UTC --- Author: jakub Date: Wed Apr 25 14:27:08 2012 New Revision: 186819 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186819 Log: PR middle-end/52979 * stor-layout.c (get_best_mode): Don't return mode with bitsize larger than maxbits. Don't compute maxbits modulo align. Also check that unit bytes long store at bitpos / unit * unit doesn't affect bits beyond bitregion_end. * expmed.c (store_bit_field_1): Avoid trying insv if OP_MODE MEM would not fit into bitregion_start ... bitregion_end + 1 bit region. (store_split_bit_field): Decrease unit close to end of bitregion_end if access is restricted in order to avoid mutual recursion. * gcc.c-torture/compile/pr52979-1.c: New test. * gcc.c-torture/execute/pr52979-1.c: New test. * gcc.c-torture/execute/pr52979-2.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr52979-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr52979-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr52979-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c trunk/gcc/stor-layout.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/53117] missed-optimization: worse code for 'x <= 0' compared to 'x < 0'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53117 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek 2012-04-25 14:25:51 UTC --- So, what are you proposing? Testing of flags after the subtraction from memory can't be used in the first case...
[Bug rtl-optimization/53117] New: missed-optimization: worse code for 'x <= 0' compared to 'x < 0'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53117
Bug #: 53117
Summary: missed-optimization: worse code for 'x <= 0' compared
to 'x < 0'
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vermaelen.wou...@gmail.com
void f1(int* p) {
p[1] -= 5;
if (p[1] < 0) p[2] += 3;
}
void f2(int* p) {
p[1] -= 5;
if (p[1] <= 0) p[2] += 3;
}
The only difference between f1() and f2() is the comparison ('<' vs '<='). On
x86_64 (and x86) gcc revision trunk@186808 generates more efficient code for
f1() than for f2(). Here's the assembler output when compiled with -Os (but -O2
and -O3) show a similar difference:
<_Z2f1Pi>:
0: 83 6f 04 05 subl $0x5,0x4(%rdi)
4: 79 04 jnsa <_Z2f1Pi+0xa>
6: 83 47 08 03 addl $0x3,0x8(%rdi)
a: c3 retq
000b <_Z2f2Pi>:
b: 8b 47 04mov0x4(%rdi),%eax
e: 83 e8 05sub$0x5,%eax
11: 85 c0 test %eax,%eax
13: 89 47 04mov%eax,0x4(%rdi)
16: 7f 04 jg 1c <_Z2f2Pi+0x11>
18: 83 47 08 03 addl $0x3,0x8(%rdi)
1c: c3 retq
gcc-4.6.1 generates the less efficient variant for both functions.
[Bug c++/53116] New: protected member access from derived template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53116
Bug #: 53116
Summary: protected member access from derived template
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lex4...@gmail.com
According to "11.4 Protected member access" part of C++11 standard, member
function of derived class has no access to protected member of base class
through pointer to member class. In example below, we have base class "B",
derived classes D and Di. Either of them has access to B::f() through "this",
it is OK. D has not access through "B *" pointer, it is OK. But Di has access
through "B *" and it is a bug. The only difference between D and Di that Di is
template class.
I have tested it with "template " template declaration, behavior is
the same.
Example:
class B
{
protected:
void f();
};
class D: public B
{
public:
void k()
{
f(); // this->f(), no error, OK
//static_cast(0)->f(); // error here, OK
}
};
template
class Di: public B
{
public:
void k()
{
f(); // this->f(), no error, OK
static_cast(0)->f(); // no error here, BUG
}
private:
int m_field[size];
};
int main() {}
[Bug libstdc++/53115] New: _Hashtable::_M_rehash_aux(false_type) is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53115
Bug #: 53115
Summary: _Hashtable::_M_rehash_aux(false_type) is broken
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tat...@mail.ru
Function _Hashtable::_M_rehash_aux, added in rev. libstdc++/52476, is broken
for not unique keys (unordered_multiset and unordered_multimap).
Scheduled checking after series of equal elements is performed after inserting
of next different element. This can lead to invalid bucket links and broken
equal_range/count.
Below is simple example that demonstrates this bug.
#include
#include
typedef std::unordered_multiset TMap;
int main()
{
TMap x;
x.insert(10);
x.insert(10);
x.insert(10);
x.insert(10);
x.insert(10);
x.insert(24);
x.insert(25);
x.insert(2);
x.insert(2);
x.insert(1);
printf("count=%u\n", x.count(2));
x.insert(10);
printf("count=%u\n", x.count(2));
return 0;
}
Output is:
count=2
count=0
[Bug fortran/53086] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53086 Richard Guenther changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Comment #14 from Richard Guenther 2012-04-25 13:57:06 UTC --- Thus, invalid. -std=legacy support would be an enhacement request (tracked separately please) 416.gamess still works with LTO which merges the decls properly and papers over the issue.
[Bug tree-optimization/53114] Extra load store/instructions compared to gcc-3.4 on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53114 --- Comment #3 from Alexey Kravets 2012-04-25 13:37:02 UTC --- Created attachment 27239 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27239 Assembly generated by GCC-3.4.6
[Bug tree-optimization/53114] Extra load store/instructions compared to gcc-3.4 on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53114 --- Comment #2 from Alexey Kravets 2012-04-25 13:36:35 UTC --- Created attachment 27238 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27238 Assembly generated by GCC-4.6.3
[Bug tree-optimization/53114] Extra load store/instructions compared to gcc-3.4 on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53114 --- Comment #1 from Alexey Kravets 2012-04-25 13:35:47 UTC --- Created attachment 27237 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27237 Assembly generated by ARMCC
[Bug tree-optimization/53114] New: Extra load store/instructions compared to gcc-3.4 on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53114 Bug #: 53114 Summary: Extra load store/instructions compared to gcc-3.4 on ARM Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: mr.kayr...@gmail.com Created attachment 27236 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27236 Shell sort function Hi guys, I have a test case (shell sort, see attached) compiled with different ARM compilers: GCC-4.6.3, GCC-3.4.6, and ARMCC. Both ARMCC and GCC-3.4.6 generate quite optimal assembly while GCC-4.6.3 inserts extra load/store instructions compared to the other compilers. Can the SSA representation usage in modern GCC be the reason for this? If so, has anyone tried to do something about it? % armcc ARM C/C++ Compiler, 4.1 [Build 713] The file has been compiled with following options: for GCC: -O3 for ARMCC: -O3 -Otime
[Bug fortran/53086] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53086 --- Comment #13 from Steve Kargl 2012-04-25 13:32:26 UTC --- On Wed, Apr 25, 2012 at 06:46:03AM +, burnus at gcc dot gnu.org wrote: > > Thus, the -fcheck=bounds error seems to be appropriate. The question is what > we > do about x(2). While it is invalid, it seems to be used. As the Fortran FE > knows that the last item in a given common block is an array element, it could > change the middle-end decl to "[1:]". This is probably a candidate for -std=legacy. > > (I have not yet checked the exact wording in the Fortran 66 to 2008 > standards.) > I've already quoted the F77 and F03 text. Here's F66: The size of a common block in a program unit is the sum of the storage required for the the elements introduced through COMMON and EQUIVALENCE statements. The sizes of labeled common blocks with the same label in the program units that comprise an executable program must be the same. The sizes of blank common in the various program units that are to be executed together need not be the same. Size is measured in terms of storage units (7.2.1.3.1). The code is invalid. Someone with access to SPEC 200humble should complain loudly about invalid code in their benchmark.
[Bug target/53110] GCC-4.7 generates stupid x86_64 asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53110 --- Comment #8 from peterz at infradead dot org 2012-04-25 13:15:56 UTC --- Jakub's patch seems to improve the situation: --- gcc-bug-4.7.s 2012-04-25 14:58:21.494815266 +0200 +++ gcc-bug-4.7+.s 2012-04-25 15:14:13.784243427 +0200 @@ -22,12 +22,12 @@ .cfi_startproc movq%rdi, %r8 movq%rsi, %r9 - andl$4294967295, %esi + movl%esi, %esi shrq$32, %r9 shrq$32, %r8 movq%rsi, %rdx imulq %r8, %rdx - andl$4294967295, %edi + movl%edi, %edi movq%r9, %rax imulq %rdi, %rax imulq %r9, %r8
[Bug target/53110] GCC-4.7 generates stupid x86_64 asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53110 --- Comment #7 from Jakub Jelinek 2012-04-25 13:02:26 UTC --- Created attachment 27235 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27235 gcc48-pr53110.patch Totally untested patch. We already have a splitter to handle and by 0x, 0x and 0xff, but it only triggers if the register is different and IMHO it is quite late anyway. This attempts to optimize this already during expansion, perhaps giving the register allocator more freedom (unfortunately it doesn't seem to improve the code in this case and the movl %edi, %edi (and for %esi too) stays. Ideally if RA swapped the two, it could movl %edi, %r8d and shrl $32, %rdi instead of movq %rdi, %r8; shrl $32, %r8; movl %edi, %edi).
[Bug target/53110] GCC-4.7 generates stupid x86_64 asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53110 --- Comment #6 from peterz at infradead dot org 2012-04-25 13:00:47 UTC --- OK rectification, that's what it _should_ compute, I just noticed add_u128() is missing: a.hi += b.hi; Anyway, that's all besides the point, the issue is that gcc shouldn't generate those andl 0x, %r thingies, regardless if the C makes sense or not.
[Bug fortran/53111] [4.7/4.8 Regression] Derived types cannot be USE-associated again with -std=f95
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53111 Tobias Burnus changed: What|Removed |Added Keywords||rejects-valid CC||burnus at gcc dot gnu.org Target Milestone|--- |4.7.1 Summary|[4.7/4.8 Regression]|[4.7/4.8 Regression] |Derived types cannot be |Derived types cannot be |included again with |USE-associated again with |-std=f95|-std=f95
[Bug target/53087] [powerpc] Poor code from cstore expander
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53087 Alan Modra changed: What|Removed |Added CC||bonzini at gnu dot org --- Comment #8 from Alan Modra 2012-04-25 12:58:17 UTC --- The regression appeared with r149032 2009-06-28 Paolo Bonzini * expr.c (expand_expr_real_1): Just use do_store_flag. (do_store_flag): Drop support for TRUTH_NOT_EXPR. Use emit_store_flag_force. * expmed.c (emit_store_flag_force): Copy here trick previously in expand_expr_real_1. Try reversing the comparison. (emit_store_flag_1): Work if target is NULL. (emit_store_flag): Work if target is NULL, using the result mode from the comparison. Use split_comparison, restructure final part to simplify conditionals.
[Bug target/53110] GCC-4.7 generates stupid x86_64 asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53110 --- Comment #5 from peterz at infradead dot org 2012-04-25 12:47:31 UTC --- Yes that's what it computes.. and no the function won't ever get used on x86_64, but I ran it through the compiler anyway :-) Thing is we need u128 to work on all archs linux supports on all gcc version we support, so we can't use __int128. Anyway, if you're interested in what we're doing and want to see the current patches click: https://lkml.org/lkml/2012/4/25/149
[Bug target/53110] GCC-4.7 generates stupid x86_64 asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53110
--- Comment #4 from Richard Guenther 2012-04-25
12:35:08 UTC ---
I'm not sure what the function computes, but for
u128 mult_u128(u64 a, u64 b)
{
u128 t1;
__uint128_t r = (__uint128_t)a * (__uint128_t)b;
memcpy (&t1, &r, sizeof (u128));
return t1;
}
we generate
mult_u128:
.LFB1:
.cfi_startproc
movq%rsi, %rax
mulq%rdi
movq%rax, -56(%rsp)
movq%rdx, -48(%rsp)
movq-48(%rsp), %rdx
ret
[Bug middle-end/53089] [4.8 Regression] gfortran.dg/coarray/atomic_1.f90 and gfortran.dg/coarray/registering_1.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53089 --- Comment #3 from Jan Hubicka 2012-04-25 12:34:18 UTC --- OK, the problem here is that Fortran produces nested functions that are static constructors and we are not quite ready for that. I am testing fix. Honza
[Bug fortran/45521] [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521
--- Comment #13 from janus at gcc dot gnu.org 2012-04-25 12:29:55 UTC ---
(In reply to comment #12)
> > For for former, we clearly need to add a check in 'compare_parameter' to
> > reject it
Actually, we do have a check for this already, which is just not working in
some cases. Therefore the patch in comment #12 is not the right thing to do.
Here is a better one (which is actually free of testsuite regressions):
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(revision 186596)
+++ gcc/fortran/interface.c(working copy)
@@ -2393,9 +2397,8 @@ compare_actual_formal (gfc_actual_arglist **ap, gf
/* Satisfy 12.4.1.2 by ensuring that a procedure actual argument is
provided for a procedure formal argument. */
- if (a->expr->ts.type != BT_PROCEDURE && !gfc_is_proc_ptr_comp (a->expr,
NULL)
- && a->expr->expr_type == EXPR_VARIABLE
- && f->sym->attr.flavor == FL_PROCEDURE)
+ if (f->sym->attr.flavor == FL_PROCEDURE
+ && gfc_expr_attr (a->expr).flavor != FL_PROCEDURE)
{
if (where)
gfc_error ("Expected a procedure for argument '%s' at %L",
Cleanup side note: A lot of the stuff in 'compare_actual_formal' could probably
be moved into 'compare_parameter'. It does not really make a difference, but
the distinction of what goes where seems completely arbitrary right now.
[Bug libitm/53113] New: Build fails in x86_avx.cc if AVX disabled but supported by as (Solaris & Linux)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113 Bug #: 53113 Summary: Build fails in x86_avx.cc if AVX disabled but supported by as (Solaris & Linux) Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libitm AssignedTo: unassig...@gcc.gnu.org ReportedBy: windw...@gmx.com 4.7.0 fails to bootstrap on x86_64 (tested on Solaris 10 and CentOS 5.5) if the CPU doesn't support AVX (Xeon E5420) but the assembler (GNU as 2.22) does. For campatibility reasons I'm using "-march=core2", and GCC 4.6.3 builds without any problem with the same build script. checking whether /opt/SP/build/gcc/gcc-4.7.0/host-x86_64-unknown-linux-gnu/gcc/xgcc -B/opt/SP/build/gcc/gcc-4.7.0/host-x86_64-unknown-linux-gnu/gcc/ -B/opt/SP/gcc/gcc-4.7.0/x86_64-unknown-linux-gnu/bin/ -B/opt/SP/gcc/gcc-4.7.0/x86_64-unknown-linux-gnu/lib/ -isystem /opt/SP/gcc/gcc-4.7.0/x86_64-unknown-linux-gnu/include -isystem /opt/SP/gcc/gcc-4.7.0/x86_64-unknown-linux-gnu/sys-include -m32 and cc understand -c and -o together... ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â does not name a type ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â does not name a type ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â does not name a type ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â does not name a type ../.././libitm/config/x86/x86_avx.cc:83:1: error: variable or field â_ITM_WM256â declared void ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:83:1: error: âptrâ was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:83:1: error: variable or field â_ITM_WaRM256â declared void ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:83:1: error: âptrâ was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:83:1: error: variable or field â_ITM_WaWM256â declared void ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:83:1: error: âptrâ was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:83:1: error: â_ITM_TYPE_M256â was not declared in this scope ../.././libitm/config/x86/x86_avx.cc:86:19: error: â_ITM_TYPE_M256â does not name a type ../.././libitm/config/x86/x86_avx.cc:86:35: error: ISO C++ forbids declaration of âptrâ with no type [-fpermissive] gmake[4]: *** [x86_avx.lo] Error 1 gmake[4]: Leaving directory `/opt/SP/build/gcc/gcc-4.7.0/x86_64-unknown-linux-gnu/libitm' I'm not a programmer, but on a first look the declaration of _ITM_TYPE_M256 seems to be missing if __AVX__ is not set, but HAVE_AS_AVX: ./libitm/libitm.h # ifdef __AVX__ typedef float _ITM_TYPE_M256 __attribute__((vector_size(32), may_alias)); ITM_BARRIERS(M256) ITM_LOG(M256) # endif ./libitm/config/x86/x86_avx.cc #ifndef HAVE_AS_AVX // If we don't have an AVX capable assembler, we didn't set -mavx on the // command-line either, which means that libitm.h defined neither this type // nor the functions in this file. Define the type and unconditionally // wrap the file in extern "C" to make up for the lack of pre-declaration. typedef float _ITM_TYPE_M256 __attribute__((vector_size(32), may_alias)); #endif But simply adding the definition (if defined(__AVX__) || defined(HAVE_AS_AVX)) just leads to an "avx vector argument without avx enabled changes the abi" error. As said above, I'm not a programmer. Adding "-mno-avx" does not change anything. I would expect AVX to be completely disabled if CPU and target architecture do not support it?
[Bug c++/39970] gcc accepts the . dot operator in template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39970 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot |com |gnu.org --- Comment #4 from Paolo Carlini 2012-04-25 12:08:54 UTC --- Not actively working on this.
[Bug bootstrap/53112] New: Fails at Configuring stage 1 in sparc64-sun-solaris2.10/libgcc: error: cannot compute suffix of object files: cannot compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53112 Bug #: 53112 Summary: Fails at Configuring stage 1 in sparc64-sun-solaris2.10/libgcc: error: cannot compute suffix of object files: cannot compile Classification: Unclassified Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: birender.si...@hotmail.com 1. Machine Deatils: bash-3.00# uname -a SunOS slimsol10t1 5.10 Generic_118822-25 sun4u sparc SUNW,Sun-Fire-V240 bash-3.00# cat /etc/release Solaris 10 1/06 s10s_u1wos_19a SPARC Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 07 December 2005 2. Following are the PATH setting done on system: bash-3.00# echo $PATH /els/install/biru/local/find4/bin:/els/install/biru/local/tar-1.12-bin/bin:/els/install/jdk1.6.0_16/bin/:/els/install/gcc-3.4.5_64/bin:/els/install/staf64/bin:/els/install/staf64/services/STAFHTTP.jar:/usr/local/bin:/usr/ccs/bin:/usr/sbin:/usr/bin:/usr/openwin/bin:/usr/dt/bin:/usr/platform/SUNW,Sun-Fire-V240/sbin:/opt/VRTS/bin:/etc/vx/bin:/opt/SUNWexplo/bin:/opt/SUNWsneep/bin::/usr/local/staf/lib/:/els/install/staf/lib:/usr/bin/:/usr/xpg4/bin:/usr/sfw/bin:/usr/dt/bin: bash-3.00# echo $LD_LIBRARY_PATH /usr/sfw/lib:/usr/local/lib:/usr/ccs/lib:/els/install/gcc-3.4.5_64/lib:/els/install/jdk1.6.0_16/jre/lib/sparc/:/els/install/jdk1.6.0_16/jre/lib/sparc/client:/els/install/staf64/lib:/els/install/staf64/lib/JSTAF.zip:/els/install/staf64/lib/JSTAF.jar:/els/install/staf64/services/STAFHTTP.jar 3. Trying to build GCC-4.4.4 in 64 bit, Downloaded gcc-4.4.4.tar.gz and extarcted and configured as below: ../gcc-4.4.4/configure CC='gcc -m64' --prefix=/els/install/biru/local/gcc4_64 --build=sparc64-sun-solaris2.10 --with-gmp=/els/install/biru/local/gmp_64 --with-mpfr=/els/install/biru/local/mpfr_64 Configured successfuly. 4. extectued make and below error received. make[3]: Leaving directory `/els/install/biru/gcc4_64/obj/gcc' mkdir sparc64-sun-solaris2.10/libgcc Checking multilib configuration for libgcc... Configuring stage 1 in sparc64-sun-solaris2.10/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /els/install/biru/gcc4_64/gcc-4.4.4/install-sh -c checking for gawk... no checking for mawk... no checking for nawk... nawk checking build system type... sparc64-sun-solaris2.10 checking host system type... sparc64-sun-solaris2.10 checking for sparc64-sun-solaris2.10-ar... ar checking for sparc64-sun-solaris2.10-lipo... lipo checking for sparc64-sun-solaris2.10-nm... /els/install/biru/gcc4_64/obj/./gcc/nm checking for sparc64-sun-solaris2.10-ranlib... ranlib checking for sparc64-sun-solaris2.10-strip... strip checking whether ln -s works... yes checking for sparc64-sun-solaris2.10-gcc... /els/install/biru/gcc4_64/obj/./gcc/xgcc -B/els/install/biru/gcc4_64/obj/./gcc/ -B/els/install/biru/local/gcc4_64/sparc64-sun-solaris2.10/bin/ -B/els/install/biru/local/gcc4_64/sparc64-sun-solaris2.10/lib/ -isystem /els/install/biru/local/gcc4_64/sparc64-sun-solaris2.10/include -isystem /els/install/biru/local/gcc4_64/sparc64-sun-solaris2.10/sys-include checking for suffix of object files... configure: error: in `/els/install/biru/gcc4_64/obj/sparc64-sun-solaris2.10/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage1-target-libgcc] Error 1 make[2]: Leaving directory `/els/install/biru/gcc4_64/obj' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/els/install/biru/gcc4_64/obj' make: *** [all] Error 2 bash-3.00# Kindly please provide the solution for the above error. Regards, -BK
[Bug tree-optimization/53058] [4.8 Regression] Another ice in remove_range_assertions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53058 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek 2012-04-25 11:51:00 UTC --- Fixed.
[Bug fortran/53111] [4.7/4.8 Regression] Derived types cannot be included again with -std=f95
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53111 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-25 CC||janus at gcc dot gnu.org Summary|Derived types cannot be |[4.7/4.8 Regression] |included again when using |Derived types cannot be |standard Fortran 95 |included again with ||-std=f95 Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2012-04-25 11:41:43 UTC --- Confirmed. This is a regression in gfortran 4.7 (and trunk, 4.6 works). Slightly reduced test case: module a type :: my real :: x end type end module module b use a end module program test use a use b end program
[Bug c/52880] -Woverride-init emitts unexpected error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52880 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #5 from Jakub Jelinek 2012-04-25 11:38:45 UTC --- Fixed for 4.7+.
[Bug tree-optimization/53058] [4.8 Regression] Another ice in remove_range_assertions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53058 --- Comment #5 from Jakub Jelinek 2012-04-25 11:35:43 UTC --- Author: jakub Date: Wed Apr 25 11:35:38 2012 New Revision: 186816 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186816 Log: PR tree-optimization/53058 * double-int.h (double_int_max_value, double_int_min_value): New prototypes. * double-int.c (double_int_max_value, double_int_min_value): New functions. * tree-vrp.c (register_edge_assert_for_2): Compare mask for LE_EXPR or GT_EXPR with double_int_max_value instead of double_int_mask. * gcc.c-torture/compile/pr53058.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr53058.c Modified: trunk/gcc/ChangeLog trunk/gcc/double-int.c trunk/gcc/double-int.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug middle-end/53088] [4.8 Regression] gcc.target/i386/pr39082-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53088 --- Comment #6 from Jan Hubicka 2012-04-25 11:31:47 UTC --- Author: hubicka Date: Wed Apr 25 11:31:42 2012 New Revision: 186815 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186815 Log: PR middle-end/53088 * gcc.target/i386/pr39082-1.c: Update warning location. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr39082-1.c
[Bug target/53110] GCC-4.7 generates stupid x86_64 asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53110 Markus Trippelsdorf changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #3 from Markus Trippelsdorf 2012-04-25 11:23:59 UTC --- For comparison this is what clang generates: .file "gcc-bug.c" .text .globl mult_u128 .align 16, 0x90 .type mult_u128,@function mult_u128: # @mult_u128 .cfi_startproc # BB#0: movabsq $-4294967296, %rdx # imm = 0x andq%rdi, %rdx movl%esi, %ecx movq%rdi, %rax shrq$32, %rax shrq$32, %rsi imulq %rsi, %rax imulq %rcx, %rdx imull %edi, %esi shlq$32, %rsi addq%rdx, %rsi adcq$0, %rax movl%edi, %edx imulq %rcx, %rdx addq%rsi, %rdx adcq$0, %rax ret .Ltmp0: .size mult_u128, .Ltmp0-mult_u128 .cfi_endproc .section".note.GNU-stack","",@progbits
[Bug middle-end/53088] [4.8 Regression] gcc.target/i386/pr39082-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53088 --- Comment #5 from Jan Hubicka 2012-04-25 11:21:52 UTC --- Hmm, after some playing with this, I don't really know how to make the warning output right all the time. To fix the regression I will simply update the testcase. The warning now goes on different place because of different gimplification order. We used to first gimplify the call. Now we first gimplify the function and warn on its declaration. It is not bad and the input_location is correctly initialized by cgraph. I do not get any confused carret: a.c: In function 'foo1': a.c:16:1: note: the ABI of passing union with long double has changed in GCC 4.4 foo1 (union un u) ^
[Bug target/53110] GCC-4.7 generates stupid x86_64 asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53110 --- Comment #2 from peterz at infradead dot org 2012-04-25 11:11:19 UTC --- I'll have to let Linus and Peter Anvin argue this (they're on CC), this report is the direct result of their complaints: "If you can *ever* get gcc to generate those andl instructions on x86, then please file a gcc bug report: the constant is 0x and those are plain zero-extension instructions which is much better done with mov." https://lkml.org/lkml/2012/4/24/524 "What insane version of gcc is that? Can you please make a gcc bug-report?" https://lkml.org/lkml/2012/4/24/549 I'm just the sorry sod who wrote the code... :-)
[Bug middle-end/53103] bug locating unsigned type for non-standard precision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53103 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-25 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-04-25 11:08:45 UTC --- Confirmed. All callers of type_for_size need to be audited for this case.
[Bug tree-optimization/53105] Segmentation fault in is_gimple_min_invariant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53105 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |tree-optimization Resolution||FIXED --- Comment #1 from Richard Guenther 2012-04-25 11:07:22 UTC --- I cannot reproduce this, I believe it was fixed with 2012-04-22 Jan Hubicka * tree-ssa-loop-ivopts.c (expr_invariant_in_loop_p): Bail out at NULL tree refs.
[Bug middle-end/53106] [4.8 Regression] Benchmarks in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53106 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug target/53110] GCC-4.7 generates stupid x86_64 asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53110 Richard Guenther changed: What|Removed |Added Component|c |target --- Comment #1 from Richard Guenther 2012-04-25 11:03:55 UTC --- movq%rdi, %r8 movq%rsi, %rcx andl$4294967295, %edi I'm not sure it's pointless - %rdi contains a 64bit value and we want to access the zero-extended %rdi later: imulq%rdi, %rcx it could have used a move to another register which implicitely zero-extends or maybe a zero-extension on the same register (if that exists). The and is only 3 bytes in size. A mov %edi, %edi is 2 bytes but I'm not sure that implicitely zero-extends.
