[Bug preprocessor/41943] include search path composition is bogus
--- Comment #5 from rainer at emrich-ebersheim dot de 2009-12-04 08:24 --- Subject: Re: include search path composition is bogus -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ktietz at gcc dot gnu dot org schrieb: --- Comment #4 from ktietz at gcc dot gnu dot org 2009-12-03 21:56 --- Would it be a solution (at least for -w64- targets) to remove the sys-root/mingw part and default to sysroot/include sysroot/lib instead. At least for the -w64- targets there is no real need of this /mingw subfolder. Kai I'm fine with such a solution! Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksYxxMACgkQoUhjsh59BL4zKQCfYIyhzc8De0cE7D5xjG9QCYg1 z6MAnjvLRVeV/a0bSks4jFHf0cwt27VY =bekw -END PGP SIGNATURE- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41943
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #20 from dominiq at lps dot ens dot fr 2009-12-04 08:25 --- At revision 154970, there are still 16 failures, but the error has changed for libffi.call/cls_longdouble.c: ... FAIL: libffi.call/cls_longdouble.c -O0 -W -Wall output pattern test, is 1 2 3 4 5 6 7 8: 36 ... Looking at the log file, I see: 1 2 3 4 5 6 7 8: 36 res: 36 1 2 3 4 5 6 7 7: 35 res: 35 PASS: libffi.call/cls_longdouble.c -O2 execution test FAIL: libffi.call/cls_longdouble.c -O2 output pattern test, is 1 2 3 4 5 6 7 8: 36 res: 361 2 3 4 5 6 7 7: 35res: 35 , should match 1 2 3 4 5 6 7 8: 36^M? res: 36^M? 1 2 3 4 5 6 7 8: 36^M? res: 36 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug c++/42266] [C++0x] ICE with decltype and variadic templates
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-04 08:50 --- Thanks Jason, it looks like the larger testcases we have also build fine now! -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC|jason at gcc dot gnu dot org| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42266
[Bug libstdc++/42261] infinite recursion from string(string::size_type(6), string::size_type('f'))
--- Comment #5 from paolo at gcc dot gnu dot org 2009-12-04 09:21 --- Subject: Bug 42261 Author: paolo Date: Fri Dec 4 09:20:58 2009 New Revision: 154975 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154975 Log: 2009-12-04 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/42261 * include/bits/basic_string.h (_S_construct_aux(_Integer, _Integer, const _Alloc, __true_type)): Cast the second argument to value_type. * include/ext/sso_string_base.h (_M_construct_aux(_Integer, _Integer, std::__true_type)): Likewise. * include/ext/rc_string_base.h (_S_construct_aux(_Integer, _Integer, const _Alloc, std::__true_type)): Likewise. * testsuite/21_strings/basic_string/cons/char/42261.cc: New. * testsuite/21_strings/basic_string/cons/wchar_t/42261.cc: Likewise. Added: branches/gcc-4_4-branch/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/42261.cc branches/gcc-4_4-branch/libstdc++-v3/testsuite/21_strings/basic_string/cons/wchar_t/42261.cc Modified: branches/gcc-4_4-branch/libstdc++-v3/ChangeLog branches/gcc-4_4-branch/libstdc++-v3/include/bits/basic_string.h branches/gcc-4_4-branch/libstdc++-v3/include/ext/rc_string_base.h branches/gcc-4_4-branch/libstdc++-v3/include/ext/sso_string_base.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42261
[Bug libstdc++/42261] infinite recursion from string(string::size_type(6), string::size_type('f'))
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-04 09:21 --- Fixed for 4.4.3 too, arguably this is a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42261
[Bug libstdc++/42273] New: atomic_2.h:111: = instead of == in if
Is it a silly bug or a contrived way of calling __sync_synchronize regardless
of the required memory_order?
--- atomic_2.h 2009-12-04 11:23:26.0 +0200
+++ atomic_2.h 2009-12-04 11:23:35.0 +0200
@@ -108,7 +108,7 @@
{
// write_mem_barrier();
_M_i = __v;
- if (__m = memory_order_seq_cst)
+ if (__m == memory_order_seq_cst)
__sync_synchronize();
}
}
--
Summary: atomic_2.h:111: = instead of == in if
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: to dot roma dot from dot bugcc at qwertty dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42273
[Bug libstdc++/42273] atomic_2.h:111: = instead of == in if
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-04 09:31 --- Benjamin, can you check this? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42273
[Bug c++/42272] derived template default argument
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-04 09:48 --- SMARTA a(); This does not declare an object of type SMARTA, it declares a function called 'a' which returns SMARTA You need to change that to: SMARTA a; or SMARTA a = SMARTA(); -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42272
[Bug ada/41912] FAIL: gnat.dg/null_pointer_deref1.adb execution test
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2009-12-04 09:52
---
The catch for the first null pointer exception in libjava.lang/Array_3
is not caught but I don't know why.
Very likely because of the adjustment made in libjava/pa-signal.h:
#define MAKE_THROW_FRAME(_exception)\
do \
{ \
struct ucontext *uc = (struct ucontext *)arg; \
struct sigcontext *sc = uc-uc_mcontext; \
(void)_dummy; \
(void)_info; \
/* Advance the program counter so that it is after the start \
of the instruction: the exception handler expects \
the PC to point to the instruction after a call. */\
sc-sc_iaoq[0] = sc-sc_iaoq[1]; \
sc-sc_iaoq[1] += 4; \
} \
while (0)
That's not true if you set fs-signal_frame to 1 in the fallback routine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41912
[Bug ada/41912] FAIL: gnat.dg/null_pointer_deref1.adb execution test
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2009-12-04 09:58
---
Very likely because of the adjustment made in libjava/pa-signal.h:
libjava/hppa-signal contains a slight variant:
#define MAKE_THROW_FRAME(_exception)\
do \
{ \
ucontext_t *_context = (ucontext_t *) arg;\
(void)_dummy; \
(void)_info; \
mcontext_t *mc = (_context-uc_mcontext);\
SetSSReg (mc, ss_pcoq_head, GetSSReg (mc, ss_pcoq_tail)); \
SetSSReg (mc, ss_pcsq_head, GetSSReg (mc, ss_pcsq_tail)); \
/* This part is not quit right if the head pc was pointing\
at a branch. The tail needs to be adjusted to the branch \
target if the branch is taken. The tail space register\
may need adjustment as well if the branch is an interspace \
branch. */\
SetSSReg (mc, ss_pcoq_tail, (GetSSReg (mc, ss_pcoq_tail) + 4)); \
\
} \
while (0)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41912
[Bug ada/41912] FAIL: gnat.dg/null_pointer_deref1.adb execution test
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2009-12-04 10:18 --- That's not true if you set fs-signal_frame to 1 in the fallback routine. And I need to do the same clean-up in include/dwarf2-signal.h and include/sparc-signal.h for SPARC... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41912
[Bug bootstrap/42271] os_defines.h:60:1: error: expected '{' before '_GLIBCXX_PSEUDO_VISIBILITY'
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-04 10:49 --- Let's add DaveK in CC -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||dave dot korn dot cygwin at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42271
[Bug libstdc++/42273] atomic_2.h:111: = instead of == in if
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-04 10:54 --- the suggested change is correct -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42273
[Bug libstdc++/42273] atomic_2.h:111: = instead of == in if
--- Comment #3 from redi at gcc dot gnu dot org 2009-12-04 11:00 --- Although as I noted in Bug 40297 comment 2 I think that function should also have a memory barrier when m == memory_order_release, which the current code has by accident because of this bug ... so arguably it's better that way! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42273
[Bug rtl-optimization/42269] [4.4/4.5 Regression] Extra sign extension instructions generated
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-04 11:40 --- P4 unless this affects primary or secondary targets. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P4 Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42269
[Bug middle-end/42110] [4.5 Regression] ICE with inlining
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-04 12:03 --- This also happens when I try to reproduce the tramp3d profile mismatch (well, if checking is enabled only obviously). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42110
[Bug middle-end/42110] [4.5 Regression] ICE with inlining
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-04 12:06 --- The ICE goes away with -fno-ipa-cp. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42110
[Bug target/41780] File gcc/config/arm/lib1funcs.asm broken for THUMB version 1 since r150545
--- Comment #3 from sebastian dot huber at embedded-brains dot de 2009-12-04 12:15 --- The problem is still present with: arm-elf-gcc (GCC) 4.5.0 20091203 (experimental) -- sebastian dot huber at embedded-brains dot de changed: What|Removed |Added CC||rguenther at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41780
[Bug libgcj/40868] ecjx.cc should be compiled by host gcc
--- Comment #6 from flameeyes at gentoo dot org 2009-12-04 12:54 --- Created an attachment (id=19222) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19222action=view) Proposed patch With this patch applied, gcj cross-builds fine (not a canadian cross though). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868
[Bug middle-end/42110] [4.5 Regression] ICE with inlining
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-04 13:00 --- So we come in tree-inline.c: 1695 if (id-transform_call_graph_edges == CB_CGE_MOVE_CLONES) 1696cgraph_create_edge_including_clones as we figure out a new direct call. But while cgraph_create_edge_including_clones creates a new edge with CIF_ORIGINALLY_INDIRECT_CALL failed reason it does not create a new clone for the callee even though the callee has global.inlined_to set (though it isn't a clone appearantly: A* A::fooA()/7(-1) @0xb7cb9924 (inline copy in void baz()/1) availability:available 17 time, 12 benefit 6 size, 3 benefit reachable body finalized inlinable called by: void Banonymous ::fooB(char) [with int anonymous = 0]/5 (1.00 per call) (can throw external) void Banonymous ::fooB(char) [with int anonymous = 0]/6 (1.00 per call) (inlined) (can throw external) calls: bool foo()/4 (1.00 per call) (can throw external) bool foo()/4 (0.39 per call) (can throw external) so we shouldn't create a new direct call edge to an inline-copy node but to it's real node. Somehow. Maybe we removed that node already? Indeed. We remove it's clone_of here: Breakpoint 7, cgraph_remove_node (node=0xb7cb9384) at /home/richard/src/trunk/gcc/cgraph.c:1282 gdb) up #1 0x08ae1705 in cgraph_remove_unreachable_nodes (before_inlining_p=0 '\000', file=0x0) at /home/richard/src/trunk/gcc/ipa.c:213 213 cgraph_remove_node (node); (gdb) #2 0x08ab1fd1 in cgraph_optimize () at /home/richard/src/trunk/gcc/cgraphunit.c:1791 1791 cgraph_remove_unreachable_nodes (false, dump_file); (gdb) #3 0x08aaf8e5 in cgraph_finalize_compilation_unit () at /home/richard/src/trunk/gcc/cgraphunit.c:1083 1083 cgraph_optimize (); and the callee node looks like this before we proceed with removing: A* A::fooA()/7(-1) @0xb7cb9924 (inline copy in void baz()/1) (clone of A* A::fooA()/0) availability:available 17 time, 12 benefit 6 size, 3 benefit reachable body finalized inlinable called by: void Banonymous ::fooB(char) [with int anonymous = 0]/6 (1.00 per call) (inlined) (can throw external) calls: bool foo()/4 (1.00 per call) (can throw external) bool foo()/4 (0.39 per call) (can throw external) no idea if keeping the clone_of would have magically solved the problem here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42110
[Bug target/41780] File gcc/config/arm/lib1funcs.asm broken for THUMB version 1 since r150545
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-04 13:04 --- patches need to be sent to gcc-patc...@gcc.gnu.org please specify if older gcc versions work for you. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC|rguenther at suse dot de|rearnsha at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41780
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #5 from dominiq at lps dot ens dot fr 2009-12-04 13:17 --- The smaller testcase of comment #1 is fixed with Confirmed The original fails because the vtable cannot be found. THis is due to: use grid_module, only : grid Removing the ,only : grid restores correct linkage. I don't see any difference with/without ,only : grid. In both cases I get: [trunk revision 154654] pr42051*.f90:27:0: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:550 [branch fortran-dev revision 154936] and [trunk revision 154973p4v] f951: internal compiler error: in gfc_build_null_descriptor, at fortran/trans-array.c:372 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug target/41780] File gcc/config/arm/lib1funcs.asm broken for THUMB version 1 since r150545
--- Comment #5 from sebastian dot huber at embedded-brains dot de 2009-12-04 13:31 --- This one works: arm-elf-gcc (GCC) 4.4.3 20091201 (prerelease) I think that r150545 introduced the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41780
[Bug middle-end/42110] [4.5 Regression] ICE with inlining
--- Comment #7 from hjl dot tools at gmail dot com 2009-12-04 13:45 --- It is caused by revision 154200: http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00421.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42110
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -funroll*-loops
--- Comment #8 from dominiq at lps dot ens dot fr 2009-12-04 14:21 --- It may be related to PR 42202. If I am not mistaken this has been fixed by revision 154944 (see http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg00343.html ). However this pr is not fixed at revision 154970. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -funroll*-loops
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug fortran/42131] Weird translation of DO loops
--- Comment #29 from dominiq at lps dot ens dot fr 2009-12-04 14:24 --- AFAICT the inner loop of PR42108 is still unrolled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug middle-end/42202] [4.5 regression] Revision 154688 caused many gfortran failures
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-04 14:24 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42202
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #24 from dominiq at lps dot ens dot fr 2009-12-04 14:25 --- AFAICT fixing pr42131 does not help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug rtl-optimization/41862] [4.5 Regression] -fgcse-sm causes bootstrap comparison failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41862
[Bug rtl-optimization/42216] [4.5 Regression] changes in scheduling regress 464.h264ref 20%
--- Comment #18 from bernds_cb1 at t-online dot de 2009-12-04 14:26 --- Unfortunately it causes failures. Tracking these mismatches really is quite tricky. I'll try to fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42216
[Bug fortran/42274] New: ICE: segmentation fault
The attached code gives an ICE against the fortran-dev branch as of r154975. [sfili...@donald bug12]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnudev/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran : (reconfigured) ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran Thread model: posix gcc version 4.5.0 20091203 (experimental) (GCC) [sfili...@donald bug12]$ gfortran -c bug12.f03 bug12.f03:229:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE: segmentation fault Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it 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=42274
[Bug fortran/42274] ICE: segmentation fault
--- Comment #1 from sfilippone at uniroma2 dot it 2009-12-04 14:30 --- Created an attachment (id=19223) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19223action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug rtl-optimization/42216] [4.5 Regression] changes in scheduling regress 464.h264ref 20%
--- Comment #19 from rguenther at suse dot de 2009-12-04 14:34 --- Subject: Re: [4.5 Regression] changes in scheduling regress 464.h264ref 20% On Fri, 4 Dec 2009, bernds_cb1 at t-online dot de wrote: --- Comment #18 from bernds_cb1 at t-online dot de 2009-12-04 14:26 --- Unfortunately it causes failures. Tracking these mismatches really is quite tricky. I'll try to fix it. Thanks. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42216
[Bug libffi/42275] New: pkg-config (.pc) file missing in libffi (lost during import)
http://gcc.gnu.org/viewcvs/trunk/libffi/ does not have a libffi.pc.in in its source tree, which that is present in the tree the code got imported from: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libffi/?cvsroot=libffi This caused issues elsewhere, e.g. https://bugzilla.gnome.org/show_bug.cgi?id=603653 -- Summary: pkg-config (.pc) file missing in libffi (lost during import) Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ensonic at hora-obscura dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42275
[Bug fortran/42274] ICE: segmentation fault
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-04 14:48 --- Fortran people - if you want to use bugzilla for fortran-dev please add a fortran-dev version people can report bugs against. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Version|4.5.0 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] ICE: segmentation fault
--- Comment #3 from dominiq at lps dot ens dot fr 2009-12-04 14:58 --- The code compiles with [trunk revision 154654]. It looks like a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] ICE: segmentation fault
--- Comment #4 from sfilippone at uniroma2 dot it 2009-12-04 15:02 --- (In reply to comment #3) The code compiles with [trunk revision 154654]. It looks like a regression. Yes, I know, this is due to the recent work by Paul Thomas and Janus Weil about the dynamic dispatching implementation via vtables. I opened a PR to have a clear track for this problem. Richard is probably right, it should be clearly marked against the branch, except that I have neither the knowledge nor the authorization for doing it. Salvatore -- sfilippone at uniroma2 dot it changed: What|Removed |Added Version|unknown |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug java/42276] When creating cross-gcj compiler, libjvm gets installed in system library paths
--- Comment #1 from flameeyes at gentoo dot org 2009-12-04 15:06 --- Created an attachment (id=19224) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19224action=view) Proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42276
[Bug libffi/42275] pkg-config (.pc) file missing in libffi (lost during import)
--- Comment #1 from ensonic at hora-obscura dot de 2009-12-04 15:39 --- Also is the copy of the lib actually needed, could gcc not use the standalone libffi instead? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42275
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #5 from burnus at gcc dot gnu dot org 2009-12-04 15:57 --- (In reply to comment #3) Richard is probably right, it should be clearly marked against the branch, I have now set Reported against to 'fortran-dev', marked it in the Subject line and in 'known to work/fail' Backtrace: mio_pointer_ref (gp=0x28) at /home/tob/projects/fortran-dev/gcc/fortran/module.c:2237 2237 p = get_pointer (*((char **) gp)); (gdb) bt #0 mio_pointer_ref (gp=0x28) at /home/tob/projects/fortran-dev/gcc/fortran/module.c:2237 #1 0x004f8da9 in mio_symbol_ref (symp=value optimized out) at /home/tob/projects/fortran-dev/gcc/fortran/module.c:2498 #2 0x004f90e9 in mio_typebound_proc (proc=0x154b908) at /home/tob/projects/fortran-dev/gcc/fortran/module.c:3352 #3 0x004fa344 in mio_component (c=0x154b880) at /home/tob/projects/fortran-dev/gcc/fortran/module.c:2362 -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||fortran-dev Known to work||4.5.0 Last reconfirmed|-00-00 00:00:00 |2009-12-04 15:57:20 date|| Summary|ICE: segmentation fault |[fortran-dev Regression] ||ICE: segmentation fault Version|unknown |fortran-dev http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug other/42230] abi::__cxa_demangle fails to return the length of the decoded name
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-04 16:20 --- I'm recategorizing as other, because actually the demangler doesn't belong to the library. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Component|libstdc++ |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42230
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #21 from dominiq at lps dot ens dot fr 2009-12-04 16:27 --- At revision 154983, I get === libffi tests === Running target unix FAIL: libffi.call/cls_double_va.c -O0 -W -Wall output pattern test, is -0.0 FAIL: libffi.call/cls_longdouble_va.c -O0 -W -Wall output pattern test, is -0.0 FAIL: libffi.call/nested_struct5.c -O0 -W -Wall execution test FAIL: libffi.call/cls_double_va.c -O2 output pattern test, is -0.0 FAIL: libffi.call/cls_longdouble_va.c -O2 output pattern test, is -0.0 FAIL: libffi.call/cls_double_va.c -O3 output pattern test, is -0.0 FAIL: libffi.call/cls_longdouble_va.c -O3 output pattern test, is -0.0 FAIL: libffi.call/cls_double_va.c -Os output pattern test, is -0.0 FAIL: libffi.call/cls_longdouble_va.c -Os output pattern test, is -0.0 FAIL: libffi.call/cls_double_va.c -O2 -fomit-frame-pointer output pattern test, is -0.0 FAIL: libffi.call/cls_longdouble_va.c -O2 -fomit-frame-pointer output pattern test, is -0.0 === libffi Summary === # of expected passes1597 # of unexpected failures11 # of expected failures 10 # of unsupported tests 15 So it seems that all the problems due to revision 154855 are now fixed. Thanks for the patches. BTW did you get an idea about where to look for the remaining 11 failures? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug libfortran/40812] Files 2GB are incorrectly handled on mingw
--- Comment #18 from jb at gcc dot gnu dot org 2009-12-04 16:28 --- Subject: Bug 40812 Author: jb Date: Fri Dec 4 16:28:44 2009 New Revision: 154984 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154984 Log: PR libfortran/40812 Large file support for MinGW Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unix.c trunk/libgfortran/io/unix.h trunk/libgfortran/libgfortran.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40812
[Bug c++/42266] [C++0x] ICE with decltype and variadic templates
--- Comment #3 from jason at gcc dot gnu dot org 2009-12-04 16:40 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42266
[Bug libfortran/40812] Files 2GB are incorrectly handled on mingw
--- Comment #19 from jb at gcc dot gnu dot org 2009-12-04 17:02 --- Fixed, closing. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40812
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #6 from janus at gcc dot gnu dot org 2009-12-04 17:06 --- (In reply to comment #5) #3 0x004fa344 in mio_component (c=0x154b880) at /home/tob/projects/fortran-dev/gcc/fortran/module.c:2362 The component here is 'is_null', and the parent symbol is 'vtype$psb_d_base_sparse_mat'. In this context, the component 'is_null' refers to the PPC of the vtype, not the TBP of the original type. I think the problem is that c-tb-ppc is not set correctly for the PPCs inside vtype. If one looks at psb_base_mat_mod.mod, one finds: (55 'is_null' (LOGICAL 4 0 0 LOGICAL ()) () (PROCEDURE UNKNOWN-INTENT UNKNOWN-PROC DECL UNKNOWN 0 0 EXTERNAL FUNCTION PROCEDURE PROC_POINTER) PRIVATE ( NULL (UNKNOWN 0 0 0 UNKNOWN ()) 0) 56 (57) (PUBLIC OVERRIDABLE PASS SPECIFIC NO_PPC 'a' 0 30)) Note the 'NO_PPC'! Although this clearly *is* a PPC, as indicated by 'PROC_POINTER', the tb.ppc attribute is missing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug middle-end/31249] pseudo-optimization with sincos/cexpi
-- dominiq at lps dot ens dot fr changed: What|Removed |Added Severity|normal |minor Summary|pseudo-optimzation with |pseudo-optimization with |sincos/cexpi|sincos/cexpi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug c++/42272] derived template default argument
--- Comment #3 from debian dot templier at free dot fr 2009-12-04 17:12
---
Subject: Re: derived template default argument
redi at gcc dot gnu dot org wrote:
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-04 09:48 ---
SMARTA a();
This does not declare an object of type SMARTA, it declares a function
called
'a' which returns SMARTA
You need to change that to:
SMARTA a;
or
SMARTA a = SMARTA();
the pb is on line :
template typename X , typename XT2 =T , typename X2 = typename XT2 ::
X SMART(SMARTX value) : data(value.CastUp) {} ;
if i replace the line by
template typename XT2 = T , typename X2 = typename XT2 :: X
SMART(SMARTX2 value) : data(value.CastUp()) {} ;
the constructor is find but i want an unherited constraint on X = X2 is
T::X
sh-3.2$ gcc-4.5-20091126/bin/g++ -std=c++0x -c main.cc
main.cc: In constructor SMARTT::SMART(SMARTX2) [with XT2 = B, X2 =
A, T = B]:
main.cc:45:13: instantiated from here
main.cc:17:118: erreur: no matching function for call to
SMARTA::CastUp()
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42272
[Bug c++/42277] New: decltype error in template
// { dg-options -std=c++0x }
struct S { int s; };
template int N
void foo ()
{
S s;
decltype (s.s) i;
}
diagnoses:
t.C: In function âvoid foo()â:
t.C:6: error: type of âs.sâ is unknown
t.C:6: error: invalid type in declaration before â;â token
(but compiles just fine when template int N line is commented out).
Both 4.4 and trunk diagnose this.
--
Summary: decltype error in template
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42277
[Bug bootstrap/42271] os_defines.h:60:1: error: expected '{' before '_GLIBCXX_PSEUDO_VISIBILITY'
--- Comment #4 from davek at gcc dot gnu dot org 2009-12-04 17:30 --- Just got awake in my $TZ, will look at this straight away and fix or revert in the next couple of hours. Sorry for the inconvenience. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42271
[Bug c++/42272] derived template default argument
--- Comment #4 from redi at gcc dot gnu dot org 2009-12-04 17:31 ---
(In reply to comment #3)
the pb is on line :
template typename X , typename XT2 =T , typename X2 = typename XT2 ::
X SMART(SMARTX value) : data(value.CastUp) {} ;
I don't understand, that line did not appear in your original report.
The error you originally posted is caused by the problem I pointed out.
if i replace the line by
template typename XT2 = T , typename X2 = typename XT2 :: X
SMART(SMARTX2 value) : data(value.CastUp()) {} ;
the constructor is find but i want an unherited constraint on X = X2 is
T::X
I have no idea what an unherited constraint is.
sh-3.2$ gcc-4.5-20091126/bin/g++ -std=c++0x
-c main.cc
main.cc: In constructor SMARTT::SMART(SMARTX2) [with XT2 = B, X2 =
A, T = B]:
main.cc:45:13: instantiated from here
main.cc:17:118: erreur: no matching function for call to
SMARTA::CastUp()
CastUp is a template function but the template parameters cannot be deduced, so
you need to say value.CastUpfoo() for some type foo
The bug is in your code, not GCC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42272
[Bug c++/42272] derived template default argument
--- Comment #5 from debian dot templier at free dot fr 2009-12-04 17:33
---
the pb is on line :
template typename X , typename XT2 =T , typename X2 = typename XT2 ::
X SMART(SMARTX value) : data(value.CastUp) {} ;
if i replace the line by
template typename XT2 = T , typename X2 = typename XT2 :: X
SMART(SMARTX2 value) : data(value.CastUp()) {} ;
the constructor is find but i want an unherited constraint on X = X2 is
T::X
sh-3.2$ gcc-4.5-20091126/bin/g++ -std=c++0x -c main.cc
main.cc: In constructor SMARTT::SMART(SMARTX2) [with XT2 = B, X2 =
A, T = B]:
main.cc:45:13: instantiated from here
main.cc:17:118: erreur: no matching function for call to
SMARTA::CastUp()
--
debian dot templier at free dot fr changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42272
[Bug c++/42272] derived template default argument
--- Comment #6 from debian dot templier at free dot fr 2009-12-04 17:39
---
i want a constructor on template class SMARTT with reference parameter on
SMARTX value with the constraint of T on SMART instanciation is
T is unherited of X
class A
{
} ;
class B : virtual public A
{
} ;
where T is B and X is A
thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42272
[Bug c++/42272] derived template default argument
--- Comment #7 from debian dot templier at free dot fr 2009-12-04 17:44
---
template typename X , typename XT2 =T , typename X2 = typename XT2 ::
X SMART(SMARTX value) : data(value.CastUp) {} ;
The code to do the constructor
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42272
[Bug c++/42272] derived template default argument
--- Comment #8 from paolo dot carlini at oracle dot com 2009-12-04 17:44 --- . -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42272
[Bug rtl-optimization/42164] [4.5 Regression] internal compiler error: in simplify_subreg, at simplify-rtx.c:5138
--- Comment #12 from daney at gcc dot gnu dot org 2009-12-04 17:46 --- Subject: Bug 42164 Author: daney Date: Fri Dec 4 17:46:23 2009 New Revision: 154987 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154987 Log: 2009-12-04 David Daney dda...@caviumnetworks.com PR rtl-optimization/42164 * combine.c (combine_simplify_rtx): Handle truncation of integer constants. 2009-12-04 David Daney dda...@caviumnetworks.com PR rtl-optimization/42164 * gcc.c-torture/compile/pr42164.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr42164.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42164
[Bug bootstrap/42271] os_defines.h:60:1: error: expected '{' before '_GLIBCXX_PSEUDO_VISIBILITY'
--- Comment #5 from davek at gcc dot gnu dot org 2009-12-04 17:58 --- Created an attachment (id=19225) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19225action=view) Simple fix The comment in the patch should explain. Namespace macros are defined at the top of c++config.h before target-specific headers are included, but need to allow a target-specific override, so we have the pseudo-vis macro in there and if it still isn't defined after the target-specific os_defines.h is included, it gets defaulted empty. That means the namespace macros can't be used until after either the os-specific override if any or the empty default has actually been defined for it of course. This works fine, except when an os_defines.h header needs to use the namespace macros itself. The trivial fix is for it to provide its own empty definition of the os-specific override, as here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42271
[Bug bootstrap/42271] os_defines.h:60:1: error: expected '{' before '_GLIBCXX_PSEUDO_VISIBILITY'
--- Comment #6 from davek at gcc dot gnu dot org 2009-12-04 18:00 --- I didn't anticipate any of the os-specific config headers trying to use the namespace macros, since all the necessary defines and stuff are only half-way through being set up, but I didn't imagine the possibility of wanting to import some libc functions. I probably could have anticipated this if I'd done a bit more grepping around, sorry. JDA, I don't have headers and libs to test a hpux cross-compiler, could you test the patch? -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-04 18:00:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42271
[Bug middle-end/42245] ICE in verify_backedges for 197.parser with sel-sched
--- Comment #2 from amonakov at gcc dot gnu dot org 2009-12-04 18:00 --- (In reply to comment #0) Janis, Thank you for the testcase. This bug and PR42249 are fixed by Andrey's old patch: http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01930.html The patch in that message still applies cleanly. I'm working on re-testing it with current mainline. If you could test that patch in your environment, it would be very appreciated. -- amonakov at gcc dot gnu dot org changed: What|Removed |Added CC||amonakov at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |amonakov at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-04 18:00:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42245
[Bug rtl-optimization/42246] ICE in init_seqno for 186.crafty with sel-sched
-- amonakov at gcc dot gnu dot org changed: What|Removed |Added CC||amonakov at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |amonakov at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-04 18:01:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42246
[Bug rtl-optimization/42249] unrecognizable insn for 254.gap with sel-sched
-- amonakov at gcc dot gnu dot org changed: What|Removed |Added CC||amonakov at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |amonakov at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-04 18:02:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42249
[Bug debug/42278] New: incorrect dwarf data gcc-4.4.2
I faced an error ERROR: ctfconvert: die 37: base type without name
when run ctfconvert on some object files which were produced by gcc-4.4.2
The error like this:
/opt/onbld/bin/i386/ctfconvert -g -l NDISWRAPPER example.o
ERROR: ctfconvert: die 37: base type without name
I prepared a small example file and compile it with command line
gcc -g -O2 -o example.o -c example.c and two versions of gcc - 4.4.2 and 3.4.3
Then I run dwarfdump example.o on files produced by 4.4.2 and by 3.4.3
$ cat example.c
#include sys/types.h
int main()
{
return 0;
}
Below the file from dwarfdump that was produced by gcc 4.4.2
.debug_info
COMPILE_UNITheader overall offset = 0:
0 11 DW_TAG_compile_unit
DW_AT_producer GNU C 4.4.2
DW_AT_language DW_LANG_C89
DW_AT_name example.c
DW_AT_comp_dir /home/unix/Documents/bugs
DW_AT_low_pc0
DW_AT_high_pc 0x3
DW_AT_stmt_list 0
LOCAL_SYMBOLS:
1 37 DW_TAG_base_type
DW_AT_byte_size 4
DW_AT_encoding DW_ATE_unsigned
1 40 DW_TAG_base_type
DW_AT_byte_size 4
DW_AT_encoding DW_ATE_signed
DW_AT_name long int
1 47 DW_TAG_base_type
...
And here the file from gcc-3.4.3
.debug_info
COMPILE_UNITheader overall offset = 0:
0 11 DW_TAG_compile_unit
DW_AT_stmt_list 0
DW_AT_high_pc 0x10
DW_AT_low_pc0
DW_AT_producer GNU C 3.4.3
(csl-sol210-3_4-20050802)
DW_AT_language DW_LANG_C89
DW_AT_name example.c
DW_AT_comp_dir /home/unix/Documents/bugs
LOCAL_SYMBOLS:
1 37 DW_TAG_base_type
DW_AT_name unsigned int
DW_AT_byte_size 4
DW_AT_encoding DW_ATE_unsigned
1 44 DW_TAG_base_type
DW_AT_name long int
DW_AT_byte_size 4
DW_AT_encoding DW_ATE_signed
...
The DIE describing base type from 3.4.3 contains DW_AT_name.
1 37 DW_TAG_base_type
DW_AT_name unsigned int
DW_AT_byte_size 4
DW_AT_encoding DW_ATE_unsigned
but the same DIE from 4.4.2 doesn't contain DW_AT_name
1 37 DW_TAG_base_type
DW_AT_byte_size 4
DW_AT_encoding DW_ATE_unsigned
--
Summary: incorrect dwarf data gcc-4.4.2
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: YLitvinenko at astana dot oilfield dot slb dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42278
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2009-12-04 18:13 --- Have you tried r154983 with http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00255.html? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug rtl-optimization/42164] [4.5 Regression] internal compiler error: in simplify_subreg, at simplify-rtx.c:5138
--- Comment #13 from daney at gcc dot gnu dot org 2009-12-04 18:20 --- Fixed by the patch. -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42164
[Bug bootstrap/42271] os_defines.h:60:1: error: expected '{' before '_GLIBCXX_PSEUDO_VISIBILITY'
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2009-12-04
18:22 ---
Subject: Re: os_defines.h:60:1: error: expected '{' before
'_GLIBCXX_PSEUDO_VISIBILITY'
JDA, I don't have headers and libs to test a hpux cross-compiler, could you
test the patch?
I'll test tonight.
Thanks,
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42271
[Bug bootstrap/42271] os_defines.h:60:1: error: expected '{' before '_GLIBCXX_PSEUDO_VISIBILITY'
--- Comment #8 from davek at gcc dot gnu dot org 2009-12-04 18:23 --- (In reply to comment #7) I'll test tonight. Thanks. So sorry for the aggro :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42271
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #23 from dominiq at lps dot ens dot fr 2009-12-04 18:34 --- Have you tried r154983 with http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00255.html? Not yet! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug libmudflap/42279] New: libmudflap checks with the wrong CPP for execinfo.h
Libmudflap receives the host CPP to test the headers with, instead of receiving the target CPP. I noticed it having a linux gnu system with glibc and targetting a uclibc linux. I will attach a patch with the fix I used. -- Summary: libmudflap checks with the wrong CPP for execinfo.h Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libmudflap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: viriketo at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: armv5tel-unknown-linux-uclibceabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
[Bug libffi/41908] closures fail for some structure arguments containing floats
--- Comment #7 from uros at gcc dot gnu dot org 2009-12-04 18:42 --- Subject: Bug 41908 Author: uros Date: Fri Dec 4 18:41:59 2009 New Revision: 154988 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154988 Log: PR libffi/41908 * src/x86/ffi64.c (classify_argument): Update from gcc/config/i386/i386.c. (ffi_closure_unix64_inner): Do not use the address of two consecutive SSE registers directly. * testsuite/libffi.call/cls_dbls_struct.c (main): Remove xfail for x86_64 linux targets. Modified: trunk/libffi/ChangeLog trunk/libffi/src/x86/ffi64.c trunk/libffi/testsuite/libffi.call/cls_dbls_struct.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41908
[Bug libstdc++/42273] atomic_2.h:111: = instead of == in if
--- Comment #4 from bkoz at gcc dot gnu dot org 2009-12-04 18:43 --- Agree with #2. This is a one-liner to fix. Jonathan, can you put your comments in 40297 into the wiki page for atomics? I'd forgotten about this whole commentary. We are just starting in again on this. See: http://gcc.gnu.org/wiki/Atomic best, benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42273
[Bug libffi/41908] closures fail for some structure arguments containing floats
--- Comment #8 from ubizjak at gmail dot com 2009-12-04 18:43 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41908
[Bug libmudflap/42279] libmudflap checks with the wrong CPP for execinfo.h
--- Comment #1 from viriketo at gmail dot com 2009-12-04 18:44 --- Created an attachment (id=19226) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19226action=view) Fix the CPP needed by libmudflap when cross-compiling -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
[Bug libstdc++/42273] atomic_2.h:111: = instead of == in if
--- Comment #5 from redi at gcc dot gnu dot org 2009-12-04 18:46 --- will do -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||redi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42273
[Bug other/42280] New: libiberty configure script fails checking pid_t when without-headers
Trying to build a gcc 4.4.2 for 'baremetal' targets, in my case for later libc building, I find that the libiberty configure script at some stage checks for some libc headers to be available. I'm calling the gcc main configure with --without-headers. The total flags are: --prefix=/nix/store/bqyab4kls4czwyzazmrjbf2y62xiil48-gcc-4.4.2-armv5tel-unknown-linux-uclibceabi-stage-static --with-ppl=/nix/store/kdsz815whid3giyi9ll3bshxdmp3jyyj-ppl-0.10.2 --with-cloog=/nix/store/zidphypb94508svrm4b2dxj9bhwpp2fr-cloog-ppl-0.15.4 --with-gmp=/nix/store/sli4r6plz8bkbizia8mr8p0rhxvrk06v-gmp-4.3.1 --with-mpfr=/nix/store/q5x2ajrskdj5bv2md78k5yqapdiy0sqg-mpfr-2.4.1 --disable-libstdcxx-pch --without-included-gettext --with-system-zlib --enable-languages=c --target=armv5tel-unknown-linux-uclibceabi --disable-libssp --disable-nls --without-headers --disable-threads --disable-libmudflap --disable-libgomp --disable-shared I could build gcc 4.3.4 perfectly with the options I was using. The concerning contents at the directory build/armv5tel-unknown-linux-uclibceabi/libiberty/config.log give: configure:5359: /tmp/nix-build-12l4vcfky0013w4gx5fpky81s4gb90gd-gcc-4.4.2-armv5tel-unknown-linux-uclibceabi-stage-static.drv-0/build/./gcc/xgcc -B/tmp/nix-build-12l4vcfky0013w4gx5fpky81s4gb90gd-gcc-4.4.2-armv5tel-unknown-linux-uclibceabi-stage-static.drv-0/build/./gcc/ -B/nix/store/bqyab4kls4czwyzazmrjbf2y62xiil48-gcc-4.4.2-armv5tel-unknown-linux-uclibceabi-stage-static/armv5tel-unknown-linux-uclibceabi/bin/ -B/nix/store/bqyab4kls4czwyzazmrjbf2y62xiil48-gcc-4.4.2-armv5tel-unknown-linux-uclibceabi-stage-static/armv5tel-unknown-linux-uclibceabi/lib/ -isystem /nix/store/bqyab4kls4czwyzazmrjbf2y62xiil48-gcc-4.4.2-armv5tel-unknown-linux-uclibceabi-stage-static/armv5tel-unknown-linux-uclibceabi/include -isystem /nix/store/bqyab4kls4czwyzazmrjbf2y62xiil48-gcc-4.4.2-armv5tel-unknown-linux-uclibceabi-stage-static/armv5tel-unknown-linux-uclibceabi/sys-include -c -B/lib -idirafter /include -Wl,-L/libconftest.c 5 conftest.c:41:19: error: stdio.h: No such file or directory conftest.c:43:24: error: sys/types.h: No such file or directory conftest.c:46:23: error: sys/stat.h: No such file or directory conftest.c:53:22: error: stdlib.h: No such file or directory conftest.c:58:22: error: memory.h: No such file or directory conftest.c:60:21: error: string.h: No such file or directory conftest.c:63:22: error: strings.h: No such file or directory conftest.c:66:23: error: inttypes.h: No such file or directory conftest.c:73:21: error: unistd.h: No such file or directory conftest.c: In function 'main': conftest.c:78: error: 'pid_t' undeclared (first use in this function) conftest.c:78: error: (Each undeclared identifier is reported only once conftest.c:78: error: for each function it appears in.) conftest.c:78: error: expected expression before ')' token configure:5365: $? = 1 -- Summary: libiberty configure script fails checking pid_t when without-headers Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: viriketo at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: armv5tel-unknown-linux-uclibceabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42280
[Bug fortran/42268] [4.4/4.5 Regression] derived type segfault with pack
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-12-04 19:22 --- Janus, I just re-checked the patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478#c12 and found that that is all that's needed. OK to commit to trunk and, after a few days, to 4.4 with the testcase from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478#c9 (if you don't mind the reassignment of this bug :-) -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|tkoenig at gcc dot gnu dot |janus at gcc dot gnu dot org |org | Summary|[4.4/4.5 Regression] derived|[4.4/4.5 Regression] derived |type segfault with pack and |type segfault with pack |unpack | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42268
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #7 from janus at gcc dot gnu dot org 2009-12-04 19:43 ---
(In reply to comment #6)
I think the problem is that c-tb-ppc is not set correctly for the PPCs
inside
vtype.
The following patches fixes it:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 154956)
+++ gcc/fortran/symbol.c(working copy)
@@ -4751,6 +4751,7 @@ add_proc_component (gfc_component *c, gfc_symbol *
if (!c-tb)
c-tb = XCNEW (gfc_typebound_proc);
*c-tb = *st-n.tb;
+ c-tb-ppc = 1;
c-attr.procedure = 1;
c-attr.proc_pointer = 1;
c-attr.flavor = FL_PROCEDURE;
@@ -4790,6 +4791,7 @@ add_proc_comps (gfc_component *c, gfc_symbol *vtyp
else if (c-attr.proc_pointer c-tb)
{
*c-tb = *st-n.tb;
+ c-tb-ppc = 1;
c-ts.interface = st-n.tb-u.specific-n.sym;
}
}
@@ -4886,7 +4888,7 @@ copy_vtab_proc_comps (gfc_symbol *declared, gfc_sy
c-attr.flavor = FL_PROCEDURE;
c-attr.access = ACCESS_PRIVATE;
c-attr.external = 1;
- c-ts.interface = cmp-tb-u.specific-n.sym;
+ c-ts.interface = cmp-ts.interface;
c-attr.untyped = 1;
c-attr.if_source = IFSRC_IFBODY;
c-initializer = gfc_get_expr ();
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2009-12-04 15:57:20 |2009-12-04 19:43:51
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug c++/42281] New: g++ instantiates function templates at the wrong place
[Code]
template class T
int doSomething(T const aT)
{
return aT.a();
}
class A
{
public:
int a() const
{
return 1;
}
};
class B
{
public:
int b() const
{
return 1;
}
};
template class T
inline bool isOne(T const aT)
{
return doSomething(aT) == 1;
}
int doSomething(int aI)
{
return aI;
}
int doSomething(B const aB)
{
return aB.b();
}
int
main(int argc, char *argv[])
{
A a;
isOne(a);
B b;
isOne(b);
isOne(1);
return 0;
}
[/Code]
This code returns this error:
template1.cc: In function #8216;int doSomething(const T) [with T =
int]#8217;:
template1.cc:28:30: instantiated from #8216;bool isOne(const T) [with T =
int]#8217;
template1.cc:50:11: instantiated from here
template1.cc:4:16: error: request for member #8216;a#8217; in
#8216;aT#8217;, which is of non-class type #8216;const int#8217;
This bug is similar to bug 23885, but the difference is that there is template
function isOne instantioned in main and all is defined before main. But right
doSomething is defined after isOne function. Forward declaration helps.
When using class templates it is ok:
[Code]
template class T
struct DoTraits
{
static int doSomething(T const aT)
{
return aT.a();
}
};
class A
{
public:
int a() const
{
return 1;
}
};
class B
{
public:
int b() const
{
return 1;
}
};
template class T
bool isOne(T const aT)
{
return DoTraitsT::doSomething(aT) == 1;
}
template
struct DoTraitsint
{
static int doSomething(int const aI)
{
return aI;
}
};
template
struct DoTraitsB
{
static int doSomething(B const aB)
{
return aB.b();
}
};
int
main(int argc, char *argv[])
{
A a;
isOne(a);
B b;
isOne(b);
isOne(1);
return 0;
}
[/Code]
Sun Studio 11 reports no error on this code (MSVC is working with similar (real
app) code - not tested with this example).
Failing compilers:
/tmp/gcc/usr/bin/g++ -v:
Using built-in specs.
COLLECT_GCC=/tmp/gcc/usr/bin/g++
COLLECT_LTO_WRAPPER=/tmp/gcc/usr/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.5-20091203/configure --prefix=/tmp/gcc/usr
--with-local-prefix=/tmp/gcc/usr --enable-clocale=gnu --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++
--disable-libstdcxx-pch --disable-multilib --disable-bootstrap
Thread model: posix
gcc version 4.5.0 20091203 (experimental) (GCC)
g++ -v:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-6'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --with-tune=generic --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.4 (Debian 4.3.4-6)
--
Summary: g++ instantiates function templates at the wrong place
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jezz at hkfree dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42281
[Bug fortran/42189] gfc_is_constant_expr has unacceptable side effects
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-04 19:52 --- Jerry, this might be involved in PR41165 as well?! -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42189
[Bug c++/42281] g++ instantiates function templates at the wrong place
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-04 19:56 --- One issue is Koenig lookup does not apply to fundamental types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42281
[Bug regression/42282] New: regression: ICE when bootstrapping trunk with -O2 -funswitch-loops
With 20091201 trunk on Linux/amd64 ICE does not happen with GCC 4.4.1-ubuntu8. Appears to be bad interaction between -O2 and -funswitch-loops. Either alone is fine, but together the crash occurs. The commandline below reproduces the issue, but removing all but -O2 and -funswitch-loops will also reproduce. gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/. -I../../gcc-trunk/gcc/../include -I../../gcc-trunk/gcc/../libcpp/include -I../../gcc-trunk/gcc/../libdecnumber -I../../gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber -DCLOOG_PPL_BACKEND -I/usr/include/libelf -O2 -floop-interchange -floop-strip-mine -floop-block -findirect-inlining -ftree-switch-conversion -fvect-cost-model -fgcse-sm -fgcse-las -fgcse-after-reload -fsee -ftree-loop-linear -ftree-loop-distribution -ftree-loop-im -ftree-loop-ivcanon -fivopts -fvpt -funroll-loops -funswitch-loops ../../gcc-trunk/gcc/simplify-rtx.c -o simplify-rtx.o ../../gcc-trunk/gcc/simplify-rtx.c: In function #8216;simplify_immed_subreg#8217;: ../../gcc-trunk/gcc/simplify-rtx.c:4829:1: error: definition in block 35 does not dominate use in block 131 for SSA_NAME: vp_549 in statement: # DEBUG vp = vp_549 + 1 ../../gcc-trunk/gcc/simplify-rtx.c:4829:1: internal compiler error: verify_ssa failed -- Summary: regression: ICE when bootstrapping trunk with -O2 - funswitch-loops Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matt at use dot net 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=42282
[Bug tree-optimization/42283] New: regression: ICE when bootstrapping trunk with -O2 -ftree-loop-distribution
While bootstrapping trunk from 20091201 on amd64. Crash doesn't happen with GCC 4.4.1-ubuntu8. The ICE occurs when -ftree-loop-distribution is combined with -O2 -ftree-loop-linear. The commandline below reproduces the issue as well, but can be reduced to the forementioned options as well. gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/. -I../../gcc-trunk/gcc/../include -I../../gcc-trunk/gcc/../libcpp/include -I../../gcc-trunk/gcc/../libdecnumber -I../../gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber -DCLOOG_PPL_BACKEND -I/usr/include/libelf -O2 -floop-interchange -floop-strip-mine -floop-block -findirect-inlining -ftree-switch-conversion -fvect-cost-model -fgcse-sm -fgcse-las -fgcse-after-reload -fsee -ftree-loop-linear -ftree-loop-distribution -ftree-loop-im -ftree-loop-ivcanon -fivopts -fvpt -funroll-loops -funswitch-loops ../../gcc-trunk/gcc/sbitmap.c -o sbitmap.o ../../gcc-trunk/gcc/reload1.c: In function #8216;delete_output_reload#8217;: ../../gcc-trunk/gcc/reload1.c:8440:1: error: type mismatch in binary expression long unsigned int unnamed-signed:64 long unsigned int D.75724_180 = D.75723_179 - D.75718_194; ../../gcc-trunk/gcc/reload1.c:8440:1: error: type mismatch in binary expression long unsigned int unnamed-signed:64 long unsigned int D.75733_135 = D.75732_154 - D.75727_163; ../../gcc-trunk/gcc/reload1.c:8440:1: internal compiler error: verify_stmts failed -- Summary: regression: ICE when bootstrapping trunk with -O2 - ftree-loop-distribution Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matt at use dot net 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=42283
[Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components
--- Comment #14 from tkoenig at gcc dot gnu dot org 2009-12-04 20:33 --- The problem is with the allocatable components for intrinsics, at least. This has the same problem: program main type :: container_t integer, dimension(:), allocatable :: entry end type container_t type(container_t), dimension(2) :: a1, a2 integer :: i do i = 1, 2 allocate (a1(i)%entry (1), a2(i)%entry (1)) a1(i)%entry = 1 a2(i)%entry = 0 end do a1 = eoshift(a2, 1) end program main What we must do is to deallocate anything on the left hand side of the assignment, so instead of using a1 = eoshift(a2,1) we shoud loop over a1, deallocate everything, and then do the assignment. This looks like heavy front-end work, is anybody up for this? :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
[Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components
--- Comment #15 from tkoenig at gcc dot gnu dot org 2009-12-04 20:36 --- Very probably a dup of PR 40850. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
[Bug tree-optimization/42284] New: failing tree check in graphite-sese-to-poly.c for 164.gzip
GCC trunk gets an internal compiler error when building SPEC CPU2000 test 164.gzip with -O2 -floop-interchange on powerpc-linux, as demonstrated by a minimized testcase that I'll attach to this PR. elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -c -O2 -floop-interchange bug.c bug.c: In function inflate_fixed: bug.c:56:1: internal compiler error: tree check: expected ssa_name, have integer_cst in detect_commutative_reduction, at graphite-sese-to-poly.c:2654 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. A Graphite-enabled trunk build is broken during the 19-hour range from r150250 to 150300. The test passes with the build just before that range and fails with r150301, the first revision that builds after a merge from the Graphite branch. -- Summary: failing tree check in graphite-sese-to-poly.c for 164.gzip Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42284
[Bug tree-optimization/42284] failing tree check in graphite-sese-to-poly.c for 164.gzip
--- Comment #1 from janis at gcc dot gnu dot org 2009-12-04 20:39 --- Created an attachment (id=19227) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19227action=view) Minimized testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42284
[Bug tree-optimization/42285] New: ICE in Graphite's scan_tree_for_params for 416.gamess
GCC trunk gets an internal compiler error when building SPEC CPU2006 test 416.gamess with -O2 -floop-interchange on powerpc-linux, as demonstrated by this minimized testcase: SUBROUTINE EFGRDM(NCF,NFRG,G,RTRMS,GM,IOPT,K1) IMPLICIT DOUBLE PRECISION (A-H,O-Z) DIMENSION G(*),RTRMS(*),GM(*) DUM = 0 DO I=1,NFRG DO J=1,3 IF (IOPT.EQ.0) THEN GM(K1)=G(K1) END IF END DO DO J=1,3 JDX=NCF*9+IOPT*9*NFRG DO M=1,3 DUM=DUM+RTRMS(JDX+M) END DO GM(K1)=DUM END DO END DO RETURN END elm3b187% /opt/gcc-nightly/trunk/bin/gfortran -c -O2 -floop-interchange bug.f bug.f: In function efgrdm: bug.f:1:0: internal compiler error: in scan_tree_for_params, at graphite-sese-to-poly.c:815 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. A Graphite-enabled trunk build is broken during the 19-hour range from r150250 to 150300. The test passes with the build just before that range and fails with r150301, the first revision that builds after a merge from the Graphite branch. -- Summary: ICE in Graphite's scan_tree_for_params for 416.gamess Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42285
[Bug c++/42277] decltype error in template
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-04 20:47:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42277
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #24 from dominiq at lps dot ens dot fr 2009-12-04 21:00 --- Have you tried r154983 with http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00255.html? The patch does not change anything, I get the same failures with or without it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components
--- Comment #16 from tkoenig at gcc dot gnu dot org 2009-12-04 21:03 --- We get this right on assignment, so it is probably just a matter of copying over the logic from there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
[Bug tree-optimization/42286] New: October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math
The October 23rd, 2009 change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math. When you start up the benchmark with reference input, it fails almost immediately because the calculations don't converge. At this point, I don't have a narrowed down test case, but the following change: 2009-10-23 Richard Guenther rguent...@suse.de PR tree-optimization/41778 * tree-ssa-pre.c (do_regular_insertion): Only insert if a redundancy along a path in the CFG we want to optimize for speed is going to be removed. (execute_pre): Do partial-PRE only if the function is to be optimized for speed. (gate_pre): Do not turn off all of PRE when not optimizing a function for speed. Now prevents the spec 2006 calculix benchmark from running if calculix was built with -ffast-math. The change is due to the special code in rs6000.md (and mips.md) for optimizing negative multiply and add and negative multiply and subtract optimizations with -fno-signed-zeros is used (which is set with -ffast-math). If I undo this one change in a local compiler, it builds and runs fine at full speed. If I disable the negative multiply and subtract operation from the the machine description, it runs fine, but at about 1/2 speed. Similarly if I disable -ffast-math, it runs fine, but at 1/2 speed. If I use the -fno-tree-pre option to disable the PRE pass, it fails. -- Summary: October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: meissner at gcc dot gnu dot org GCC build triplet: powerpc64-unknown-linux-gnu GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42286
[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-04 21:18 --- This change merely turns off PRE in cold code regions. So if -fno-tree-pre breaks calculix for you I'd guess some later optimization manages to miscompile it (my guess: the vectorizer). What options do you build calculix with? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42286
[Bug libmudflap/42279] libmudflap checks with the wrong CPP for execinfo.h
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-04 21:24 --- Please send patches to gcc-patc...@gcc.gnu.org -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math
--- Comment #2 from meissner at linux dot vnet dot ibm dot com 2009-12-04 21:28 --- Subject: Re: October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math On Fri, Dec 04, 2009 at 09:18:45PM -, rguenth at gcc dot gnu dot org wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-04 21:18 --- This change merely turns off PRE in cold code regions. So if -fno-tree-pre breaks calculix for you I'd guess some later optimization manages to miscompile it (my guess: the vectorizer). What options do you build calculix with? -m32 -O3 -mcpu=power5 -ffast-math -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42286
[Bug c++/42281] g++ instantiates function templates at the wrong place
--- Comment #2 from jezz at hkfree dot org 2009-12-04 21:30 ---
I have tried to simplify the code, but I have created only problem with int
(not with user structure). In real code we have also something like this:
Tested with same compilers:
template2.cc: In function #8216;bool isEqual(const A, const B) [with A =
std::mapint, int, B = std::mapint, double]#8217;:
template2.cc:16:4: instantiated from #8216;void isTrue(const A, const B)
[with A = std::mapint, int, B = std::mapint, double]#8217;
template2.cc:53:17: instantiated from here
template2.cc:6:17: error: no match for #8216;operator==#8217; in #8216;aA ==
aB#8217;
[Code]
#include map
template typename A, typename B
bool isEqual(A const aA, B const aB)
{
return aA == aB;
}
// Forward declaration works
//template typename Key, typename Value1, typename Value2
//bool isEqual(std::mapKey,Value1 const aA, std::mapKey,Value2 const aB);
template typename A, typename B
inline void isTrue(A const aA, B const aB)
{
if (not isEqual(aA, aB)) throw new std::exception();
}
template typename A, typename B
void isFalse(A const aA, B const aB)
{
if (isEqual(aA, aB)) throw new std::exception();
}
template typename Key, typename Value1, typename Value2
bool isEqual(std::mapKey,Value1 const aA, std::mapKey,Value2 const aB)
{
if (aA.size() != aB.size()) return false;
for (typename std::mapKey,Value1::const_iterator it1 = aA.begin();
it1 != aA.end(); ++it1)
{
typename std::mapKey,Value2::const_iterator it2 = aB.find(it1-first);
if (it2 == aB.end() or it1-second != it2-second) return false;
}
return true;
}
int
main(int argc, char *argv[])
{
isTrue(1, 1);
double da, db;
da = 1.0;
db = 2.0;
isFalse(da, db);
isTrue(da, 1);
std::mapint, int ma;
std::mapint, double mb;
isTrue(ma, mb); // Error here
return 0;
}
[/Code]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42281
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #8 from dominiq at lps dot ens dot fr 2009-12-04 21:37 --- With the patch in comment #7 the tests in pr41829 and the following ones segfault at runtime. ! module m type :: t1 integer :: i = 42 contains procedure, pass :: prod = i_m_j end type t1 type, extends(t1) :: t2 integer :: j = 99 end type t2 contains integer function i_m_j (arg) class(t1), intent(in) :: arg select type (arg) type is (t1) i_m_j = 0 class is (t2) i_m_j = 1 class default print *, should not be here end select end function i_m_j end module m use m class(t1), pointer :: a type(t1), target :: b type(t2), target :: c integer :: itmp a = b itmp = a%prod() print *, itmp a = c itmp = a%prod() print *, itmp end ! module m type :: null_type end type type :: t1 integer :: i = 42 procedure(make_real), pointer :: ptr contains procedure, pass :: real = make_real procedure, pass :: make_integer procedure, pass :: prod = i_m_j generic, public :: extract = real, make_integer end type t1 type, extends(t1) :: t2 integer :: j = 99 contains procedure, pass :: real = make_real2 procedure, pass :: make_integer_2 procedure, pass :: prod = i_m_j_2 generic, public :: extract = real, make_integer_2 end type t2 contains real function make_real (arg) class(t1), intent(in) :: arg make_real = real (arg%i) end function make_real real function make_real2 (arg) class(t2), intent(in) :: arg make_real2 = real (arg%j) end function make_real2 integer function make_integer (arg, arg2) class(t1), intent(in) :: arg integer :: arg2 make_integer = arg%i * arg2 end function make_integer integer function make_integer_2 (arg, arg2) class(t2), intent(in) :: arg integer :: arg2 make_integer_2 = arg%j * arg2 end function make_integer_2 integer function i_m_j (arg) class(t1), intent(in) :: arg i_m_j = arg%i end function i_m_j integer function i_m_j_2 (arg) class(t2), intent(in) :: arg i_m_j_2 = arg%j end function i_m_j_2 end module m use m class(t1), pointer :: a != NULL() type(t1), target :: b type(t2), target :: c a = b print *, a%i,a%real(), a%prod(), a%extract (2) a = c print *, a%i,a%real(), a%prod(), a%extract (3) end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug tree-optimization/42285] ICE in Graphite's scan_tree_for_params for 416.gamess
--- Comment #1 from dominiq at lps dot ens dot fr 2009-12-04 21:41 --- Confirmed on x86_64-apple-darwin10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42285
[Bug tree-optimization/42284] failing tree check in graphite-sese-to-poly.c for 164.gzip
--- Comment #2 from dominiq at lps dot ens dot fr 2009-12-04 21:47 --- Confirmed on x86_64-apple-darwin10: [macbook] f90/bug% gcc45 -O2 -floop-interchange -c pr42284.c pr42284.c:6:14: warning: conflicting types for built-in function 'malloc' pr42284.c: In function 'inflate_fixed': pr42284.c:56:1: internal compiler error: tree check: expected ssa_name, have integer_cst in detect_commutative_reduction, at graphite-sese-to-poly.c:2631 Note the warning: conflicting types for built-in function 'malloc'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42284
[Bug target/42287] New: xgcc: Internal error: Segmentation fault (program as)
Attempting to build GCC for a powerpc-linux-gnu target. Host machine is i686 running Linux 2.6.31.6-145.fc12.i686.PAE Get the dreaded checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. message. Looking at config.log (in powerpc-linux-gnu/libgcc), I find a message telling me to report the segmentation fault of as. So, I'm doing it. What a pain it is to build GCC for this target. Any help is greatly appreciated. -- Summary: xgcc: Internal error: Segmentation fault (program as) Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mark at advancedtechcorp dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: powerpc-linux-gnu GCC target triplet: powerpc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42287
[Bug target/42287] xgcc: Internal error: Segmentation fault (program as)
--- Comment #1 from mark at advancedtechcorp dot com 2009-12-04 21:55 --- Created an attachment (id=19228) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19228action=view) config log configuration log where the crash is shown. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42287
