[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4
--- Comment #18 from dominiq at lps dot ens dot fr 2010-08-05 07:04 --- Unverified but I am told that this issue should be fixed in Xcode 3.2.3. AFAICT it is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
[Bug fortran/45187] ICE with CRAY pointer in module depending on variable name
--- Comment #1 from tkoenig at gcc dot gnu dot org 2010-08-05 07:05 --- Confirmed, also fails with current trunk. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2010-08-05 07:05:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45187
[Bug fortran/45190] New: Compile-time error on valid code: can't convert TYPE(_gfortran_iso_c_binding_c_ptr) to TYPE(c_ptr)
gfortran --version GNU Fortran (GCC) 4.5.1 uname -a Linux tiree.nag.co.uk 2.6.27.25-170.2.72.fc10.x86_64 #1 SMP Sun Jun 21 18:39:34 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux cat cfpointerstress.f90 MODULE NAG_J_TYPES USE ISO_C_BINDING, ONLY : C_PTR IMPLICIT NONE TYPE:: NAG_IMAGE INTEGER :: WIDTH, HEIGHT, PXFMT, NCHAN TYPE (C_PTR) :: PIXELS END TYPE NAG_IMAGE END MODULE NAG_J_TYPES program cfpointerstress use nag_j_types use iso_c_binding implicit none type(nag_image),pointer :: img type(C_PTR) :: ptr real, pointer :: r allocate(r) allocate(img) r = 12 ptr = c_loc(img) write(*,*) 'C_ASSOCIATED =', C_ASSOCIATED(ptr) call c_f_pointer(ptr, img) write(*,*) 'ASSOCIATED =', associated(img) deallocate(r) end program cfpointerstress gfortran cfpointerstress.f90 cfpointerstress.f90:19.8: ptr = c_loc(img) 1 Error: Can't convert TYPE(_gfortran_iso_c_binding_c_ptr) to TYPE(c_ptr) at (1) -- Summary: Compile-time error on valid code: can't convert TYPE(_gfortran_iso_c_binding_c_ptr) to TYPE(c_ptr) Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mathewc at nag dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45190
[Bug libstdc++/45191] New: unqualified atomic access
current implementation has issues with namespace scopes and allows unqualified
access, ie:
#include atomic
int main()
{
atomic_int ai;
return 0;
}
this should require std::atomic_int
--
Summary: unqualified atomic access
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45191
[Bug libgomp/45192] New: OpenMP fails in DLLs
I have an OpenMP code segment: #pragma omp parallel for for (i = 0; i size; i++) Built with mingw gcc 4.4.0. Run on Windows XP SP3, AMD 64 Athlon FX62 dual core. Run in an exe application it works fine, however when invoked as code in a DLL the for loop threads do not increment properly and the loop runs infinitely repeating the same values of i. eg: 19 thread 0 26936 thread 1 20 thread 0 0 thread 1 21 thread 0 19 thread 1 22 thread 0 20 thread 1 21 thread 1 23 thread 0 22 thread 1 0 thread 0 23 thread 1 19 thread 0 24 thread 1 20 thread 0 ... -- Summary: OpenMP fails in DLLs Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john at quivinco dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45192
[Bug libstdc++/45193] New: unqualified atomic access
current implementation has issues with namespace scopes and allows unqualified
access, ie:
#include atomic
int main()
{
atomic_int ai;
return 0;
}
this should require std::atomic_int
--
Summary: unqualified atomic access
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45193
[Bug libstdc++/45193] unqualified atomic access
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-05 09:34 --- *** This bug has been marked as a duplicate of 45191 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45193
[Bug libstdc++/45191] unqualified atomic access
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-05 09:34 --- *** Bug 45193 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45191
[Bug libgomp/45192] OpenMP fails in DLLs
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-05 09:42 --- You probably have to build applications that use the DLL thread-aware. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45192
[Bug debug/45189] [4.6 regression] New stack alignment test failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45189
[Bug debug/45188] [4.6 regression] Failed to bootstrap on Linux/ia64
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45188
[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #2 from jv244 at cam dot ac dot uk 2010-08-05 11:13 --- confirmed with 4.5/4.6, works with 4.3/4.4. Compiling with -fdump-tree-all-lineno and looking into tx_f90_pointers.f90.003t.original shows that most of the lineno info has disappeared in 4.5. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-debug Last reconfirmed|-00-00 00:00:00 |2010-08-05 11:13:14 date|| Summary|Gfortran 4.5.0 emits wrong |[4.5/4.6 Regression] |linenumbers |Gfortran 4.5.0 emits wrong ||linenumbers http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #56 from bernds at gcc dot gnu dot org 2010-08-05 11:31 --- Created an attachment (id=21400) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21400action=view) A patch to aid debugging This patch should help pinpoint exactly what went wrong. It adds a dbg-cnt to the code in question. If you could experiment with passing -fdbg-cnt=bug:N to the compiler, where N is an integer value, using a binary search you should arrive relatively quickly at a value of N where the generated code is OK for N but fails for N + 1. Then, could you attach good/bad assembly files and debug dumps? Just the .expand, .combine and .ira dumps initially would be helpful if we want to save disk space here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug lto/45194] New: lto1: internal compiler error: in lto_varpool_replace_node, at lto-symtab.c:292
With gcc trunk revision 162816 I am unable to compile Firefox with WHOPR (or LTO, for that matter) because I get the following ICE: lto1: internal compiler error: in lto_varpool_replace_node, at lto-symtab.c:292 I will attach preprocessed versions of four source files which are necessary to reproduce the issue. -- Summary: lto1: internal compiler error: in lto_varpool_replace_node, at lto-symtab.c:292 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jamborm at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45194
[Bug lto/45194] lto1: internal compiler error: in lto_varpool_replace_node, at lto-symtab.c:292
--- Comment #1 from jamborm at gcc dot gnu dot org 2010-08-05 11:53 --- Created an attachment (id=21401) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21401action=view) Original testcase After extracting, set CC and CXX variables to paths to c and c++ compilers respectively and run the run script: $ CXX=/abuild/mjambor/inst/icln/bin/g++ CC=/abuild/mjambor/inst/icln/bin/gcc ./run + /abuild/mjambor/inst/icln/bin/gcc -fPIC -fno-exceptions -fwhopr=24 -fuse-linker-plugin -fno-strict-aliasing -pthread -pipe -Os -freorder-blocks -fno-reorder-functions -fomit-frame-pointer -c sysunix.i + /abuild/mjambor/inst/icln/bin/gcc -fPIC -fno-exceptions -fwhopr=24 -fuse-linker-plugin -fno-strict-aliasing -pthread -pipe -Os -freorder-blocks -fno-reorder-functions -fomit-frame-pointer -c editline.i + /abuild/mjambor/inst/icln/bin/g++ -fPIC -fno-exceptions -fwhopr=24 -fuse-linker-plugin -fno-strict-aliasing -pthread -pipe -Os -freorder-blocks -fno-reorder-functions -fomit-frame-pointer -c -fno-rtti -fpermissive -Wno-invalid-offsetof js.ii + /abuild/mjambor/inst/icln/bin/g++ -fPIC -fno-exceptions -fwhopr=24 -fuse-linker-plugin -fno-strict-aliasing -pthread -pipe -Os -freorder-blocks -fno-reorder-functions -fomit-frame-pointer -c -fno-rtti -fpermissive -Wno-invalid-offsetof jsworkers.ii + /abuild/mjambor/inst/icln/bin/g++ -o js -fPIC -fno-exceptions -fwhopr=24 -fuse-linker-plugin -fno-strict-aliasing -pthread -pipe -Os -freorder-blocks -fno-reorder-functions -fomit-frame-pointer js.o jsworkers.o editline.o sysunix.o -lpthread -Wl,-rpath-link,/bin -Wl,-rpath-link,/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm lto1: internal compiler error: in lto_varpool_replace_node, at lto-symtab.c:292 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /abuild/mjambor/inst/icln/bin/g++ returned 1 exit status /usr/bin/gold: fatal error: lto-wrapper failed collect2: ld returned 1 exit status -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45194
[Bug fortran/44065] [OOP] Undefined reference to vtab$...
--- Comment #14 from janus at gcc dot gnu dot org 2010-08-05 11:58 --- (In reply to comment #13) On x86_64-apple-darwin10.4.0 at r162881, I have tested all the codelets I have for the PRs fixed by r162879 with both -m32 and -m64 without linking error. Great. So I guess we can close this PR. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44065
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #23 from janus at gcc dot gnu dot org 2010-08-05 12:11 --- For me all the test cases seems to be working now. Mikael, can we close this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug tree-optimization/45195] New: incorrect array subscript above bounds warning
Using GCC 4.4.1 and the following command, test generates an array subscript
is above array bounds warning.
gcc -S -Os test.c -Wall
void foo (int b[2][6])
{
int i = 0;
for (i = 0; i 6; i++)
{
int *pb = b[1][i];
*pb = 0;
}
}
Output from VRP looks like
foo (int[6] * b)
{
int i;
unsigned int D.1240;
unsigned int i.0;
bb 2:
goto bb 6;
bb 3:
# i_16 = PHI i_1(4), i_14(6)
i.0_6 = (unsigned int) i_16;
D.1240_7 = i.0_6 + 6;
(*b_4(D))[D.1240_7] = 0; -- warning generated here
i_10 = i_16 + 1;
bb 4:
# i_1 = PHI i_10(3)
if (i_1 = 5)
goto bb 3;
else
goto bb 5;
bb 5:
return;
bb 6:
# i_14 = PHI 0(2)
goto bb 3;
}
In the statement (*b_4(D))[D.1240_7] = 0, range of b_4 appears to be [0 5]
while the range of index D.1240_7 is [6 11].
--
Summary: incorrect array subscript above bounds warning
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rahul at icerasemi dot com
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45195
[Bug libgomp/45192] OpenMP fails in DLLs
--- Comment #2 from john at quivinco dot com 2010-08-05 12:39 --- Thanks, but how is that done? Is it in the documentation? (In reply to comment #1) You probably have to build applications that use the DLL thread-aware. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45192
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #24 from mikael at gcc dot gnu dot org 2010-08-05 12:59 --- (In reply to comment #23) For me all the test cases seems to be working now. Mikael, can we close this? I'll backport the fixes to 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug fortran/44857] [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:4996
--- Comment #17 from clerman at fuse dot net 2010-08-05 13:03 --- Subject: Re: [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:4996 Hello, Your fix worked fine, and I am now again able to build my application. Thanks again. Yours truly, Norm Norman S. Clerman Consulting computer scientist burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: = --- Comment #14 from burnus at gcc dot gnu dot org 2010-08-04 11:53 --- FIXED on the trunk (4.6). Thanks for the report! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44857 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44857
[Bug tree-optimization/45195] incorrect array subscript above bounds warning
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-05 13:16 --- Fixed in 4.4.3. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.4.3 Resolution||FIXED Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45195
[Bug testsuite/42855] FAIL: gcc.dg/tree-ssa/pr42585.c scan-tree-dump-times optimized *
--- Comment #8 from jamborm at gcc dot gnu dot org 2010-08-05 13:36 --- Subject: Bug 42855 Author: jamborm Date: Thu Aug 5 13:36:18 2010 New Revision: 162913 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162913 Log: 2010-08-05 Martin Jambor mjam...@suse.cz PR testsuite/42855 * testsuite/gcc.dg/tree-ssa/pr42585.c: Skip dump scan on powerpc and arm. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42855
[Bug target/45196] New: ld: warning: can't add line info to anonymous symbol
The cleanups to i386 prologue/epilogue generation (r162882 -r162891) cause 161 libstdc++ failures at -m32 on *86*-apple-darwin10 due to new warnings of the form... Executing on host: /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/g++ -shared-libgcc -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.4.0/i386/libstdc++-v3/src -L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.4.0/i386/libstdc++-v3/src/.libs -B/sw/lib/gcc4.6/x86_64-apple-darwin10.4.0/bin/ -B/sw/lib/gcc4.6/x86_64-apple-darwin10.4.0/lib/ -isystem /sw/lib/gcc4.6/x86_64-apple-darwin10.4.0/include -isystem /sw/lib/gcc4.6/x86_64-apple-darwin10.4.0/sys-include -m32 -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.4.0/i386/libstdc++-v3/src/.libs -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -g -O2 -DLOCALEDIR=. -nostdinc++ -I/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.4.0/i386/libstdc++-v3/include/x86_64-apple-darwin10.4.0 -I/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.4.0/i386/libstdc++-v3/include -I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100803/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100803/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100803/libstdc++-v3/testsuite/util /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100803/libstdc++-v3/testsuite/19_diagnostics/error_code/cons/39882.cc -std=gnu++0x ./libtestc++.a -lm -m32 -o ./39882.exe(timeout = 600) ld: warning: can't add line info to anonymous symbol initializer$0 from /var/tmp//ccuyXXr3.o^M output is: ld: warning: can't add line info to anonymous symbol initializer$0 from /var/tmp//ccuyXXr3.o^M FAIL: 19_diagnostics/error_code/cons/39882.cc (test for excess errors) Excess errors: ld: warning: can't add line info to anonymous symbol initializer$0 from /var/tmp//ccuyXXr3.o This has been filed as radar://8274440, ld: warning: can't add line info to anonymous symbol, with two standalone testcases generated before and after the patches. According the darwin linker developer, the explanation and possible workaround are as follows... - ld: warning: can't add line info to anonymous symbol initializer$0 from 39882.o [/tmp/anonymous_symbol_post] size -l 39882.o ... Section (__TEXT, __textcoal_nt): 176 (addr 0x6580 offset 27668) Section (__DATA, __mod_init_func): 4 (addr 0x6630 offset 27844) ... I suspect what is happening is that the dwarf debug line info has a pc-range that goes from the last function in the __textcoal_nt section up to the start of the __mod_init_func section. When ld is parsing the debug line info, it sees a pc address that is in the __mod_init_func section and issues the warning. The linker should be smarter and realize the pc address is the *end* address and therefore ok to be also the beginning address of another section. You could work around this by moving the __textcoal_nt section to be after the __text section. That is, put a .section __TEXT, __textcoal_nt,blah,blah directive at the top of the file before the .section __DWARF, blah directives. This would mean any edge cases in the end of the __textcoal_nt would be into the __DWARF sections with ld ignores. - He also mentioned that this bug doesn't appear to exist in the Xcode 4.0 linker (so it will go away in the future) and that it is in fact a non-fatal warning (but that the resulting dwarf line tables might be bad). -- Summary: ld: warning: can't add line info to anonymous symbol Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: *86*-apple-darwin10 GCC host triplet: *86*-apple-darwin10 GCC target triplet: *86*-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45196
[Bug c/45176] restrict qualifier is not used in a manually unrolled loop
--- Comment #4 from siarhei dot siamashka at gmail dot com 2010-08-05 13:40 --- Looks like this missed optimization regression was introduced in gcc 4.5 Are any similar fixes possible in 4.5 branch? -- siarhei dot siamashka at gmail dot com changed: What|Removed |Added CC||siarhei dot siamashka at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45176
[Bug c/45176] restrict qualifier is not used in a manually unrolled loop
--- Comment #5 from bmei at broadcom dot com 2010-08-05 13:44 --- I tried to apply the patches (this one alone is not enough) Richard suggested. It becomes a chain of too many patches in the end. I am confident any more to apply them to 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45176
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #21 from janus at gcc dot gnu dot org 2010-08-05 13:56 --- Subject: Bug 44929 Author: janus Date: Thu Aug 5 13:56:00 2010 New Revision: 162914 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162914 Log: 2010-08-05 Janus Weil ja...@gcc.gnu.org Steven G. Kargl ka...@gcc.gnu.org PR fortran/44929 * match.c (match_type_spec): Try to parse derived types before intrinsic types. 2010-08-05 Janus Weil ja...@gcc.gnu.org PR fortran/44929 * gfortran.dg/allocate_derived_3.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/allocate_derived_3.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/match.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #22 from janus at gcc dot gnu dot org 2010-08-05 13:57 --- Fixed on trunk an 4.5. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug debug/45189] [4.6 regression] New stack alignment test failures
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-05 14:04 --- It is caused by revision 162888: http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00099.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45189
[Bug target/45196] ld: warning: can't add line info to anonymous symbol
--- Comment #1 from iains at gcc dot gnu dot org 2010-08-05 14:23 ---
does this solve the problem?
(it's a hack - we should ensure that the debug sections do not appear in
between our program sections, but that's for another day).
Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c (revision 162881)
+++ gcc/config/darwin.c (working copy)
@@ -1699,6 +1699,23 @@ darwin_asm_output_dwarf_delta (FILE *file, int siz
void
darwin_file_start (void)
{
+ fputs (\t.const\n\t.static_const\n\t.cstring\n, asm_out_file) ;
+ fputs (\t.literal4\n\t.literal8\n\t.literal16\n, asm_out_file) ;
+ fputs (\t.data\n\t.static_data\n\t.const_data\n, asm_out_file) ;
+ if (!TARGET_64BIT)
+{
+ if (flag_pic == 2)
+ fputs (\t.picsymbol_stub\n, asm_out_file) ;
+ else
+ fputs (\t.symbol_stub\n, asm_out_file) ;
+ fputs (\t.lazy_symbol_pointer\n\t.non_lazy_symbol_pointer\n,
asm_out_file);
+ fputs (\t.section __TEXT,__textcoal_nt,coalesced,pure_instructions\n,
asm_out_file);
+}
+ else
+{
+ fputs (\t.section
__TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support\n,
asm_out_file) ;
+}
+ in_section = NULL;
if (write_symbols == DWARF2_DEBUG)
{
static const char * const debugnames[] =
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
CC||iains at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45196
[Bug bootstrap/45053] libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc
--- Comment #5 from paolo dot carlini at oracle dot com 2010-08-05 14:38 --- Ian, is this a libgcc issue? Can you suggest the best wa to triage it? Thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45053
[Bug fortran/45197] New: [F2008] Allow IMPURE elemental procedures
In Fortran 2008, an ELEMENTAL procedure needs not necessarily be PURE. Procedures can now be specified to be IMPURE, and if this is applied to an ELEMENTAL procedure it is not automatically PURE as it otherwise is. For instance, the following code will fill b(n) with cumulative sum of elements in array element order and thus print (/ 1, 3, 6, 10, 15 /): PROGRAM main IMPLICIT NONE INTEGER, PARAMETER :: n = 5 INTEGER :: i REAL :: a(n), b(n), s a = (/ (i, i = 1, n) /) s = 0.0 b = accumulate (a, s) PRINT *, b CONTAINS IMPURE ELEMENTAL FUNCTION accumulate (a, s) REAL, INTENT(IN) :: a REAL, INTENT(INOUT) :: s REAL :: accumulate s = s + a accumulate = s END FUNCTION accumulate END PROGRAM main -- Summary: [F2008] Allow IMPURE elemental procedures Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45197
[Bug target/45198] New: Unnecessary spill slot for highpart extraction of xmm reg
When building g++.dg/torture/pr36445.C at -O2 you can see
call_Z5func2v
movaps %xmm0, (%rsp)
movq(%rsp), %rdx
movq8(%rsp), %rax
movq%rdx, 16(%rsp)
movl%eax, 24(%rsp)
where the stack-slot spills are caused by
(insn 26 5 27 2 (set (reg:V4SF 72)
(reg:V4SF 21 xmm0))
/space/rguenther/src/svn/trunk/gcc/testsuite/g++.dg/torture/pr36445.C:20 1054
{*movv4sf_internal}
(nil))
(insn 27 26 28 2 (set (reg:DI 70 [ D.2130 ])
(subreg:DI (reg:V4SF 72) 0))
/space/rguenther/src/svn/trunk/gcc/testsuite/g++.dg/torture/pr36445.C:20 61
{*movdi_internal_rex64}
(nil))
(insn 28 27 24 2 (set (reg:DI 71 [ D.2130+8 ])
(subreg:DI (reg:V4SF 72) 8))
/space/rguenther/src/svn/trunk/gcc/testsuite/g++.dg/torture/pr36445.C:20 61
{*movdi_internal_rex64}
(nil))
where we are unable to verify the constraints for insn 28 because there
is no move pattern that would special case hipart extraction (which
could use movhps).
--
Summary: Unnecessary spill slot for highpart extraction of xmm
reg
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: x86-64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45198
[Bug fortran/45197] [F2008] Allow IMPURE elemental procedures
--- Comment #1 from domob at gcc dot gnu dot org 2010-08-05 15:02 --- Mine. -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-05 15:02:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45197
[Bug target/45198] Unnecessary spill slot for highpart extraction of xmm reg
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-05 15:03 --- Created an attachment (id=21402) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21402action=view) patch needed Patch needed to trigger this exact situation with that exact testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45198
[Bug debug/45189] [4.6 regression] New stack alignment test failures
--- Comment #2 from rth at gcc dot gnu dot org 2010-08-05 15:40 --- Subject: Bug 45189 Author: rth Date: Thu Aug 5 15:39:54 2010 New Revision: 162917 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162917 Log: PR 45189 Unbreak ia64 build after last dwarf2out.c change. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45189
[Bug debug/42487] FAIL: gcc.dg/debug/dwarf2/aranges-fnsec-1.c scan-assembler DW_AT_ranges
--- Comment #4 from danglin at gcc dot gnu dot org 2010-08-05 15:43 --- Also seen on darwin9. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-05 15:43:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42487
[Bug fortran/45190] Compile-time error on valid code: can't convert TYPE(_gfortran_iso_c_binding_c_ptr) to TYPE(c_ptr)
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-05 15:46 --- The problem also occurs with 4.6.0. Note, if you remove the ', only : c_ptr' in NAG_J_TYPES, the code compiles and produces laptop:kargl[214] gfc4x -o z tr.f90 laptop:kargl[215] ./z C_ASSOCIATED = T ASSOCIATED = T So, there appears to be a problem with using an ONLY clause with ISO C binding. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-05 15:46:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45190
[Bug target/45198] Unnecessary spill slot for highpart extraction of xmm reg
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-05 15:53 ---
Sth like
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 162913)
+++ config/i386/i386.md (working copy)
@@ -1957,6 +1957,30 @@ (define_insn *movti_internal_sse
(const_string V4SF)]
(const_string TI)))])
+(define_insn *movdi_internal_rex642
+ [(set (match_operand:DI 0 nonimmediate_operand
+ =r,m)
+ (subreg:DI
+ (match_operand:V4SF 1 register_operand
+ x,x) 0))]
+ TARGET_SSE2
+ @
+ movq\t{%1, %0|%0, %1}
+ movq\t{%1, %0|%0, %1}
+ [(set_attr type ssemov)])
+
+(define_insn *movdi_internal_rex642
+ [(set (match_operand:DI 0 nonimmediate_operand
+ =r,m)
+ (subreg:DI
+ (match_operand:V4SF 1 register_operand
+ x,x) 8))]
+ TARGET_SSE2
+ @
+ movhps\t{%1, %0|%0, %1}
+ movhps\t{%1, %0|%0, %1}
+ [(set_attr type ssemov)])
+
(define_insn *movdi_internal_rex64
[(set (match_operand:DI 0 nonimmediate_operand
=r,r ,r,m ,!m,*y,*y,?r ,m ,?*Ym,?*y,*x,*x,?r ,m,?*Yi,*x,?*x,?*Ym)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45198
[Bug target/45198] Unnecessary spill slot for highpart extraction of xmm reg
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-08-05 15:55 --- (subreg:DI + (match_operand:V4SF 1 register_operand + x,x) 0) That is not a valid subreg and should have be rejected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45198
[Bug target/45198] Unnecessary spill slot for highpart extraction of xmm reg
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-05 15:58 --- How did you get that subreg in the first place; it should have produced a vec_extract there instead of a subreg. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45198
[Bug fortran/45190] Compile-time error on valid code: can't convert TYPE(_gfortran_iso_c_binding_c_ptr) to TYPE(c_ptr)
--- Comment #2 from dominiq at lps dot ens dot fr 2010-08-05 16:03 --- The problem also occurs with 4.6.0. As well as with 4.4.4. Note that an other pr related to the use of ONLY (pr44702) has been fixed by Tobias Burnus: I CCed him. -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45190
[Bug target/45198] Unnecessary spill slot for highpart extraction of xmm reg
--- Comment #5 from rguenther at suse dot de 2010-08-05 16:16 --- Subject: Re: Unnecessary spill slot for highpart extraction of xmm reg On Thu, 5 Aug 2010, pinskia at gcc dot gnu dot org wrote: --- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-05 15:58 --- How did you get that subreg in the first place; it should have produced a vec_extract there instead of a subreg. via forwprop from (subreg:DI (subreg:TI (:V4SF)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45198
[Bug debug/45189] [4.6 regression] New stack alignment test failures
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-05 16:38 --- -fpic is broken. On Fedora 13, I got: [...@gnu-15 gcc]$ ./xgcc -B./ /net/gnu-6/export/gnu/import/git/gcc/gcc/testsuite/g++.dg/torture/stackalign/eh-thiscall-1.C -mstackrealign -mpreferred-stack-boundary=5 -O -c [...@gnu-15 gcc]$ g++ eh-thiscall-1.o [...@gnu-15 gcc]$ ./a.out [...@gnu-15 gcc]$ ./xgcc -B./ /net/gnu-6/export/gnu/import/git/gcc/gcc/testsuite/g++.dg/torture/stackalign/eh-thiscall-1.C -mstackrealign -mpreferred-stack-boundary=5 -O -c -fpic [...@gnu-15 gcc]$ g++ eh-thiscall-1.o [...@gnu-15 gcc]$ ./a.out Segmentation fault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45189
[Bug target/45198] Unnecessary spill slot for highpart extraction of xmm reg
--- Comment #6 from hjl dot tools at gmail dot com 2010-08-05 16:44 --- Unlike integer modes, middle-end only knows memory when moving with subreg on vector mode. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-05 16:44:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45198
[Bug target/45198] Unnecessary spill slot for highpart extraction of xmm reg
--- Comment #7 from hjl dot tools at gmail dot com 2010-08-05 16:58 --- Can we add direct support for moving with (subreg:DI (reg:TI)) and (subreg:TI (reg:OI))? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45198
[Bug bootstrap/45174] Make fails in zlib
--- Comment #13 from rwild at gcc dot gnu dot org 2010-08-05 17:01 --- config.log excerpt from zlib: configure:7903: result: yes configure:7936: checking whether the gcc -m64 linker (ld) supports shared libraries configure:9020: result: yes configure:9265: checking dynamic linker characteristics configure:9710: error: Link tests are not allowed after GCC_NO_EXECUTABLES. which corresponds to this code in zlib/configure, from AC_PROG_LIBTOOL: lt_cv_shlibpath_overrides_runpath=no save_LDFLAGS=$LDFLAGS save_libdir=$libdir eval libdir=/foo; wl=\$lt_prog_compiler_wl\; \ LDFLAGS=\\$LDFLAGS $hardcode_libdir_flag_spec\ if test x$gcc_no_link = xyes; then as_fn_error Link tests are not allowed after GCC_NO_EXECUTABLES. $LINENO 5 Either GCC or the user needs to prime cache variables in the way this test shows: http://git.savannah.gnu.org/cgit/libtool.git/tree/tests/no-executables.at (There is currently one item missing there for AIX, which is relevant for GCC but irrelevant to this particular PR). This same issue supposedly holds for other GCC directories in which GCC_NO_EXECUTABLES is used; it might just be latent. Question is, what values the variables should be primed with. In general, tough one. In this specific case: find out whether your linker sets DT_RUNPATH upon -Wl,-rpath (yes) or only DT_RPATH (no). Pass lt_cv_shlibpath_overrides_runpath=no or =yes to configure accordingly. Hmm. How can I ensure this primes the cache for host directories only? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45174
[Bug fortran/37829] Incorrect name mangling with iso_c_binding
--- Comment #13 from mikael at gcc dot gnu dot org 2010-08-05 17:51 --- *** Bug 45190 has been marked as a duplicate of this bug. *** -- mikael at gcc dot gnu dot org changed: What|Removed |Added CC||mathewc at nag dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
[Bug fortran/45190] Compile-time error on valid code: can't convert TYPE(_gfortran_iso_c_binding_c_ptr) to TYPE(c_ptr)
--- Comment #3 from mikael at gcc dot gnu dot org 2010-08-05 17:51 --- I think it is the same as pr37829. *** This bug has been marked as a duplicate of 37829 *** -- mikael at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45190
[Bug target/45196] ld: warning: can't add line info to anonymous symbol
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-08-05 17:55 --- This bug doesn't occur with the actual committed version of the cleanups to i386 prologue/epilogue generation (as opposed to the proposed patches). Let's leave this open for now in case it reappears. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45196
[Bug debug/45188] [4.6 regression] Failed to bootstrap on Linux/ia64
--- Comment #1 from rth at gcc dot gnu dot org 2010-08-05 17:59 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45188
[Bug target/45189] [4.6 regression] New stack alignment test failures
--- Comment #4 from rth at gcc dot gnu dot org 2010-08-05 18:01 --- I've now reproduced this on a 64-bit host with -m32, though still not on the 32-bit host. -- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Component|debug |target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-05 18:01:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45189
[Bug target/45189] [4.6 regression] New stack alignment test failures
--- Comment #5 from rth at gcc dot gnu dot org 2010-08-05 18:05 --- Subject: Bug 45189 Author: rth Date: Thu Aug 5 18:04:58 2010 New Revision: 162919 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162919 Log: PR target/45189 Fix unwind for i386 stack re-alignment. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45189
[Bug target/45189] [4.6 regression] New stack alignment test failures
--- Comment #6 from rth at gcc dot gnu dot org 2010-08-05 18:13 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45189
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #57 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-05 19:26 --- Subject: Re: [4.6 regression] Revision 162270 failed to bootstrap On Thu, 05 Aug 2010, bernds at gcc dot gnu dot org wrote: If you could experiment with passing -fdbg-cnt=bug:N to the compiler, where N is an integer value, using a binary search you should arrive relatively quickly at a value of N where the generated code is OK for N but fails for N + 1. Then, could you attach good/bad assembly files and debug dumps? Just the .expand, .combine and .ira dumps initially would be helpful if we want to save disk space here. Failure occurs for N = 0. N = 1 compiles successfully. Attached files. Dave --- Comment #58 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-05 19:26 --- Created an attachment (id=21403) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21403action=view) --- Comment #59 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-05 19:26 --- Created an attachment (id=21404) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21404action=view) --- Comment #60 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-05 19:26 --- Created an attachment (id=21405) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21405action=view) --- Comment #61 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-05 19:26 --- Created an attachment (id=21406) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21406action=view) --- Comment #62 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-05 19:26 --- Created an attachment (id=21407) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21407action=view) --- Comment #63 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-05 19:26 --- Created an attachment (id=21408) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21408action=view) --- Comment #64 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-05 19:26 --- Created an attachment (id=21409) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21409action=view) --- Comment #65 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-05 19:26 --- Created an attachment (id=21410) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21410action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #66 from bernds at gcc dot gnu dot org 2010-08-05 19:56 --- (In reply to comment #57) Failure occurs for N = 0. N = 1 compiles successfully. Attached files. Argh. I seem to have swapped the logic of the dbg_cnt test. Still, this result appears useful. I think initial RTL generation is fine, so it looks like my change has exposed a latent bug. What seems to happen is that some pass between expand and combine lengthens the lifetime of register %r25, which holds an incoming argument, so that it now crosses another call, which clobbers it. This seems to happen in fwprop1, Cc Paolo. I can't find any code in that pass which tries to handle the situation. -- bernds at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org AssignedTo|bernds at gcc dot gnu dot |bonzini at gnu dot org |org | Status|ASSIGNED|UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug tree-optimization/45199] New: ICE in loop distribution
When compiled with -O3 the following code ICEs on amd64-linux. parameter(numlev=3,numoblev=1000) integer i_otyp(numoblev,numlev), i_styp(numoblev,numlev) logical l_numob(numoblev,numlev) do ixe=1,numoblev do iye=1,numlev i_otyp(ixe,iye)=0 i_styp(ixe,iye)=0 l_numob(ixe,iye)=.false. enddo enddo do i=1,m do j=1,n if (l_numob(i,j)) then write(20,'(7I4,F12.2,4F16.10)') i_otyp(i,j),i_styp(i,j) endif enddo enddo end -- Summary: ICE in loop distribution Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: spop at gcc dot gnu dot org ReportedBy: spop at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45199
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #67 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-05 20:54 --- Subject: Re: [4.6 regression] Revision 162270 failed to bootstrap I think initial RTL generation is fine, so it looks like my change has exposed a latent bug. What seems to happen is that some pass between expand and combine lengthens the lifetime of register %r25, which holds an incoming argument, so that it now crosses another call, which clobbers it. This seems to happen in fwprop1, Cc Paolo. I can't find any code in that pass which tries to handle the situation. Yes, the rtl generated by fwprop1 is wrong as r25 is clobbered by the call to pool_alloc. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug c++/45200] New: ICE in template instantiation
The attached code leads to segfaults when compiled with gcc-4.5.0 or gcc-4.5.1. gcc-4.4.1 accepts the code. I have absolutely no idea what is actually causing the segfault, as the very same instantiation does not segfault in another context. -- Summary: ICE in template instantiation Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mr dot chr dot schmidt at online dot de GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45200
[Bug c++/45200] ICE in template instantiation
--- Comment #1 from mr dot chr dot schmidt at online dot de 2010-08-05 21:02 --- Created an attachment (id=21411) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21411action=view) preprocessed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45200
[Bug c++/45200] ICE in template instantiation
--- Comment #2 from mr dot chr dot schmidt at online dot de 2010-08-05 21:04 --- Created an attachment (id=21412) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21412action=view) g++ -v / g++ reverse.cpp output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45200
[Bug fortran/44064] [OOP] ICE with file containing two modules and one program
--- Comment #15 from mikael at gcc dot gnu dot org 2010-08-05 21:08 --- Subject: Bug 44064 Author: mikael Date: Thu Aug 5 21:08:36 2010 New Revision: 162921 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162921 Log: 2010-08-05 Mikael Morin mik...@gcc.gnu.org Janus Weil ja...@gcc.gnu.org PR fortran/42051 PR fortran/44064 PR fortran/45151 * intrinsic.c (gfc_get_intrinsic_sub_symbol): Commit changed symbol. * symbol.c (gen_cptr_param, gen_fptr_param, gen_shape_param, gfc_copy_formal_args, gfc_copy_formal_args_intr, gfc_copy_formal_args_ppc, generate_isocbinding_symbol): Ditto. (gfc_find_derived_vtab): Commit newly created symbols. * parse.c (parse_derived_contains, parse_spec, parse_progunit): Call reject_statement in case of error. (match_deferred_characteritics): Call gfc_undo_symbols in case match fails. Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/intrinsic.c branches/gcc-4_5-branch/gcc/fortran/parse.c branches/gcc-4_5-branch/gcc/fortran/symbol.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44064
[Bug fortran/45151] [4.6 regression] New Fortran failuires
--- Comment #16 from mikael at gcc dot gnu dot org 2010-08-05 21:08 --- Subject: Bug 45151 Author: mikael Date: Thu Aug 5 21:08:36 2010 New Revision: 162921 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162921 Log: 2010-08-05 Mikael Morin mik...@gcc.gnu.org Janus Weil ja...@gcc.gnu.org PR fortran/42051 PR fortran/44064 PR fortran/45151 * intrinsic.c (gfc_get_intrinsic_sub_symbol): Commit changed symbol. * symbol.c (gen_cptr_param, gen_fptr_param, gen_shape_param, gfc_copy_formal_args, gfc_copy_formal_args_intr, gfc_copy_formal_args_ppc, generate_isocbinding_symbol): Ditto. (gfc_find_derived_vtab): Commit newly created symbols. * parse.c (parse_derived_contains, parse_spec, parse_progunit): Call reject_statement in case of error. (match_deferred_characteritics): Call gfc_undo_symbols in case match fails. Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/intrinsic.c branches/gcc-4_5-branch/gcc/fortran/parse.c branches/gcc-4_5-branch/gcc/fortran/symbol.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45151
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #25 from mikael at gcc dot gnu dot org 2010-08-05 21:08 --- Subject: Bug 42051 Author: mikael Date: Thu Aug 5 21:08:36 2010 New Revision: 162921 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162921 Log: 2010-08-05 Mikael Morin mik...@gcc.gnu.org Janus Weil ja...@gcc.gnu.org PR fortran/42051 PR fortran/44064 PR fortran/45151 * intrinsic.c (gfc_get_intrinsic_sub_symbol): Commit changed symbol. * symbol.c (gen_cptr_param, gen_fptr_param, gen_shape_param, gfc_copy_formal_args, gfc_copy_formal_args_intr, gfc_copy_formal_args_ppc, generate_isocbinding_symbol): Ditto. (gfc_find_derived_vtab): Commit newly created symbols. * parse.c (parse_derived_contains, parse_spec, parse_progunit): Call reject_statement in case of error. (match_deferred_characteritics): Call gfc_undo_symbols in case match fails. Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/intrinsic.c branches/gcc-4_5-branch/gcc/fortran/parse.c branches/gcc-4_5-branch/gcc/fortran/symbol.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug c++/45200] ICE in template instantiation
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-08-05 21:08 --- Trunk gives: ..\..\..\..\../boost/fusion/view/reverse_view/detail/end_impl.hpp:39:13: internal compiler error: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:10167 Please submit a full bug report, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45200
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #26 from mikael at gcc dot gnu dot org 2010-08-05 21:11 --- Done -- mikael at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug tree-optimization/45199] ICE in loop distribution
--- Comment #1 from dominiq at lps dot ens dot fr 2010-08-05 21:11 --- Confirmed on x86_64-apple-darwin10 (for both -m32 and -m64) and the code compiles with -O2 -ftree-vectorize. Revision 162490 is OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45199
[Bug c++/45200] ICE in template instantiation
--- Comment #4 from mr dot chr dot schmidt at online dot de 2010-08-05
21:14 ---
A workaround is to wrap the faulting template instantiation in a thin wrapper:
typename detail::forward_as_lref
Seq
, typename detail::remove_referenceSeq::type::seq_type
::type
... does not work, whereas ...
templatetypename TestType,typename Type
struct forward_as_gcc_helper
: detail::forward_as_lrefTestType, Type
{};
typename forward_as_gcc_helper
Seq
, typename detail::remove_referenceSeq::type::seq_type
::type
... compiles fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45200
[Bug fortran/44660] [4.4/4.5 Regression] ICE in resolve_equivalence()
--- Comment #21 from mikael at gcc dot gnu dot org 2010-08-05 21:38 --- Subject: Bug 44660 Author: mikael Date: Thu Aug 5 21:38:36 2010 New Revision: 162922 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162922 Log: 2010-08-05 Mikael Morin mik...@gcc.gnu.org PR fortran/44660 * gfortran.h (gfc_namespace): New field old_equiv. (gfc_free_equiv_until): New prototype. * match.c (gfc_free_equiv_until): New, renamed from gfc_free_equiv with a parameterized stop condition. (gfc_free_equiv): Use gfc_free_equiv_until. * parse.c (next_statement): Save equivalence list. (reject_statement): Restore equivalence list. Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/gfortran.h branches/gcc-4_5-branch/gcc/fortran/match.c branches/gcc-4_5-branch/gcc/fortran/parse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44660
[Bug tree-optimization/45199] ICE in loop distribution
--- Comment #2 from dominiq at lps dot ens dot fr 2010-08-05 21:40 --- Backtrace #0 find_uses_to_rename_use (bb=0x141f28138, use=0x141f13058, use_blocks=value temporarily unavailable, due to optimizations, need_phis=value temporarily unavailable, due to optimizations) at ../../work/gcc/tree-ssa-loop-manip.c:1242 #1 0x000100780838 in find_uses_to_rename_bb (bb=value temporarily unavailable, due to optimizations, use_blocks=0x141923730, need_phis=0x142081b68) at ../../work/gcc/tree-ssa-loop-manip.c:284 #2 0x000100780f0e in rewrite_into_loop_closed_ssa (changed_bbs=value temporarily unavailable, due to optimizations, update_flag=value temporarily unavailable, due to optimizations) at ../../work/gcc/tree-ssa-loop-manip.c:331 #3 0x0001006f0131 in distribute_loop (loop=0x7fff5fbfd550, stmts=value temporarily unavailable, due to optimizations) at ../../work/gcc/tree-loop-distribution.c:1094 #4 0x0001006f160f in tree_loop_distribution () at ../../work/gcc/tree-loop-distribution.c:1215 #5 0x0001005d1e46 in execute_one_pass (pass=0x100cdb420) at ../../work/gcc/passes.c:1564 #6 0x0001005d211d in execute_pass_list (pass=0x100cdb420) at ../../work/gcc/passes.c:1619 #7 0x0001005d212f in execute_pass_list (pass=0x100cdc5e0) at ../../work/gcc/passes.c:1620 #8 0x0001005d212f in execute_pass_list (pass=0x100cdb7e0) at ../../work/gcc/passes.c:1620 #9 0x0001007017ac in tree_rest_of_compilation (fndecl=0x141efc900) at ../../work/gcc/tree-optimize.c:452 #10 0x0001008d038d in cgraph_expand_function (node=0x141f03000) at ../../work/gcc/cgraphunit.c:1643 #11 0x0001008d363a in cgraph_optimize () at ../../work/gcc/cgraphunit.c:1722 #12 0x0001008d3cca in cgraph_finalize_compilation_unit () at ../../work/gcc/cgraphunit.c:1185 #13 0x00010055f506 in write_global_declarations () at ../../work/gcc/langhooks.c:310 #14 0x00010069358e in toplev_main (argc=3, argv=0x7fff5fbfd9c8) at ../../work/gcc/toplev.c:983 #15 0x000117e4 in start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45199
[Bug fortran/44660] [4.4 Regression] ICE in resolve_equivalence()
--- Comment #22 from mikael at gcc dot gnu dot org 2010-08-05 21:40 --- Only 4.4 left. Let's not weaken now. -- mikael at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.4.5 4.5.1 |4.4.5 Known to work|4.3.6 4.6.0 |4.3.6 4.6.0 4.5.1 Summary|[4.4/4.5 Regression] ICE in |[4.4 Regression] ICE in |resolve_equivalence() |resolve_equivalence() http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44660
[Bug c++/45201] New: ICE: stack overflow during debug information generation
The attached code will lead to a stack overflow if compiled with -std=c++0x and -g . The code compiles fine without -g. gcc-4.5.0 accepts the code just fine as well, even when compiled with -g. -- Summary: ICE: stack overflow during debug information generation Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mr dot chr dot schmidt at online dot de GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45201
[Bug c++/45201] ICE: stack overflow during debug information generation
--- Comment #1 from mr dot chr dot schmidt at online dot de 2010-08-05 21:53 --- Created an attachment (id=21413) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21413action=view) preprocessed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45201
[Bug c++/45201] ICE: stack overflow during debug information generation
--- Comment #2 from mr dot chr dot schmidt at online dot de 2010-08-05 21:54 --- Created an attachment (id=21414) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21414action=view) g++ -v / g++ proto_fusion.cpp -std=c++0x -g output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45201
[Bug libstdc++/45202] New: Strict aliasing warning in stl_tree (returning a copy of a set from a member function in a loop)
The following code (as small as I can get but I'm not sure its minimal)
#include set
struct X{
unsigned a;
X(){}
bool operator(const X i)const { return a i.a; }
};
struct R{
std::setX getSet() const{
std::setX result;
result.insert(X());
return result;
}
};
void bug(){
for(unsigned x = 0; x 2; ++x){
std::setX pts = R().getSet();
}
}
Produces the following warnings:
bug-check2.cpp: In function void bug():
bug-check2.cpp:6: warning: dereferencing pointer __x.22 does break
strict-aliasing rules
/usr/include/c++/4.4/bits/stl_tree.h:525: note: initialized from here
bug-check2.cpp:6: warning: dereferencing pointer __x.22 does break
strict-aliasing rules
/usr/include/c++/4.4/bits/stl_tree.h:525: note: initialized from here
When compiled with:
g++ -Wall -O3 -c bug-check2.cpp
With version 4.4.1 on Ubuntu 9.10 (Sorry for the old version, it would take
hours to recompile g++ and I already have put several into reducing the
test-case.)
I will be attaching the g++ verbose output, the preprocessed source, and the
original source.
Unusual symptoms:
1. Making getSet static or a global function removes the warning.
2. Reducing the number of loop iterations below 2 reduces or removes the
warning.
3. Removing the constructor for X removes one of the warnings.
4. Changing X::operator to return a constant value removes the warning
5. Changing X::operator to {return a b; } where b is a global variable
removes the warning
6. Removing the result.insert(X()) line removes the warnings
7. Making result a global variable removes the warnings.
--
Summary: Strict aliasing warning in stl_tree (returning a copy of
a set from a member function in a loop)
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric_moyer at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45202
[Bug libstdc++/45202] Strict aliasing warning in stl_tree (returning a copy of a set from a member function in a loop)
--- Comment #1 from eric_moyer at yahoo dot com 2010-08-05 22:02 --- Created an attachment (id=21415) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21415action=view) Test case: original source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45202
[Bug libstdc++/45202] Strict aliasing warning in stl_tree (returning a copy of a set from a member function in a loop)
--- Comment #2 from eric_moyer at yahoo dot com 2010-08-05 22:03 --- Created an attachment (id=21416) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21416action=view) Test case: preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45202
[Bug libstdc++/45202] Strict aliasing warning in stl_tree (returning a copy of a set from a member function in a loop)
--- Comment #3 from eric_moyer at yahoo dot com 2010-08-05 22:04 --- Created an attachment (id=21417) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21417action=view) Test case: output of g++ 4.4.1-ubutntu9 with -v switch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45202
[Bug libstdc++/45202] Strict aliasing warning in stl_tree (returning a copy of a set from a member function in a loop)
--- Comment #4 from eric_moyer at yahoo dot com 2010-08-05 22:18 --- This is not a duplicate of bug# 39390 because my copy of g++ compiles the test case for that bug without complaint. It may be related to 42032 since that does not compile correctly but (1) the error messages are different; (2) the errors are for different lines of the stl_tree file; and (3) that bug relates to a map rather than a set -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45202
[Bug c++/45200] ICE in template instantiation
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-05 22:42 --- It is caused by revision 145440: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00060.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||dseketel at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-05 22:42:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45200
[Bug c++/45203] New: [Feature request] #pragma start_no_warn_regex
I am requesting a pragma to suppress warnings that match a given regular expression. (Really I'd be happy with any way to suppress arbitrary warnings for small sections of code. This is just my proposal of a simple way to do it.) I propose adding two new pragmas: #pragma start_no_warn_regex [regular expression here to end of line] and #pragma end_no_warn_regex When the preprocessor encounters start_no_warn_regex, it pushes the regular expression onto a stack of regular expressions. When it encounters end_no_warn_regex, it pops the top regex off the stack. Then for any line of code, if a warning would be emitted that matches any regex in the stack, that warning is suppressed. - Why? - Warnings, by definition are going to have false positives. However, after one has looked carefully at the case in question (through a code-review or whatever other quality assurance procedures are in place) and decided that the code as written is good, the warning becomes noise needing to be mentally filtered out by the programmer each time and possibly obscuring new warnings that should be heeded. This can be especially burdensome in library code. One may have a complex templated class in a header that compiles correctly but which produces warnings. The library should not emit warnings because the user can not fix the problem. However, giving the compiler enough analysis force to avoid spitting out the warning is impractical. It is better for the compiler to flag suspicious things that are tractable to find and allow the human analytical skills to fill in the gap. Some warnings can be handled by simple code changes: I leave out the names of variables in function calls where the variable is unused; I initialize some variables in unreachable code that the compiler does not know is unreachable; I initialize others twice to avoid warnings about possible use of x uninitialized. and so forth. However, I would like a general method of warning suppression and #pragma start_no_warn_regex provides an easy and powerful way of meeting this goal. (Of course choose a shorter name if you'd like, the effect is what I'm interested in.) Disabling warnings for an entire compilation unit is the other way to attack this problem. However, it is too blunt a tool. I only know that variable x is not being used uninitialized on line y. Variable q on line r of the same routine may be genuinely uninitialized and I would still like to be warned about but not told that variable x is possibly uninitialized. -- Summary: [Feature request] #pragma start_no_warn_regex Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eric_moyer at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45203
[Bug c++/45203] [Feature request] #pragma start_no_warn_regex
-- eric_moyer at yahoo dot com changed: What|Removed |Added Severity|normal |enhancement Summary|[Feature request] #pragma |[Feature request] #pragma |start_no_warn_regex |start_no_warn_regex http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45203
[Bug c++/45203] [Feature request] #pragma start_no_warn_regex
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-05 23:17 --- Starting with 4.5 you can disable a class of warnings in the source. This is better than a regular expression as it is safe for internationalization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45203
[Bug bootstrap/41818] Error building cross compiler caused by changing LD_LIBRARY_PATH environment variable in Makefile
--- Comment #11 from lacombar at gmail dot com 2010-08-05 23:29 --- I encountered that issue with gcc 4.3.4 on the following target: mips-unknown-linux-uclibc. I'm currently confirming with gcc 4.3.5. If it still happen, would it be worth pulling to the 4.3 branch ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41818
[Bug c/45204] New: gcc generates incorrect code
Apologies in advance for not being able to create a small code sample. The code is in SourceForge GIT repository for treedb. To build treedb you will need v3c - the GIT version. First download v3c and make prefix=[install-location] [sudo] make install. cd [treedb-dir] make debug check works but make git branch=master check fails - hangs. The release build (make release) is definately incorrect. The code has some hacks for strict aliasing but contrary to the documentation, these aren't caught with -fstrict-aliasing -Wstrict-aliasing. The makefile I used to build gcc and it's required libraries follows. all: cd build/gmp ../../gmp-4.3.2/configure --prefix=/opt/gcc --enable-cxx \ make sudo make install cd build/mpfr ../../mpfr-3.0.0/configure --prefix=/opt/gcc --with-gmp=/opt/gcc \ make sudo make install cd build/mpc ../../mpc-0.8.2/configure --prefix=/opt/gcc --with-mpfr=/opt/gcc \ make sudo make install cd build/ppl ../../ppl-0.10.2/configure --prefix=/opt/gcc --with-libgmp-prefix=/opt/gcc --with-libgmpxx-prefix=/opt/gcc --enable-cxx --no-create --no-recursion \ make sudo make install cd build/cloog-ppl ../../cloog-ppl-0.15.9/configure --with-ppl=/opt/gcc --with-gmp=/opt/gcc --prefix=/opt/gcc \ make sudo make install cd build/gcc-4.5.1 ../../gcc-4.5.1/configure -v --with-pkgversion=Philip Ashmore's build 4.5.1-1 --with-bugurl=file:///opt/gcc/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++ --prefix=/opt/gcc --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/opt/gcc/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/opt/gcc/include/c++/4.5 --program-suffix=-4.5 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --with-arch-32=i586 --with-tune=core2 --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-mpc=/opt/gcc --with-mpfr=/opt/gcc --with-gmp=/opt/gcc --with-ppl=/opt/gcc --with-cloog=/opt/gcc \ make sudo make install -- Summary: gcc generates incorrect code Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: contact at philipashmore dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45204
[Bug bootstrap/41818] Error building cross compiler caused by changing LD_LIBRARY_PATH environment variable in Makefile
--- Comment #12 from lacombar at gmail dot com 2010-08-06 00:01 --- ok, 3.4.5, same target is bad too: ./mips-unknown-linux-uclibc/libstdc++-v3/config.log: error while loading shared libraries: /targets/mips-unknown-linux-uclibc/build/build-cc/./gcc/libgcc_s.so.1: ELF file data encoding not little-endian -- lacombar at gmail dot com changed: What|Removed |Added CC||lacombar at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41818
[Bug c/45205] New: printf does not print some long doubles correctly
The following code should print 18014398509481983.0 but it prints 36028797018963967.0 instead . long double a = 18014398509481984.0; long double b = -1.0; long double c = a + b; printf(%.1Lf\n, c); I used gcc -v -save-temps -Wall main.c -- Summary: printf does not print some long doubles correctly Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kmmertes at gmail dot com GCC build triplet: powerpc-apple-darwin8 GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45205
[Bug c/45205] printf does not print some long doubles correctly
--- Comment #1 from kmmertes at gmail dot com 2010-08-06 00:41 --- Created an attachment (id=21418) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21418action=view) short program that demonstrates the problem and possible cause -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45205
[Bug c/45205] printf does not print some long doubles correctly
--- Comment #2 from kmmertes at gmail dot com 2010-08-06 00:44 --- Created an attachment (id=21419) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21419action=view) preprocessed file for main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45205
[Bug target/45205] printf does not print some long doubles correctly
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-08-06 01:13 --- Can you provide the output of gcc -v ? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45205
[Bug c++/45203] [Feature request] #pragma start_no_warn_regex
--- Comment #2 from eric_moyer at yahoo dot com 2010-08-06 02:09 --- If you are talking about #pragma GCC diagnostic that looks good. Turning off error classes is sufficiently fine grained. However the pragma is only guaranteed to work on a file-wide scope. The 4.5 manual says, Also, while it is syntactically valid to put these pragmas anywhere in your sources, the only supported location for them is before any data or functions are defined. Doing otherwise may result in unpredictable results depending on how the optimizer manages your sources. I want to disable warnings for particular lines of code rather than whole files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45203
[Bug target/45205] printf does not print some long doubles correctly
--- Comment #4 from kmmertes at gmail dot com 2010-08-06 03:15 --- Sorry I forgot to include output of gcc -v: Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5367.obj~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5367) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45205
[Bug target/45205] printf does not print some long doubles correctly
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-08-06 03:17 --- You should report this to Apple and here. We don't support 4.0.x any more. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45205
[Bug target/45205] printf does not print some long doubles correctly
--- Comment #6 from kmmertes at gmail dot com 2010-08-06 04:17 --- Can you compile and run the program on a PowerPC computer with a version of gcc that you do support to see if the problem persists? Here is the output from my system: a - 18014398509481984.0 : 43 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + b - -1.0 : bf f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = c - 36028797018963967.0 : 43 50 00 00 00 00 00 00 bf f0 00 00 00 00 00 00 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45205
[Bug target/45205] printf does not print some long doubles correctly
--- Comment #7 from kmmertes at gmail dot com 2010-08-06 04:21 --- Prettier version of output (I hope): a - 18014398509481984.0 : 43 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +b - -1.0 : bf f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =c - 36028797018963967.0 : 43 50 00 00 00 00 00 00 bf f0 00 00 00 00 00 00 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45205
