[Bug fortran/26822] Scalarization of non-elemental intrinsic: __logical_4_l4
--- Comment #3 from c dot lemmen at fz-juelich dot de 2006-03-24 08:30 --- Created an attachment (id=0) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=0action=view) Reduced Testcase that produces the failure Testcase attached -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26822
[Bug c/26841] New: extern inline fails to create external definition in C99 mode
In C99 this
extern inline int f(int n) { return n + 1; }
does not meet the criteria in 6.7.4#6 for 'inline definition'
and is therefore an external definition. gcc -std=c99 fails
to emit an external definition, though it does for the
separate definition/declaration case in the 6.7.4#7 example.
--
Summary: extern inline fails to create external definition in C99
mode
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org
GCC build triplet: -std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26841
[Bug tree-optimization/26830] [4.1/4.2 Regression] Insane amount of compile-time / memory needed at -O1 and above
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-03-24 08:43 --- Ok, without -fno-tree-salias things are just worse, not different: tree copy propagation : 134.88 ( 2%) usr 0.67 (10%) sys 136.04 ( 2%) wall 6573 kB ( 0%) ggc tree store copy prop : 26.55 ( 0%) usr 0.01 ( 0%) sys 26.56 ( 0%) wall 1602 kB ( 0%) ggc tree PHI insertion: 75.16 ( 1%) usr 1.80 (27%) sys 76.97 ( 1%) wall 1512507 kB (76%) ggc tree SSA rewrite :6874.42 (89%) usr 0.20 ( 3%) sys6875.24 (89%) wall 22257 kB ( 1%) ggc tree SSA incremental : 281.55 ( 4%) usr 0.11 ( 2%) sys 281.64 ( 4%) wall 10460 kB ( 1%) ggc dominator optimization: 65.92 ( 1%) usr 0.03 ( 0%) sys 65.96 ( 1%) wall 20197 kB ( 1%) ggc tree loop init: 30.19 ( 0%) usr 0.00 ( 0%) sys 30.20 ( 0%) wall 9 kB ( 0%) ggc tree SSA uncprop : 28.22 ( 0%) usr 0.01 ( 0%) sys 28.22 ( 0%) wall 0 kB ( 0%) ggc dominance frontiers : 21.44 ( 0%) usr 0.02 ( 0%) sys 21.40 ( 0%) wall 0 kB ( 0%) ggc expand: 61.70 ( 1%) usr 0.07 ( 1%) sys 61.83 ( 1%) wall 49925 kB ( 3%) ggc TOTAL :7709.86 6.60 7717.99 1990005 kB (that was ia64 with 4.1.0, sorry) I believe there's something wrong with the data-structures compared to what we had in 4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug middle-end/26836] ICE on valid code (tree type is null in tree-gimple.c)
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-24 10:24 --- Seems to be fixed now. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||law at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED GCC build triplet|powerpc64-linux | GCC host triplet|powerpc64-linux | GCC target triplet|powerpc64-linux | Keywords||ice-on-valid-code Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26836
[Bug middle-end/26835] ICE in f951 on valid code at -O2 -ftree-loop-linear
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-24 10:30 --- Confirmed. We ICE after IVOPTs during computation of dominance frontiers. Other than that, tree-loop-linear seems to be somewhat buggy in general. Program received signal SIGSEGV, Segmentation fault. 0x081e85af in compute_dominance_frontiers_1 (frontiers=0x8929b90) at /space/rguenther/src/svn/summit/gcc/cfganal.c:1057 1057 bitmap_set_bit (frontiers[runner-index], (gdb) bt #0 0x081e85af in compute_dominance_frontiers_1 (frontiers=0x8929b90) at /space/rguenther/src/svn/summit/gcc/cfganal.c:1057 #1 0x081e8657 in compute_dominance_frontiers (frontiers=0x8929b90) at /space/rguenther/src/svn/summit/gcc/cfganal.c:1073 #2 0x081452d9 in update_ssa (update_flags=128) at /space/rguenther/src/svn/summit/gcc/tree-into-ssa.c:2755 #3 0x08546c15 in execute_todo (flags=197) at /space/rguenther/src/svn/summit/gcc/passes.c:765 I'd say it hints at a broken CFG. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc64-linux | GCC host triplet|powerpc64-linux | GCC target triplet|powerpc64-linux | Last reconfirmed|-00-00 00:00:00 |2006-03-24 10:30:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26835
[Bug middle-end/26835] ICE in f951 on valid code at -O2 -ftree-loop-linear
--- Comment #2 from dberlin at gcc dot gnu dot org 2006-03-24 12:27 --- Subject: Re: ICE in f951 on valid code at -O2 -ftree-loop-linear On Fri, 2006-03-24 at 10:30 +, rguenth at gcc dot gnu dot org wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-24 10:30 --- Confirmed. We ICE after IVOPTs during computation of dominance frontiers. Other than that, tree-loop-linear seems to be somewhat buggy in general. The code generation portion of tree-loop-linear is pretty solid (there may be a few off by one errors lurking, however). The perfect nest conversion is a rats nest in a lot of ways, because it's a really really bad hack to avoid real loop distribution. I've seen cases where it breaks the cfg and dominance info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26835
[Bug c/26841] extern inline fails to create external definition in C99 mode
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-24 13:26 --- *** This bug has been marked as a duplicate of 16622 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26841
[Bug c/16622] [C99] extern inline is handled wrong in C99 mode
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-24 13:26 --- *** Bug 26841 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||algrant at acm dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
[Bug fortran/26822] Scalarization of non-elemental intrinsic: __logical_4_l4
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-24 13:27 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-24 13:27:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26822
[Bug middle-end/26836] ICE on valid code (tree type is null in tree-gimple.c)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-24 13:28 --- Reopening to ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26836
[Bug middle-end/26836] ICE on valid code (tree type is null in tree-gimple.c)
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-24 13:29 --- Mark as a dup of bug 26806. *** This bug has been marked as a duplicate of 26806 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26836
[Bug tree-optimization/26806] [4.2 Regression] ICE at gcc/tree-gimple.c:269
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-03-24 13:29 --- *** Bug 26836 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||uttamp at us dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26806
[Bug c++/26844] New: in compile time
-- Summary: in compile time Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bedorlan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26844
[Bug c/26845] New: V850Ex/xxx hardware conflict with SLD instruction
on some revised hardware manuals of V850Ex/xxx controllers a hardware conflict in conjunction with the SLD instruction and Interrupt requests are described. For example: V850E/ME2, August 2005, p113, 3.4.11 Restriction on conflict between sld instruction and interrupt request http://www.necel.com/nesdis/image/U16031EJ4V1UD00.pdf V850ES/HG2, December 2005, p75 , (3) Restriction on conflict between sld instruction and interrupt request http://www.necel.com/nesdis/image/U17718EJ1V0UD00.pdf The NEC CA850 V2.61 C-Compiler and IAR C-Compiler for V850 V3.20A compensate this hardware problem. Does the current Gnu C-Compiler for V850E also compensate this problem ? Thanks, Mathias -- Summary: V850Ex/xxx hardware conflict with SLD instruction Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Mathias dot Jirgal at gmx dot net GCC target triplet: gcc-v850-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26845
[Bug c++/26844] in compile time
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-24 13:56 --- Details about this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26844
[Bug middle-end/26840] [4.2 Regression] escaping global variables cause 'definition follows use' error.
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-24 13:58 --- This was __NOT__ fixed by the patch for PR 26806. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26840
[Bug c++/26844] in compile time
--- Comment #2 from bedorlan at gmail dot com 2006-03-24 14:06 --- Created an attachment (id=2) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=2action=view) g++ -ansi result.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26844
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #26 from rguenth at gcc dot gnu dot org 2006-03-24 14:08 --- Note that with the fix installed on the 4.1 branch programs linked against libgcj.so get to use libgcjs pthread_create wrapper, but programs later opening libgcj.so via dlopen, like OpenOffice, fail here. LD_PRELOADing libgcj.so from the 4.1 branch will not help either, because libgcj.so does not provide the correct versioned symbol. Fixing that reveals maybe another problem for OpenOffice, namely we now crash like Program received signal SIGSEGV, Segmentation fault. 0xb78bb7f3 in GC_is_black_listed () from /usr/lib/libgcj.so.7.0.0 (gdb) bt #0 0xb78bb7f3 in GC_is_black_listed () from /usr/lib/libgcj.so.7.0.0 #1 0xb78b979d in GC_allochblk_nth () from /usr/lib/libgcj.so.7.0.0 #2 0xb78b9b62 in GC_allochblk () from /usr/lib/libgcj.so.7.0.0 #3 0xb78c527d in GC_new_hblk () from /usr/lib/libgcj.so.7.0.0 #4 0xb78bb581 in GC_allocobj () from /usr/lib/libgcj.so.7.0.0 #5 0xb78c00a8 in GC_generic_malloc_inner () from /usr/lib/libgcj.so.7.0.0 #6 0xb78c0511 in GC_generic_malloc_inner_ignore_off_page () from /usr/lib/libgcj.so.7.0.0 #7 0xb78be3f7 in GC_grow_table () from /usr/lib/libgcj.so.7.0.0 #8 0xb78be61a in GC_register_finalizer_inner () from /usr/lib/libgcj.so.7.0.0 #9 0xb78be7c3 in GC_register_finalizer_no_order () from /usr/lib/libgcj.so.7.0.0 #10 0xb72d9b2d in _Jv_RegisterFinalizer () from /usr/lib/libgcj.so.7.0.0 #11 0xb72d2052 in _Jv_NewStringUtf8Const () from /usr/lib/libgcj.so.7.0.0 #12 0xb72a5deb in _Jv_Linker::ensure_class_linked () from /usr/lib/libgcj.so.7.0.0 #13 0xb72a5fbe in _Jv_Linker::wait_for_state () from /usr/lib/libgcj.so.7.0.0 #14 0xb72cc421 in java::lang::Class::initializeClass () from /usr/lib/libgcj.so.7.0.0 #15 0xb72cc3c3 in java::lang::Class::initializeClass () from /usr/lib/libgcj.so.7.0.0 #16 0xb7297417 in _Jv_CreateJavaVM () from /usr/lib/libgcj.so.7.0.0 #17 0xb729c58d in JNI_CreateJavaVM () from /usr/lib/libgcj.so.7.0.0 #18 0xacbf47fc in jfw_plugin_startJavaVirtualMachine () from /usr/lib/ooo-2.0/program/sunjavaplugin.so #19 0xb57df25e in jfw_startVM () from /usr/lib/ooo-2.0/program/libjvmfwk.so.3 See https://bugzilla.novell.com/show_bug.cgi?id=153386 - open the attached A sample .odb file and click on 'Tables' on i686. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug tree-optimization/26830] [4.1/4.2 Regression] Insane amount of compile-time / memory needed at -O1 and above
--- Comment #10 from bonzini at gnu dot org 2006-03-24 14:15 ---
so it may even be that something creates an incredibly interconnected CFG?
can you add a test somewhere in execute_one_pass to print the number of basic
blocks and the total number of edges? along these lines:
if (pass-name current_function_decl (curr_properties PROP_cfg)) {
tot_bb = tot_edge = 0;
FOR_EACH_BB (bb)
tot_bb++, tot_edge += EDGE_COUNT (bb-succ);
fprintf (%s %s %d %d %f, pass-name, IDENTIFIER_POINTER
(DECL_ASSEMBLER_NAME (current_function_decl)),
tot_bb, tot_edge, ((double)tot_edge) / tot_bb);
}
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug tree-optimization/26830] [4.1/4.2 Regression] Insane amount of compile-time / memory needed at -O1 and above
--- Comment #11 from bonzini at gnu dot org 2006-03-24 14:16 --- so it may even be that something creates an incredibly interconnected CFG? i mean, we may end up having the equivalent of the multiple computed gotos, that we factor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug tree-optimization/26830] [4.1/4.2 Regression] Insane amount of compile-time / memory needed at -O1 and above
--- Comment #12 from bonzini at gnu dot org 2006-03-24 14:16 --- confirming, but removing the alias keyword. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords|alias | Last reconfirmed|-00-00 00:00:00 |2006-03-24 14:16:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #15 from amodra at bigpond dot net dot au 2006-03-24 14:23 --- Appears to be the peephole in rs6000.md immediately after this comment: ;; after inserting conditional returns we can sometimes have ;; unnecessary register moves. (subreg:DF (reg:DI 3 3 [128]) 0) is a valid gpc_reg_operand. Try this (totally untested) patch. Index: gcc/config/rs6000/rs6000.md === --- gcc/config/rs6000/rs6000.md (revision 112347) +++ gcc/config/rs6000/rs6000.md (working copy) @@ -9771,18 +9771,20 @@ operands[0] = widen_memory_access (operands[0], V2DFmode, 0); operands[1] = gen_rtx_REG (V2DFmode, REGNO (operands[1]));) -;; after inserting conditional returns we can sometimes have +;; After inserting conditional returns we can sometimes have ;; unnecessary register moves. Unfortunately we cannot have a ;; modeless peephole here, because some single SImode sets have early ;; clobber outputs. Although those sets expand to multi-ppc-insn ;; sequences, using get_attr_length here will smash the operands ;; array. Neither is there an early_cobbler_p predicate. +;; Disallow subregs for E500 so we don't munge frob_di_df_2. (define_peephole2 [(set (match_operand:DF 0 gpc_reg_operand ) (match_operand:DF 1 any_operand )) (set (match_operand:DF 2 gpc_reg_operand ) (match_dup 0))] - peep2_reg_dead_p (2, operands[0]) + !(TARGET_E500_DOUBLE GET_CODE (operands[2]) == SUBREG) +peep2_reg_dead_p (2, operands[0]) [(set (match_dup 2) (match_dup 1))]) (define_peephole2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug tree-optimization/26806] [4.2 Regression] ICE at gcc/tree-gimple.c:269
--- Comment #15 from malitzke at metronets dot com 2006-03-24 14:30 --- re this PR 26806 and PR 26833 (judged equivalent) the yasm--0.4.0 referred to in PR 26833 compiled OK with the temporary fix and passed an extensive battery of tests included in yasm-0.4.0. Documentation issues (irrelevant to GCC) were faked out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26806
[Bug middle-end/26840] [4.2 Regression] escaping global variables cause 'definition follows use' error.
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-03-24 14:49 --- The only reason i can think that this would occur is if the copies had different SMT's or NMT's associated with them, but that shouldn't happen, since they are copies :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26840
[Bug middle-end/26836] ICE on valid code (tree type is null in tree-gimple.c)
--- Comment #4 from law at redhat dot com 2006-03-24 14:51 --- Subject: Re: ICE on valid code (tree type is null in tree-gimple.c) On Fri, 2006-03-24 at 10:24 +, rguenth at gcc dot gnu dot org wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-24 10:24 --- Seems to be fixed now. Yes. That should have been fixed with my patch from last night. A null tree-type on an SSA_NAME is a symptom of having an SSA_NAME in the IL and the freelist -- we null-out TREE_TYPE as we put the name on the list. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26836
[Bug middle-end/26840] [4.2 Regression] escaping global variables cause 'definition follows use' error.
--- Comment #7 from law at redhat dot com 2006-03-24 14:53 --- Subject: Re: [4.2 Regression] escaping global variables cause 'definition follows use' error. On Fri, 2006-03-24 at 13:58 +, pinskia at gcc dot gnu dot org wrote: --- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-24 13:58 --- This was __NOT__ fixed by the patch for PR 26806. I know. Never claimed otherwise. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26840
[Bug middle-end/26840] [4.2 Regression] escaping global variables cause 'definition follows use' error.
--- Comment #8 from law at redhat dot com 2006-03-24 14:56 --- Subject: Re: [4.2 Regression] escaping global variables cause 'definition follows use' error. On Fri, 2006-03-24 at 14:49 +, dberlin at gcc dot gnu dot org wrote: --- Comment #6 from dberlin at gcc dot gnu dot org 2006-03-24 14:49 --- The only reason i can think that this would occur is if the copies had different SMT's or NMT's associated with them, but that shouldn't happen, since they are copies :) The problem here is the set of virtual operands changes as a result of propagating an invariant ADDR_EXPR into a use site. What's odd is the code should be mimicking how other passes already deal with this issue. For reasons I don't understand yet, we haven't marked those virtual operands which are removed from the use site for renaming. I'll be working on this today. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26840
[Bug c++/26846] New: hidden visibility of static member in class derived from hash_map changes to default visibility
gcc (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux)
SUSE Linux 10.0 i686
I don'know, if this is a gcc or elf bug.
I use the following construct:
Slib1 = Dlib1
Slib1 + Dlib1 = Dlib2
Test = dlopen/dlclose (Dlib2)
Slib1 is a static lib.
Dlib1 is a shared lib containing Slib1.
Dlib2 is a shared lib containing Dlib1 and Slib1.
After building the libraries with hidden visibility:
tmp/demo/lib/linuxrelease readelf -s -W -D libdlib1.so | c++filt
...
14 15: 1a80 4 OBJECT GLOBAL DEFAULT 23 SLibC1::m_str
...
tmp/demo/lib/linuxrelease readelf -s -W -D libdlib2.so | c++filt
...
14 15: 1ad8 4 OBJECT GLOBAL DEFAULT 23 SLibC1::m_str
...
Both Dso-s will have the static member SLibC1::m_str with DEFAULT visibility.
If you try to load / read symbol / close / load the Dso libdlib2.so,
it will crash with the following error message:
*** glibc detected *** double free or corruption (fasttop): 0x0804b888 ***
If you set:
export MALLOC_CHECK_=3
you can see in the debugger,
that calling the global dtor in libdlib2.so at ~SLibC1::m_str() causes the
crash.
If you change hash_map to map in the example below (comment the line #define
BUG 1),
the test is OK. In this case the visibility of SLibC1::m_str is hidden.
If this problem already known, does a workaround exist?
I will supply the automake files. Without them I could not reproduce bug(?).
I try to upload the whole configuration, but here are source files in the
following tree:
(how can I upload an attachment?)
.
|-- AUTHORS = dummy
|-- COPYING = dummy
|-- ChangeLog = dummy
|-- INSTALL = dummy
|-- NEWS = dummy
|-- README= dummy
|-- configure.ac
|-- dlib1
| |-- dlib1_m1.cpp
| `-- makefile.am
|-- dlib2
| |-- dlib2_m1.cpp
| `-- makefile.am
|-- lib
|-- makefile.am
`-- stlib1
|-- makefile.am
`-- stlib1_m1.cpp
stlib1_m1.cpp
#include string
#define BUG 1
#ifdef BUG
#include ext/hash_map
class SLibC1 : public __gnu_cxx::hash_mapint, int
#else
#include map
class SLibC1 : public std::mapint, int
#endif
{
public:
static const std::string m_str;
};
const std::string SLibC1::m_str = SLibC1 1.0;
EOF
dlib1_m1.cpp
struct __attribute__ ((visibility(default))) Dlib1C1
{
void Dlib1Func1() {}
};
EOF
dlib2_m1.cpp
struct __attribute__ ((visibility(default))) Dlib2C1
{
void Dlib2Func1() {};
};
EOF
configure.ac
_dnl Process this file with autoconf to produce a configure script.
AC_INIT([PSP],[pre])
AM_INIT_AUTOMAKE
dnl Checks for programs.
AC_PROG_LIBTOOL
#AC_PROG_RANLIB
AC_PROG_CXX
AC_PROG_CPP
AC_PROG_CC
AC_LANG(C++)
abs_top_srcdir=`pwd`
VERSION_INFO=-avoid-version
AC_CONFIG_FILES([dlib1/makefile])
AC_CONFIG_FILES([dlib2/makefile])
AC_CONFIG_FILES([stlib1/makefile])
PRODNAME=linuxrelease
CXXFLAGS= -fvisibility=hidden -fvisibility-inlines-hidden -D_Linux
CFLAGS=$CFLAGS -fvisibility=hidden -D_Linux
ALD_FLAGS= -no-undefined
SYSLIBS=-ldl
AM_CONFIG_HEADER([config.h])
AC_CONFIG_FILES([makefile])
dnl Checks for libraries.
dnl Checks for header files.
dnl Checks for typedefs, structures, and compiler characteristics.
AC_C_CONST
AC_C_INLINE
AC_C_BIGENDIAN
AC_TYPE_SIZE_T
dnl Checks for library functions.
AC_SUBST(abs_top_srcdir)
AC_SUBST(PRODNAME)
AC_SUBST(AINC_PATH)
AC_SUBST(ALD_FLAGS)
AC_SUBST(SYSLIBS)
AC_SUBST(VERSION_INFO)
AC_OUTPUT([])
EOF
./makefile.am
SUBDIRS = stlib1 dlib1 dlib2 exe
EOF
stlib1/makefile.am
libdir = ${abs_top_srcdir}/lib/@PRODNAME@
lib_LTLIBRARIES = libstlib1.la
libstlib1_la_LDFLAGS = -all-static
libstlib1_la_LIBADD =
libstlib1_la_SOURCES = stlib1_m1.cpp
libstlib1_la_CPPFLAGS = -D_LIB -I${top_srcdir}/inc @AINC_PATH@
install-exec-local:
mkdir -p $(libdir)/.libs \
sed -e
1s/libstlib1.la/libstlib1_noi.la/;s/^old_library=.*/old_library='..\/libstlib1.a'/;s/^installed=.*/installed=no/;s/^libdir=.*/libdir=''/
libstlib1.la $(libdir)/libstlib1_noi.la
EOF
dlib1/makefile.am
libdir = ${abs_top_srcdir}/lib/@PRODNAME@
lib_LTLIBRARIES = libdlib1.la
libdlib1_la_LDFLAGS = @VERSION_INFO@ @ALD_FLAGS@
-L${abs_top_srcdir}/lib/@PRODNAME@
libdlib1_la_SOURCES = dlib1_m1.cpp
libdlib1_la_LIBADD = -lstlib1 @SYSLIBS@
libdlib1_la_CPPFLAGS = -D_USRDLL -DDLIB1_EXPORTS -I${top_srcdir}/stlib1
-I${top_srcdir}/inc @AINC_PATH@
install-exec-local:
rm -f $(libdir)/libdlib1.a \
touch $(libdir)/_x.o \
ar cru $(libdir)/libdlib1.a $(libdir)/_x.o \
ranlib $(libdir)/libdlib1.a \
cp $(libdir)/libdlib1.a .libs/ \
rm -f $(libdir)/_x.o
EOF
dlib2/makefile.am
libdir = ${abs_top_srcdir}/lib/@PRODNAME@
lib_LTLIBRARIES = libdlib2.la
libdlib2_la_LDFLAGS = @VERSION_INFO@ @ALD_FLAGS@
-L${abs_top_srcdir}/lib/@PRODNAME@
libdlib2_la_SOURCES = dlib2_m1.cpp
libdlib2_la_LIBADD = -ldlib1 -lstlib1 @SYSLIBS@
libdlib2_la_CPPFLAGS = -D_USRDLL -DDLIB2_EXPORTS -I${top_srcdir}/stlib1
-I${top_srcdir}/dlib1 -I${top_srcdir}/inc @AINC_PATH@
install-exec-local:
rm -f $(libdir)/libdlib2.a \
touch
[Bug rtl-optimization/26847] New: Missed optimization in simplify_plus_minus - regression against 4.1.0
copied from:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00812.html
Hi Paolo,
with your patch:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01718.html
simplify_plus_minus isn't able anymore to simplify things like (r1 + 8) - r1.
The function is left at:
if (!canonicalized)
{
int n_constants = 0;
for (i = 0; i n_ops; i++)
if (GET_CODE (ops[i].op) == CONST_INT)
n_constants++;
if (n_constants = 1)
return NULL_RTX;
}
because only a single constant was found and no canonicalization took place.
Your patch changed:
if (n_ops = 2 !force)
return NULL_RTX;
to:
gcc_assert (n_ops = 2);
if (!canonicalized)
return NULL_RTX;
Which was later on changed by Alan Modra with:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00015.html
to the version mentioned above. The reason here was that expressions
like reg + c1 + c2 were not simplified anymore.
So the new version exits always if the initial loop couldn't do any
canonicalization work and only 0 or 1 constants are left. What prevents
simplification in all those cases.
...
As Roger Sayle pointed out the patch I've proposed in the email isn't the
proper fix for this issue.
Paolo Bonzini already proposed a solution in:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00884.html
Thats why I'll assign the bug to him.
--
Summary: Missed optimization in simplify_plus_minus - regression
against 4.1.0
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: bonzini at gnu dot org
ReportedBy: krebbel at gcc dot gnu dot org
GCC build triplet: s390x-ibm-linux-gnu
GCC host triplet: s390x-ibm-linux-gnu
GCC target triplet: s390x-ibm-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26847
[Bug c++/26846] hidden visibility of static member in class derived from hash_map changes to default visibility
--- Comment #1 from laszlo dot szakony at philips dot com 2006-03-24 15:06 --- Created an attachment (id=3) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=3action=view) Automke sources to reproduce/test the visibility change of static members -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26846
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #27 from rguenth at gcc dot gnu dot org 2006-03-24 15:35 --- Created an attachment (id=5) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=5action=view) patch fixing OO problems with LD_PRELOAD of libgcj One problem with LD_PRELOADing of libgcj.so is that boehm starts with GC_all_interior_pointers == 1 and libgcj sets it to 0 after startup, so we segfault because in GC_bl_init we did not properly initialize GC_old_normal_bl. Changing the boehm default config and exporting pthread_create with the glibc versioning makes OO work with LD_PRELOADing of libgcj.so. This is what the patch does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug tree-optimization/26830] [4.1/4.2 Regression] Insane amount of compile-time / memory needed at -O1 and above
--- Comment #13 from bonzini at gnu dot org 2006-03-24 15:42 --- maybe it's enough to throttle down the salias limits, depending on the number of incoming edges in the basic block? readding alias keyword, and ccing Dan -- bonzini at gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Keywords||alias http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug ada/26849] New: gnat_to_gnu error when using Short_Integer
This simple package causes a GNAT bug box package Short is bug : Short_Integer; end Short; +===GNAT BUG DETECTED==+ | 4.1.0 20060116 (prerelease) AVR-Ada snapshot (avr-unknown-none) GCC error:| | in gnat_to_gnu, at ada/trans.c:2588 | | No source file position information available| A somewhat related case is the derivation of Integer types: package AVR_B2 is type Toto is new Integer; end AVR_B2; -- Summary: gnat_to_gnu error when using Short_Integer Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rolf dot ebert dot gcc at gmx dot de GCC target triplet: avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26849
[Bug tree-optimization/26830] [4.1/4.2 Regression] Insane amount of compile-time / memory needed at -O1 and above
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-03-24 15:50 --- I wonder what makes us regress so much in comparison to 4.0.3. The CFG structure before into-ssa should be the same (-fno-inline doesn't help the testcase). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug tree-optimization/26830] [4.1/4.2 Regression] Insane amount of compile-time / memory needed at -O1 and above
--- Comment #15 from bonzini at gnu dot org 2006-03-24 16:07 ---
tree_duplicate_sese_region calls update_ssa. that makes the loop grow very
fast with the number of basic blocks.
4.0, instead, has
5081 /* Add phi nodes for definitions at exit. TODO -- once we have
immediate
5082 uses, it should be possible to emit phi nodes just for definitions
that
5083 are used outside region. */
5084 EXECUTE_IF_SET_IN_BITMAP (definitions, 0, ver, bi)
5085 {
5086 tree name = ssa_name (ver);
5087
5088 phi = create_phi_node (name, exit-dest);
5089 add_phi_arg (phi, name, exit);
5090 add_phi_arg (phi, name, exit_copy);
5091
5092 SSA_NAME_DEF_STMT (name) = phi;
5093 }
5094
5095 /* And create new definitions inside region and its copy. TODO -- once
we
5096 have immediate uses, it might be better to leave definitions in
region
5097 unchanged, create new ssa names for phi nodes on exit, and rewrite
5098 the uses, to avoid changing the copied region. */
5099 allocate_ssa_names (definitions, ssa_name_map);
5100 rewrite_to_new_ssa_names (region, n_region, ssa_name_map);
5101 allocate_ssa_names (definitions, ssa_name_map);
5102 rewrite_to_new_ssa_names (region_copy, n_region, ssa_name_map);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug c++/26844] in compile time
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-24 16:14 ---
Fixed in 3.4.0.
Reduced testcase:
namespace std
{
class type_info {};
}
int main(int argc, char **argv)
{
int filas, columnas;
typeid( new double[filas][columnas] );
}
This is invalid code:
t.cc: In function int main(int, char**):
t.cc:8: error: columnas cannot appear in a constant-expression
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Keywords||ice-on-invalid-code
Resolution||FIXED
Target Milestone|--- |3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26844
[Bug middle-end/26611] openmp gomp ICE at gimplify.c:4257
--- Comment #6 from jakub at gcc dot gnu dot org 2006-03-24 16:14 --- Subject: Bug 26611 Author: jakub Date: Fri Mar 24 16:14:40 2006 New Revision: 112351 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112351 Log: PR middle-end/26611 * gimplify.c (gimplify_bind_expr): Only call omp_add_variable on non-global variables that don't have DECL_SEEN_IN_BIND_EXPR_P bit set yet or weren't marked as local yet. * g++.dg/gomp/pr26611-1.C: New test. * g++.dg/gomp/pr26611-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr26611-1.C trunk/gcc/testsuite/g++.dg/gomp/pr26611-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26611
[Bug tree-optimization/26850] New: unused function not eliminated with -fwhole-program --combine
Compile these 2 files with gcc -O2 -fwhole-program --combine a.c b.c
a.c:
int main (void) { return 0;}
b.c:
static int tst1 (int x) {return x;}
static int global_static;
int global;
int tst2 (int x, int y) {foo (tst1, x, y, global_static, global);}
The generated assembly still contains the tst1 function. tst2, global and
static_global have been eliminated.
It seems that functions that have their address taken should be reconsidered
for elimination after eliminating the functions (and variables too) that took
their address.
Note that in the above case compiling the files separately will generate less
code as the whole b.o file will be eliminated by the linker...
--
Summary: unused function not eliminated with -fwhole-program --
combine
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26850
[Bug tree-optimization/26830] [4.1/4.2 Regression] Insane amount of compile-time / memory needed at -O1 and above
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-03-24 16:26 --- With -O1 -fno-tree-ch we get (on ia64 again): tree copy propagation : 132.88 (22%) usr 0.07 ( 1%) sys 132.94 (22%) wall 5037 kB ( 0%) ggc tree store copy prop : 27.43 ( 5%) usr 0.01 ( 0%) sys 27.44 ( 5%) wall 1090 kB ( 0%) ggc tree PHI insertion: 79.40 (13%) usr 1.74 (31%) sys 81.14 (13%) wall 1512507 kB (77%) ggc tree SSA rewrite : 94.23 (16%) usr 0.09 ( 2%) sys 94.32 (16%) wall 22257 kB ( 1%) ggc dominator optimization: 66.17 (11%) usr 0.07 ( 1%) sys 66.24 (11%) wall 18901 kB ( 1%) ggc tree loop init: 29.35 ( 5%) usr 0.00 ( 0%) sys 29.35 ( 5%) wall 9 kB ( 0%) ggc tree SSA uncprop : 27.61 ( 5%) usr 0.00 ( 0%) sys 27.61 ( 5%) wall 0 kB ( 0%) ggc expand: 31.99 ( 5%) usr 0.04 ( 1%) sys 32.04 ( 5%) wall 49360 kB ( 3%) ggc TOTAL : 599.15 5.55 604.92 1964166 kB so, much more mixed results, but tree copy propagation now being the worst offender. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug tree-optimization/26850] unused function not eliminated with -fwhole-program --combine
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-24 16:27 --- IIRC the problem here is that we don't go through the program again to change TREE_ADDRESSABLE on those decls. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26850
[Bug tree-optimization/26830] [4.1/4.2 Regression] Insane amount of compile-time / memory needed at -O1 and above
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-03-24 16:33 --- Now compare numbers from 4.0.3 (i686 again): tree PHI insertion: 6.50 (12%) usr 0.06 ( 2%) sys 6.99 (11%) wall tree SSA rewrite : 8.25 (15%) usr 0.02 ( 1%) sys 8.75 (14%) wall tree SSA other: 3.18 ( 6%) usr 0.20 ( 6%) sys 5.07 ( 8%) wall dominator optimization: 8.73 (16%) usr 0.06 ( 2%) sys 8.87 (14%) wall global alloc : 4.58 ( 8%) usr 0.27 ( 9%) sys 5.28 ( 8%) wall TOTAL : 53.96 3.0863.37 the usual and expected offender, DOM. But you can also imagine the big PHIs there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
--- Comment #3 from walter dot zimmer at dlr dot de 2006-03-24 16:57 --- (In reply to comment #1) Mudflap needs memory to set up runtime data structures, so you simply need more (virtual) memory. I investigated further and found that it is not the size of the memory that matters. The problem seems to be that we also use fortran code, which is not mudflapped, but needs the gfortran library. The mudflapped C code uses malloc(), which gets wrapped into calls to __mfwrap_malloc(). Unfortunately, libgfortran also uses malloc(), which is instrumented by libmudflap but shouldn't, as this exactly is causing the error. One workaround is to use g77 instead of gfortran, as libg2c apparently doesn't call malloc(). The other proposal we came up with is to link the fortran part as dynamic library at runtime, but we didn't try this yet. Therefore, I guess this is not a bug in mudflap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446
[Bug c++/26740] [4.2 regression] ICE taking the address of a bound member function
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-03-24 17:08
---
The following code should compile with -fpermissive or -fms-extensions.
So changing to ice-on-valid-code.
==
struct A
{
void foo();
};
void bar()
{
A().foo;
}
==
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|error-recovery, ice-on- |ice-on-valid-code, monitored
|invalid-code|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26740
[Bug bootstrap/26852] New: bootstrap fails, if neither zip nor fastjar can be found
the install in libjava/classpath/tools fails, if neither zip nor fastjar can be found. The just built fastjar is not found/used. (cd classes; \ if test != ; then -r ../tools.zip .; fi; \ if test /usr/bin/fastjar != ; then /usr/bin/fastjar cf ../tools.zip .; fi; \ cd ..) rm -rf classes works, but if we don't a fastjar installed: (cd classes; \ if test != ; then -r ../tools.zip .; fi; \ if test != ; then cf ../tools.zip .; fi; \ cd ..) rm -rf classes test -z /usr/lib/gcc-snapshot/share/classpath/tools || mkdir -p -- /build/buildd/gcc-snapshot-20060323/debian/tmp/usr/lib/gcc-snapshot/share/classpath/tools /usr/bin/install -c -m 644 '../../../../../src/libjava/classpath/tools/tools.zip' '/build/buildd/gcc-snapshot-20060323/debian/tmp/usr/lib/gcc-snapshot/share/classpath/tools/tools.zip' /usr/bin/install: cannot stat `../../../../../src/libjava/classpath/tools/tools.zip': No such file or directory -- Summary: bootstrap fails, if neither zip nor fastjar can be found Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26852
[Bug bootstrap/26829] broken classpath install (missed tools.zip), zip or fastjar not found
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-24 17:14:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26829
[Bug bootstrap/26852] bootstrap fails, if neither zip nor fastjar can be found
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-24 17:14 --- *** This bug has been marked as a duplicate of 26829 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26852
[Bug bootstrap/26829] broken classpath install (missed tools.zip), zip or fastjar not found
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-24 17:14 --- *** Bug 26852 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26829
[Bug bootstrap/26829] broken classpath install (missed tools.zip), zip or fastjar not found
--- Comment #7 from debian-gcc at lists dot debian dot org 2006-03-24 17:24 --- testing fix ... --- libjava/configure.ac~ 2006-03-14 01:03:16.0 + +++ libjava/configure.ac2006-03-24 18:14:55.0 + @@ -340,6 +340,7 @@ # We need this as qt is disabled by default in classpath. ac_configure_args=$ac_configure_args --enable-qt-peer fi +ac_configure_args=$ac_configure_args --with-fastjar=$ZIP dnl --with-gcj=$GCJ dnl --with-javah=$GCJH dnl gjdoc? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26829
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #28 from aph at gcc dot gnu dot org 2006-03-24 17:41 --- Richard Guenther: should this be posted to [EMAIL PROTECTED] for discussion? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug gcov/profile/25351] Segmentation fault in function coverage_checksum_string
--- Comment #5 from lothar at tradescape dot biz 2006-03-24 18:45 --- We also get ICEs on valid code with gcc 4.1.0 on both i686 and x86_64 both on Linux if we compile our source with -fprofile-arcs -ftest-coverage. When I tried to produce a precompiled (-E) file I could NOT reproduce the ICE which made it impossible for me to file a bug report on my own. It worked without problems with gcc 4.0.2. I downloaded the Quick Fix and we no longer get ICEs. I have NOT checked the quality of the coverage output produced by this patched gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25351
[Bug ada/26853] New: [4.2 Regression] ACATS c43212a failure at runtime
The error message is: ,.,. C43212A ACATS 2.5 06-03-24 20:48:43 C43212A CHECK THAT CONSTRAINT_ERROR IS RAISED IF ALL SUBAGGREGATES FOR A PARTICULAR DIMENSION DO NOT HAVE THE SAME BOUNDS. raised STORAGE_ERROR : stack overflow (or erroneous memory access) FAIL: c43212a -- Summary: [4.2 Regression] ACATS c43212a failure at runtime Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ebotcazou at gcc dot gnu dot org GCC build triplet: i586-*-* GCC host triplet: i586-*-* GCC target triplet: i586-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26853
[Bug c/26854] New: Inordinate compile times on large routines
At this location: http://www.math.purdue.edu/~lucier/gcc/test-files/bugzilla/1/all.i.gz is the file -rw-r--r--1 lucier lucier 6556015 Mar 22 20:28 all.i.gz On a 2GHz Mac G5, this file took 3.4GB and 30 minutes to compile using gcc-4.1.0 configured and compiled with /bin/rm -rf *; env CC='gcc -mcpu=970 -m64' ../configure --prefix=/pkgs/gcc-4.1.0 --with-gmp=/opt/local/ --with-mpfr=/opt/local/ --with-as=/usr/local/odcctools-20060123/bin/as --with-ld=/usr/local/odcctools-20060123/bin/ld --enable-languages=c; make -j 8 bootstrap BOOT_CFLAGS='-mcpu=970 -m64 -O2 -g' build.log I had to build gcc as a 64-bit binary so it could allocate more than 2GB at some point in the compilation process. (The compiler itself, however, builds 32-bit binaries by default.) The compile options were /pkgs/gcc-4.1.0/bin/gcc -mcpu=970 -m64 -no-cpp-precomp -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -bundle -flat_namespace -undefined suppress -I/usr/local/Gambit-C/include/ -ftime-report -fmem-report all.i The reports were Memory still allocated at the end of the compilation process Size AllocatedUsedOverhead 8 16k 14k480 1652k 12k 1144 64 1276k 1239k 19k 256 484k452k 6776 512 36k 25k504 1024 220k216k 3080 2048 24k 20k336 4096 68k 68k952 8192 56k 56k392 16384 16k 16k 56 32768288k288k504 65536 64k 64k 56 131072128k128k 56 262144512k512k112 524288512k512k 56 1048576 1024k 1024k 56 2097152 4096k 4096k112 112 34M 16M484k 208 40k 38k560 192 3344k 3287k 45k 160 28k 6240 392 176 564k261k 7896 48 2088k 1165k 32k 32 148k 68k 2664 8035M 2063k495k Total 84M 32M 1104k String pool entries 158178 identifiers 158178 (100.00%) slots 262144 bytes 1982k (168k overhead) table size 2048k coll/search 1.1104 ins/search 0.1934 avg. entry 12.83 bytes (+/- 7.81) longest entry 67 ??? tree nodes created (No per-node statistics) Type hash: size 1021, 598 elements, 0.900368 collisions DECL_DEBUG_EXPR hash: size 8191, 0 elements, 1.307819 collisions DECL_VALUE_EXPR hash: size 1021, 0 elements, 0.00 collisions Execution times (seconds) garbage collection: 1.87 ( 0%) usr 0.03 ( 0%) sys 2.38 ( 0%) wall 0 kB ( 0%) ggc callgraph construction: 1.78 ( 0%) usr 0.36 ( 0%) sys 2.60 ( 0%) wall 21241 kB ( 2%) ggc callgraph optimization: 0.05 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall 0 kB ( 0%) ggc ipa reference : 0.42 ( 0%) usr 0.14 ( 0%) sys 0.65 ( 0%) wall 7 kB ( 0%) ggc cfg construction : 0.35 ( 0%) usr 0.00 ( 0%) sys 0.43 ( 0%) wall 8421 kB ( 1%) ggc cfg cleanup : 103.72 ( 7%) usr 0.71 ( 1%) sys 128.58 ( 7%) wall 2170 kB ( 0%) ggc trivially dead code : 2.60 ( 0%) usr 0.06 ( 0%) sys 3.32 ( 0%) wall 0 kB ( 0%) ggc life analysis : 6.42 ( 0%) usr 3.91 ( 3%) sys 12.64 ( 1%) wall 19365 kB ( 2%) ggc life info update : 1.04 ( 0%) usr 0.03 ( 0%) sys 1.32 ( 0%) wall 525 kB ( 0%) ggc alias analysis: 1.70 ( 0%) usr 0.07 ( 0%) sys 2.13 ( 0%) wall 16385 kB ( 2%) ggc register scan : 0.96 ( 0%) usr 0.02 ( 0%) sys 1.28 ( 0%) wall 4 kB ( 0%) ggc rebuild jump labels : 0.32 ( 0%) usr 0.00 ( 0%) sys 0.38 ( 0%) wall 0 kB ( 0%) ggc preprocessing : 8.05 ( 1%) usr 13.05 (10%) sys 25.54 ( 1%) wall 2197 kB ( 0%) ggc lexical analysis : 12.59 ( 1%) usr 25.04 (19%) sys 46.78 ( 2%) wall 0 kB ( 0%) ggc parser: 9.97 ( 1%) usr 13.25 (10%) sys 28.99 ( 1%) wall 72677 kB ( 7%) ggc tree gimplify : 1.50 ( 0%) usr 0.07 ( 0%) sys 1.93 ( 0%) wall 30969 kB ( 3%) ggc tree eh : 0.17 ( 0%) usr 0.01 ( 0%) sys 0.21 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.55 ( 0%) usr 0.13 ( 0%) sys 0.81 ( 0%) wall 76077 kB ( 8%) ggc tree CFG cleanup : 5.82 ( 0%) usr 0.08 ( 0%) sys 7.25 ( 0%) wall 955 kB ( 0%) ggc tree copy propagation : 5.42 ( 0%) usr 0.44 ( 0%) sys 7.11 ( 0%) wall 12020 kB ( 1%) ggc tree store copy prop : 0.75 ( 0%) usr 0.05 ( 0%) sys 0.97 ( 0%) wall 1600 kB ( 0%) ggc tree find ref. vars : 0.23 ( 0%) usr 0.01 ( 0%) sys 0.24 ( 0%) wall 2502 kB (
[Bug rtl-optimization/26855] New: ICE in add_deps_for_def with -fmodulo-sched -maltivec
GCC mainline gets an internal compiler error on powerpc-linux building HMMER (http://hmmer.wustl.edu/) with -O2 -fmodulo-sched -maltivec. I'll attach a minimized test case. The failure is with trunk; 4.1 and 4.0 don't fail. elm3b145% /opt/gcc-nightly/trunk/bin/gcc -O2 -fmodulo-sched -maltivec -c hmmer.c hmmer.c: In function bar: hmmer.c:30: internal compiler error: in add_deps_for_def, at ddg.c:243 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. A regression hunt identified this patch: http://gcc.gnu.org/viewcvs?view=revrev=110312 r110312 | zadeck | 2006-01-27 22:23:32 + (Fri, 27 Jan 2006) -- Summary: ICE in add_deps_for_def with -fmodulo-sched -maltivec Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26855
[Bug rtl-optimization/26855] ICE in add_deps_for_def with -fmodulo-sched -maltivec
--- Comment #1 from janis at gcc dot gnu dot org 2006-03-24 21:42 --- Created an attachment (id=6) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6action=view) minimized testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26855
[Bug rtl-optimization/26855] [4.2 Regression] ICE in add_deps_for_def with -fmodulo-sched -maltivec
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Summary|ICE in add_deps_for_def with|[4.2 Regression] ICE in |-fmodulo-sched -maltivec|add_deps_for_def with - ||fmodulo-sched -maltivec Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26855
[Bug target/26793] [4.2 Regression] C++ is broken on powerpc-darwin7.9.0 after __cxa_atexit patch
--- Comment #2 from geoffk at gcc dot gnu dot org 2006-03-24 21:59 --- Subject: Bug 26793 Author: geoffk Date: Fri Mar 24 21:59:48 2006 New Revision: 112361 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112361 Log: 2006-03-23 Geoffrey Keating [EMAIL PROTECTED] PR 26793 * config/t-darwin (crt3.o): Work around bug 26840. * config/darwin-crt3.c: Rewrite. * config/darwin.h (STARTFILE_SPEC): Don't use -l for crt3.o. Index: gcc/testsuite/ChangeLog 2006-03-24 Geoffrey Keating [EMAIL PROTECTED] * g++.old-deja/g++.other/init19.C: New. Added: trunk/gcc/testsuite/g++.old-deja/g++.other/init19.C - copied, changed from r112297, branches/apple-local-200502-branch/gcc/testsuite/g++.old-deja/g++.other/init19.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-crt3.c trunk/gcc/config/darwin.h trunk/gcc/config/t-darwin trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26793
[Bug middle-end/26840] [4.2 Regression] escaping global variables cause 'definition follows use' error.
--- Comment #9 from geoffk at gcc dot gnu dot org 2006-03-24 21:59 --- Subject: Bug 26840 Author: geoffk Date: Fri Mar 24 21:59:48 2006 New Revision: 112361 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112361 Log: 2006-03-23 Geoffrey Keating [EMAIL PROTECTED] PR 26793 * config/t-darwin (crt3.o): Work around bug 26840. * config/darwin-crt3.c: Rewrite. * config/darwin.h (STARTFILE_SPEC): Don't use -l for crt3.o. Index: gcc/testsuite/ChangeLog 2006-03-24 Geoffrey Keating [EMAIL PROTECTED] * g++.old-deja/g++.other/init19.C: New. Added: trunk/gcc/testsuite/g++.old-deja/g++.other/init19.C - copied, changed from r112297, branches/apple-local-200502-branch/gcc/testsuite/g++.old-deja/g++.other/init19.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-crt3.c trunk/gcc/config/darwin.h trunk/gcc/config/t-darwin trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26840
[Bug other/26856] New: compilation errors in mesa and xorg-server with -march=k6-3
When compiling mesa and xorg-server (in the same file in fact) and using
-march=k6-3 I got an assembly error, that not occurs if using (for proximity to
my type of cpu) -march=pentium-mmx
I've got the same error also in two other packages: imagemagick and sdl_image.
Steps to reproduce:
--
1) compile the Mesa-6.4.2/src/mesa/main/texcompress_fxt1.c with the following
comand line:
gcc -c -I../../include -I../../src/mesa -I../../src/mesa/main
-I../../src/mesa/glapi -I../../src/mesa/math -I../../src/mesa/tnl
-I../../src/mesa/shader -I../../src/mesa/shader/grammar
-I../../src/mesa/shader/slang -I../../src/mesa/shader/slang/OSDependent/Linux
-I../../src/mesa/shader/slang/OGLCompilersDLL -I../../src/mesa/swrast
-I../../src/mesa/swrast_setup -Wall -O2 -march=k6-3 -fomit-frame-pointer -pipe
-fPIC -m32 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE
-D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1
-DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS
-DDEFAULT_DRIVER_DIR='/usr/lib/xorg/modules/dri' -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 -ffast-math main/texcompress_fxt1.c -o
main/texcompress_fxt1.o -Wall
Results:
---
The output of the compiler is
{entrada estándar}: Mensajes del ensamblador:
{entrada estándar}:1385: Error: el valor de ff7e es demasiado
grande para el campo de 1 bytes en 10d5
The english translation I think is like:
{standard input}: Assembler messages:
{standard input}:1385: Error: value of ff7e too large for field of
1 bytes at 10d5
Build Date Platform:
-
2006-03-24
Linux (kernel 2.6.15-gentoo-r1 )
i586 AMD-K6-III(tm) 3D+ Processor
--
Summary: compilation errors in mesa and xorg-server with -
march=k6-3
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: agathos at fobos dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26856
[Bug target/20653] value too large for field on k6-2 (loop instruction)
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-24 22:56 --- *** Bug 26856 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||agathos at fobos dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20653
[Bug target/26856] compilation errors in mesa and xorg-server with -march=k6-3
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-24 22:56 --- *** This bug has been marked as a duplicate of 20653 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26856
[Bug middle-end/26840] [4.2 Regression] escaping global variables cause 'definition follows use' error.
--- Comment #10 from law at redhat dot com 2006-03-24 23:23 --- Subject: Re: [4.2 Regression] escaping global variables cause 'definition follows use' error. On Fri, 2006-03-24 at 03:03 +, pinskia at gcc dot gnu dot org wrote: --- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-24 03:03 --- Caused by: 2006-03-20 Jeff Law [EMAIL PROTECTED] * tree-pass.h (pass_phi_only_copy_prop): Delete. (pass_phi_only_cprop): Declare. * passes.c (init_optimization_passes): Replace pass_phi_only_copy_prop with phi_only_cprop * tree-ssa-dom.c (degenerate_phi_result): New function. (remove_stmt_or_phi, get_lhs_or_phi_result): Likewise. (get_rhs_or_phi_arg, propagate_rhs_into_lhs): Likewise. (eliminate_const_or_copy, eliminate_degenerate_phis_1): Likewise. (eliminate_degenerate_phis): Likewise. (pass_phi_only_cprop): New pass descriptor. * tree-ssa-copy.c (init_copy_prop): Lose PHIS_ONLY argument and support code. Callers updated. (execute_copy_prop, do_copy_prop): Likewise and corresponding changes. (store_copy_prop): Likewise. (do_phi_only_copy_prop, pass_phi_only_copy_prop): Remove. Fixed by not calling update_stmt directly, but instead letting mark_new_vars_to_rename call update_stmt at the appropriate time. Bootstrapped and regression tested on i686-pc-linux-gnu. Onward to Ada... --- Comment #11 from law at redhat dot com 2006-03-24 23:23 --- Created an attachment (id=7) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26840
[Bug middle-end/26840] [4.2 Regression] escaping global variables cause 'definition follows use' error.
--- Comment #12 from law at redhat dot com 2006-03-24 23:24 --- Fix via today's checkin. -- law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26840
[Bug preprocessor/26857] New: Warning for absolute or dotted header paths
Given that some build systems try to encapsulate system headers separately from those found in /usr/include, primarily through careful arrangement of -I flags, it would be helpful if there was a warning flag, let's call it -Wstrict-header-path for now, which would signal when a source file tries to do the following: #include /usr/include/sys/stat.h #include ../../../sys/stat.h Ian Lance Taylor has indicated to me that this could be done as a check on fname in do_include_common in libcpp/directives.c. I would be willing to attempt a patch myself if this enhancement is accepted. -- Summary: Warning for absolute or dotted header paths Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mbland at google dot com GCC build triplet: N/A GCC host triplet: N/A GCC target triplet: N/A http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26857
[Bug libgcj/26858] New: NullPointerException not generated for large classes...
When running on some Linux kernels, the heap is mapped into memory low in the address space. Dereferencing a null pointer for class with a lot of fields an erroneously access the heap instead of throwing a NullPointerException. -- Summary: NullPointerException not generated for large classes... Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: daney at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26858
[Bug c/26859] New: ICE Segmentation Fault
dunno see complete test case -- Summary: ICE Segmentation Fault Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets dot com GCC build triplet: i686-slackware-linux GCC host triplet: i686-slackware-linux GCC target triplet: i686-slackware-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26859
[Bug c/26859] ICE Segmentation Fault
--- Comment #1 from malitzke at metronets dot com 2006-03-25 00:45 --- Created an attachment (id=8) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8action=view) complete test case (command, console out, *.e) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26859
[Bug tree-optimization/26859] ICE Segmentation Fault
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-25 00:59 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26859
[Bug tree-optimization/26859] ICE Segmentation Fault
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-25 01:00 --- Oh, by the way please next time put the command and console out not in the attachment but in the comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26859
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #29 from matz at suse dot de 2006-03-25 01:07 --- There is a minor glitch in the patch from Richard, which went in when cleaning it up. This line: + __asm__ (.symver pthread_create, pthread_create@@ GC_PTHREAD_SYM_VERSION); which creates the right version of the overriding symbol actually needs to read + __asm__ (.symver GC_pthread_create,pthread_create@@GC_PTHREAD_SYM_VERSION); as that is how the function now is called. regtesting of libjava with that change in the patch on x86_64 looks good now (it doesn't with the patch as posted). -- matz at suse dot de changed: What|Removed |Added CC||matz at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug libgcj/26860] New: NullPointerException not generated for large classes...
When running on some Linux kernels, the heap is mapped into memory low in the address space. Dereferencing a null pointer for class with a lot of fields an erroneously access the heap instead of throwing a NullPointerException. -- Summary: NullPointerException not generated for large classes... Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: daney at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26860
[Bug libgcj/26860] NullPointerException not generated for large classes...
--- Comment #1 from daney at gcc dot gnu dot org 2006-03-25 01:56 --- Due to a slip of the fingers, I created a duplicate entry. *** This bug has been marked as a duplicate of 26858 *** -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26860
[Bug libgcj/26858] NullPointerException not generated for large classes...
--- Comment #1 from daney at gcc dot gnu dot org 2006-03-25 01:56 --- *** Bug 26860 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26858
[Bug libgcj/26858] NullPointerException not generated for large classes...
--- Comment #2 from daney at gcc dot gnu dot org 2006-03-25 01:57 --- The testcase has been committed to the libgcj testsuite as testsuite/libjava.lang/PR26858.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26858
[Bug libgcj/26861] New: VirtualMachineError in interperter.
While running make -k check for libjava, the testcase for PR26858 protuces a VirtualMachineError in the interperter. Exception in thread main java.lang.VirtualMachineError at PR26858.printV (PR26858.java:2057) at PR26858.main (PR26858.java:2067) XFAIL: PR26858 execution - gij test UNTESTED: PR26858 output - gij test -- Summary: VirtualMachineError in interperter. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: daney at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26861
[Bug c++/26862] New: Non-pod data structure copied incorrectly during static initialization
When a structure is defined without a constructor but that contains non-pod
data, the containing structure is also non-pod. When an array of these
enclosing non-pod structures is declared as a global static array with an
initializer list, the structures appear to be constructed on the stack and
copied into place without the use of the copy constructors of the contained
non-pod members, which is illegal.
The following C++ program demonstrates the problem:
#include iostream
class A {
public:
A( int b ) {
a_ = reinterpret_cast void * ( this );
b_ = b;
}
A( A const that ) {
a_ = this;
b_ = that.b_;
}
void dump() const {
std::coutthis = reinterpret_cast const void * ( this )
std::endl;
std::couta_ = a_ std::endl;
std::coutb_ = b_ std::endl std::endl;
}
private:
const void * a_;
int b_;
};
A globalA( 1 );
static const A globalAArray[] =
{
A( 11 ),
A( 22 ),
A( 33 )
};
struct ContainsA {
#if !defined( SHOW_GCC_BUG )
ContainsA( A const a1, A const a2 );
#endif // #if !defined( SHOW_GCC_BUG )
A a1_;
A a2_;
};
#if !defined( SHOW_GCC_BUG )
ContainsA::ContainsA( A const a1, A const a2 )
: a1_( a1 ),
a2_( a2 ) {
}
#endif // #if !defined( SHOW_GCC_BUG )
static const ContainsA containsAArray[] =
{
#if !defined( SHOW_GCC_BUG )
ContainsA( A( 111 ), A( 222 ) ),
ContainsA( A( 333 ), A( 444 ) ),
ContainsA( A( 555 ), A( 666 ) )
#else // #if !defined( SHOW_GCC_BUG )
{
A( 111 ),
A( 222 )
},
{
A( 333 ),
A( 444 )
},
{
A( 555 ),
A( 666 )
}
#endif // #if !defined( SHOW_GCC_BUG )
};
int main( void ) {
std::cout Global A: std::endl;
globalA.dump();
std::cout Local A: std::endl;
A localA( 3 );
localA.dump();
std::cout Global A Array: std::endl;
for ( int i = 0; i 3; ++i ) {
globalAArray[ i ].dump();
}
std::cout Global ContainsA Array: std::endl;
for ( int i = 0; i 3; ++i ) {
containsAArray[ i ].a1_.dump();
containsAArray[ i ].a2_.dump();
}
return 0;
}
If this program is compiled (on gcc 3.4.2) using -DSHOW_GCC_BUG and run, the
output shows that a_ != this, which is not correct. Both constructors of the
non-pod A class assign a_ = this. There should never be an instance of A
where a_ != this. Inspecting the values of a_ when a_ != this shows that
they are similar to the value of a_ for the instance of class A created locally
(on the stack), suggesting that the instances of A or the instances of
ContainsA were created on the stack and then memcpy'd or memmov'd into place
rather than copy constructed into place. Either of these cases is invalid
because class A is non-pod and should not ever be memcpy'd.
--
Summary: Non-pod data structure copied incorrectly during static
initialization
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: e_hohenstein at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26862
[Bug tree-optimization/26859] [4.2 Regression] ICE Segmentation Fault
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-25 02:40 ---
Reduced testcase:
void f(long nb)
{
long i, j, d, d2;
for (i=1; i=nb; i++)
if (i1)
{
d = i-1;
d2 = 2*i-3;
for (j=d; j0; j--)
{
divrs( d2 );
d2-=2;
}
}
}
The segfault is in fold-const but the backtrace comes from scev.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||spop at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|i686-slackware-linux|
GCC host triplet|i686-slackware-linux|
GCC target triplet|i686-slackware-linux|
Last reconfirmed|-00-00 00:00:00 |2006-03-25 02:40:09
date||
Summary|ICE Segmentation Fault |[4.2 Regression] ICE
||Segmentation Fault
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26859
[Bug c++/26862] Non-pod data structure copied incorrectly during static initialization
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-25 02:45 --- Fixed in 4.0.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26862
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED Last reconfirmed|2006-02-24 18:42:12 |2006-03-25 02:59:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #16 from amodra at bigpond dot net dot au 2006-03-25 03:00 --- Indeed, that patch cures the problem. -- amodra at bigpond dot net dot au changed: What|Removed |Added CC|amodra at bigpond dot net | |dot au | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug c/26864] New: multithreaded mudflap not working
gcc version:
gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
Sample program t1.c:
int main()
{
int a[3] = { 1, 2, 3 };
return a[3];
}
When I compile this with mudflap, it correctly reports an error:
$ gcc -fmudflap t1.c -lmudflap
$ a.out
***
mudflap violation 1 (check/read): time=1143264091.275264 ptr=0xbf97b680 size=16
pc=0x5e8373 location=`s3.c:4 (main)'
/usr/lib/libmudflap.so.0(__mf_check+0x44) [0x5e8373]
a.out(main+0xa1) [0x8048751]
/usr/lib/libmudflap.so.0(__wrap_main+0x1d8) [0x5e90be]
Nearby object 1: checked region begins 0B into and ends 4B after
mudflap object 0x8712380: name=`s3.c:3 (main) a'
bounds=[0xbf97b680,0xbf97b68b] size=12 area=stack check=3r/0w liveness=3
alloc time=1143264091.275229 pc=0x5e8e7a
number of nearby objects: 1
The manual recommends using -fmudflapth for multithreaded programs. One thing
in the man page/online manual that is not clear is whether to link with
libmudflap or libmudflapth for multithreaded program. Both libraries exist but
only libmudflap is mentioned in the manual. This should be clarified.
In any case, when I link with either -lmudflap or -lmudflapth and compile with
-fmudflapth, a.out gives no output at all.
$ gcc -pthread -fmudflapth t1.c -lmudflapth
[ omitted irrelevant warnings about deprecated pthread_attr_getstackaddr ]
$ a.out
[ no output at all ]
$ gcc -pthread -fmudflapth t1.c -lmudflap
[ same ]
$ a.out
[ no output ]
--
Summary: multithreaded mudflap not working
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pr2345 at gmail dot com
GCC build triplet: same
GCC host triplet: Linux 2.6 i386
GCC target triplet: same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26864
[Bug c/26865] New: Segmentation fault with -std=c99 -O1 on genksyms.c
The attached preprocessed files, 122593_genksyms_min.i and its Delta-reduction 122593_genksyms_min.i, cause a segfault for checking=all builds of GCC 4.1.0 on both Ubuntu 5.04 and OSX 10.4.5 with -std=c99 and -O1. The original .c and .h files from the Linux kernel distribution (which I'll also attach) crash on Ubuntu but not OSX. Ubuntu issues warnings before crashing, whereas OSX compiles cleanly, which suggests a header problem. A checking=all build of 4.0.2 compiles all three versions of the file with warnings but no error, as does a checking build of GCC 3.4.3; so this is a regression. Here's the session: 48 /opt/gcc410-chk-all/bin/gcc -v -std=c99 -O1 ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i Using built-in specs. Target: powerpc-apple-darwin8.5.0 Configured with: /opt/Gcc-4.1.0-dist/configure --enable-checking=all --prefix=/opt/gcc410-chk-all --enable-languages=c,c++ --with-comment=PalmSource checking=all build by Flash Sheridan 3/17/06 Thread model: posix gcc version 4.1.0 /opt/gcc410-chk-all/libexec/gcc/powerpc-apple-darwin8.5.0/4.1.0/cc1 -fpreprocessed ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i -fPIC -quiet -dumpbase 122593_genksyms_min.i -auxbase 122593_genksyms_min -O1 -std=c99 -version -o /var/tmp//cc4PRuEJ.s GNU C version 4.1.0 (powerpc-apple-darwin8.5.0) compiled by GNU C version 4.0.1 (Apple Computer, Inc. build 5247). GGC heuristics: --param ggc-min-expand=0 --param ggc-min-heapsize=0 Compiler executable checksum: 1116648296470812f723ca4bff2463c0 ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:60: warning: return type defaults to 'int' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:63: warning: return type defaults to 'int' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:66: warning: return type defaults to 'int' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:69: warning: return type defaults to 'int' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:72: warning: return type defaults to 'int' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i: In function 'add_symbol': ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:74: warning: implicit declaration of function 'map_to_ns' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:75: warning: implicit declaration of function 'strlen' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:75: warning: incompatible implicit declaration of built-in function 'strlen' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:75: warning: implicit declaration of function 'memcmp' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:75: warning: implicit declaration of function 'strcmp' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i: At top level: ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:80: warning: return type defaults to 'int' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:83: warning: return type defaults to 'int' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:86: warning: return type defaults to 'int' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:91: warning: return type defaults to 'int' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:96: warning: return type defaults to 'int' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i: In function 'print_list': ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:101: warning: implicit declaration of function 'alloca' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:101: warning: assignment makes pointer from integer without a cast ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i: At top level: ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:106: warning: return type defaults to 'int' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i: In function 'expand_and_crc_list': ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:111: warning: implicit declaration of function 'error_with_pos' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i: At top level: ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:120: warning: return type defaults to 'int' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:125: warning: return type defaults to 'int' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:129: warning: conflicting types for 'error_with_pos' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:111: warning: previous implicit declaration of 'error_with_pos' was here ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i: In function 'genksyms_usage': ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:138: warning: implicit declaration of function 'fprintf' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:138: warning: incompatible implicit declaration of built-in function 'fprintf' ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i: In function 'print_list': ../cpp/bugfiles/GCC_bugfiles/error/122593_genksyms_min.i:96: internal compiler
[Bug c/26865] Segmentation fault with -std=c99 -O1 on genksyms.c
--- Comment #1 from flash at pobox dot com 2006-03-25 05:56 --- Created an attachment (id=11120) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11120action=view) Preprocessed Delta-reduced source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26865
[Bug c/26865] Segmentation fault with -std=c99 -O1 on genksyms.c
--- Comment #2 from flash at pobox dot com 2006-03-25 05:56 --- Created an attachment (id=11121) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11121action=view) Pre-processed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26865
[Bug c/26865] Segmentation fault with -std=c99 -O1 on genksyms.c
--- Comment #3 from flash at pobox dot com 2006-03-25 05:57 --- Created an attachment (id=11122) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11122action=view) Original source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26865
[Bug c/26865] Segmentation fault with -std=c99 -O1 on genksyms.c
--- Comment #4 from flash at pobox dot com 2006-03-25 05:57 --- Created an attachment (id=11123) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11123action=view) Original header -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26865
[Bug libmudflap/26864] multithreaded mudflap not working
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-25 07:20 --- This was reported to the list before (I cannot find it right now). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |libmudflap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26864
[Bug tree-optimization/26865] [4.1 Regression] Segmentation fault with -std=c99 -O1 on genksyms.c
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-25 07:24 --- Backtrace: #0 0x006fa7ae in find_func_aliases (t=0x2b1483c0, ai=0xb1d9b0) at /home/pinskia/src/gcc-4.1/gcc/gcc/tree-ssa-structalias.c:2932 #1 0x006fad8e in compute_points_to_sets (ai=0xb1d9b0) at /home/pinskia/src/gcc-4.1/gcc/gcc/tree-ssa-structalias.c:3742 #2 0x0047c74e in compute_may_aliases () at /home/pinskia/src/gcc-4.1/gcc/gcc/tree-ssa-alias.c:263 #3 0x006e5c66 in execute_one_pass (pass=0xa319a0) at /home/pinskia/src/gcc-4.1/gcc/gcc/passes.c:827 #4 0x006e5d5c in execute_pass_list (pass=0xa319a0) at /home/pinskia/src/gcc-4.1/gcc/gcc/passes.c:859 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |tree-optimization Keywords||ice-on-valid-code Known to fail||4.1.0 4.2.0 Known to work||4.2.0 4.0.3 Summary|Segmentation fault with - |[4.1 Regression] |std=c99 -O1 on genksyms.c |Segmentation fault with - ||std=c99 -O1 on genksyms.c Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26865
