[Bug target/52323] New: i386: gcse runs amok with pic-addresses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52323 Bug #: 52323 Summary: i386: gcse runs amok with pic-addresses Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: kaffeemons...@googlemail.com I have here some very bad interaction between gcse and pic addresses on i386. The attached testcase (yes, i know, it's not a beauty, could prop. be reduces some more) compiled by: gcc-4.6.2 -Wall -O1 -fpic -S gcse_amok.c -o gcse_amok.s creates roughly this code: to_base32_BMI2: .LFB1: .cfi_startproc pushl%ebp .cfi_def_cfa_offset 8 .cfi_offset 5, -8 pushl%edi .cfi_def_cfa_offset 12 .cfi_offset 7, -12 pushl%esi .cfi_def_cfa_offset 16 .cfi_offset 6, -16 pushl%ebx .cfi_def_cfa_offset 20 .cfi_offset 3, -20 call__i686.get_pc_thunk.bx addl$_GLOBAL_OFFSET_TABLE_, %ebx movl20(%esp), %eax movl24(%esp), %edx movl28(%esp), %ecx cmpl$4, %ecx jbe.L2 .L4: movl(%edx), %esi bswap%esi movl%esi, %edi shrl$12, %edi #APP # 19 gcse_amok.c 1 pdep 64+vals@GOTOFF(%ebx), %edi, %edi # 0 2 #NO_APP movzbl4(%edx), %ebp sall$8, %esi orl%ebp, %esi #APP # 20 gcse_amok.c 1 pdep 64+vals@GOTOFF(%ebx), %esi, %esi # 0 2 #NO_APP bswap%edi bswap%esi #APP # 25 gcse_amok.c 1 movd%edi, %xmm0 pinsrd$1, %esi, %xmm0 paddb80+vals@GOTOFF(%ebx), %xmm0 movdqa%xmm0, %xmm1 pcmpgtb96+vals@GOTOFF(%ebx), %xmm1 pand112+vals@GOTOFF(%ebx), %xmm1 psubb%xmm1, %xmm0 movq%xmm0, (%eax) # 0 2 #NO_APP addl$8, %eax addl$5, %edx subl$5, %ecx cmpl$4, %ecx ja.L4 ... If -fgcse (like in -O2) gets added to the command line, things get ugly: gcc-4.6.2 -Wall -O1 -fpic -fgcse -S gcse_amok.c -o gcse_amok.s results in: to_base32_BMI2: .LFB1: .cfi_startproc pushl%ebp .cfi_def_cfa_offset 8 .cfi_offset 5, -8 pushl%edi .cfi_def_cfa_offset 12 .cfi_offset 7, -12 pushl%esi .cfi_def_cfa_offset 16 .cfi_offset 6, -16 pushl%ebx .cfi_def_cfa_offset 20 .cfi_offset 3, -20 subl$36, %esp .cfi_def_cfa_offset 56 call__i686.get_pc_thunk.bx addl$_GLOBAL_OFFSET_TABLE_, %ebx movl56(%esp), %eax movl60(%esp), %edx movl64(%esp), %ecx cmpl$4, %ecx jbe.L2 leal64+vals@GOTOFF, %edi leal80+vals@GOTOFF, %esi movl%esi, 32(%esp) leal96+vals@GOTOFF, %ebp movl%ebp, 28(%esp) leal112+vals@GOTOFF, %esi movl%esi, 24(%esp) movl%eax, 8(%esp) movl%edx, (%esp) movl%ecx, 4(%esp) movl%edi, 12(%esp) .L3: movl(%esp), %edi movl(%edi), %esi bswap%esi movl%esi, %edi shrl$12, %edi movl12(%esp), %eax #APP # 19 gcse_amok.c 1 pdep (%eax,%ebx), %edi, %edi # 0 2 #NO_APP movl(%esp), %edx movzbl4(%edx), %eax sall$8, %esi orl%eax, %esi movl12(%esp), %ecx #APP # 20 gcse_amok.c 1 pdep (%ecx,%ebx), %esi, %esi # 0 2 #NO_APP bswap%edi bswap%esi movl8(%esp), %eax movl32(%esp), %edx movl28(%esp), %ecx movl24(%esp), %ebp #APP # 25 gcse_amok.c 1 movd%edi, %xmm0 pinsrd$1, %esi, %xmm0 paddb(%edx,%ebx), %xmm0 movdqa%xmm0, %xmm1 pcmpgtb(%ecx,%ebx), %xmm1 pand0(%ebp,%ebx), %xmm1 psubb%xmm1, %xmm0 movq%xmm0, (%eax) # 0 2 #NO_APP addl$8, %eax movl%eax, 8(%esp) addl$5, (%esp) subl$5, 4(%esp) cmpl$4, 4(%esp) ja.L3 ... Later passes (-O2, -O3) only make things worse or can not recover from this. For some reason gcse tries to hoist the constant address-offsets out the loop. this needs a bunch of register, which i386 does not have, and so the spilling begins... GCC 4.5.3 does not even compile it $ gcc-4.5.3 -Wall -O1 -fpic -fgcse -S -o gcse_amok.s gcse_amok.c gcse_amok.c: In function 'to_base32_BMI2': gcse_amok.c:25:2: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' gcse_amok.c:19:2: error: 'asm' operand has impossible constraints gcse_amok.c:20:2: error: 'asm' operand has impossible constraints gcse_amok.c:25:2: error: 'asm' operand has impossible constraints without gcse, no problem: $ gcc -Wall -O1 -fpic -S -o gcse_amok.s gcse_amok.c $ echo $? 0 I do not really know which component this is, but i guess it is a target problem, the low costs for more complicated addressing modes on x86 (so the compiler generates them at all)
[Bug target/52323] i386: gcse runs amok with pic-addresses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52323 --- Comment #1 from Jan Seiffert kaffeemonster at googlemail dot com 2012-02-21 08:15:19 UTC --- Created attachment 26709 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26709 Testcase exposing gcse hyperactivity with pic on i386 the testcase *mumbel mumbel* that the description field is mandatory could be made more visible...
[Bug c++/52320] missing destructor call after thrown exception in initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52320
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC||daniel.kruegler at
||googlemail dot com
--- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com
2012-02-21 08:26:30 UTC ---
Confirmed for 4.7.0 20120218 (experimental).
Reduced example with added information:
//
#include iostream
#define FUNCTION_NAME __PRETTY_FUNCTION__
#define TRACE_FUNCTION(I) { std::cout this - FUNCTION_NAME ; i
= I std::endl; }
struct A {
int i;
A(int i) : i(i) { TRACE_FUNCTION(i); }
A(const A rhs) : i(rhs.i) { TRACE_FUNCTION(i); }
A operator=(const A rhs) { i = rhs.i; TRACE_FUNCTION(i); return *this; }
~A() { TRACE_FUNCTION(i); }
};
struct Y {
A e1[2];
};
int main() {
try {
Y y1[1] = { {{1, (throw 0, 2)} } };
} catch (int) {
}
}
//
Observed output is:
0x22fd60-A::A(int); i = 1
It does not happen when the local array y1 is replaced by a non-array Y.
[Bug rtl-optimization/52323] i386: gcse runs amok with pic-addresses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52323 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||ra Component|target |rtl-optimization --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-21 08:38:04 UTC --- Is there a reason why you are using inline-asm here, rather than the intrinsics?
[Bug middle-end/52316] Loops with floating-point iteration variables not optimized away, though result is not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52316 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org Summary|Loops not optimized away, |Loops with floating-point |though result is not used |iteration variables not ||optimized away, though ||result is not used --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-21 08:50:57 UTC --- (In reply to comment #1) Is it sufficiently common to do something that insane though? Well, seemingly, other vendors answer this question with yes. The loop is optimized away with pathf95, openf90, ifort and crayftn. Whether it is common? I don't know. Some problems can naturally be expressed with loops which use floating-point (FP) iteration variables (IV). Though, I assume that a simple FP count (r = r + 1.0) should be a bit rarer. The feature was seemingly popular enough that Fortran 77 introduced real/complex IV in DO loops. On the other hand, loops with FP IV are ill defined - and that's the presumably the reason why Fortran 90 has deleted the feature (FP IV in DO loops). But using WHILE/DO WHILE one can still use floating-point IV - as one can do in C/C++.
[Bug tree-optimization/52318] [4.7 Regression] ICE: in execute_todo, at passes.c:1748 with -O3 -ftracer -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce and stpcpy_chk()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52318 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-21 09:24:47 UTC --- Author: jakub Date: Tue Feb 21 09:24:42 2012 New Revision: 184428 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184428 Log: PR tree-optimization/52318 * gimple-fold.c (gimplify_and_update_call_from_tree): Add vdef also to non-pure/const call stmts in the sequence. * gcc.dg/pr52318.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr52318.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #15 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-02-21 09:30:11 UTC --- Created attachment 26710 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26710 patch reverting PR26632 I am testing this. It reverts PR26632 fix and ignores recurses into NOPs at the warning point. Do you see any potential issues?
[Bug tree-optimization/51782] -ftree-sra: Missing address-space information leads to wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #22 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-21 09:56:08 UTC --- btw, what's the right component for the PR? tree-optimization? middle-end?
[Bug testsuite/52297] [4.7 Regression] FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o link, -flto -fgnu-tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52297 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-21 10:13:57 UTC --- That's (essentially) independent of the target, as it's a pure testsuite issue. Tests that require linking with -litm should go in libitm/testsuite instead.
[Bug tree-optimization/52324] New: [4.7 Regression] Store motion no longer performed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52324
Bug #: 52324
Summary: [4.7 Regression] Store motion no longer performed
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
The following fails on trunk but works in 4.5 and 4.6.
/* { dg-do compile } */
/* { dg-options -O2 -fdump-tree-lim1-details } */
int *l, *r;
int test_func(void)
{
int i;
int direction;
static int pos;
pos = 0;
direction = 1;
for ( i = 0; i = 400; i++ )
{
if ( direction == 0 )
pos = l[pos];
else
pos = r[pos];
if ( pos == -1 )
{
pos = 0;
direction = !direction;
}
}
return i;
}
/* { dg-final { scan-tree-dump Executing store motion of pos lim1 } } */
/* { dg-final { cleanup-tree-dump lim1 } } */
[Bug tree-optimization/52324] [4.7 Regression] Store motion no longer performed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52324 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-21 Known to work||4.5.3, 4.6.2 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 Known to fail||4.7.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-21 10:16:32 UTC --- I have a patch.
[Bug fortran/52325] New: unclear error: Unclassifiable statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52325 Bug #: 52325 Summary: unclear error: Unclassifiable statement Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: kloe...@knmi.nl The given example code generates this error: unclassifiable.F90:9.4: cc%a = 1 1 Error: Unclassifiable statement at (1) while in fact it would be much more helpfull if the error would clearly state that the symbol is not yet defined (as the commented out lines do): unclassifiable.F90:16.5: d=1 1 Error: Symbol 'd' at (1) has no IMPLICIT type Especially in larger modules/programs having a clear error in case of this kind of variable naming msitakes/typos could save a lot of debugging time for gfortran users. Example code: module test_unclassifiable implicit none type test integer :: a end type test contains subroutine test_sub1(c) type(test), intent(out) :: c cc%a = 1 end subroutine test_sub1 ! subroutine test_sub2(c) !integer :: c !d=1 ! end subroutine test_sub2 end module test_unclassifiable
[Bug middle-end/51782] -ftree-sra: Missing address-space information leads to wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Component|tree-optimization |middle-end --- Comment #23 from Martin Jambor jamborm at gcc dot gnu.org 2012-02-21 10:35:58 UTC --- (In reply to comment #21) On Mon, 20 Feb 2012, jamborm at gcc dot gnu.org wrote: Perhaps get_base_address misses a DECL_P in the condition looking into MEM_REFs? No, sure not - in the above we have a component-ref inside the ADDR_EXPR. I know it's invalid, I just thought it would be better to return the MEM_REF rather than NULL_TREE anyway. Most of checks whether the zero argument is ADDR_EXPR are accompanied with a DECL_P of its argument check too (e.g. the new mem_ref_refers_to_non_mem_p). However, now I see we don't do it e.g. in get_ref_base_and_extent so I agree we should not do it in get_base_address either. (In reply to comment #22) btw, what's the right component for the PR? tree-optimization? middle-end? Yeah, I guess (and what it's worth, I'm changing the component to middle-end).
[Bug middle-end/51782] -ftree-sra: Missing address-space information leads to wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #24 from Martin Jambor jamborm at gcc dot gnu.org 2012-02-21 10:37:40 UTC --- Unfortunately, with the patch I got following new LTO link failures on x86_64-linux: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o link, -flto -fgnu-tm gcc.dg/lto/trans-mem-2 c_lto_trans-mem-2_0.o-c_lto_trans-mem-2_1.o link, -flto -fgnu-tm gcc.dg/lto/trans-mem-4 c_lto_trans-mem-4_0.o-c_lto_trans-mem-4_1.o link, -flto -fgnu-tm I'll have a look a that, even though they look rather scary.
[Bug c++/52320] missing destructor call after thrown exception in initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52320 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-21 10:37:29 UTC --- This looks similar to PR 41449 which Jason fixed
[Bug tree-optimization/52318] [4.7 Regression] ICE: in execute_todo, at passes.c:1748 with -O3 -ftracer -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce and stpcpy_chk()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52318 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-21 10:47:50 UTC --- Fixed.
[Bug c++/52320] missing destructor call after thrown exception in initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52320 --- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-02-21 10:53:59 UTC --- (In reply to comment #2) Agreed. It seems that the fix did not solve some array-related corner cases like this one.
[Bug libstdc++/52317] incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 --- Comment #9 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-02-21 10:56:00 UTC --- Author: paolo Date: Tue Feb 21 10:55:54 2012 New Revision: 184430 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184430 Log: 2012-02-21 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/52317 * python/Makefile.am: Update boilerplate license text to GPLv3. * include/profile/unordered_map: Likewise. * include/profile/set: Likewise. * include/profile/base.h: Likewise. * include/profile/impl/profiler_list_to_slist.h: Likewise. * include/profile/impl/profiler_container_size.h: Likewise. * include/profile/impl/profiler_vector_size.h: Likewise. * include/profile/impl/profiler_hash_func.h: Likewise. * include/profile/impl/profiler_trace.h: Likewise. * include/profile/impl/profiler_list_to_vector.h: Likewise. * include/profile/impl/profiler_vector_to_list.h: Likewise. * include/profile/impl/profiler.h: Likewise. * include/profile/impl/profiler_state.h: Likewise. * include/profile/impl/profiler_map_to_unordered_map.h: Likewise. * include/profile/impl/profiler_algos.h: Likewise. * include/profile/impl/profiler_hashtable_size.h: Likewise. * include/profile/impl/profiler_node.h: Likewise. * include/profile/vector: Likewise. * include/profile/unordered_set: Likewise. * include/profile/map.h: Likewise. * include/profile/map: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/ wchar_t/dr1261.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/ char/dr1261.cc: Likewise. * testsuite/20_util/reference_wrapper/invoke-2.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/profile/base.h trunk/libstdc++-v3/include/profile/impl/profiler.h trunk/libstdc++-v3/include/profile/impl/profiler_algos.h trunk/libstdc++-v3/include/profile/impl/profiler_container_size.h trunk/libstdc++-v3/include/profile/impl/profiler_hash_func.h trunk/libstdc++-v3/include/profile/impl/profiler_hashtable_size.h trunk/libstdc++-v3/include/profile/impl/profiler_list_to_slist.h trunk/libstdc++-v3/include/profile/impl/profiler_list_to_vector.h trunk/libstdc++-v3/include/profile/impl/profiler_map_to_unordered_map.h trunk/libstdc++-v3/include/profile/impl/profiler_node.h trunk/libstdc++-v3/include/profile/impl/profiler_state.h trunk/libstdc++-v3/include/profile/impl/profiler_trace.h trunk/libstdc++-v3/include/profile/impl/profiler_vector_size.h trunk/libstdc++-v3/include/profile/impl/profiler_vector_to_list.h trunk/libstdc++-v3/include/profile/map trunk/libstdc++-v3/include/profile/map.h trunk/libstdc++-v3/include/profile/set trunk/libstdc++-v3/include/profile/unordered_map trunk/libstdc++-v3/include/profile/unordered_set trunk/libstdc++-v3/include/profile/vector trunk/libstdc++-v3/python/Makefile.am trunk/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-2.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/wchar_t/dr1261.cc
[Bug libstdc++/52317] incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.3 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2012-02-21 10:57:31 UTC --- Fixed mainline and 4.6.3.
[Bug libstdc++/52317] incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 --- Comment #10 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-02-21 10:56:40 UTC --- Author: paolo Date: Tue Feb 21 10:56:34 2012 New Revision: 184431 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184431 Log: 2012-02-21 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/52317 * python/Makefile.am: Update boilerplate license text to GPLv3. * include/profile/unordered_map: Likewise. * include/profile/set: Likewise. * include/profile/base.h: Likewise. * include/profile/impl/profiler_list_to_slist.h: Likewise. * include/profile/impl/profiler_container_size.h: Likewise. * include/profile/impl/profiler_vector_size.h: Likewise. * include/profile/impl/profiler_hash_func.h: Likewise. * include/profile/impl/profiler_trace.h: Likewise. * include/profile/impl/profiler_list_to_vector.h: Likewise. * include/profile/impl/profiler_vector_to_list.h: Likewise. * include/profile/impl/profiler.h: Likewise. * include/profile/impl/profiler_state.h: Likewise. * include/profile/impl/profiler_map_to_unordered_map.h: Likewise. * include/profile/impl/profiler_algos.h: Likewise. * include/profile/impl/profiler_hashtable_size.h: Likewise. * include/profile/impl/profiler_node.h: Likewise. * include/profile/vector: Likewise. * include/profile/unordered_set: Likewise. * include/profile/map.h: Likewise. * include/profile/map: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/ wchar_t/dr1261.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/ char/dr1261.cc: Likewise. * testsuite/20_util/reference_wrapper/invoke-2.cc: Likewise. Modified: branches/gcc-4_6-branch/libstdc++-v3/ChangeLog branches/gcc-4_6-branch/libstdc++-v3/include/profile/base.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_algos.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_container_size.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_hash_func.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_hashtable_size.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_list_to_slist.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_list_to_vector.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_map_to_unordered_map.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_node.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_state.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_trace.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_vector_size.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_vector_to_list.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/map branches/gcc-4_6-branch/libstdc++-v3/include/profile/map.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/set branches/gcc-4_6-branch/libstdc++-v3/include/profile/unordered_map branches/gcc-4_6-branch/libstdc++-v3/include/profile/unordered_set branches/gcc-4_6-branch/libstdc++-v3/include/profile/vector branches/gcc-4_6-branch/libstdc++-v3/python/Makefile.am branches/gcc-4_6-branch/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-2.cc branches/gcc-4_6-branch/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc branches/gcc-4_6-branch/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/wchar_t/dr1261.cc
[Bug fortran/52325] unclear error: Unclassifiable statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52325
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
CC||burnus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-21
11:05:11 UTC ---
Untested patch:
--- primary.c (revision 184431)
+++ primary.c (working copy)
@@ -1910,6 +1910,19 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl
gfc_get_default_type (sym-name, sym-ns)-type == BT_DERIVED)
gfc_set_default_type (sym, 0, sym-ns);
+ if (sym-ts.type == BT_UNKNOWN gfc_match_char ('%') == MATCH_YES)
+{
+ gfc_error (Symbol %s at %C has no IMPLICIT type, sym-name);
+ return MATCH_ERROR;
+}
+ else if ((sym-ts.type != BT_DERIVED sym-ts.type != BT_CLASS)
+ gfc_match_char ('%') == MATCH_YES)
+{
+ gfc_error (Unexpected %% for nonderived type variable %s at %C,
+sym-name);
+ return MATCH_ERROR;
+}
+
if ((sym-ts.type != BT_DERIVED sym-ts.type != BT_CLASS)
|| gfc_match_char ('%') != MATCH_YES)
goto check_substring;
[Bug c++/52321] poor diagnostic of invalid cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
Severity|normal |enhancement
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-21
11:08:07 UTC ---
Comeau online gives:
ComeauTest.c, line 5: error: invalid type conversion
Clang gives:
l.cc:5:17: error: static_cast from 'foo *' to 'bar *' is not allowed
So G++ is no worse at least.
It wouldn't be as simple as just checking if the operand is a pointer/reference
to incomplete type when a static_cast fails, e.g. this fails because of casting
away const, not because the type is incomplete:
class foo;
int main() {
const foo* f;
static_castvoid*(f);
}
There are lots of reasons a static_cast could be invalid (inaccessible bases,
virtual bases, casting away const etc. and that's just for casting Class1* to
Class2*) so if the diagnostic is improved it should cover more than just
casting from a pointer/reference to (possibly cv-qualified) incomplete type.
[Bug middle-end/51782] -ftree-sra: Missing address-space information leads to wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #25 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-02-21 11:16:25 UTC --- Unfortunately, with the patch I got following new LTO link failures on x86_64-linux: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o link, -flto -fgnu-tm gcc.dg/lto/trans-mem-2 c_lto_trans-mem-2_0.o-c_lto_trans-mem-2_1.o link, -flto -fgnu-tm gcc.dg/lto/trans-mem-4 c_lto_trans-mem-4_0.o-c_lto_trans-mem-4_1.o link, -flto -fgnu-tm I'll have a look a that, even though they look rather scary. Don't you see the failures without the patch (see pr52297)?
[Bug c++/50043] [C++0x] Implement core/1123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50043 --- Comment #1 from Michel Morin mimomorin at gmail dot com 2012-02-21 11:51:14 UTC --- Created attachment 26711 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26711 A testcase for N3204 Attached a testcase for N3204 ;)
[Bug middle-end/51782] -ftree-sra: Missing address-space information leads to wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 --- Comment #26 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-21 11:54:36 UTC --- Author: gjl Date: Tue Feb 21 11:54:27 2012 New Revision: 184434 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184434 Log: PR middle-end/51782 * gcc.target/avr/torture/pr51782-1.c: New test. Added: trunk/gcc/testsuite/gcc.target/avr/torture/pr51782-1.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/52080] Stores to bitfields introduce a store-data-race on adjacent data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-21 11:58:00 UTC --- Created attachment 26712 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26712 candidate patch Here is a candidate patch (it ICEs one Ada testcase, see PR52134). It enforces the C++11 memory model (as far as bitfields are concerned) upon everyone and builds on the machinery that was implemented for it (changing the implementation for when we compute an underlying object and permanently store it, to make it possible to use this information for optimization purposes). It fixes the related PR48124 as well. It's an invasive change that will change code generation on STRICT_ALIGNMENT platforms quite severely for bitfield accesses. So it is not an appropriate fix for GCC 4.7 at this point of the development cycyle, nor would it be appropriate to backport it. Queued for GCC 4.8.
[Bug middle-end/48124] [4.4/4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #17 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-21 11:58:53 UTC --- Mine, at least for 4.8, see PR52080 for the patch.
[Bug target/18141] mips64-none-elf-gcc: Excessive NOPs with -march=r3000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18141 --- Comment #2 from Dinar Temirbulatov dtemirbulatov at gmail dot com 2012-02-21 11:58:23 UTC --- proposed fix for this issue posted here http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01693.html and the GNU copyright assignment form available upon request.
[Bug c++/50043] [C++0x] Implement core/1123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50043 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-21 12:05:40 UTC --- We don't want front-end testcases that rely on iostream and need to check what gets printed. A better test would use static_assert, but would also test cases with both throwing and non-throwing base class and members.
[Bug middle-end/52314] [4.4/4.5/4.6/4.7 Regression] gimplifier produces volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52314
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-21
12:11:42 UTC ---
I am testing
Index: gcc/gimplify.c
===
--- gcc/gimplify.c (revision 184428)
+++ gcc/gimplify.c (working copy)
@@ -504,7 +504,8 @@ create_tmp_reg (tree type, const char *p
static inline tree
create_tmp_from_val (tree val)
{
- return create_tmp_var (TREE_TYPE (val), get_name (val));
+ /* Drop all qualifiers and address-space information from the value type.
*/
+ return create_tmp_var (TYPE_MAIN_VARIANT (TREE_TYPE (val)), get_name (val));
}
/* Create a temporary to hold the value of VAL. If IS_FORMAL, try to reuse
[Bug tree-optimization/52324] [4.7 Regression] Store motion no longer performed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52324 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-21 12:37:37 UTC --- Author: rguenth Date: Tue Feb 21 12:37:33 2012 New Revision: 184435 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184435 Log: 2012-02-21 Richard Guenther rguent...@suse.de PR tree-optimization/52324 * gimplify.c (gimplify_expr): When re-gimplifying expressions do not gimplify a MEM_REF address operand if it is already in suitable form. * gcc.dg/tree-ssa/ssa-lim-10.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-10.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/52324] [4.7 Regression] Store motion no longer performed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52324 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-21 12:46:40 UTC --- Fixed.
[Bug c/52326] New: float result incorrect with -O1 and calling external function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52326 Bug #: 52326 Summary: float result incorrect with -O1 and calling external function. Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: bauge...@cisco.com Created attachment 26713 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26713 Two source files, one header file and a Makefile The sample program attached fails when built with -O1, but not with any other optimization levels (0,2,3). Unfortunately it only fails when we call an external function, therefore we had to attach a tgz file instead of a preprocessed file. The tar file contains four files: main.c, foo.c, foo.h and a Makefile. The Makefile, which builds two targets (fail and success) can be used to re-create the problem as well as to build a non-failing version. Also, the error only occurs when certain other conditions are met. We've written a C comment for every condition we found in the source file named main.c. Please search for the text NOTE. GCC Version: Our GCC version is 4.6.2. It fails on multiple versions/builds of 4.6.2, both the one provided with Gentoo and the one provided by Centos 6. The info below is from my Gentoo host: COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.2/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.2/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.6.2/work/gcc-4.6.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.2/python --enable-checking=release --disable-libgcj --disable-libquadmath --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.2 p1.4, pie-0.5.0' Thread model: posix gcc version 4.6.2 (Gentoo 4.6.2 p1.4, pie-0.5.0) The complete command line that triggers the bug: gcc -o fail -O1 -Wall -Wextra -Wconversion -Werror -Wshadow -Wmissing-declarations -std=c89 main.c foo.c ./fail (Note that it also fails with less arguments, -O1 is all it takes) Compiler output: --- None Preprocessed file: -- Due to the nature of the bug, calling an external function, we could not provide a preprocessed file.
[Bug middle-end/51782] -ftree-sra: Missing address-space information leads to wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-02/msg01080.htm ||l --- Comment #27 from Martin Jambor jamborm at gcc dot gnu.org 2012-02-21 13:12:56 UTC --- (In reply to comment #25) Unfortunately, with the patch I got following new LTO link failures on x86_64-linux: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o link, -flto -fgnu-tm gcc.dg/lto/trans-mem-2 c_lto_trans-mem-2_0.o-c_lto_trans-mem-2_1.o link, -flto -fgnu-tm gcc.dg/lto/trans-mem-4 c_lto_trans-mem-4_0.o-c_lto_trans-mem-4_1.o link, -flto -fgnu-tm I'll have a look a that, even though they look rather scary. Don't you see the failures without the patch (see pr52297)? No, I don't, for some reason. Nevertheless, it indeed seems to be an unrelated problem and so I have posted the patch to the mailing list and now only wait for test results on a platform with address spaces: http://gcc.gnu.org/ml/gcc-patches/2012-02/msg01080.html
[Bug rtl-optimization/52326] [4.6 Regression] float result incorrect with -O1 and calling external function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52326 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |NEW Known to work||4.5.3, 4.7.0 Keywords||wrong-code Last reconfirmed||2012-02-21 Component|c |rtl-optimization Ever Confirmed|0 |1 Summary|float result incorrect with |[4.6 Regression] float |-O1 and calling external|result incorrect with -O1 |function. |and calling external ||function. Target Milestone|--- |4.6.3 Known to fail||4.6.0, 4.6.2 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-21 13:20:34 UTC --- Confirmed. foo.c is unrelated and can be compiled with -O0. Works with 4.5.3, fails with 4.6.0 already, works with 4.7. The tree level looks good to me.
[Bug rtl-optimization/52326] [4.6 Regression] float result incorrect with -O1 and calling external function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52326
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-21
13:27:23 UTC ---
Reduced single-file testcase, fails at -O1:
float fabsf(float x);
void abort (void);
static float minf(float a, float b)
{
return (a b) ? a: b;
}
static float maxf(float a, float b)
{
return (a b) ? a: b;
}
struct EC {
float fftout;
int extragainOn;
};
static float __attribute__((noinline))
foo (float a)
{
asm();
return a;
}
static struct EC * __attribute__((noinline))
ec_create(void)
{
static struct EC p;
p.fftout = 1.234567f;
p.extragainOn = 1;
return p;
}
static float ec_process(struct EC *p, float beflev, float estlev)
{
float fullgCorr;
float extrag;
fullgCorr = maxf(0.0f, beflev - estlev) / beflev;
extrag = 1.0f;
if (p-extragainOn)
extrag = minf(1.0f, fullgCorr);
foo(0.0f);
return extrag * p-fftout;
}
int main(void)
{
unsigned int i = 0;
float beflev[] = {11.6f, 1.0f};
float estlev[] = {11.5f, 1.0f};
float output;
struct EC *p = ec_create();
/* NOTE: If the for-loop is removed, the error disappears */
for (i = 0; i 1; i++)
output = ec_process(p, beflev[i], estlev[i]);
if (fabsf(output - 0.010643f) 1e-5f)
return 0;
else
abort ();
}
[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981 --- Comment #38 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-21 13:32:38 UTC --- Pending trunk patches (approved, but not committed; 4.8?): - http://gcc.gnu.org/ml/fortran/2012-02/msg00061.html - http://gcc.gnu.org/ml/fortran/2012-02/msg00062.html
[Bug fortran/52270] [OOP] Polymorphic vars: wrong intent(in) check, passing nonptr variable to intent(in) ptr dummy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52270 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-21 13:36:30 UTC --- Submitted patch, pending review: http://gcc.gnu.org/ml/fortran/2012-02/msg00085.html
[Bug fortran/52196] Add -Wrealloc-lhs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52196 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-21 13:36:46 UTC --- Submitted patch, pending review: http://gcc.gnu.org/ml/fortran/2012-02/msg00071.html
[Bug go/52218] [4.7 Regression] libgo ftbfs on arm-linux-gnueabi (unknown case for SETCONTEXT_CLOBBERS_TLS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52218 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from Matthias Klose doko at gcc dot gnu.org 2012-02-21 13:36:44 UTC --- Peter Maydell commented: Specifically the functions exist but return ENOSYS, which is why this: if (getcontext (c) 0) abort (); will abort. Trying to get these functions into eglibc for ARM is kind of on the Linaro toolchain group's todo list, but (a) not at a hugely high priority and (b) it will take a little while for them to percolate through eglibc and back into distros anyway, so apps/configure scripts need to be prepared to handle the returns-ENOSYS case anyway.
[Bug middle-end/52314] [4.4/4.5/4.6/4.7 Regression] gimplifier produces volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52314 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-21 14:10:43 UTC --- Author: rguenth Date: Tue Feb 21 14:10:31 2012 New Revision: 184436 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184436 Log: 2012-02-21 Richard Guenther rguent...@suse.de PR middle-end/52314 * gimplify.c (create_tmp_from_val): Use the main variant type for the type of the temporary we create. Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c
[Bug middle-end/52314] [4.4/4.5/4.6/4.7 Regression] gimplifier produces volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52314 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-21 14:11:22 UTC --- Fixed for 4.7.
[Bug target/52137] bdver2 scheduler needs to be added to bdver1 insn reservations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52137 --- Comment #1 from Quentin Neill qneill at gcc dot gnu.org 2012-02-21 15:15:48 UTC --- Author: qneill Date: Tue Feb 21 15:15:42 2012 New Revision: 184440 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184440 Log: 2012-02-21 Quentin Neill quentin.ne...@amd.com PR target/52137 * config/i386/bdver1.md (bdver1_call, bdver1_push, bdver1_pop, bdver1_leave, bdver1_lea, bdver1_imul_DI, bdver1_imul, bdver1_imul_mem_DI, bdver1_imul_mem, bdver1_idiv, bdver1_idiv_mem, bdver1_str, bdver1_idirect, bdver1_ivector, bdver1_idirect_loadmov, bdver1_idirect_load, bdver1_ivector_load, bdver1_idirect_movstore, bdver1_idirect_both, bdver1_ivector_both, bdver1_idirect_store, bdver1_ivector_store, bdver1_fldxf, bdver1_fld, bdver1_fstxf, bdver1_fst, bdver1_fist, bdver1_fmov_bdver1, bdver1_fadd_load, bdver1_fadd, bdver1_fmul_load, bdver1_fmul, bdver1_fsgn, bdver1_fdiv_load, bdver1_fdiv, bdver1_fpspc_load, bdver1_fpspc, bdver1_fcmov_load, bdver1_fcmov, bdver1_fcomi_load, bdver1_fcomi, bdver1_fcom_load, bdver1_fcom, bdver1_fxch, bdver1_ssevector_avx128_unaligned_load, bdver1_ssevector_avx256_unaligned_load, bdver1_ssevector_sse128_unaligned_load, bdver1_ssevector_avx128_load, bdver1_ssevector_avx256_load, bdver1_ssevector_sse128_load, bdver1_ssescalar_movq_load, bdver1_ssescalar_vmovss_load, bdver1_ssescalar_sse128_load, bdver1_mmxsse_load, bdver1_sse_store_avx256, bdver1_sse_store, bdver1_mmxsse_store_short, bdver1_ssevector_avx256, bdver1_movss_movsd, bdver1_mmxssemov, bdver1_sselog_load_256, bdver1_sselog_256, bdver1_sselog_load, bdver1_sselog, bdver1_ssecmp_load, bdver1_ssecmp, bdver1_ssecomi_load, bdver1_ssecomi, bdver1_vcvtX2Y_avx256_load, bdver1_vcvtX2Y_avx256, bdver1_ssecvt_cvtss2sd_load, bdver1_ssecvt_cvtss2sd, bdver1_sseicvt_cvtsi2sd_load, bdver1_sseicvt_cvtsi2sd, bdver1_ssecvt_cvtpd2ps_load, bdver1_ssecvt_cvtpd2ps, bdver1_ssecvt_cvtdq2ps_load, bdver1_ssecvt_cvtdq2ps, bdver1_ssecvt_cvtdq2pd_load, bdver1_ssecvt_cvtdq2pd, bdver1_ssecvt_cvtps2pd_load, bdver1_ssecvt_cvtps2pd, bdver1_ssecvt_cvtsX2si_load, bdver1_ssecvt_cvtsX2si, bdver1_ssecvt_cvtpd2pi_load, bdver1_ssecvt_cvtpd2pi, bdver1_ssecvt_cvtpd2dq_load, bdver1_ssecvt_cvtpd2dq, bdver1_ssecvt_cvtps2pi_load, bdver1_ssecvt_cvtps2pi, bdver1_ssemuladd_load_256, bdver1_ssemuladd_256, bdver1_ssemuladd_load, bdver1_ssemuladd, bdver1_sseimul_load, bdver1_sseimul, bdver1_sseiadd_load, bdver1_sseiadd, bdver1_ssediv_double_load_256, bdver1_ssediv_double_256, bdver1_ssediv_single_load_256, bdver1_ssediv_single_256, bdver1_ssediv_double_load, bdver1_ssediv_double, bdver1_ssediv_single_load, bdver1_ssediv_single, bdver1_sseins): Add bdver2 attribute. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/bdver1.md
[Bug libstdc++/51967] FAIL: libstdc++-prettyprinters/48362.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51967 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #8 from John David Anglin danglin at gcc dot gnu.org 2012-02-21 15:20:06 UTC --- Resolved by upgrading to python 2.7.2 and rebuilding gdb.
[Bug c++/52321] poor diagnostic of invalid cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321 --- Comment #2 from Ivan Godard igodard at pacbell dot net 2012-02-21 15:30:42 UTC --- Somewhere there's an attept to coerce a to b that sees the source is a class and the target is a class and tries to see if the source is derived from target. That check fails because source is undefined, and the failure propagates out as other possible casts are tried. If you save the reason for failure your can't cast message can look at the reason. The message could expand on other possible reasons too. Just a suggestion - that's how we did it in the Mary compilers, and gave a list of the plausible reasons for failure.
[Bug target/52294] [4.7 Regression] [ARM Thumb] generated asm code produces branch out of range error in gas with -Os -mcpu=cortex-a9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52294 --- Comment #8 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-02-21 15:38:40 UTC --- Author: rearnsha Date: Tue Feb 21 15:38:35 2012 New Revision: 184442 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184442 Log: PR target/52294 * thumb2.md (thumb2_shiftsi3_short): Split register and immediate shifts. For register shifts tie operands 0 and 1. (peephole2 for above): Check that register-controlled shifts have suitably tied operands. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/thumb2.md
[Bug c++/52321] poor diagnostic of invalid cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-21 15:53:10 UTC --- Yep, it's build_static_cast_1 in typeck.c But currently that has no way to store or pass back a message (just a boolean indicating success or failure and the result of the cast) and would need a lot of restructuring. if (target is pointer or reference source is class type target is class type (target is rvalue || source is lvalue) target is derived from source can convert at least as qualified) Your example fails the target is derived from source test, but that test doesn't say it failed because the type is incomplete, it just returns false. And the can convert step might fail for a number of reasons, but again it just returns a boolean. Modifying that to report different reasons (rather than just evaluating to 'false') is not simple.
[Bug fortran/52325] unclear error: Unclassifiable statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52325 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-21 15:58:23 UTC --- Submitted patch (pending review): http://gcc.gnu.org/ml/fortran/2012-02/msg00089.html
[Bug c++/52327] New: Virtual inheritance and template copy construction doesn't call the correct copy constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52327 Bug #: 52327 Summary: Virtual inheritance and template copy construction doesn't call the correct copy constructors Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ryan_at_work_a...@hotmail.com Created attachment 26714 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26714 Error test case Using: g++ (GCC) 4.6.1 20110908 (Red Hat 4.6.1-9) 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. The attached code produces the following output: construct base construct derived construct top COMMENCE NORMAL COPY copy construct base copy construct derived copy construct top COMMENCE TEMPLATED COPY construct base construct derived copy construct top DONE For the templated copy, I expect the base and derived copy constructors to be called (as such my application is losing information because these are NOT being called). Linux 2.6.40.3-0.fc15.x86_64
[Bug fortran/52328] New: Wrong line in warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52328 Bug #: 52328 Summary: Wrong line in warning Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: kel...@hlrs.de The line numbering in the warning of below example is wrong: Warning: Nonconforming tab character in column 1 of line 6 This is warning is emitted starting with gfortran-4.2 and occurs in svn-trunk when compiling with -Wall. This is related to the fix back then in PR 34899. Thank You very much. PS: some more info: gcc -v: Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/gcc-svn/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/opt/gcc-svn --enable-bootstrap --enable-threads --enable-tls --enable-languages=c,c++,fortran,java,lto,go --enable-lto --enable-gold --enable-plugins Thread model: posix gcc version 4.7.0 20120213 (experimental) (GCC uname -a: james:/usr/src/gcc-svn # uname -a Linux james 3.2.6-2 #1 SMP Mon Feb 20 20:54:52 CET 2012 x86_64 x86_64 x86_64 GNU/Linux
[Bug fortran/52328] Wrong line in warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52328 --- Comment #1 from Rainer Keller Keller at hlrs dot de 2012-02-21 16:54:39 UTC --- Created attachment 26715 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26715 test-case showing the wrong location of nonconformant tab-character.
[Bug c++/52327] Virtual inheritance and template copy construction doesn't call the correct copy constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52327 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-21 16:54:45 UTC --- Virtual bases are constructed by the most-derived class, which is InitializerTop in your templated copy case, and the ctor-initializer-list for InitializerTop doesn't construct the Base and Derived classes, so they are default constructed. i.e. G++ is correct.
[Bug c++/52327] Virtual inheritance and template copy construction doesn't call the correct copy constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52327 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-02-21 17:04:06 UTC --- To quote the standard, [class.base.init] p7 says A mem-initializer where the mem-initializer-id denotes a virtual base class is ignored during execution of a constructor of any class that is not the most derived class. So when Top is not the most-derived class, the mem-initializers in Top's copy constructor are ignored, and the virtual bases get default-constructed. c.f. http://www.parashift.com/c++-faq/multiple-inheritance.html#faq-25.12
[Bug c++/52321] poor diagnostic of invalid cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321 --- Comment #4 from Ivan Godard igodard at pacbell dot net 2012-02-21 17:38:30 UTC --- Define an enum of reasons with success first, flop the sense of the test so that false means coercion was OK (grep to find all calls and put a ! in front of each), and return the reason enum instead of bool. The code that is reason-aware saves the enum and builds a good message; the legacy code that is not reason-aware treats the enum as a bool and works as before except for the inverted sense of the test. Maybe half an hour of work. Plausible?
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #16 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-02-21 17:40:36 UTC --- On Tue, 21 Feb 2012, manu at gcc dot gnu.org wrote: Created attachment 26710 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26710 patch reverting PR26632 I am testing this. It reverts PR26632 fix and ignores recurses into NOPs at the warning point. Do you see any potential issues? I think the full set of testcases from the patch originally proposed on gcc-patches should be added, but don't see any issues with this new patch from a front-end perspective.
[Bug middle-end/52329] New: Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52329 Bug #: 52329 Summary: Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: jamb...@gcc.gnu.org CC: ja...@gcc.gnu.org Host: x86_64-suse-linux Target: x86_64-suse-linux Build: x86_64-suse-linux Created attachment 26716 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26716 Preprocessed source Bootstrapping revision 184388 with the following patch Index: gcc/emit-rtl.c === --- gcc/emit-rtl.c (revision 184388) +++ gcc/emit-rtl.c (working copy) @@ -1681,6 +1681,7 @@ set_mem_attributes_minus_bitpos (rtx ref MEM_NOTRAP_P (ref) = !tree_could_trap_p (t); base = get_base_address (t); + gcc_assert (base); if (base DECL_P (base) TREE_READONLY (base) (TREE_STATIC (base) || DECL_EXTERNAL (base)) causes an ICE when compiling libstdc++-v3/src/c++98/complex_io.cc because get_base_address stumbles upon encountering an invalid MEM_REF MEM[(struct basic_stringbuf *)__s._M_stringbuf]._M_string and returns NULL. This expression is passed to it by expand_debug_expr via set_mem_attributes. Attached is the preprocessed testcase, invocation flags are -g -O2 -S
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #17 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-02-21 17:52:12 UTC --- (In reply to comment #16) I think the full set of testcases from the patch originally proposed on gcc-patches should be added, but don't see any issues with this new patch from a front-end perspective. Thanks for looking at it. Sorry, I don't know which testcases you mean. Which patch?
[Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52329 --- Comment #1 from Martin Jambor jamborm at gcc dot gnu.org 2012-02-21 17:51:10 UTC --- Created attachment 26717 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26717 Delta reduced testcase This as far as I managed to reduce the testcase with multidelta.
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #18 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-02-21 17:56:32 UTC --- On Tue, 21 Feb 2012, manu at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #17 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-02-21 17:52:12 UTC --- (In reply to comment #16) I think the full set of testcases from the patch originally proposed on gcc-patches should be added, but don't see any issues with this new patch from a front-end perspective. Thanks for looking at it. Sorry, I don't know which testcases you mean. Which patch? http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00794.html
[Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52329
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-21
18:24:37 UTC ---
Slightly more reduced testcase for -O2 -g:
template typename
class A;
template class
struct B;
template typename T, typename = B T, typename = A T
class C;
template typename _Tp
class A {};
template typename T, typename, typename U
struct D
{
struct E
{
T *e1 () {}
void e2 (U a) { e3 (a); }
void e3 (U) throw ();
};
struct F { F (T *, U) {} };
F f;
E *d1 () {}
static E d2 () {}
D () : f (d2 ().e1 (), U ())
{
d1 ()-e2 (this-d3 ());
}
U d3 () {}
};
template typename, typename
struct G
{
virtual ~G () {}
};
template typename T, typename U
struct H
{
void h1 (G T, U *);
};
template typename T, typename U
struct I : H T, U
{
I () { this-h1 (0); }
};
template typename T, typename U, typename V
struct J : G T, U
{
D T, U, V j;
};
template typename T, typename U, typename V
struct C : I T, U
{
J T, U, V c;
};
struct K;
template typename T, class U
I T, U
operator (I T, U , const K )
{
C U s;
}
template I wchar_t, B wchar_t
operator (I wchar_t, B wchar_t , const K );
[Bug go/52218] [4.7 Regression] libgo ftbfs on arm-linux-gnueabi (unknown case for SETCONTEXT_CLOBBERS_TLS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52218 --- Comment #5 from Ian Lance Taylor ian at airs dot com 2012-02-21 18:33:14 UTC --- If ARM GNU/Linux does not support getcontext/setcontext, then this particular configure test is not particularly relevant, since the library isn't going to work anyhow. I suppose the error message could be more clear but it's going to boil down to a compilation or runtime error regardless.
[Bug middle-end/52329] Invalid MEM_REF encountered in set_mem_attributes_minus_bitpos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52329 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-21 18:41:01 UTC --- Richard, so what exactly is not kosher? We have: # DEBUG D#7 = s.c.D.2422 ... MEM[(struct J *)s].D.2422._vptr.G = MEM[(void *)_ZTV1JI1BIwES0_IS1_E1AIS1_EE + 16B]; in the optimized dump, s.c.D.2422 is ADDR_EXPR of COMPONENT_REF of MEM_REF, the first operand in the real stmt is COMPONENT_REF of COMPONENT_REF of MEM_REF.
[Bug fortran/52328] Wrong line in warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52328 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org 2012-02-21 18:53:37 UTC --- It works for me with all versions from 4.2 through 4.7. troutmask:sgk[213] gfc4x -o z -Wall pr.f Warning: Nonconforming tab character in column 1 of line 3 troutmask:sgk[214] gfc46 -o z -Wall pr.f Warning: Nonconforming tab character in column 1 of line 3 troutmask:sgk[215] gfc45 -o z -Wall pr.f Warning: Nonconforming tab character in column 1 of line 3 troutmask:sgk[216] gfc44 -o z -Wall pr.f Warning: Nonconforming tab character in column 1 of line 3 troutmask:sgk[217] gfc43 -o z -Wall pr.f Warning: Nonconforming tab character in column 1 of line 3 troutmask:sgk[218] gfc42 -o z -Wall pr.f Warning: Nonconforming tab character in column 1 of line 3
[Bug libstdc++/50349] /usr/bin/ld: warning: wildcard match appears in both version 'GLIBCXX_3.4' and 'CXXABI_1.3' in script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50349 Benjamin Kosnik bkoz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-21 AssignedTo|unassigned at gcc dot |bkoz at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #4 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-02-21 20:07:30 UTC --- confirmed with gcc-trunk and gold as: %ld --version GNU gold (GNU Binutils 2.22.52.20120220) 1.11 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. /mnt/share/bin/H-x86_64-binutils.20120220-gold/bin/ld: warning: wildcard match appears in both version 'GLIBCXX_3.4' and 'CXXABI_1.3' in script /mnt/share/bin/H-x86_64-binutils.20120220-gold/bin/ld: warning: wildcard match appears in both version 'CXXABI_1.3' and 'CXXABI_TM_1' in script /mnt/share/bin/H-x86_64-binutils.20120220-gold/bin/ld: warning: using 'GLIBCXX_3.4' as version for '_ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv' which is also named in version 'GLIBCXX_3.4.6' in script /mnt/share/bin/H-x86_64-binutils.20120220-gold/bin/ld: warning: using 'GLIBCXX_3.4' as version for '_ZNKSs11_M_disjunctEPKc' which is also named in version 'GLIBCXX_3.4.5' in script /mnt/share/bin/H-x86_64-binutils.20120220-gold/bin/ld: warning: using 'GLIBCXX_3.4' as version for '_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw' which is also named in version 'GLIBCXX_3.4.5' in script
[Bug c/52330] New: pr50305.c: valgrind problem on invalid asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52330 Bug #: 52330 Summary: pr50305.c: valgrind problem on invalid asm Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com I just tried to compile the file gcc/testsuite/gcc.target/arm/pr50305.c under valgrind on trunk dated 20120219 on an AMD x86_64 box. Valgrind said ==4007== Invalid read of size 8 ==4007==at 0x6B0212: adjust_address_1(rtx_def*, machine_mode, long, int, int) (emit-rtl.c:2043) ==4007==by 0xBCA083: ix86_print_operand(_IO_FILE*, rtx_def*, int) (i386.c:14096) ==4007==by 0x6F4DF0: _Z15output_asm_insnPKcPP7rtx_def.part.16 (final.c:3531)==4007==by 0x6F66D4: final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*) (final.c:1941) No special flags required.
[Bug c/52331] New: 20011127-1.c: valgrind problem on invalid asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52331 Bug #: 52331 Summary: 20011127-1.c: valgrind problem on invalid asm Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com I just tried to compile the file gcc/testsuite/gcc.target/cris/20011127-1.c under valgrind on trunk dated 20120219 on an AMD x86_64 box. Valgrind said ==4274== Invalid read of size 2 ==4274==at 0x8E4F91: copy_rtx(rtx_def*) (rtl.c:243) ==4274==by 0x6B024E: adjust_address_1(rtx_def*, machine_mode, long, int, int) (emit-rtl.c:2054) ==4274==by 0xBCA083: ix86_print_operand(_IO_FILE*, rtx_def*, int) (i386.c:14096) ==4274==by 0x6F4DF0: _Z15output_asm_insnPKcPP7rtx_def.part.16 (final.c:3531) No special flags required.
[Bug libstdc++/52317] incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 Alfred Minarik alfred.minarik.1 at aon dot at changed: What|Removed |Added CC||alfred.minarik.1 at aon dot ||at --- Comment #12 from Alfred Minarik alfred.minarik.1 at aon dot at 2012-02-21 20:16:41 UTC --- Sorry for my ignorance, but shouldn't the files which previous contained the special exception // As a special exception, you may use this file as part of a free // software library without restriction. Specifically, if other files // instantiate templates or use macros or inline functions ... now contain the new replacement (like other libstdc++ files) // Under Section 7 of GPL version 3, you are granted additional // permissions described in the GCC Runtime Library Exception, version // 3.1, as published by the Free Software Foundation. // You should have received a copy of the GNU General Public License and // a copy of the GCC Runtime Library Exception along with this program; // see the files COPYING3 and COPYING.RUNTIME respectively. If not, see // http://www.gnu.org/licenses/.
[Bug rtl-optimization/52326] [4.6 Regression] float result incorrect with -O1 and calling external function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52326 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-21 20:22:59 UTC --- Works on the trunk since http://gcc.gnu.org/viewcvs?root=gccview=revrev=174664
[Bug libstdc++/52317] incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 2012-02-21 20:23:47 UTC --- Nope (and note that we don't have that anywhere else).
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Attachment #26710|0 |1 is obsolete|| --- Comment #19 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-02-21 20:28:30 UTC --- Created attachment 26718 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26718 take 2 The new testcases seem to work, but I haven't done a full check. Anyway, it will have to wait for 4.8... @chbr or anyone else, feel free to take it and submit it, now or later.
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Blocks||37985 --- Comment #20 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-02-21 20:29:35 UTC --- My patch also fixes PR37985.
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #21 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-02-21 20:35:31 UTC --- BTW, why warn_if_unused_value is in stmt.c? The comment at the top says: /* Expands front end tree to back end RTL for GCC */ And warn_if_unused_value is exclusively used by the C/C++ FEs. WTF!
[Bug libstdc++/52317] incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 --- Comment #14 from Alfred Minarik alfred.minarik.1 at aon dot at 2012-02-21 20:48:38 UTC --- ok, only that I see that nearly everywhere else, just nearby in /trunk/libstdc++-v3/include/profile/iterator_tracker.h /trunk/libstdc++-v3/include/profile/forward_list or any file I looked at in /trunk/libstdc++-v3/include/std/
[Bug c++/52224] [C++0x] Generic operator gets pulled into compile-time expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52224 --- Comment #5 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-02-21 21:17:41 UTC --- I just found this closed CWG issue: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#487 It seems that the compiler behaviour is indeed intended by the core language. Based on this rationale this bug entry should be closed as invalid.
[Bug middle-end/50211] ICE: verify_flow_info: Incorrect fallthru 11-12 with -funroll-all-loops --param case-values-threshold=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50211 --- Comment #3 from Zdenek Sojka zsojka at seznam dot cz 2012-02-21 21:25:56 UTC --- Created attachment 26719 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26719 even shorter testcase $ gcc -O -funroll-all-loops --param=case-values-threshold=1 testcase.c testcase.c: In function 'foo': testcase.c:13:1: error: verify_flow_info: Incorrect fallthru 17-18 testcase.c:13:1: error: wrong insn in the fallthru edge (barrier 107 104 129) testcase.c:13:1: internal compiler error: in rtl_verify_flow_info, at cfgrtl.c:2180 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. ICEs with r184423
[Bug libstdc++/52317] incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 --- Comment #15 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-02-21 21:30:31 UTC --- Author: paolo Date: Tue Feb 21 21:30:26 2012 New Revision: 184448 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184448 Log: 2012-02-21 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/52317 (cont) * include/profile/unordered_map: Ad Library Exception comment. * include/profile/set: Likewise. * include/profile/base.h: Likewise. * include/profile/impl/profiler_list_to_slist.h: Likewise. * include/profile/impl/profiler_container_size.h: Likewise. * include/profile/impl/profiler_vector_size.h: Likewise. * include/profile/impl/profiler_hash_func.h: Likewise. * include/profile/impl/profiler_trace.h: Likewise. * include/profile/impl/profiler_list_to_vector.h: Likewise. * include/profile/impl/profiler_vector_to_list.h: Likewise. * include/profile/impl/profiler.h: Likewise. * include/profile/impl/profiler_state.h: Likewise. * include/profile/impl/profiler_map_to_unordered_map.h: Likewise. * include/profile/impl/profiler_algos.h: Likewise. * include/profile/impl/profiler_hashtable_size.h: Likewise. * include/profile/impl/profiler_node.h: Likewise. * include/profile/vector: Likewise. * include/profile/unordered_set: Likewise. * include/profile/map.h: Likewise. * include/profile/map: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/profile/base.h trunk/libstdc++-v3/include/profile/impl/profiler.h trunk/libstdc++-v3/include/profile/impl/profiler_algos.h trunk/libstdc++-v3/include/profile/impl/profiler_container_size.h trunk/libstdc++-v3/include/profile/impl/profiler_hash_func.h trunk/libstdc++-v3/include/profile/impl/profiler_hashtable_size.h trunk/libstdc++-v3/include/profile/impl/profiler_list_to_slist.h trunk/libstdc++-v3/include/profile/impl/profiler_list_to_vector.h trunk/libstdc++-v3/include/profile/impl/profiler_map_to_unordered_map.h trunk/libstdc++-v3/include/profile/impl/profiler_node.h trunk/libstdc++-v3/include/profile/impl/profiler_state.h trunk/libstdc++-v3/include/profile/impl/profiler_trace.h trunk/libstdc++-v3/include/profile/impl/profiler_vector_size.h trunk/libstdc++-v3/include/profile/impl/profiler_vector_to_list.h trunk/libstdc++-v3/include/profile/map trunk/libstdc++-v3/include/profile/map.h trunk/libstdc++-v3/include/profile/set trunk/libstdc++-v3/include/profile/unordered_map trunk/libstdc++-v3/include/profile/unordered_set trunk/libstdc++-v3/include/profile/vector
[Bug libstdc++/52317] incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 --- Comment #17 from Paolo Carlini paolo.carlini at oracle dot com 2012-02-21 21:31:27 UTC --- Ah, Ok, should be fixed now.
[Bug libstdc++/52317] incorrect FSF address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317 --- Comment #16 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-02-21 21:30:54 UTC --- Author: paolo Date: Tue Feb 21 21:30:44 2012 New Revision: 184449 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184449 Log: 2012-02-21 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/52317 (cont) * include/profile/unordered_map: Ad Library Exception comment. * include/profile/set: Likewise. * include/profile/base.h: Likewise. * include/profile/impl/profiler_list_to_slist.h: Likewise. * include/profile/impl/profiler_container_size.h: Likewise. * include/profile/impl/profiler_vector_size.h: Likewise. * include/profile/impl/profiler_hash_func.h: Likewise. * include/profile/impl/profiler_trace.h: Likewise. * include/profile/impl/profiler_list_to_vector.h: Likewise. * include/profile/impl/profiler_vector_to_list.h: Likewise. * include/profile/impl/profiler.h: Likewise. * include/profile/impl/profiler_state.h: Likewise. * include/profile/impl/profiler_map_to_unordered_map.h: Likewise. * include/profile/impl/profiler_algos.h: Likewise. * include/profile/impl/profiler_hashtable_size.h: Likewise. * include/profile/impl/profiler_node.h: Likewise. * include/profile/vector: Likewise. * include/profile/unordered_set: Likewise. * include/profile/map.h: Likewise. * include/profile/map: Likewise. Modified: branches/gcc-4_6-branch/libstdc++-v3/ChangeLog branches/gcc-4_6-branch/libstdc++-v3/include/profile/base.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_algos.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_container_size.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_hash_func.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_hashtable_size.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_list_to_slist.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_list_to_vector.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_map_to_unordered_map.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_node.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_state.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_trace.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_vector_size.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/impl/profiler_vector_to_list.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/map branches/gcc-4_6-branch/libstdc++-v3/include/profile/map.h branches/gcc-4_6-branch/libstdc++-v3/include/profile/set branches/gcc-4_6-branch/libstdc++-v3/include/profile/unordered_map branches/gcc-4_6-branch/libstdc++-v3/include/profile/unordered_set branches/gcc-4_6-branch/libstdc++-v3/include/profile/vector
[Bug c++/52224] [C++0x] Generic operator gets pulled into compile-time expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52224 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-02-21 21:51:49 UTC --- Great.
[Bug fortran/52332] New: Internal compiler error in in gfc_get_symbol_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52332 Bug #: 52332 Summary: Internal compiler error in in gfc_get_symbol_decl Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fmarti...@gmv.com Created attachment 26720 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26720 Sample code for bug The attached code produces the following fatal error m_xfunit_assertion_array_character.f90: In function ‘get_expected’: m_xfunit_assertion_array_character.f90:179:0: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1234 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The command line is: /opt/gcc-4.7/bin/gfortran -c m_string.F90 m_xfunit_tools.f90 m_xfunit_xml.f90 m_xfunit_assertion.f90 m_xfunit_assertion_character.f90 m_xfunit_assertion_array_character.f90
[Bug fortran/52332] Internal compiler error in in gfc_get_symbol_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52332 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-02-21 23:07:43 UTC --- Fails for: pure function get_expected( ast ) result(res) class(t_xfunit_assertion_array_character), intent(in) :: ast character, dimension(size(ast%rast)) :: res integer :: i res = (/ (character(ast%rast(i)%get_expected()), i=1, size(ast%rast)) /) end function get_expected Hereby, character is a generic name for the specific function (in m_string.F90): elemental function string_to_char( s ) result(res) type(t_string),intent(in) :: s #if defined(__G95__) || defined(__GFORTRAN__) character(len=size(s%string)) :: res #endif The failue is for s at the assert: /* Dummy variables should already have been created. */ gcc_assert (sym-backend_decl); #0 gfc_get_symbol_decl (sym=0x177cfe0) at /home/tob/projects/gcc-trunk-checkout/gcc/fortran/trans-decl.c:1234 #1 0x005db598 in gfc_conv_variable (se=0x7fffc850, expr=0x1768930) at trans-expr.c:1196 #2 0x005dbd19 in gfc_conv_expr_lhs (se=0x7fffc850, expr=0x1768930) at trans-expr.c:5542 If one looks at the expr, one sees that there is a REF_COMPONENT followed by a REF_ARRAY. (gdb) p ((gfc_expr *)0x1768930)-ref-u.c-sym-name $2 = 0x2ccdbf30 t_string (gdb) p ((gfc_expr *)0x1768930)-ref-u.c-component-name $5 = 0x2cd10048 string
[Bug target/52294] [4.7 Regression] [ARM Thumb] generated asm code produces branch out of range error in gas with -Os -mcpu=cortex-a9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52294 --- Comment #9 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-02-21 23:46:10 UTC --- Author: rearnsha Date: Tue Feb 21 23:46:05 2012 New Revision: 184452 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184452 Log: PR target/52294 * thumb2.md (thumb2_shiftsi3_short): Split register and immediate shifts. For register shifts tie operands 0 and 1. (peephole2 for above): Check that register-controlled shifts have suitably tied operands. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/arm/thumb2.md
[Bug libstdc++/50349] /usr/bin/ld: warning: wildcard match appears in both version 'GLIBCXX_3.4' and 'CXXABI_1.3' in script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50349 --- Comment #5 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-02-21 23:46:55 UTC --- Author: bkoz Date: Tue Feb 21 23:46:49 2012 New Revision: 184453 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184453 Log: 2012-02-17 Benjamin Kosnik b...@redhat.com PR libstdc++/50349 * config/abi/pre/gnu.ver: Only one local. * config/abi/pre/gnu-versioned-namespace.ver: Same. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver trunk/libstdc++-v3/config/abi/pre/gnu.ver
[Bug libstdc++/50349] /usr/bin/ld: warning: wildcard match appears in both version 'GLIBCXX_3.4' and 'CXXABI_1.3' in script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50349 Benjamin Kosnik bkoz at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.7.0 |--- --- Comment #6 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-02-21 23:50:01 UTC --- Fixed: /mnt/share/bin/H-x86_64-binutils.20120220-gold/bin/ld: warning: wildcard match appears in both version 'GLIBCXX_3.4' and 'CXXABI_1.3' in script /mnt/share/bin/H-x86_64-binutils.20120220-gold/bin/ld: warning: wildcard match appears in both version 'CXXABI_1.3' and 'CXXABI_TM_1' in script With patch. The rest: /mnt/share/bin/H-x86_64-binutils.20120220-gold/bin/ld: warning: using 'GLIBCXX_3.4' as version for '_ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv' which is also named in version 'GLIBCXX_3.4.6' in script /mnt/share/bin/H-x86_64-binutils.20120220-gold/bin/ld: warning: using 'GLIBCXX_3.4' as version for '_ZNKSs11_M_disjunctEPKc' which is also named in version 'GLIBCXX_3.4.5' in script /mnt/share/bin/H-x86_64-binutils.20120220-gold/bin/ld: warning: using 'GLIBCXX_3.4' as version for '_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw' which is also named in version 'GLIBCXX_3.4.5' in script are correct warnings, but the symbols are correct. This is symbol hiding, and gold warns for this but GNU ld does not. Doesn't matter, binary is still the same.
[Bug target/52294] [4.7 Regression] [ARM Thumb] generated asm code produces branch out of range error in gas with -Os -mcpu=cortex-a9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52294 --- Comment #10 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-02-21 23:51:21 UTC --- Author: rearnsha Date: Tue Feb 21 23:51:16 2012 New Revision: 184454 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184454 Log: PR target/52294 * thumb2.md (thumb2_shiftsi3_short): Split register and immediate shifts. For register shifts tie operands 0 and 1. (peephole2 for above): Check that register-controlled shifts have suitably tied operands. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/arm/thumb2.md
[Bug target/52323] i386: gcse runs amok with pic-addresses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52323 --- Comment #3 from Jan Seiffert kaffeemonster at googlemail dot com 2012-02-22 00:03:53 UTC --- My use case are not large floating point math funcs. While intrinsics are nice (the new Tile ports rock! Every spec. instruction as intrinsic from day 1, that's how it should be for a VLIW arch, can't say the same for IA64...), for x86 they are generally not on my radar. x86 being the primary architecture today for my use case, if things are only mediocre on PPC/ARM or whatever, i can live with it, but not for x86. And on x86 intrinsics simply do not work good enough. Intrinsics have one deadly limitation: You can only use them if -march= is set right. And x86 has one gazillion ISA extensions, every 2 years a new one. This way you can not wright code which dynamically dispatches at runtime. User which get code by some general build (Distro, package from website) are the majority for x86. You can expect from an PPC user or ARM user or Alpha user to set his march right, he will be compiling it by himself anyway, but not for x86. Also distros hate it when you do not obey the CFLAGS they set during build and muck around with these CFLAGS (for good reasons). BMI2 is an ISA extention where the CPUs will only get released. If there are intrinsics in GCC for it, it's prop. somewhere in CVS. GCCs in use out there are generally not bleeding edge new. Another problem is what GCC (but also other compiler) does when he is one or two register short (very common on i386). Stackframe, foo, bar, often not the perfect spill (to but it in a positive light). This is the point where a human can either: a) find a better spill (more cold) b) squeeze and push and shove to make it fit. But you can't flip a switch on a compiler: please be 20% smarter now. And so why write it as inline asm instead of a stand alone .s? Let the compiler do the leg work, that's his job. Calling conventions, debug info, sections, .gnu-note-stack, pic/non-pic, etc. I only need to write the kernel and can do as much or few as i like to, without wasting any thought on the ASM boiler plate stuff. I could write it with intrinsics for this testcase (but then the problem would prop. vanish?), i generally do not for x86 and this is a snipped from a larger code body. (the alpha version uses __builtin_zapnot and __builtin_cmpbge, the NEON version uses the stuff from neon.h, but for other instruction sets, there are not enough intrinsics or they work poorly (ex. ARM iWMMXt, MIPS Loongson)...)
[Bug target/52294] [4.7 Regression] [ARM Thumb] generated asm code produces branch out of range error in gas with -Os -mcpu=cortex-a9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52294 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.7.0 |4.5.4 --- Comment #11 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-02-22 00:11:27 UTC --- Fixed in 4.5, 4.6 and trunk
[Bug target/52261] [avr] Add support for AVR Xmega cores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52261 --- Comment #5 from Stefan Reichardt fbi.sr at gmx dot de 2012-02-22 01:38:52 UTC --- Its no problem to compile and link it that way but i dont have that device so cant test it. I would make a patch myself and post it here and on binutils, if i knew that this would only involve copying some lines from the devices without USB support. Some devices like xmega128A1U are already there so i suppose all functionality for the new USB devices is already in the code. Maybe you or Eric could give a short statement about this? Stefan
[Bug c++/50043] [C++0x] Implement core/1123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50043 --- Comment #3 from Michel Morin mimomorin at gmail dot com 2012-02-22 02:43:30 UTC --- Created attachment 26721 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26721 A updated testcase OK, here is a take two!
[Bug fortran/52333] New: Explicit etime interface should work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52333
Bug #: 52333
Summary: Explicit etime interface should work
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pablo...@googlemail.com
gfortran differs from all other compilers I have access to (Intel's, NAG's,
PathScale's, Portland Group's, Sun's and g95) in that it does not accept
defining an explicit interface to the etime intrinsic:
--
$ cat test_etime.f90
PROGRAM test_etime
IMPLICIT NONE
REAL x(2)
print *,etime(x)
END PROGRAM test_etime
$ cat test_etime_iface.f90
PROGRAM test_etime_iface
IMPLICIT NONE
REAL x(2)
INTERFACE
REAL FUNCTION etime(x)
REAL,INTENT(inout) :: x(2)
END FUNCTION etime
END INTERFACE
print *,etime(x)
END PROGRAM test_etime_iface
$ echo NY ;\
for c in gfortran ifort nagfor pathf95 pgf95 g95 sunf95 ; do\
$c -o t test_etime.f90 /dev/null a=1 || a=0 ;\
rm -f t *.o ;\
$c -o t test_etime_iface.f90 /dev/null a=${a}1 || a=${a}0 ;\
rm -f t *.o ;\
echo $a - $c ;\
done
NY
10 - gfortran
01 - ifort
00 - nagfor
11 - pathf95
01 - pgf95
11 - g95
01 - sunf95
--
The above table tells us if each compiler succeeded (1) or failed (0) compiling
the code without (N) or with (Y) an explicit etime interface. Without the
explicit interface the outcome is mixed, but every compiler other than gfortran
will successfully compile the code with the explicit interface (if the compiler
provides an etime extension; nagfor doesn't).
The same thing happens if one uses etime as a subroutine (with a second
argument): gfortran is alone in failing to compile the code if there is an
explicit interface. Using etime as a subroutine and not providing an explicit
interface seems to work on all of the above compilers, including gfortran.
This may be true of other extensions or intrinsics - I can run specific tests
with other compilers if this would be helpful.
[Bug fortran/52333] Explicit etime interface should work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52333 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2012-02-22 03:16:04 UTC --- Please define fails. What is the error message you get? All procedure included in gfortran's runtime library are treated as intrinsic procedures unless you use -std= to restrict gfortran to a particular standard. As it is an intrinsic procedure, etime already has an explicit interface. So, trying to re-specify an interface makes no sense.
[Bug fortran/52333] Explicit etime interface should work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52333 --- Comment #2 from kargl at gcc dot gnu.org 2012-02-22 03:29:28 UTC --- (In reply to comment #1) Please define fails. What is the error message you get? All procedure included in gfortran's runtime library are treated as intrinsic procedures unless you use -std= to restrict gfortran to a particular standard. As it is an intrinsic procedure, etime already has an explicit interface. So, trying to re-specify an interface makes no sense. Just a follow-up page 283 in F2008, A procedure shall not have more than one explicit specific interface in a given scoping unit. Now, I need to see if specifying an interface block for a procedure implies the external attribute. That would open a whole other can of worms that one does not want to open.
[Bug fortran/52333] Explicit etime interface should work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52333 --- Comment #3 from pablomme pablomme at googlemail dot com 2012-02-22 03:32:14 UTC --- Please define fails. What is the error message you get? Namely: $ gfortran -o t test_etime_iface.f90 /scratch/pl275/ccyZ7sWC.o: In function `MAIN__': test_etime_iface.f90:(.text+0x4b): undefined reference to `etime_' collect2: ld returned 1 exit status gfortran accepts the inteface but ld fails because the intrinsic has been obscured by a missing external procedure. As it is an intrinsic procedure, etime already has an explicit interface. So, trying to re-specify an interface makes no sense. I don't doubt that gfortran's behaviour may be sensible. The bug here is that it behaves differently from 6 other compilers. About whether this construction makes sense or not, in our code we use this explicit interface in order to support optional compilation of a C replacement for etime for compilers that do not offer the extension. At present, gfortran requires the C replacement because of this problem, but it shouldn't need it. No biggie, of course, but it'd be nice to see this consistency.
[Bug fortran/52333] Explicit etime interface should work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52333 --- Comment #4 from pablomme pablomme at googlemail dot com 2012-02-22 03:40:12 UTC --- Adding EXTERNAL etime to the program gives: -- $ gfortran -o t test_etime_iface.f90 test_etime_iface.f90:9.15: EXTERNAL etime 1 Error: Duplicate EXTERNAL attribute specified at (1) $ ifort -o t test_etime_iface.f90 test_etime_iface.f90(9): error #6409: This name has already been used as an external procedure name. [ETIME] EXTERNAL etime --^ compilation aborted for test_etime_iface.f90 (code 1) -- Then adding INTRINSIC etime gives: -- $ gfortran -o t test_etime_iface.f90 test_etime_iface.f90:9.16: INTRINSIC etime 1 Error: EXTERNAL attribute conflicts with INTRINSIC attribute at (1) $ ifort -o t test_etime_iface.f90 test_etime_iface.f90(9): error #6409: This name has already been used as an external procedure name. [ETIME] INTRINSIC etime ---^ compilation aborted for test_etime_iface.f90 (code 1) -- So ifort seems to agree with gfortran in its error messages that providing an explicit interface to a function implies that the function is EXTERNAL, and that INTRINSIC is incompatible with EXTERNAL. This seems inconsistent with its using the intrinsic version if etime when an explicit interface is present, but there you go..
[Bug fortran/52333] Explicit etime interface should work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52333 --- Comment #5 from Steve Kargl sgk at troutmask dot apl.washington.edu 2012-02-22 03:49:15 UTC --- On Wed, Feb 22, 2012 at 03:32:14AM +, pablomme at googlemail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52333 --- Comment #3 from pablomme pablomme at googlemail dot com 2012-02-22 03:32:14 UTC --- Please define fails. What is the error message you get? Namely: $ gfortran -o t test_etime_iface.f90 /scratch/pl275/ccyZ7sWC.o: In function `MAIN__': test_etime_iface.f90:(.text+0x4b): undefined reference to `etime_' collect2: ld returned 1 exit status gfortran accepts the inteface but ld fails because the intrinsic has been obscured by a missing external procedure. Well, obscured may be misleading. gfortran's intrinsic procedure is named _gfortran_etime. When you give the interface block, gfortran is clearly treating this as an external procedure. I'm still reading through Sec. 12 of F2008 to see if this is the expected behavior. As it is an intrinsic procedure, etime already has an explicit interface. So, trying to re-specify an interface makes no sense. I don't doubt that gfortran's behaviour may be sensible. The bug here is that it behaves differently from 6 other compilers. Well, the other compilers do not make a very striction distinction between an intrinsic and external procedure for procedures that are supplied with the compiler but are not listed in the standard. gfortran is very consistent with how it treats precedures it supplies in its runtime library. About whether this construction makes sense or not, in our code we use this explicit interface in order to support optional compilation of a C replacement for etime for compilers that do not offer the extension. At present, gfortran requires the C replacement because of this problem, but it shouldn't need it. No biggie, of course, but it'd be nice to see this consistency. What happens with all your compilers if you supply an explicit interface for say DSIN.
[Bug fortran/52333] Explicit etime interface should work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52333 --- Comment #6 from Steve Kargl sgk at troutmask dot apl.washington.edu 2012-02-22 04:16:21 UTC --- On Wed, Feb 22, 2012 at 03:40:12AM +, pablomme at googlemail dot com wrote: So ifort seems to agree with gfortran in its error messages that providing an explicit interface to a function implies that the function is EXTERNAL, and that INTRINSIC is incompatible with EXTERNAL. This seems inconsistent with its using the intrinsic version if etime when an explicit interface is present, but there you go.. Thanks for testing. This points at the other can of worms I mentions. Old code sometimes contains 'external etime', and gfortran will expect a user supplied routine. It will not use _gfortran_etime until the programmer removes the offending statement. I've closed a few bug reports about this and have taken some heat about gfortran's behavior. In the end, we decided that the libgfortran namespace should be segregated from the user's namespace.
[Bug target/52301] avr-gcc 4.6.2 produces NOP loop in simple while statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52301 --- Comment #2 from rickyrockrat gpib at rickyrockrat dot net 2012-02-22 04:27:01 UTC --- Created attachment 26722 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26722 Intermediate file Intermediate file, as requested. Changed name to bug52301.
[Bug target/52301] avr-gcc 4.6.2 produces NOP loop in simple while statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52301 --- Comment #3 from rickyrockrat gpib at rickyrockrat dot net 2012-02-22 04:29:21 UTC --- Created attachment 26723 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26723 Script to compile bug52301.c Script to run avr-gcc on the subject file.
[Bug target/52301] avr-gcc 4.6.2 produces NOP loop in simple while statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52301 --- Comment #4 from rickyrockrat gpib at rickyrockrat dot net 2012-02-22 04:31:11 UTC --- Created attachment 26724 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26724 Assembly generated using script and original source Resulting assembly from recently supplied files - just to make sure the problem is still there.
[Bug target/52301] avr-gcc 4.6.2 produces NOP loop in simple while statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52301 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2012-02-22 04:33:50 UTC --- This is invalid as GCC has no way to know that stat can change. Mark stat as volatile and then GCC will know it can change.
