[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-07 08:01 --- I checked again with a current x86 gcc, 3.4.4 20041206, and the problem is still there. Note that this only happens with cc1plus. Sorry, you're right, I was able to reproduce on i586-redhat-linux-gnu and i586-mandrake-linux-gnu but I needed -mtune=i686. As to why we get the impossible assembly, what happens is that the inline function cti gets expanded twice, but the first return label is used for both expansions: cti body jump ret_label ret_label cti body jump ret_label Thanks for the analysis. I'm going to investigate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug target/18864] New: ICE: insn does not satisfy its constraints
I see the following ICE with the appended source file:
$ gcc -c -DHAVE_CONFIG_H -I.. -I. -I.. -Wall -O2 slocal.c -save-temps -v
Reading specs from /usr/lib/gcc/powerpc-suse-linux/4.0.0/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,f95,java,ada --enable-checking
--with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit
--without-system-libunwind powerpc-suse-linux
Thread model: posix
gcc version 4.0.0 20041204 (experimental) (SUSE Linux)
/usr/lib/gcc/powerpc-suse-linux/4.0.0/cc1 -E -quiet -v -I.. -I. -I..
-D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux
-Asystem=linux -Asystem=unix -Asystem=posix -DHAVE_CONFIG_H slocal.c -Wall -O2
-fpch-preprocess -o slocal.i
ignoring duplicate directory ..
#include ... search starts here:
#include ... search starts here:
..
.
/usr/local/include
/usr/lib/gcc/powerpc-suse-linux/4.0.0/include
/usr/lib/gcc/powerpc-suse-linux/4.0.0/../../../../powerpc-suse-linux/include
/usr/include
End of search list.
/usr/lib/gcc/powerpc-suse-linux/4.0.0/cc1 -fpreprocessed slocal.i -quiet
-dumpbase slocal.c -auxbase slocal -O2 -Wall -version -o slocal.s
GNU C version 4.0.0 20041204 (experimental) (SUSE Linux) (powerpc-suse-linux)
compiled by GNU C version 4.0.0 20041204 (experimental) (SUSE Linux).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
slocal.c: In function ?parse?:
slocal.c:769: warning: pointer targets in passing argument 2 of ?m_getfld?
differ in signedness
slocal.c:769: warning: pointer targets in passing argument 3 of ?m_getfld?
differ in signedness
slocal.c:775: warning: pointer targets in passing argument 2 of ?m_getfld?
differ in signedness
slocal.c:775: warning: pointer targets in passing argument 3 of ?m_getfld?
differ in signedness
slocal.c: In function ?suppress_duplicates?:
slocal.c:1531: warning: pointer targets in passing argument 2 of ?m_getfld?
differ in signedness
slocal.c:1531: warning: pointer targets in passing argument 3 of ?m_getfld?
differ in signedness
slocal.c:1539: warning: pointer targets in passing argument 2 of ?m_getfld?
differ in signedness
slocal.c:1539: warning: pointer targets in passing argument 3 of ?m_getfld?
differ in signedness
slocal.c:1545: warning: pointer targets in passing argument 2 of ?m_getfld?
differ in signedness
slocal.c:1545: warning: pointer targets in passing argument 3 of ?m_getfld?
differ in signedness
slocal.c: In function ?usr_delivery?:
slocal.c:459: warning: ?status? may be used uninitialized in this function
slocal.c: In function ?main?:
slocal.c:415: error: insn does not satisfy its constraints:
(insn 1796 1761 1795 0 (set (reg:DI 32 0)
(const_int 0 [0x0])) 239 {*movdi_internal32} (nil)
(nil))
slocal.c:415: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
--
Summary: ICE: insn does not satisfy its constraints
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aj at gcc dot gnu dot org
CC: amodra at bigpond dot net dot au,gcc-bugs at gcc dot gnu
dot org
GCC build triplet: powerpc-linux
GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18864
[Bug target/18864] ICE: insn does not satisfy its constraints
--- Additional Comments From aj at gcc dot gnu dot org 2004-12-07 08:22 --- Created an attachment (id=7695) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7695action=view) Preprocessed file for Linux/PPC -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18864
[Bug target/18442] [4.0 Regression] Rejects attribute((mode(SI))) when using -mint64
--- Additional Comments From echristo at redhat dot com 2004-12-07 08:25 --- This came about with the scalar_mode_supported_p work. Patch in testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18442
[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-07 08:30 --- Investigating. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug target/18864] ICE: insn does not satisfy its constraints
--- Additional Comments From amodra at bigpond dot net dot au 2004-12-07 08:44 --- Confirmed with 4.0.0 20041206 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-07 08:44:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18864
[Bug c++/18865] New: ICE in cp_expr_size, at cp/cp-objcp-common.c:86
The following error occurs both with a 32-bit build on i686 and one with gcc -m32 on x86-64. /opt/gcc/4.0-devel/libexec/gcc/x86_64-suse-linux-gnu/4.0.0/cc1plus -m32 -fpreprocessed libskim_la.all_cpp.ii -quiet -dumpbase libskim_la.all_cpp.cpp -march=i686 -mtune=i686 -ansi -auxbase-strip libskim_la.all_cpp.lo -O2 -ansi -version -fmessage-length=0 -fno-exceptions -fno-check-new -fno-common -o libskim_la.all_cpp.s GNU C++ version 4.0.0 20041206 (experimental) (x86_64-suse-linux-gnu) compiled by GNU C version 4.0.0 20041206 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 libskim_la.all_cpp.ii: In member function 'void SkimGlobalActions::create_properties(QWidget*, PropertyRepository, const scim::PropertyList, __gnu_cxx::__normal_iteratorconst scim::Property*, std::vectorscim::Property, std::allocatorscim::Property , __gnu_cxx::__normal_iteratorconst scim::Property*, std::vectorscim::Property, std::allocatorscim::Property , int)': libskim_la.all_cpp.ii:72312: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:86 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE in cp_expr_size, at cp/cp-objcp-common.c:86 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aj at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18865
[Bug c++/18865] ICE in cp_expr_size, at cp/cp-objcp-common.c:86
--- Additional Comments From aj at gcc dot gnu dot org 2004-12-07 08:49 --- Created an attachment (id=7696) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7696action=view) Preprocessed and compressed file for Linux/x86 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18865
Re: complex numbers
On Mon, 6 Dec 2004, Gabriel Dos Reis wrote: As a matter of fact, the implementation of complex is criticized, once in a while, because it does NOT use the grammar school rule you present above. However, for float, double, long double it specializes to __complex__ T which is what the compiler uses to implement complex numbers in C99 and Fortran. So, the problem is a compiler problem not libstdc++ problem. I have testet my program with a 2.95 and several 3.x versionsions of gcc. The lastet version I have is 3.3.3. All versions gave the same result. What was the critice you mentioned above? I can not imagine a sitation in which I would need the naive implementation. But I think it can not be good that if I get different result for complex and real arithmetic. If the number are the same real numbers. Did you look at the actual implementation? As you mentinon it if have missed the specilization at the end of std_complex.h. Sorry. I still think that we should have and other implementation for complexfloating_point, but I cannot change the code of __complex__ T in the complier. Yours Andreas Klein
[Bug tree-optimization/17340] [4.0 Regression] Internal error compiling with -O3
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-07 09:01 --- This PR makes my 3GB x86-64 box go swapping. -- What|Removed |Added Last reconfirmed|2004-10-21 21:04:09 |2004-12-07 09:01:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17340
[Bug middle-end/18499] [4.0 Regression] quadratic behavior in cfgexpand
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-07 09:15 --- Fixed: Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 10 samples %symbol name 63499 4.4898 replace_goto_queue_stmt_list 40791 2.8842 ggc_alloc_stat 39075 2.7629 find_reloads 38041 2.6898 record_reg_classes 25783 1.8230 ggc_set_mark 22879 1.6177 walk_tree 22876 1.6175 gt_ggc_mx_lang_tree_node 19695 1.3926 mark_set_1 17427 1.2322 comptypes 14800 1.0465 htab_find_with_hash Execution times (seconds) garbage collection: 0.58 ( 4%) usr 0.01 ( 1%) sys 0.59 ( 4%) wall callgraph construction: 0.20 ( 1%) usr 0.03 ( 2%) sys 0.23 ( 1%) wall callgraph optimization: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall cfg cleanup : 0.28 ( 2%) usr 0.00 ( 0%) sys 0.31 ( 2%) wall trivially dead code : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall life analysis : 0.45 ( 3%) usr 0.01 ( 1%) sys 0.43 ( 3%) wall life info update : 0.20 ( 1%) usr 0.00 ( 0%) sys 0.22 ( 1%) wall register scan : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall rebuild jump labels : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.11 ( 1%) wall preprocessing : 0.12 ( 1%) usr 0.13 ( 7%) sys 0.27 ( 2%) wall parser: 3.55 (25%) usr 0.53 (29%) sys 3.88 (24%) wall name lookup : 0.88 ( 6%) usr 0.75 (41%) sys 1.60 (10%) wall tree gimplify : 0.63 ( 4%) usr 0.02 ( 1%) sys 0.80 ( 5%) wall tree eh : 0.89 ( 6%) usr 0.02 ( 1%) sys 0.93 ( 6%) wall tree CFG construction : 0.24 ( 2%) usr 0.04 ( 2%) sys 0.27 ( 2%) wall tree CFG cleanup : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 1%) wall expand: 1.19 ( 8%) usr 0.04 ( 2%) sys 1.14 ( 7%) wall varconst : 0.11 ( 1%) usr 0.02 ( 1%) sys 0.15 ( 1%) wall jump : 0.42 ( 3%) usr 0.02 ( 1%) sys 0.40 ( 3%) wall flow analysis : 0.10 ( 1%) usr 0.00 ( 0%) sys 0.11 ( 1%) wall local alloc : 0.76 ( 5%) usr 0.00 ( 0%) sys 0.78 ( 5%) wall global alloc : 1.59 (11%) usr 0.08 ( 4%) sys 1.68 (11%) wall flow 2: 0.33 ( 2%) usr 0.00 ( 0%) sys 0.31 ( 2%) wall shorten branches : 0.28 ( 2%) usr 0.00 ( 0%) sys 0.25 ( 2%) wall final : 0.59 ( 4%) usr 0.11 ( 6%) sys 0.80 ( 5%) wall symout: 0.03 ( 0%) usr 0.01 ( 1%) sys 0.03 ( 0%) wall rest of compilation : 0.50 ( 4%) usr 0.00 ( 0%) sys 0.46 ( 3%) wall TOTAL : 14.14 1.8215.97 -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18499
[Bug tree-optimization/17340] [4.0 Regression] Internal error compiling with -O3
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-07 09:27 --- This dies at -O1 -fno-inline when allocating the conflict graph: #0 xmalloc_failed (size=142104496) at xmalloc.c:118 #1 0x007c774b in xcalloc (nelem=Variable nelem is not available.) at xmalloc.c:161 #2 0x00766852 in global_alloc (file=0x0) at global.c:526 #3 0x00713123 in rest_of_compilation () at passes.c:529 #4 0x004baa8f in execute_pass_list (pass=0xa1c340) at tree-optimize.c:516 #5 0x004bad29 in tree_rest_of_compilation (fndecl=0x2a9def2e00) at tree-optimize.c:652 #6 0x00470cf2 in expand_body (fn=0x2a9def2e00) at semantics.c:2901 #7 0x00735111 in cgraph_expand_function (node=0x2aa00720e0) at cgraphunit.c:822 It *cough* dies somewhere else at -O2: #14001 0x004d2ac8 in compute_avail (block=0x2aa73ccb60) at tree-ssa-pre.c:1866 #14002 0x004d2ac8 in compute_avail (block=0x2aa73cca80) at tree-ssa-pre.c:1866 #14003 0x004d2ac8 in compute_avail (block=0x2aa73cc9a0) at tree-ssa-pre.c:1866 #14004 0x004d2ac8 in compute_avail (block=0x2aa73cc8c0) at tree-ssa-pre.c:1866 #14005 0x004d2ac8 in compute_avail (block=0x2aa73cc7e0) at tree-ssa-pre.c:1866 #14006 0x004d2ac8 in compute_avail (block=0x2aa73cc700) at tree-ssa-pre.c:1866 #14007 0x004d2ac8 in compute_avail (block=0x2aa73cc620) at tree-ssa-pre.c:1866 #14008 0x004d2ac8 in compute_avail (block=0x2aa73cc0e0) at tree-ssa-pre.c:1866 #14009 0x004d2ac8 in compute_avail (block=0x2aa73cc000) at tree-ssa-pre.c:1866 #14010 0x004d2ac8 in compute_avail (block=0x2aa7386ee0) at tree-ssa-pre.c:1866 #14011 0x004d2ac8 in compute_avail (block=0x2aa7386e00) at tree-ssa-pre.c:1866 #14012 0x004d2ac8 in compute_avail (block=0x2aa7386d20) at tree-ssa-pre.c:1866 #14013 0x004d2ac8 in compute_avail (block=0x2aa7386c40) at tree-ssa-pre.c:1866 #14014 0x004d2ac8 in compute_avail (block=0x2aa7386b60) at tree-ssa-pre.c:1866 #14015 0x004d2ac8 in compute_avail (block=0x2aa7386a80) at tree-ssa-pre.c:1866 #14016 0x004d2ac8 in compute_avail (block=0x2aa73869a0) at tree-ssa-pre.c:1866 #14017 0x004d2ac8 in compute_avail (block=0x2aa73868c0) at tree-ssa-pre.c:1866 #14018 0x004d2ac8 in compute_avail (block=0x2aa73867e0) at tree-ssa-pre.c:1866 #14019 0x004d2ac8 in compute_avail (block=0x2aa7386700) at tree-ssa-pre.c:1866 #14020 0x004d2ac8 in compute_avail (block=0x2aa7386620) at tree-ssa-pre.c:1866 #14021 0x004d2ac8 in compute_avail (block=0x2aa73861c0) at tree-ssa-pre.c:1866 -- What|Removed |Added CC||dberlin at dberlin dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17340
[Bug tree-optimization/17340] [4.0 Regression] Internal error compiling with -O3
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-07 09:28 --- For the record: (gdb) p current_function_name () $2 = 0x1d8124a0 int main(int, const char* const*) (gdb) p n_basic_blocks $1 = 29662 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17340
[Bug tree-optimization/17340] [4.0 Regression] Internal error compiling with -O3
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-07 09:31 --- The end of the backtrace looks like this: #18159 0x004d2ac8 in compute_avail (block=0x2aa7c9f0e0) at tree-ssa-pre.c:1866 #18160 0x004d2ac8 in compute_avail (block=0x2aa7c9de00) at tree-ssa-pre.c:1866 #18161 0x004d2ac8 in compute_avail (block=0x2aa7c9da80) at tree-ssa-pre.c:1866 #18162 0x004d30eb in execute_pre (do_fre=0 '\0') at tree-ssa-pre.c:2053 #18163 0x004baa8f in execute_pass_list (pass=0xa18780) at tree-optimize.c:516 ---Type return to continue, or q return to quit--- #18164 0x004bab24 in execute_pass_list (pass=0xa18200) at tree-optimize.c:554 #18165 0x004bad29 in tree_rest_of_compilation (fndecl=0x2a9def2e00) at tree-optimize.c:652 #18166 0x00470cf2 in expand_body (fn=0x2a9def2e00) at semantics.c:2901 #18167 0x00735111 in cgraph_expand_function (node=0x2aa00720e0) at cgraphunit.c:822 #18168 0x00735b1f in cgraph_optimize () at cgraphunit.c:1689 #18169 0x004407ea in cp_finish_file () at decl2.c:3074 #18170 0x004a5dca in c_common_parse_file (set_yydebug=Variable set_yydebug is not available.) at c-opts.c:1093 #18171 0x006faa4e in toplev_main (argc=Variable argc is not available.) at toplev.c:992 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17340
[Bug c/17932] gcc-3.4.2 fails to compile glibc-2.3.3
--- Additional Comments From ansgar dot radermacher at cea dot fr 2004-12-07 09:33 --- Subject: Re: gcc-3.4.2 fails to compile glibc-2.3.3 I understand that this is a glibc bug, a patch is available here: http://kegel.com/crosstool/crosstool-0.28-rc37/patches/glibc-2.3.2/fixup.patch I havn't tried it - alternatively, a workaround is to use gcc 3.3.4 or older to compile glibc-2.3.3. maryburak11 at aol dot com wrote: --- Additional Comments From maryburak11 at aol dot com 2004-12-03 19:58 --- Any fix for this? I'm getting the same error. I tried to build glibc 2.3.3 on RedHat Linux Advanced Serer 2.1 (kernel 2.4.9-e.24), but ran into an error saying compiler support for __threads is required, so I used configure --enable-add-ons=linuxthreads --prefix=/usr/local/glibc (note: prefix is not the same directory where the distribution was un-packed. That was done in /usr/local/glibc-2.3.3) That allowed configure to complete without any further errors. However, when I ran make, I got the following: ld-runtime.c:56: error: conflicting types for 'fixup' .../sysdeps/i386/dl-machine.h:158: error: previous declaration of 'fixup' was here dl-runtime.c:56: error: conflicting types for 'fixup' .../sysdeps/i386/dl-machine.h:158: error: previous delcaration of 'fixup' was here dl-runtime.c:141: error: conflicting types for 'profile_fixup' .../systemps/i386/dl-machine.h:161: error: previous delcaration of 'profile_fixup' was here dl-runtime.c:141: error: conflicting types for 'profile_fixup' .../sysdeps/i386/dl-machine.h:161: error: previous delcaration of 'profile_fixup' was here .../sysdeps/i386/dl-machine.h:158: warning: 'fixup' declared 'static' but never defined .../sysdeps/i386/sl-machine.h:161: warning: 'profile_fixup' declared' static' but never defined make[2]: *** [/usr/local/glibc/elf/dl-runtime.o] Error 1 make[2]: Leaving directory '/usr/local/glibc-2.3.3/elf' make[1]: *** [elf/subdir_lib] Error 2 make[1]: Leaving directory '/usr/local/glibc-2.3.3' make: *** [all] Error 2 I'm using gcc 3.4.3, with binutils 2.15. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17932
[Bug tree-optimization/17340] [4.0 Regression] Internal error compiling with -O3
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-07 09:40 --- With -fno-tree-pre we still die in global.c, only somewhere else this time: #0 xmalloc_failed (size=4072) at xmalloc.c:118 #1 0x007c in xmalloc (size=Variable size is not available.) at xmalloc.c:145 #2 0x002a956d8ff7 in _obstack_newchunk () from /lib64/tls/libc.so.6 #3 0x00505ea6 in bitmap_elt_insert_after (head=0x7fbfffe230, elt=0x1b7ade30) at bitmap.c:110 #4 0x00506f2b in bitmap_and_compl (dst=0x7fbfffe230, a=Variable a is not available.) at bitmap.c:661 #5 0x00507017 in bitmap_ior_and_compl (dst=0x4803960, a=0x4803900, from1=Variable from1 is not available.) at bitmap.c:1120 #6 0x0076628d in make_accurate_live_analysis () at global.c:2307 #7 0x007663ed in global_alloc (file=0x0) at global.c:347 #8 0x00713123 in rest_of_compilation () at passes.c:529 Not really surprising, given this: (gdb) p max_regno $6 = 65597 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17340
[Bug tree-optimization/17340] [4.0 Regression] Internal error compiling with -O3
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-07 09:40 --- Not Alpha-specific -- What|Removed |Added GCC build triplet|alphaev56-unknown-linux-gnu | GCC host triplet|alphaev56-unknown-linux-gnu | GCC target triplet|alphaev56-unknown-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17340
[Bug tree-optimization/17340] [4.0 Regression] Internal error compiling with -O3
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-07 09:46 --- When we die in PRE we have a huge number of SSA names too: (gdb) p ssa_names-elements_used $8 = 159414 GCC just doesn't scale to such sizes. I wonder how the function could grow this large. Even at -O2 -fno-inline we still ICE in global.c with n_basic_blocks == 37278 and max_regno == 49402. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17340
[Bug c++/18865] [4.0 Regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:86
--- Additional Comments From belyshev at lubercy dot com 2004-12-07 10:20
---
// reduced testcase
struct T
{
T ();
T (const T);
T operator= (const T);
};
struct S {
void *p;
T t;
void *q;
};
void foo ()
{
S s = {0, T (), 0};
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
GCC build triplet|i686-linux-gnu |
GCC host triplet|i686-linux-gnu |
GCC target triplet|i686-linux-gnu |
Keywords||ice-on-valid-code
Known to fail||4.0.0
Known to work||3.4.4
Last reconfirmed|-00-00 00:00:00 |2004-12-07 10:20:29
date||
Summary|ICE in cp_expr_size, at |[4.0 Regression] ICE in
|cp/cp-objcp-common.c:86 |cp_expr_size, at cp/cp-
||objcp-common.c:86
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18865
[Bug target/18564] ICE: output_operand: invalid expression as operand
--- Additional Comments From belyshev at lubercy dot com 2004-12-07 10:25 --- Why did you mark this bug as a duplicate? Because all these bugs (18542, 18563, 18564) triggered on one testcase and have identical backtrace. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18564
[Bug c++/18866] New: delete via pointer-to-member
Dear all,
I would like to post a fault report for the GNU C/C++ compiler 3.3-e500.
We use the compiler to generate code for a PowerPC processor.
Used invokation line for the GNU C++ compiler:
ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
-fmerge-templates -mmultiple -mno-string -mstrict-align -O3
-fno-exceptions -fno-rtti -fno-builtin-printf
-Idifferent include paths
-Ddifferen #define's
K.CPP -oK.O
// example program
struct X { char c; };
void f (char X::* p)
{
delete p;
delete[] p;
}
The compiler translates this without complaints even though the parameter p
doesn't have pointer type (it has pointer-to-member type).
With kind regards
W. Roehrl
--
Summary: delete via pointer-to-member
Product: gcc
Version: 3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wolfgang dot roehrl at de dot gi-de dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.5.1
GCC host triplet: i386-pc-mingw32
GCC target triplet: powerpc-wrs-vxworks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18866
[Bug c/18867] New: [4.0 Regression] ICE on invalid switch quantity
current mainline crashes on this invalid code:
void f()
{
float x;
switch (x) {case 0: break;};
}
bug.c: In function `f':
bug.c:4: error: switch quantity not an integer
bug.c:4: internal compiler error: Segmentation fault
: Search converges between 2004-07-20-trunk (#491) and 2004-07-21-trunk (#492).
--
Summary: [4.0 Regression] ICE on invalid switch quantity
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at lubercy dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18867
[Bug c/18867] [4.0 Regression] ICE on invalid switch quantity
-- What|Removed |Added Known to fail||4.0.0 Known to work||3.4.4 Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18867
Re: complex numbers
As you mentinon it if have missed the specilization at the end of std_complex.h. Sorry. I still think that we should have and other implementation for complexfloating_point, but I cannot change the code of __complex__ T in the complier. Interestingly, it looks like the discussed improved algorithm is *already* implemented, just not used! Have a look to expand_complex_division in gcc/tree-complex.c, then gcc/toplev.c for flag_complex_divide_method. Andreas, just for curiosity, are you willing to rebuild your gcc with flag_complex_divide_method = 1 and report??? Thanks, Paolo.
[Bug c/16351] NULL dereference warnings
--- Additional Comments From walles at mailblocks dot com 2004-12-07 12:04
---
Bug 18854 deals with *potential* NULL pointer dereferences, while this one
mentions only *confirmed* NULL pointer dereferences, i.e:
1 #include stdlib.h
2 int main(int argc, char *argv[]) {
3 volatile char *monkey = (char*)malloc(1234);
4 monkey[0] = '\0';
5 return 0;
6 }
Since malloc() on line 3 can *potentially* return NULL, I'd like a warning on
line 4.
Phython, would you say potential NULL dereferences are within the scope of this
bug, or should bug 18854 be re-opened for those cases?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
[Bug c++/18865] [4.0 Regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:86
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-07 12:24 --- Bug related to PR18793. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18865
[Bug c++/18100] [3.4/4.0 regression] template member with same name as class not rejected
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-07 12:34 --- Patch for 3.4 is submitted: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00450.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18100
[Bug c/18867] [4.0 Regression] ICE on invalid switch quantity
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18867
[Bug c/18867] [4.0 Regression] ICE on invalid switch quantity
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-07 13:05 --- Test this: Index: c-common.c === RCS file: /cvs/gcc/gcc/gcc/c-common.c,v retrieving revision 1.589 diff -u -p -r1.589 c-common.c --- c-common.c 29 Nov 2004 23:11:23 - 1.589 +++ c-common.c 7 Dec 2004 13:04:57 - @@ -1467,7 +1467,7 @@ check_case_bounds (tree type, tree orig_ tree case_high = case_high_p ? *case_high_p : case_low; /* If there was a problem with the original type, do nothing. */ - if (orig_type == error_mark_node) + if (! INTEGRAL_TYPE_P (orig_type)) return true; min_value = TYPE_MIN_VALUE (orig_type); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18867
Re: complex numbers
Hello Interestingly, it looks like the discussed improved algorithm is *already* implemented, just not used! Curious Have a look to expand_complex_division in gcc/tree-complex.c, then gcc/toplev.c for flag_complex_divide_method. Andreas, just for curiosity, are you willing to rebuild your gcc with flag_complex_divide_method = 1 and report??? Willing is not the problem. But I have only limitet privileges on this machine and I am not sure if I can find an other machine with enough resources. However I think if flag_complex_divide_method = 1 fix the problem it would be a good idea to set it by default. Andreas Klein
Re: complex numbers
Andreas Klein wrote: Have a look to expand_complex_division in gcc/tree-complex.c, then gcc/toplev.c for flag_complex_divide_method. Andreas, just for curiosity, are you willing to rebuild your gcc with flag_complex_divide_method = 1 and report??? Willing is not the problem. But I have only limitet privileges on this machine and I am not sure if I can find an other machine with enough resources. I will try to do the same as soon as possible... However I think if flag_complex_divide_method = 1 fix the problem it would be a good idea to set it by default. ... but notice that this issue is tricky: there are computational issues (we are adding at least a branch for each division) and correctness issues (what about C99?) Exerimenting a bit with those options and functions is only a *very* preliminary, explorative step! Paolo. P.S. In gcc3.3.x the relevant functions are in gcc/optabs.c
[Bug target/15834] NO_IMPLICIT_EXTERN_C should be gotten rid of
--- Additional Comments From hp at gcc dot gnu dot org 2004-12-07 13:18 --- Just to mention that arm-elf has the same oversight; missing NO_IMPLICIT_EXTERN_C. (The only define of it in config/arm, is in config/arm/linux-elf.h.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15834
[Bug java/18868] New: Interface containing anonymous class breaks gij
The following construct seems to have issues with gij (3.4 and 4.0) but works ok
with kaffe and jamvm (output lower down)
public class C {
public static void main(String[] arg) {
System.err.println(A.instance);
System.err.println(A.instance.getInstance());
}
}
interface A {
public static A instance = new A() {
public A getInstance() {
return instance;
}
};
public abstract A getInstance();
}
JamVM output:
[EMAIL PROTECTED] ~ jamvm C
[EMAIL PROTECTED]
[EMAIL PROTECTED]
GIJ-3.4 output:
[EMAIL PROTECTED] ~ gij-3.4 C
[EMAIL PROTECTED]
Exception in thread main java.lang.IncompatibleClassChangeError: field
A$1.instance was not found.
at _Jv_ResolvePoolEntry(java.lang.Class, int) (/usr/lib/libgcj.so.5.0.0)
at A$1.getInstance() (Unknown Source)
at C.main(java.lang.String[]) (Unknown Source)
[EMAIL PROTECTED] ~ /home/mkoch/local/gcc-
gcc-3.4-debian gcc-4.0 gcc-awt
GIJ-4.0 output:
[EMAIL PROTECTED] ~ /home/mkoch/local/gcc-4.0/bin/gij-4.0 C
[EMAIL PROTECTED]
Exception in thread main java.lang.IncompatibleClassChangeError: field
A$1.instance was not found.
at _Jv_Linker.resolve_pool_entry(java.lang.Class, int)
(/home/mkoch/local/gcc-4.0/lib/libgcj.so.6.0.0)
at A$1.getInstance() (Unknown Source)
at C.main(java.lang.String[]) (Unknown Source)
Kaffe output:
[EMAIL PROTECTED] ~ kaffe C
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED] ~
--
Summary: Interface containing anonymous class breaks gij
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: konqueror at gmx dot de
ReportedBy: steph at tangency dot co dot uk
CC: gcc-bugs at gcc dot gnu dot org,java-prs 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=18868
[Bug java/18868] Interface containing anonymous class breaks gij
--- Additional Comments From konqueror at gmx dot de 2004-12-07 13:24 --- The bug only occurs when compiling the testcase with jikes (1.22) and not when compiling gcj (3.4.2 or 4.0.0). -- What|Removed |Added Known to fail||3.4.2 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18868
Re: complex numbers
Paolo Carlini wrote: I will try to do the same as soon as possible... I can confirm that setting flag_complex_divide_method = 1 leads to (0, 0). Paolo.
[Bug c++/18866] delete via pointer-to-member
--- Additional Comments From giovannibajo at libero dot it 2004-12-07 13:42 --- Fixed already with the new C++ parser, available since GCC 3.4.0. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|delete via pointer-to-member|delete via pointer-to-member Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18866
[Bug target/18863] ICE in find_reloads
--- Additional Comments From giovannibajo at libero dot it 2004-12-07 13:45 --- Is this a regression? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18863
[Bug target/14766] [3.3 only] mips-sgi-irix6.5 testsuite failure in gcc.dg/overflow-1.c with -mabi=64
--- Additional Comments From kghazi at verizon dot net 2004-12-07 13:47 --- Subject: Re: [3.3 only] mips-sgi-irix6.5 testsuite failure in gcc.dg/overflow-1.c with -mabi=64 Fine with me. Then we should XFAIL it on the 3.3 branch at mabi=64. I don't have access to irix anymore (or any time for GCC at the moment) so I'd very much appreciate it if someone would take care of this. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14766
[Bug fortran/18869] New: multiple common blocks in a single line rejected
gfortran rejects the following valid syntax: $ cat common.f90 program main common /foo/ a, /bar/ b common /baz/ c /foobar/ d end program main $ gfortran common.f90 In file common.f90:2 common /foo/ a, /bar/ b 1 Error: Syntax error in COMMON statement at (1) In file common.f90:3 common /baz/ c /foobar/ d 1 Error: Syntax error in COMMON statement at (1) -- Summary: multiple common blocks in a single line rejected Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18869
[Bug java/18868] Interface containing anonymous class breaks gij
--- Additional Comments From konqueror at gmx dot de 2004-12-07 13:55 --- Created an attachment (id=7699) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7699action=view) Testcase compile by jikes 1.22 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18868
[Bug java/18868] Interface containing anonymous class breaks gij
-- What|Removed |Added AssignedTo|konqueror at gmx dot de |unassigned at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18868
[Bug target/18863] ICE in find_reloads
--- Additional Comments From simonb at wasabisystems dot com 2004-12-07 14:15 --- Subject: Re: ICE in find_reloads giovannibajo at libero dot it wrote: - Additional Comments From giovannibajo at libero dot it 2004-12-07 13:45 Is this a regression? Yes it is. gcc 3.3.3 can compile this test ok. Cheers, Simon. -- Simon Burge[EMAIL PROTECTED] NetBSD Support and Service: http://www.wasabisystems.com/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18863
[Bug c++/18793] [4.0 regression] ICE in cp_expr_size
--- Additional Comments From bangerth at dealii dot org 2004-12-07 14:19 --- This is most likely the same as PR 18865. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18793
[Bug tree-optimization/18704] [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2004-12-07 14:35 --- Subject: Re: [4.0 Regression] Inlining limits cause 340% performance regression On 6 Dec 2004, hubicka at ucw dot cz wrote: Looks like I get 4fold speedup on tree profiling with profiling compared to tree profiling on mainline that is equivalent to speedup you are seeing for leafify patch. That sounds pretty prommising (so the new heuristics can get the leafify idea without the hint from user and hitting the code growth problems). Yes, it seems so. Really nice improvement. Though profiling is sloow. I guess you avoid doing any CFG changing transformation for the profiling stage? I.e. not even inline the simplest functions? That would be the reason the Intel compiler is unusable with profiling for me. -fprofile-generate comes with a 50fold increase in runtime! It would be nice to experiment with this a little - in general the heuristics can be viewed as having three players. There are the limits (specified via --param) that it must obey, there is the cost model (estimated growth for inlining into all callees without profiling and the execute_count to estimated growth for inlining to one call with profiling) and the bin packing algorithm optimizing the gains while obeying the limits. With profiling in the cost model is pretty much realistic and it would be nice to figure out how the performance behave when the individual limits are changed and why. If you have some time for experimentation, it would be very usefull. I am trying to do the same with SPEC and GCC but I have dificulty to play with pooma or Gerald's application as I have little understanding what is going there. I will try it myself next but any feedback can be very usefull here. I can produce some numbers for the tramp testcase. My plan is to try undersand the limits first and then try to get the cost model better without profiling as it is bit too clumpsy to do both at once. Do you have some written overview of the cost model? Richard. -- Richard Guenther richard dot guenther at uni-tuebingen dot de WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
[Bug target/18665] [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic
--- Additional Comments From schlie at comcast dot net 2004-12-07 14:36 --- Subject: [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic --- Additional Comment #8 From Eric Botcazou 2004-12-06 18:45 The (useless?) mode promotion from SImode to DImode comes from: http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00625.html The c4X inspired logic seems basically wrong; built-in function type sizes should likely be determined by the mode/size (QI/HI/SI/etc.) specified by the target, not words-per-anything (where 8-bit targets may define a short as being 1 word-wide, and long as 4-words-wide; 64-bit targets may specify a short as being 1/4-words-wide, and long as 1-words-wide). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18665
[Bug tree-optimization/18704] [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From hubicka at ucw dot cz 2004-12-07 14:49 --- Subject: Re: [4.0 Regression] Inlining limits cause 340% performance regression --- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2004-12-07 14:35 --- Subject: Re: [4.0 Regression] Inlining limits cause 340% performance regression On 6 Dec 2004, hubicka at ucw dot cz wrote: Looks like I get 4fold speedup on tree profiling with profiling compared to tree profiling on mainline that is equivalent to speedup you are seeing for leafify patch. That sounds pretty prommising (so the new heuristics can get the leafify idea without the hint from user and hitting the code growth problems). Yes, it seems so. Really nice improvement. Though profiling is sloow. I guess you avoid doing any CFG changing transformation for the profiling stage? I.e. not even inline the simplest functions? I can inline but only after actually instrumenting the functios. That should minimize the costs, but I also noticed that tramp3d is surprisingly a lot slower with profiling. That would be the reason the Intel compiler is unusable with profiling for me. -fprofile-generate comes with a 50fold increase in runtime! -fprofile-generate is actually package of -fprofile-arcs/-fprofile-values + -fprofile-values-transformations It might be interesting to figure out whether -fprofile-arcs itslef brings similar slowdown. Only reason why this can happen I can think of is the fact that after instrumenting we again inline a lot less or we produce too many redundant counter. Perhaps it would make sense to think about inlining functions reducing code size before instrumenting as we would do that anyway, but it will be tricky to get gcov output and -f* flags independence right then. How our profilng performance is compared to ICC? It would be nice to experiment with this a little - in general the heuristics can be viewed as having three players. There are the limits (specified via --param) that it must obey, there is the cost model (estimated growth for inlining into all callees without profiling and the execute_count to estimated growth for inlining to one call with profiling) and the bin packing algorithm optimizing the gains while obeying the limits. With profiling in the cost model is pretty much realistic and it would be nice to figure out how the performance behave when the individual limits are changed and why. If you have some time for experimentation, it would be very usefull. I am trying to do the same with SPEC and GCC but I have dificulty to play with pooma or Gerald's application as I have little understanding what is going there. I will try it myself next but any feedback can be very usefull here. I can produce some numbers for the tramp testcase. Thanks! Note that with changling the flags you should not need to re-profile now so you can save quite a lot of time. My plan is to try undersand the limits first and then try to get the cost model better without profiling as it is bit too clumpsy to do both at once. Do you have some written overview of the cost model? not really, but it is simple for the moment. To estimate size of function I use simple walk of function body cmputing most nodes as 1, division, call and similar badies as 10, NOP and constants as 0. When profiling the priority of inlining edge is number of executions divided by the estimated growth (size of callee minus 10), when not profiling it is the overall growth after inliing to all callees (ie i count number of callees one can inline into and multiply it by size of callee minus 10). You can see the inlining decisions with -fdump-ipa-inline. Honza Richard. -- Richard Guenther richard dot guenther at uni-tuebingen dot de WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
[Bug tree-optimization/18704] [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From hubicka at ucw dot cz 2004-12-07 14:52 --- Subject: Re: [4.0 Regression] Inlining limits cause 340% performance regression --- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2004-12-07 14:35 --- Subject: Re: [4.0 Regression] Inlining limits cause 340% performance regression On 6 Dec 2004, hubicka at ucw dot cz wrote: Looks like I get 4fold speedup on tree profiling with profiling compared to tree profiling on mainline that is equivalent to speedup you are seeing for leafify patch. That sounds pretty prommising (so the new heuristics can get the leafify idea without the hint from user and hitting the code growth problems). Yes, it seems so. Really nice improvement. Though profiling is sloow. I guess you avoid doing any CFG changing transformation for the profiling stage? I.e. not even inline the simplest functions? That would be the reason the Intel compiler is unusable with profiling for me. -fprofile-generate comes with a 50fold increase in runtime! Also it might be possible to change NEXT_PASS (pass_tree_profile); NEXT_PASS (pass_cleanup_cfg); into NEXT_PASS (pass_cleanup_cfg); NEXT_PASS (pass_tree_profile); NEXT_PASS (pass_cleanup_cfg); in tree-optimize.c to get cfg cleaned up. In theory it should not have much of effect since profiling code is already smart enought to not instrument edges that are redundant control flow wise, but perhaps it is not doing it all the time. The cleanup is prevented there to avod problems with inexact coverage info, but it is not unthinkable to extend cfgcleanup to be coverage info safe or execute it when -fprofile-generate is used without -ftext-coverage if it makes any difference. Honza It would be nice to experiment with this a little - in general the heuristics can be viewed as having three players. There are the limits (specified via --param) that it must obey, there is the cost model (estimated growth for inlining into all callees without profiling and the execute_count to estimated growth for inlining to one call with profiling) and the bin packing algorithm optimizing the gains while obeying the limits. With profiling in the cost model is pretty much realistic and it would be nice to figure out how the performance behave when the individual limits are changed and why. If you have some time for experimentation, it would be very usefull. I am trying to do the same with SPEC and GCC but I have dificulty to play with pooma or Gerald's application as I have little understanding what is going there. I will try it myself next but any feedback can be very usefull here. I can produce some numbers for the tramp testcase. My plan is to try undersand the limits first and then try to get the cost model better without profiling as it is bit too clumpsy to do both at once. Do you have some written overview of the cost model? Richard. -- Richard Guenther richard dot guenther at uni-tuebingen dot de WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
[Bug fortran/18870] New: [g77 regression] Equivalencing two common blocks is not caught
$ cat common-2.f program main common /foo/ a common /bar/ b equivalence (a,c) equivalence (b,c) c=3. print *,a print *,b end $ gfortran common-2.f ./a.out 3.00 3.00 $ gfortran -v Reading specs from /home/zfkts/lib/gcc/ia64-unknown-linux-gnu/4.0.0/specs Configured with: ../gcc-4.0-20041205/configure --prefix=/home/zfkts --enable-languages=c,c++,f95 --disable-shared Thread model: posix gcc version 4.0.0 20041205 (experimental) $ g77 common-2.f common-2.f: In program `main': common-2.f:5: equivalence (b,c) ^ Attempt to EQUIVALENCE common areas `foo' and `bar' at (^) -- Summary: [g77 regression] Equivalencing two common blocks is not caught Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18870
[Bug tree-optimization/18704] [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2004-12-07 15:09 ---
Subject: Re: [4.0 Regression] Inlining limits
cause 340% performance regression
On 7 Dec 2004, hubicka at ucw dot cz wrote:
Yes, it seems so. Really nice improvement. Though profiling is
sloow. I guess you avoid doing any CFG changing transformation
for the profiling stage? I.e. not even inline the simplest functions?
I can inline but only after actually instrumenting the functios. That
should minimize the costs, but I also noticed that tramp3d is
surprisingly a lot slower with profiling.
That would be the reason the Intel compiler is unusable with profiling
for me. -fprofile-generate comes with a 50fold increase in runtime!
-fprofile-generate is actually package of
-fprofile-arcs/-fprofile-values + -fprofile-values-transformations
It might be interesting to figure out whether -fprofile-arcs itslef
brings similar slowdown. Only reason why this can happen I can think of
is the fact that after instrumenting we again inline a lot less or we
produce too many redundant counter. Perhaps it would make sense to
think about inlining functions reducing code size before instrumenting
as we would do that anyway, but it will be tricky to get gcov output and
-f* flags independence right then.
Hm. There are a lot of counters - maybe it is possible to merge
the counters themselves? The resulting asm of tramp3d-v3 consists
of 30% addl/adcl lines for adding the profiling counts - where
the total number of lines is just wc -l of a -S -fverbose-asm compilation.
That's very much a lot. And additions are in cache unfriedly sequence,
too - dunno which optimization pass could improve this though. Consider
static inline void foo() {}
void bar() { foo(); }
which for -O2 -fprofile-generate produces
bar:
addl$1, .LPBX1
pushl %ebp
movl%esp, %ebp
adcl$0, .LPBX1+4
addl$1, .LPBX1+16
popl%ebp
adcl$0, .LPBX1+20
addl$1, .LPBX1+8
adcl$0, .LPBX1+12
ret
that should be
bar:
addl$1, .LPBX1
pushl %ebp
movl%esp, %ebp
adcl$0, .LPBX1+4
addl$1, .LPBX1+8
adcl$0, .LPBX1+12
addl$1, .LPBX1+16
adcl$0, .LPBX1+20
ret
And of course all the three counters could be merged. But that
would need a changed gcov file format somehow representing a
callgraph with merged edges.
The intel compiler is so much worse here because all the
counter adding is done thread-safe in a library (i.e. they
have an extra call for every edge and do not do any inlining).
How our profilng performance is compared to ICC?
ICC is a lot worse. ICC with -prof_gen causes a 1 fold slowdown
(if the current snapshot of icc doesn't segfault compiling the tramp3d
testcase) - ICC is completely unusable for me. So - GCC is great!
It would be nice to experiment with this a little - in general the
heuristics can be viewed as having three players. There are the limits
(specified via --param) that it must obey, there is the cost model
(estimated growth for inlining into all callees without profiling and
the execute_count to estimated growth for inlining to one call with
profiling) and the bin packing algorithm optimizing the gains while
obeying the limits.
With profiling in the cost model is pretty much realistic and it would
be nice to figure out how the performance behave when the individual
limits are changed and why. If you have some time for experimentation,
it would be very usefull. I am trying to do the same with SPEC and GCC
but I have dificulty to play with pooma or Gerald's application as I
have little understanding what is going there. I will try it myself
next but any feedback can be very usefull here.
I can produce some numbers for the tramp testcase.
Thanks! Note that with changling the flags you should not need to
re-profile now so you can save quite a lot of time.
Ah, thats indeed nice.
Richard.
--
Richard Guenther richard dot guenther at uni-tuebingen dot de
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
[Bug target/18864] ICE: insn does not satisfy its constraints
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 15:11 --- *** This bug has been marked as a duplicate of 18641 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18864
[Bug middle-end/18641] [4.0 Regression] Another ICE caused by reload of a psuedo reg into f0 for a DImode expr
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 15:11 --- *** Bug 18864 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||aj at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18641
[Bug c++/18865] [4.0 Regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:86
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 15:13 --- This is a dup of bug 18793, just reduced differently. *** This bug has been marked as a duplicate of 18793 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18865
[Bug c++/18793] [4.0 regression] ICE in cp_expr_size
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 15:13 --- *** Bug 18865 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||aj at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18793
[Bug middle-end/18785] [4.0 Regression] isdigit builtin function fails with EBCDIC character sets
--- Additional Comments From darcypj at us dot ibm dot com 2004-12-07 15:21 --- Wow - curiously, I don't have a problem with it, but that is because when I added the -fexec-charset option, I no longer got the branch to puts(). Examples follow: === If I compile with the following options, I see the puts: -c print.c -fverbose-asm -Wa,-aldhs=print.lst -gdwarf-2 4:print.c printf(Hello world\n); 47.loc 1 4 0 48 001c C020 larl%r2,.LC0#, 48 49 0022 C0E5 brasl %r14,puts #, 49 === And with these options (just the -fexec-charset addded) I see a call to printf(). -c print.c -fverbose-asm -Wa,-aldhs=print.lst -gdwarf-2 -fexec-charset=IBM1047 4:print.c printf(Hello world\n); 47.loc 1 4 0 48 001c C020 larl%r2,.LC0#, 48 49 0022 C0E5 brasl %r14,printf #, 49 Note, I get this warning either way since I am not including any headers, in order to try and force the builtin printf().. print.c: In function 'main': print.c:4: warning: incompatible implicit declaration of built-in function 'printf' So it appears to me that the compiler builtin knows not to activate when the -fexec-charset is invoked? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18785
[Bug target/18863] [4.0 Regression] ICE in find_reloads
-- What|Removed |Added Known to work||3.3.3 Summary|ICE in find_reloads |[4.0 Regression] ICE in ||find_reloads Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18863
[Bug ada/18871] New: Should use -Wextra instead of -W during ada bootstrap
While compiling the ada part of itself, gcc seems to use the option -W, which is deprecated in favour of -Wextra: ../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg s-tasini.adb -o s-tasini.o -- Summary: Should use -Wextra instead of -W during ada bootstrap Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schnetter at aei dot mpg dot de CC: gcc-bugs 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=18871
[Bug tree-optimization/18704] [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2004-12-07 15:35 ---
Subject: Re: [4.0 Regression] Inlining limits
cause 340% performance regression
On Tue, 7 Dec 2004, Richard Guenther wrote:
static inline void foo() {}
void bar() { foo(); }
which for -O2 -fprofile-generate produces
bar:
addl$1, .LPBX1
pushl %ebp
movl%esp, %ebp
adcl$0, .LPBX1+4
addl$1, .LPBX1+16
popl%ebp
adcl$0, .LPBX1+20
addl$1, .LPBX1+8
adcl$0, .LPBX1+12
ret
Mainline manages to produce
bar:
addl$1, .LPBX1
pushl %ebp
movl%esp, %ebp
adcl$0, .LPBX1+4
popl%ebp
ret
but that's RTL instrumentation?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
[Bug fortran/18872] New: [g77 regression] Equivalencing two common blocks is not caught
$ cat common-2.f program main common /foo/ a common /bar/ b equivalence (a,c) equivalence (b,c) c=3. print *,a print *,b end $ gfortran common-2.f ./a.out 3.00 3.00 $ gfortran -v Reading specs from /home/zfkts/lib/gcc/ia64-unknown-linux-gnu/4.0.0/specs Configured with: ../gcc-4.0-20041205/configure --prefix=/home/zfkts --enable-languages=c,c++,f95 --disable-shared Thread model: posix gcc version 4.0.0 20041205 (experimental) $ g77 common-2.f common-2.f: In program `main': common-2.f:5: equivalence (b,c) ^ Attempt to EQUIVALENCE common areas `foo' and `bar' at (^) -- Summary: [g77 regression] Equivalencing two common blocks is not caught Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18872
Re: complex numbers
Hello However I think if flag_complex_divide_method = 1 fix the problem it would be a good idea to set it by default. ... but notice that this issue is tricky: there are computational issues (we are adding at least a branch for each division) and correctness issues (what about C99?) As I see it the naive formula needs 6 multipications, 2 divisions and 3 additions/subtractions and the improved formua needs 1 comparision, 3 multipactions, 3 divisions and 3 additions/subtractions This look like a good deal. However for floting point computations I prevere good results over fast results. What do you meen with correctness issues? Andreas Klein
[Bug c++/18873] New: Segfault in layout_class_type - splay_tree_delete
struct D { D(); };
struct E : D { E(); };
struct C { E e[4000]; };
struct A
{
A () {}
struct C m[128];
};
struct B : public A
{
B () {}
};
with any -Ox and with any of -m{32,64} segfaults with the default stack rlimit
(10MB) in GCC 3.4.3, HEAD and 3.2.3 as well.
empty_base_offsets has hundreds thousands of nodes in layout_class_type
and splay_tree_delete_helper uses recursion, so in this particular case the
recursion is hundred thousands frames deep. Each recursive call occupies
32 bytes on the stack (and x86_64 in this regard is certainly not host with
biggest frame size), so already 30 recursive calls almost reach the 10MB
limit.
Now, I don't know if it is a bug that for this simple struct it needs 50
splay tree nodes and whether splay tree is the best data structure for this
usage
(haven't looked much what exactly it is using it for) but if that is ok, then
splay-tree.c should be optimized.
Certainly splay_tree_delete can be done without any recursion.
--
Summary: Segfault in layout_class_type - splay_tree_delete
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18873
[Bug fortran/18869] multiple common blocks in a single line rejected
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-07 15:45 --- I'll have a look. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18869
[Bug other/18871] Should use -Wextra instead of -W during bootstrap
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 15:45 --- The warnings options come from the top level makefile so this is generic makefile bug it is hard to fix as you will need to check for support before using it. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|ada |other Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-07 15:45:39 date|| Summary|Should use -Wextra instead |Should use -Wextra instead |of -W during ada bootstrap |of -W during bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18871
Re: complex numbers
Andreas Klein wrote: ... but notice that this issue is tricky: there are computational issues (we are adding at least a branch for each division) and correctness issues (what about C99?) As I see it the naive formula needs 6 multipications, 2 divisions and 3 additions/subtractions and the improved formua needs 1 comparision, 3 multipactions, 3 divisions and 3 additions/subtractions This look like a good deal. However for floting point computations I prevere good results over fast results. Thanks for the summary: I just sent a message to the gcc list, let's see what comes out... Maybe you may want to reply something there. What do you meen with correctness issues? Have a look to the implementation: it looks like that even if we switch to the better algorithm, still we don't get fully right C99. Of course this last point must be better investigate (I'm not a floating point expert) but I expect someone replying: let's implement C99 division right instead. Paolo.
[Bug c++/18873] Segfault in layout_class_type - splay_tree_delete
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 15:47 --- *** This bug has been marked as a duplicate of 18462 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18873
[Bug c++/18462] [3.4/4.0 Regression] Segfault on declaration of large array member
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 15:47 --- *** Bug 18873 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18462
[Bug c++/18793] [4.0 regression] ICE in cp_expr_size
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-07 15:49 --- Mark, the regression appeared with your patch for PR 15172: http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg2.html The example still compiles fine on the 3.4 branch although you applied the patch there, too. Could you please have a look? -- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org, reichelt at gcc dot gnu ||dot org Keywords||monitored http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18793
[Bug c++/18462] [3.4/4.0 Regression] Segfault on declaration of large array member
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 15:49 --- Note there is a patch to fix splay_tree_delete in PR 18602. -- What|Removed |Added BugsThisDependsOn||18602 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18462
[Bug fortran/18872] [g77 regression] Equivalencing two common blocks is not caught
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 15:51 --- *** This bug has been marked as a duplicate of 18870 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18872
[Bug fortran/18870] [g77 regression] Equivalencing two common blocks is not caught
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 15:51 --- *** Bug 18872 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18870
[Bug c/18602] segfault on a huge switch statement.
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-07 15:52 --- DJ, are you going to push your new splay_tree_delete_helper? If it works, this fixes a regression wrt. earlier GCCs... -- What|Removed |Added CC||dj at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18602
Re: complex numbers
Andreas Klein [EMAIL PROTECTED] writes: | On Mon, 6 Dec 2004, Gabriel Dos Reis wrote: | | | As a matter of fact, the implementation of complex is criticized, | once in a while, because it does NOT use the grammar school rule you | present above. However, for float, double, long double it specializes | to __complex__ T which is what the compiler uses to implement complex | numbers in C99 and Fortran. So, the problem is a compiler problem not | libstdc++ problem. | | I have testet my program with a 2.95 and several 3.x versionsions of gcc. | The lastet version I have is 3.3.3. | All versions gave the same result. Yup. It is inside the compiler | What was the critice you mentioned above? I can not imagine a sitation in | which I would need the naive implementation. Oh, I got repeated complaints from users that the correct method of computation was slow -- look at the bugzilla archive. I believe there might alos be discussions on GCC main mailing list. The grammar school algorithms is needed for the primary template because it is the one that gets instantiated, for say, complexint. Notice that such datatypes are required by LIA-3 (in the last phase of development). We don't have overload on concepts so, for the moment that is what is used for anything other thand float, double, and long double. | But I think it can not be | good that if I get different result for complex and real arithmetic. If | the number are the same real numbers. | | | Did you look at the actual implementation? | | | As you mentinon it if have missed the specilization at the end of | std_complex.h. Sorry. I still think that we should have and other | implementation for complexfloating_point, but I cannot change the code | of __complex__ T in the complier. I don't think we need another implementation of complexfloating_point. What we need is to improve the compiler. Convince people that we have correctness, then speed. -- Gaby
Re: complex numbers
Andreas Klein [EMAIL PROTECTED] writes: | This look like a good deal. However for floting point computations I | prevere good results over fast results. You're in the minority (including me :-)). -- Gaby
mips-tfile fails throwing String too big error.
I this issue has been raised by two people earlier, but there has been no response on their threads - http://gcc.gnu.org/ml/gcc-bugs/1997-12/msg00185.html http://gcc.gnu.org/ml/gcc-bugs/1998-08/msg00032.html And I am facing the same problem... I am running following version /configuration of gcc on alphaev56-dec-osf5.1 box - Reading specs from /usr/local/gcc-3.2.1-eth/lib/gcc-lib/alphaev56-dec-osf5.1/3.2.1/specs Configured with: ./configure --prefix=/usr/local/gcc-3.2.1-eth --enable-languages=c,c++ --disable-nls --enable-threads Thread model: single gcc version 3.2.1 when I compile code with a -g flag, mips-tfile fails throwing String too big error. Do we have a resolution / workaround for this problem ? Or is it that I am going wrong some where ?? Thanks -AJ = Regards, Aniruddha. Phone [Daytime]: (+91) 20 401 4488 PS:: I dont use the cell Phone anymore ! __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250
[Bug c/16351] NULL dereference warnings
--- Additional Comments From phython at gcc dot gnu dot org 2004-12-07 16:08 --- I'd probably leave them as the same bug for now. Neither are being fixed for 4.0 so I don't think it's a problem having one bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
[Bug c++/18073] [4.0 regression] mmintrin.h rejected by C++ frontend
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-07 16:11 --- not fixed. still rejecting ./include/mmintrin.h: In function 'int _mm_cvtsi64_si32(int __vector__)': ./include/mmintrin.h:91: error: invalid cast from type 'int __vector__' to type 'long long int' -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18073
[Bug c++/18462] [3.4/4.0 Regression] Segfault on declaration of large array member
--- Additional Comments From jakub at gcc dot gnu dot org 2004-12-07 16:17 --- Any reason why that patch hasn't been applied? Just verified it works and on the testcase in PR 18873 it is even tiny bit faster than the recursive variant. Though splay_tree_splay_helper is recursive too, so it is only partial solution. -- What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18462
[Bug libf2c/18874] New: ? in namelist read leads to I/O recursion
Typing ? for a namelist input is supposed to yield a description of the input variables on standard output. This doesn't work with g77: $ g77 -v Reading specs from /usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=ia64-redhat-linux Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42) $ ./a.out $ cat nl.f program main namelist /nl/ a read (*,nl) print *,a end $ g77 nl.f a.out ? I/O recursion: I/O started while already doing I/O apparent state: unit 5 (unnamed) last format: list io lately reading direct formatted external IO Aborted -- Summary: ? in namelist read leads to I/O recursion Product: gcc Version: 3.2.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libf2c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18874
[Bug java/14853] [3.3/3.4 Regression] Assignment to final field permitted when compiling to native
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-07 17:07 --- I'm building this for 3.4 right now. If it works ok I will submit it. I don't plan to try it for 3.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14853
[Bug bootstrap/18875] New: Cannot build libcpp due to -Wno-long-long flag
When using a version of GCC that does not support -Wno-long-long as the bootstrap compiler (such as GCC 2.8.1), it is not possible to build GCC 4.0: gcc -I../../gcc-head/libcpp -I. -I../../gcc-head/libcpp/../include -I../../gcc-head/libcpp/include -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -I../../gcc-head/libcpp -I. -I../../gcc-head/libcpp/../include -I../../gcc-head/libcpp/include -c ../../gcc-head/libcpp/charset.c cc1: Invalid option `-Wno-long-long' make[1]: *** [charset.o] Error 1 make[1]: Leaving directory `/home/charlet/cvs/gcc-obj/libcpp' make: *** [all-libcpp] Error 2 -- Summary: Cannot build libcpp due to -Wno-long-long flag Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: charlet at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18875
[Bug preprocessor/18875] [4.0 Regression] Cannot build libcpp due to -Wno-long-long flag
-- What|Removed |Added CC||zack at gcc dot gnu dot org Component|bootstrap |preprocessor Keywords||build Summary|Cannot build libcpp due to -|[4.0 Regression] Cannot |Wno-long-long flag |build libcpp due to -Wno- ||long-long flag Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18875
[Bug c++/18073] [4.0 regression] mmintrin.h rejected by C++ frontend
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-07
17:29 ---
Mark, it looks like your patch only fixed conversion from integer to
vector but not the other way round. The following patch fixes the problem
for me. Does this look right?
Index: typeck.c
===
RCS file: /home/reichelt/GCC/CVS/gcc-cvs/gcc/gcc/cp/typeck.c,v
retrieving revision 1.600
diff -u -p -r1.600 typeck.c
--- typeck.c26 Nov 2004 15:45:47 - 1.600
+++ typeck.c7 Dec 2004 17:24:27 -
@@ -4970,7 +4970,8 @@ build_reinterpret_cast_1 (tree type, tre
expr = decl_constant_value (expr);
return fold_if_not_in_template (build_nop (type, expr));
}
- else if (TREE_CODE (type) == VECTOR_TYPE)
+ else if (TREE_CODE (type) == VECTOR_TYPE
+ || TREE_CODE (intype) == VECTOR_TYPE)
return fold_if_not_in_template (convert_to_vector (type, expr));
else
{
===
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18073
[Bug tree-optimization/18704] [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From hubicka at ucw dot cz 2004-12-07 17:50 ---
Subject: Re: [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2004-12-07 15:35 ---
Subject: Re: [4.0 Regression] Inlining limits
cause 340% performance regression
On Tue, 7 Dec 2004, Richard Guenther wrote:
static inline void foo() {}
void bar() { foo(); }
which for -O2 -fprofile-generate produces
bar:
addl$1, .LPBX1
pushl %ebp
movl%esp, %ebp
adcl$0, .LPBX1+4
addl$1, .LPBX1+16
popl%ebp
adcl$0, .LPBX1+20
addl$1, .LPBX1+8
adcl$0, .LPBX1+12
ret
Mainline manages to produce
bar:
addl$1, .LPBX1
pushl %ebp
movl%esp, %ebp
adcl$0, .LPBX1+4
popl%ebp
ret
but that's RTL instrumentation?
It is instrumentation after inlining. Before inlining you have two
functions so you get two entry points.
Doing little inlinng before profiling would do the trick here, but it
needs some restructuring first.
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
[Bug preprocessor/18875] [4.0 Regression] Cannot build libcpp due to -Wno-long-long flag
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 18:19 --- Can you attach the config.log for libcpp? Because we do check for -Wno-long-long in configure: ACX_PROG_CC_WARNING_ALMOST_PEDANTIC([-Wno-long-long]) Did you change CC after configuring? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18875
[Bug target/18566] Can vary constants (undefined fortran)
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-07 18:48:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18566
[Bug tree-optimization/18268] missed SRA of a block copy
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 18:51 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-07 18:51:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18268
[Bug middle-end/18259] -fdump-tree-original omits real constant values
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 18:52 --- Patches should be submitted to [EMAIL PROTECTED] Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|debug |middle-end Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-07 18:52:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18259
[Bug java/18811] [4.0 Regression] rhug build problem, regression?
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-07 18:53:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18811
[Bug ada/18818] ACATS cd10002 fails at runtime
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 18:54 --- Does this happen at -O0 and -O2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18818
[Bug ada/18819] ACATS cdd2a02 fails at runtime
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 18:54 --- Does this happen at -O0 and -O2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug c++/18386] ICE in __static_initialization_and_destruction_0
-- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18386
[Bug ada/18876] New: Bug box, Assert_Failure at namet.adb:630, on legal program
(Debian bug #284651) with ada.finalization; package Test_137 is type T1 is new ada.finalization.controlled with null record; procedure p(x: access T1); end Test_137; package body Test_137 is procedure p(x: access T1) is begin null; end p; y: T1; begin p(new T1'(y)); end Test_137; With gnat 3.15p-12: +===GNAT BUG DETECTED==+ | 3.15p (20020523) (i486-pc-linux-gnu) Assert_Failure namet.adb:581 | | No source file position information available| With gcc-3.4 3.4.2-2: +===GNAT BUG DETECTED==+ | 3.4.2 (Debian 3.4.2-2) (i486-pc-linux-gnu) Assert_Failure namet.adb:630 | | Error detected at test_137.adb:9:6 | -- Summary: Bug box, Assert_Failure at namet.adb:630, on legal program Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic dot brenta at insalien dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18876
[Bug ada/18858] ACATS ICE ce2109b ce2404b ce2410b at -O0: in expand_assignment, at expr.c:3756
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 18:57 --- Can you attach the .t14.oplower dump which you can get via -fdump-tree-oplower? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18858
[Bug ada/18876] Bug box, Assert_Failure at namet.adb:630, on legal program
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 18:59 --- Confirmed on the mainline: +===GNAT BUG DETECTED==+ | 4.0.0 20041204 (experimental) (powerpc-apple-darwin7.6.0) GCC error: | | in gnat_to_gnu_entity, at ada/decl.c:267 | | Error detected at test_137.adb:9:6 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +== + -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Known to fail||4.0.0 Last reconfirmed|-00-00 00:00:00 |2004-12-07 18:59:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18876
[Bug debug/18856] [3.3 regression] Missing .loc information after prologue
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-07 19:00:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18856
[Bug libf2c/18874] ? in namelist read leads to I/O recursion
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 19:01 --- I don't know if any libf2c bugs are going to be fixed any more since 4.0.0 uses a different library for fortran library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18874
[Bug preprocessor/18875] [4.0 Regression] Cannot build libcpp due to -Wno-long-long flag
-- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18875
[Bug c++/18073] [4.0 regression] mmintrin.h rejected by C++ frontend
-- What|Removed |Added Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18073
[Bug java/18811] [4.0 Regression] rhug build problem, regression?
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-07 19:07 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00461.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18811
[Bug other/18877] New: decompose (reload.c) can be forced to access hard_regno_nregs over its array bounds
true_regnum(x) returns only positive numbers for a pseudo register, if REG_P(x)
is true.
reload.c, function decompose, line 2363 (CVS HEAD version):
case REG:
val.reg_flag = 1;
val.start = true_regnum (x);
if (val.start 0)
{
/* A pseudo with no hard reg. */
val.start = REGNO (x);
val.end = val.start + 1;
}
else
/* A hard reg. */
val.end = val.start + hard_regno_nregs[val.start][GET_MODE (x)];
So if decompose is called with an pseudo register, which is not renumbered,
val.end = val.start + hard_regno_nregs[val.start][GET_MODE (x)];
is executed. val.start contains in that case a number = FIRST_PSEUDO_REGISTER,
which is so an access over the array-bounds of hard_regno_nregs.
I suggest to put a
gcc_assert (val.start FIRST_PSEUDO_REGISTER);
before the instruction, so that such an error will be found.
GCC calls decompose with a not renumbered register, if the following conditions
are fullfiled:
*All for allocation available registeres are in use
*An operation has for an operand an constraint like =rm and the value is an
pseudo register.
For i686 and gcc version 4.0.0 20041207 (experimental), such an assert fails
for the following example (compiled with -O1,-O2,-O3 or -Os):
long a,b,c,d,e,f,g,h,i;
int test()
{
long x1,x2,x3,l,l1,l2;
t1(x1,x2,x3);
x1+=2;
l=c+2;
l1=d+2;
l2=e+2;
asm(nop # %0 %1 %2 %3 %4 %5 %6 %7 %8 %9: =a(a), =b(b), =c(c),
=d(d), =mr(e), =mr(f),=rm(x2),=rm(l2): 2(x1),0(x2),
1(e),3(f),rm(l),rm(l1),rm(l2),m(x3),g(x2));
t1(x1,x2,x3+l2);
}
In that case, hard_regno_nregs[58][SImode] will be accessed. If some code is
inserted before the assignement of l2, l2 will get an higher number, which will
cause an segmentation fault.
As an fix, maybe changing the if-statement to
if (val.start 0||val.start=FIRST_PSEUDO_REGISTER)
can help, as the comment says, that the then-part of the if statement should be
used for pseudo registers. If that is correct, I can't tell.
For the SUBREG-case in decompose, there is a similar issue.
mfg Martin Kögler
[EMAIL PROTECTED]
--
Summary: decompose (reload.c) can be forced to access
hard_regno_nregs over its array bounds
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: e9925248 at stud4 dot tuwien dot ac dot at
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu (not i686 spezific)
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18877
[Bug middle-end/18877] decompose (reload.c) can be forced to access hard_regno_nregs over its array bounds
-- What|Removed |Added Component|other |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18877
