[Bug tree-optimization/30564] [4.3 Regression] ice for legal code with -O3
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-01-28 07:58 --- > The problem is we are calling fold_marked_statements after renumbering the > basic blocks and such which causes us to get the wrong starting point. We have to call verify_cgraph before calling fold_marked_statements, otherwise we get an ICE about an function (a builtin) which we no longer call. This shows up in the Ada front-end in C code in which we call strlen in the function which gets inlined with a constant string. The patch is able to pass bootstrap but I still have another regression I need to look into, dealing with an inline-asm and the testcase is x86 specific one at that. (it does #ifdef __i386__). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
[Bug c++/14875] When using 'or' keyword, the error message speaks of a '||' token
--- Comment #9 from gdr at cs dot tamu dot edu 2007-01-28 04:11 --- Subject: Re: When using 'or' keyword, the error message speaks of a '||' token "manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Unless someone decides to fix the whole C++ parser error handling, | this and PR 28152 won't be fixed. I would refrain from sweeping generalization like the above. Diagnostics with carret do not necessary require "fixing" the parser; and, yet they can be implemented in a way that resolves this issue. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14875
[Bug other/20955] Top-level gcc configure/makefile does not handle --with-sysroot
--- Comment #16 from drow at gcc dot gnu dot org 2007-01-28 03:48 --- Actually, I was wrong - we shouldn't try to make this case work. If you use $prefix/$target_alias as a sysroot, then /bin/as in your sysroot needs to be a host-x-target assembler! Closing instead. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20955
[Bug c++/14875] When using 'or' keyword, the error message speaks of a '||' token
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-28 02:41 --- (In reply to comment #7) > I seem to recall that when Giovanni worked on these digraph thingies, > it was pointed out that our CPP is able to mark a pp-token whether it > is a digraph or not. > Actually, it is marked as token->flags & NAMED_OP. This can be easily tested. However, the way the C++ front-end handles parser errors makes that totally useless. Once we reach c-common.c (c_parse_error), the actual cp_token is lost and we only keep the type. Also, it seems that it should be using cpp_token_as_text rather than cpp_type2name. However, the change does not seem trivial at all. Unless someone decides to fix the whole C++ parser error handling, this and PR 28152 won't be fixed. Any brave volunteer? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14875
[Bug web/30584] bugzilla: cannot add comments
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-28 03:00 --- (In reply to comment #3) > Clearing browser cache helped. Maybe bugzilla did not mark a page as changed > that had in fact changed for some reason. I'm ready to provide additional > information if I can. Just ask. Unfortunately it is too late to record the > network traffic. > This is known bug in all bugzillas. It happened to me very often in Mandriva's. Perhaps it has been fixed in a recent version. If you are interested in seeing it fixed, please report it to http://www.bugzilla.org/. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30584
[Bug middle-end/22370] Vec lower produces mis-match types
--- Comment #2 from roger at eyesopen dot com 2007-01-28 02:58 --- Hi Andrew, could you recheck whether you can reproduce this problem on mainline? Updating the MODIFY_EXPR patch in PR 22368 to check GIMPLE_MODIFY_STMT, I'm unable to reproduce this failure on x86_64-unknown-linux-gnu, even with -m32. There has been at least one type clean-up patch to veclower, so I suspect this issue may have been resolved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22370
[Bug c++/30619] G++ OpenMP uses TREE_COMPLEXITY
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-28 00:49 --- I have a fix for the line number issue I found after creating the above patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30619
[Bug c++/30619] G++ OpenMP uses TREE_COMPLEXITY
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-28 00:38 ---
Created an attachment (id=12973)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12973&action=view)
patch which needs testing and a little cleanup including documentation/comment
fixes
I quickly tested this on:
template
int Birkhoff_with_Vol_para(int n)
{
t I;
#pragma omp atomic
I++;
}
int f(int a)
{
return Birkhoff_with_Vol_para(a);
}
And I got the correct result, there still needs some cleanup of the patch, the
OMP_ATOMIC_TP_* macros need their comments fixed as I just copied from
STATIC_ASSERT_*. I need to check on line numbering issues but other than those
two, it should work.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30619
[Bug rtl-optimization/30121] ICE on frtl-abstract-sequences and mthumb.
--- Comment #3 from aldot at gcc dot gnu dot org 2007-01-28 00:28 ---
on i686, cross compiling for i586, i see:
/bin/sh ../libtool --mode=compile
/home/cow/src/buildroot.mine/build_i586/staging_dir/bin/i586-linux-uclibc-gcc
-DHAVE_CONFIG_H -I.
-I/home/cow/src/buildroot.mine/toolchain_build_i586/gmp-4.2.1/mpn -I..
-D__GMP_WITHIN_GMP
-I/home/cow/src/buildroot.mine/toolchain_build_i586/gmp-4.2.1 -DOPERATION_`echo
add | sed 's/_$//'`-fno-tree-loop-optimize -Os -fno-tree-dominator-opts
-fno-strength-reduce -fno-branch-count-reg -falign-functions=1 -falign-jumps=1
-falign-loops=1 -mpreferred-stack-boundary=2 -g -pipe -frtl-abstract-sequences
-c -o add.lo add.c
/home/cow/src/buildroot.mine/build_i586/staging_dir/bin/i586-linux-uclibc-gcc
-DHAVE_CONFIG_H -I.
-I/home/cow/src/buildroot.mine/toolchain_build_i586/gmp-4.2.1/mpn -I..
-D__GMP_WITHIN_GMP
-I/home/cow/src/buildroot.mine/toolchain_build_i586/gmp-4.2.1 -DOPERATION_add
-fno-tree-loop-optimize -Os -fno-tree-dominator-opts -fno-strength-reduce
-fno-branch-count-reg -falign-functions=1 -falign-jumps=1 -falign-loops=1
-mpreferred-stack-boundary=2 -g -pipe -frtl-abstract-sequences -c add.c -fPIC
-DPIC -o .libs/add.o
../gmp.h: In function '__gmpn_add':
../gmp.h:2028: error: unrecognizable insn:
(insn 130 0 0 (set (reg:SI 0 ax)
(symbol_ref:SI ("*.L16") [flags 0x2])) -1 (nil)
(nil))
../gmp.h:2028: internal compiler error: in insn_default_length, at
insn-attrtab.c:1083
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [add.lo] Error 1
make[3]: Leaving directory
`/home/cow/src/buildroot.mine/build_i586/gmp-4.2.1/mpn'
This is pristine gcc-4_2-branch,
$ /home/cow/src/buildroot.mine/build_i586/staging_dir/bin/i586-linux-uclibc-gcc
-v
Using built-in specs.
Target: i586-linux-uclibc
Configured with:
/home/cow/src/buildroot.mine/toolchain_build_i586/gcc-4.2/configure
--prefix=/home/cow/src/buildroot.mine/build_i586/staging_dir
--build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=i586-linux-uclibc
--enable-languages=c,c++,fortran --disable-__cxa_atexit
--enable-target-optspace --with-gnu-ld
--with-gmp=/home/cow/src/buildroot.mine/toolchain_build_i586/gmp
--with-mpfr=/home/cow/src/buildroot.mine/toolchain_build_i586/mpfr
--enable-shared --disable-nls --enable-threads --disable-multilib
--disable-largefile
Thread model: posix
gcc version 4.2.0 20070127 (prerelease)
Please let me know if additional information is required.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
CC||aldot at gcc dot gnu dot org
GCC target triplet|arm-none-eabi |arm-none-eabi, i586-linux-
||uclibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30121
[Bug c++/30619] New: G++ OpenMP uses TREE_COMPLEXITY
from cp/cp-tree.h: /* Used to store the operation code when in a template context. */ #define OMP_ATOMIC_CODE(NODE) \ (OMP_ATOMIC_CHECK (NODE)->exp.complexity) This is blocking the removal of TREE_COMPLEXITY, which is a significant source of waste of memory in gcc. -- Summary: G++ OpenMP uses TREE_COMPLEXITY Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: memory-hog Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: steven at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30619
[Bug middle-end/30421] incorrect warning when using firstprivate and lastprivate clauses
--- Comment #8 from kuba at et dot pl 2007-01-28 00:02 --- Subject: Re: incorrect warning when using firstprivate and lastprivate clauses I realised that maybe is just better to set TREE_NO_WARNING (fd->v) = 1; instead of set it (fd->v) to 0. We are sure that fd->v won't be read before is set, so there is no need to add one more instruction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30421
[Bug ada/30618] Infinite loop in sem_ch8.end_use_clauses
--- Comment #1 from ludovic at ludovic-brenta dot org 2007-01-27 23:54 --- Created an attachment (id=12972) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12972&action=view) Source files to reproduce the problem In order to reproduce the bug, extract the sources in it and say: gnatmake integer_indexed_io-debug.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30618
[Bug ada/30618] New: Infinite loop in sem_ch8.end_use_clauses
This is Debian bug #408703; see the attached files that reproduce the problem. The command line is gnatmake integer_indexed_io-debug.ads After successfully compiling a couple of files, gnat1 then goes into an infinite loop while parsing integer_indexed_io-debug.ads. The backtrace I got when running "gnat1 integer_indexed_io-debug.ads" under gdb and hitting Ctrl+C says: #1 0x005b0cc0 in sem_ch8.end_use_clauses () #2 0x005b0e4d in sem_ch8.pop_scope () #3 0x00560b4a in sem_ch10.remove_parents () #4 0x00560c19 in sem_ch10.remove_context () #5 0x005664f2 in sem_ch10.analyze_compilation_unit () #6 0x0054b4ac in sem.analyze () #7 0x0054b829 in sem.semantics.do_analyze () #8 0x0054ba66 in sem.semantics () #9 0x004f1a30 in frontend () #10 0x0062bac6 in gnat1drv () #11 0x00412dad in gnat_parse_file () #12 0x00870138 in toplev_main () #13 0x2ade5132c4ca in __libc_start_main () from /lib/libc.so.6 #14 0x00402f0a in _start () at ../sysdeps/x86_64/elf/start.S:113 If you stop gnat1 at various times, the topmost frame (#0) varies, but after executing the statements until you return to sem_ch8.end_use_clauses and type n, the infinite loop resumes. Memory usage remains constant in the infinite loop. -- Ludovic Brenta. -- Summary: Infinite loop in sem_ch8.end_use_clauses Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30618
[Bug libfortran/30617] recursive I/O hangs under OSX 10.3
--- Comment #7 from kargl at gcc dot gnu dot org 2007-01-27 23:34 --- (In reply to comment #3) > > I believe recursive IO is undefined > > Probably, but the same code works with > > Target: x86_64-unknown-linux-gnu > gcc version 4.3.0 20061231 (experimental) > Undefined means undefined. It might do what you want on one platform and something entirely different on another. If I read the F2003 standrad correctly, then your program conforms to F2003. You may want to change this to an enhancement request. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug tree-optimization/30564] [4.3 Regression] ice for legal code with -O3
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-01-27 23:31 --- The problem is we are calling fold_marked_statements after renumbering the basic blocks and such which causes us to get the wrong starting point. patch which I am tesing: Index: ../../gcc/tree-inline.c === --- ../../gcc/tree-inline.c (revision 121236) +++ ../../gcc/tree-inline.c (working copy) @@ -2658,6 +2658,10 @@ gimple_expand_calls_inline (bb, &id); pop_gimplify_context (NULL); + + fold_marked_statements (last, id.statements_to_fold); + pointer_set_destroy (id.statements_to_fold); + /* Renumber the (code) basic_blocks consecutively. */ compact_blocks (); /* Renumber the lexical scoping (non-code) blocks consecutively. */ @@ -2683,8 +2687,6 @@ Kill it so it won't confuse us. */ cgraph_node_remove_callees (id.dst_node); - fold_marked_statements (last, id.statements_to_fold); - pointer_set_destroy (id.statements_to_fold); fold_cond_expr_cond (); /* We make no attempts to keep dominance info up-to-date. */ free_dominance_info (CDI_DOMINATORS); -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
[Bug libgcj/30600] gnu.gcj.convert.BytesToCharsetAdaptor calculates bad argument for java.nio.Buffer.limit(int)
--- Comment #3 from kaloian at doganov dot org 2007-01-27 23:14 --- Created an attachment (id=12971) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12971&action=view) Trivial fix -- `inlenght' is the last valid index of the buffer, so it should be used directly, without adding it to `inpos'. It is stated in BytesToUnicode.read(char[],int,int) java docs: "Note the asymmetry in that the input upper bound is inbuffer[inlength-1], while the output upper bound is outbuffer[outpos+count-1]. The justification is that inlength is like the count field of a BufferedInputStream, while the count parameter is like the length parameter of a read request." But obviously, in BytesToCharsetAdaptor's code `inlength' is not used according to the note above. Instead, it is expected `inlength' to contain a count, which , when added to the value of `inpos', leads to the calculation of a buffer limit greater than buffer's capacity (if `inpos' turns out to be greater than zero). This can be easily avoided by simply using `inlenght' in the way it is expected to be used -- as an absolute index of array, not as a relative element count. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30600
[Bug c++/28988] [4.0/4.1/4.2/4.3 Regression] g++ does not check first type name in pseudo-destructor-name
--- Comment #6 from steven at gcc dot gnu dot org 2007-01-27 22:30 --- Approval of the patch at http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01429.html was posted today: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02253.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28988
[Bug tree-optimization/30564] [4.3 Regression] ice for legal code with -O3
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-01-27 22:30 --- (In reply to comment #7) > This works with "4.3.0 20070127" on powerpc-darwin with -O3 and -O3 -m64. Ok, I had to change a paramater internal to GCC to get it to reproduce on ppc-darwin but I am able to with today's compiler. Looking into it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
[Bug c/30559] compiler loops forever with flag -O3
--- Comment #3 from dcb314 at hotmail dot com 2007-01-27 22:12 --- (In reply to comment #2) > This should be fixed with > http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01728.html I think. I suspect not. The snapshot 20070126 still seems to have the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30559
[Bug libfortran/30617] recursive I/O hangs under OSX 10.3
--- Comment #6 from dominiq at lps dot ens dot fr 2007-01-27 22:01 --- Subject: Re: recursive I/O hangs under OSX 10.3 > I agree this is probably platform specific. Can someone do the test on a Macintel? TIA -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug libfortran/30617] recursive I/O hangs under OSX 10.3
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-01-27 21:51 --- I recall some time ago working on the patch that enabled this feature. I agree this is probably platform specific. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug libfortran/30617] recursive I/O hangs under OSX 10.3
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-27 21:47 --- This might be a bug in Mac OS X's libraries. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |libfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug libgcj/30513] [4.3 Regression] Bootstrap failure with libgcj on sparc-sun-solaris2.10
--- Comment #11 from andreast at gcc dot gnu dot org 2007-01-27 21:46 --- Subject: Bug 30513 Author: andreast Date: Sat Jan 27 21:46:15 2007 New Revision: 121239 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121239 Log: 2007-01-27 Andreas Tobler <[EMAIL PROTECTED]> PR libgcj/30513 * configure.host: Add forgottten sysdep_dir to sparc. Add a flag to libgcj_flags to undefine 'sun' at compile time. * sysdep/sparc/locks.h (read_barrier): New functions for 32 and 64 bit Sparc. (write_barrier): Likewise. Modified: trunk/libjava/ChangeLog trunk/libjava/configure.host trunk/libjava/sysdep/sparc/locks.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30513
[Bug fortran/30617] recursive I/O hangs under OSX 10.3
--- Comment #3 from dominiq at lps dot ens dot fr 2007-01-27 21:43 --- > I believe recursive IO is undefined Probably, but the same code works with Target: x86_64-unknown-linux-gnu gcc version 4.3.0 20061231 (experimental) on a linux AMD64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug tree-optimization/30564] [4.3 Regression] ice for legal code with -O3
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-01-27 21:41 --- This works with "4.3.0 20070127" on powerpc-darwin with -O3 and -O3 -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30564
[Bug fortran/30617] recursive I/O hangs under OSX 10.3
--- Comment #2 from kargl at gcc dot gnu dot org 2007-01-27 21:38 --- (In reply to comment #1) > I believe recursive IO is undefined (except maybe in some very limited > situations), but I can't locate anything in the F95 Standard that says > this. :( > Okay I found the relevant passage. 9.7 Restrictions on function references and list items A function reference shall not appear in an expression anywhere in an input/output statement if such a reference causes another input/output statement to be executed. I believe your "print *, fun()" is nonconforming. Note F2003 changes the restrictions of recursive IO. It may take a long time before gfortran supports this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug fortran/30617] recursive I/O hangs under OSX 10.3
--- Comment #1 from kargl at gcc dot gnu dot org 2007-01-27 21:31 --- I believe recursive IO is undefined (except maybe in some very limited situations), but I can't locate anything in the F95 Standard that says this. :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug middle-end/27416] ICE on invalid firstprivate/lastprivate
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27416
[Bug bootstrap/30469] [4.3 Regression] profiledbootstrap no longer works
--- Comment #2 from drow at gcc dot gnu dot org 2007-01-27 20:20 --- Testing a patch. -- drow at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |drow at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-27 20:20:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30469
[Bug pch/14933] missing pre-compiled header depends with -MD
--- Comment #7 from tromey at gcc dot gnu dot org 2007-01-27 20:03 ---
This patch looks reasonable to me, though I cannot approve it.
The formatting is slightly wrong, there should be a space
between the "if" and the "(".
Also a ChangeLog entry is required.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14933
[Bug c++/29106] [4.0 Regression] sizeof(*var) in expression drops entire line of code out of compile
--- Comment #14 from reichelt at gcc dot gnu dot org 2007-01-27 19:58 --- Subject: Bug 29106 Author: reichelt Date: Sat Jan 27 19:58:38 2007 New Revision: 121238 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121238 Log: Backport: 2006-11-13 Mark Mitchell <[EMAIL PROTECTED]> PR c++/29106 * init.c (constant_value_1): Treat a DECL_INITIAL of error_mark_node as meaning that the variable is uninitialized, rather than erroneously initialized. * g++.dg/init/self1.C: New test. * g++.dg/other/fold1.C: Adjust error markers. * g++.dg/init/member1.C: Likewise. 2006-08-27 Simon Martin <[EMAIL PROTECTED]> PR c++/28284 * pt.c (fold_non_dependent_expr): Make sure expr is not dereferenced if it is NULL. * g++.dg/template/pr28284.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/init/self1.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/pr28284.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/init.c branches/gcc-4_0-branch/gcc/cp/pt.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/g++.dg/init/member1.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/fold1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29106
[Bug c++/28284] [4.1 regression] ICE with invalid static const variable
--- Comment #10 from reichelt at gcc dot gnu dot org 2007-01-27 19:58 --- Subject: Bug 28284 Author: reichelt Date: Sat Jan 27 19:58:38 2007 New Revision: 121238 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121238 Log: Backport: 2006-11-13 Mark Mitchell <[EMAIL PROTECTED]> PR c++/29106 * init.c (constant_value_1): Treat a DECL_INITIAL of error_mark_node as meaning that the variable is uninitialized, rather than erroneously initialized. * g++.dg/init/self1.C: New test. * g++.dg/other/fold1.C: Adjust error markers. * g++.dg/init/member1.C: Likewise. 2006-08-27 Simon Martin <[EMAIL PROTECTED]> PR c++/28284 * pt.c (fold_non_dependent_expr): Make sure expr is not dereferenced if it is NULL. * g++.dg/template/pr28284.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/init/self1.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/pr28284.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/init.c branches/gcc-4_0-branch/gcc/cp/pt.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/g++.dg/init/member1.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/fold1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28284
[Bug c/4076] -Wunused doesn't warn about static function only called by itself.
--- Comment #8 from stevenb dot gcc at gmail dot com 2007-01-27 19:58 --- Subject: Re: -Wunused doesn't warn about static function only called by itself. Just one for everything should suffice. Or, if you prefer, you can remove that one function with a separate patch first, which, I believe, you can commit as obviously correct (given that the author of that function and authority of its usage already ack'ed that the function is dead code). Thanks for working on this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
[Bug fortran/30617] New: recursive I/O hangs under OSX 10.3
The executable of the following code:
external fun
real fun
real a
a = fun()
print *, a
print *, fun()
end
real function fun()
print *, 'test'
fun = 1.0
end
compiled with 4.3.0 20070126, hangs. -fdump-tree-original gives:
MAIN__ ()
{
real4 a;
_gfortran_set_std (70, 127, 0, 0);
a = fun ();
{
struct __st_parameter_dt dt_parm.0;
dt_parm.0.common.filename = "fun_external.f90";
dt_parm.0.common.line = 5;
dt_parm.0.common.unit = 6;
dt_parm.0.common.flags = 128;
_gfortran_st_write (&dt_parm.0);
_gfortran_transfer_real (&dt_parm.0, &a, 4);
_gfortran_st_write_done (&dt_parm.0);
}
{
struct __st_parameter_dt dt_parm.1;
dt_parm.1.common.filename = "fun_external.f90";
dt_parm.1.common.line = 6;
dt_parm.1.common.unit = 6;
dt_parm.1.common.flags = 128;
_gfortran_st_write (&dt_parm.1);
{
real4 D.951;
D.951 = fun ();
_gfortran_transfer_real (&dt_parm.1, &D.951, 4);
}
_gfortran_st_write_done (&dt_parm.1);
}
}
fun ()
{
real4 __result_fun;
{
struct __st_parameter_dt dt_parm.2;
dt_parm.2.common.filename = "fun_external.f90";
dt_parm.2.common.line = 9;
dt_parm.2.common.unit = 6;
dt_parm.2.common.flags = 128;
_gfortran_st_write (&dt_parm.2);
_gfortran_transfer_character (&dt_parm.2, "test", 4);
_gfortran_st_write_done (&dt_parm.2);
}
__result_fun = 1.0e+0;
return __result_fun;
}
and if run under gdb, after ^C, where gives:
#0 0x90017238 in semaphore_wait_signal_trap ()
#1 0x90001d90 in pthread_mutex_lock ()
#2 0x0020093c in get_external_unit (n=6, do_create=3331) at
../../../gcc-4.3-20070127/libgfortran/../gcc/gthr-posix.h:604
#3 0x001ff6e0 in data_transfer_init (dtp=0x6004d8, read_flag=3331) at
../../../gcc-4.3-20070127/libgfortran/io/transfer.c:1698
#4 0x2b48 in fun_ () at fun_external.f90:9
#5 0x2abc in MAIN__ () at fun_external.f90:6
#6 0x2bac in main (argc=14, argv=0xd03) at
../../../gcc-4.3-20070127/libgfortran/fmain.c:18
Note that I see the same problem on OSX 10.4 with gcc version 4.2.0 20060617.
Any idea around?
--
Summary: recursive I/O hangs under OSX 10.3
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC target triplet: powerpc-apple-darwin7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug c++/30615] c++: Internal error: Killed: 9 (program cc1plus)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-27 19:05 --- How much memory do you have? This internal error is caused by the kernel killing the process because it ran over the memory limits. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Keywords||memory-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30615
[Bug fortran/30407] Elemental functions in WHERE assignments wrongly rejected
--- Comment #6 from pault at gcc dot gnu dot org 2007-01-27 18:23 --- Subject: Bug 30407 Author: pault Date: Sat Jan 27 18:23:14 2007 New Revision: 121235 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121235 Log: 2007-01-27 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30407 * trans-expr.c (gfc_conv_operator_assign): New function. * trans.h : Add prototype for gfc_conv_operator_assign. * trans-stmt.c (gfc_trans_where_assign): Add a gfc_symbol for a potential operator assignment subroutine. If it is non-NULL call gfc_conv_operator_assign instead of the first assignment. ( gfc_trans_where_2): In the case of an operator assignment, extract the argument expressions from the code for the subroutine call and pass the symbol to gfc_trans_where_assign. resolve.c (resolve_where, gfc_resolve_where_code_in_forall, gfc_resolve_forall_body): Resolve the subroutine call for operator assignments. 2007-01-27 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30407 * gfortran.dg/where_operator_assign_1.f90: New test. * gfortran.dg/where_operator_assign_2.f90: New test. * gfortran.dg/where_operator_assign_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/where_operator_assign_1.f90 trunk/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90 trunk/gcc/testsuite/gfortran.dg/where_operator_assign_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30407
[Bug c++/29106] [4.0 Regression] sizeof(*var) in expression drops entire line of code out of compile
--- Comment #13 from patchapp at dberlin dot org 2007-01-27 18:05 --- Subject: Bug number PR c++/29106 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02248.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29106
[Bug fortran/30605] -Wno-tabs should be active for -std=f2003 and -pedantic
-- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-01-27 00:02:23 |2007-01-27 18:01:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30605
[Bug c++/30615] New: c++: Internal error: Killed: 9 (program cc1plus)
When building mysql server 5.0.33 from ports on FreeBSD 6.0-RELEASE, I get the following c++ error: [EMAIL PROTECTED] [/usr/ports/databases/mysql50-server]# make WITH_OPENSSL=yes WITHOUT_INNODB=yes ===> Building for mysql-server-5.0.33 make all-recursive Making all in include make all-am Making all in Docs Making all in strings Making all in mysys Making all in dbug Making all in extra make all-recursive Making all in regex Making all in bdb cd build_unix && make all Making all in myisam Making all in myisammrg Making all in heap Making all in vio Making all in sql make all-recursive Making all in share if c++ -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME="\"/usr/local\"" -DDATADIR="\"/var/db/mysql\"" -DSHAREDIR="\"/usr/local/share/mysql\"" -DHAVE_CONFIG_H -I. -I. -I.. -I../bdb/build_unix-I../include -I../include -I../regex -I. -I/usr/local/include -DDBUG_OFF -O2 -fno-strict-aliasing -pipe -O2 -fno-strict-aliasing -pipe -felide-constructors -fno-rtti -fno-exceptions -fno-implicit-templates -fno-exceptions -fno-rtti -DMYSQLD_NET_RETRY_COUNT=100 -MT sql_handler.o -MD -MP -MF ".deps/sql_handler.Tpo" -c -o sql_handler.o sql_handler.cc; then mv -f ".deps/sql_handler.Tpo" ".deps/sql_handler.Po"; else rm -f ".deps/sql_handler.Tpo"; exit 1; fi c++: Internal error: Killed: 9 (program cc1plus) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. *** Error code 1 Stop in /usr/ports/databases/mysql50-server/work/mysql-5.0.33/sql. *** Error code 1 Stop in /usr/ports/databases/mysql50-server/work/mysql-5.0.33/sql. *** Error code 1 Stop in /usr/ports/databases/mysql50-server/work/mysql-5.0.33/sql. *** Error code 1 Stop in /usr/ports/databases/mysql50-server/work/mysql-5.0.33. *** Error code 1 Stop in /usr/ports/databases/mysql50-server/work/mysql-5.0.33. *** Error code 1 Stop in /usr/ports/databases/mysql50-server. == [EMAIL PROTECTED] [~]$ gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.4 [FreeBSD] 20050518 [EMAIL PROTECTED] [~]$ uname -a FreeBSD nagios.unixfun.net 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov 3 09:36:13 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Please let me know what other info you need from me. Thanks, Kevin -- Summary: c++: Internal error: Killed: 9 (program cc1plus) Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kevin at penguinnetwerx dot net GCC host triplet: FreeBSD 6.0-RELEASE i386 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30615
[Bug fortran/30613] gfortran -fopenmp -static produces bad executable
--- Comment #2 from kargl at gcc dot gnu dot org 2007-01-27 17:42 --- Found the message. http://gcc.gnu.org/ml/gcc-bugs/2007-01/msg02248.html *** This bug has been marked as a duplicate of 30471 *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30613
[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64
--- Comment #8 from kargl at gcc dot gnu dot org 2007-01-27 17:42 --- *** Bug 30613 has been marked as a duplicate of this bug. *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||milan at cmm dot ki dot si http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471
[Bug fortran/30613] gfortran -fopenmp -static produces bad executable
--- Comment #1 from kargl at gcc dot gnu dot org 2007-01-27 17:33 --- Works for me with both the 4.2 branch and trunk gfortran. troutmask:sgk[235] gfc4x -o z -fopenmp -static t.f troutmask:sgk[236] ./z n,p= 0 0.00 n,p= 0 0.00 troutmask:sgk[237] gfc42 -o z -fopenmp -static t.f troutmask:sgk[238] ./z n,p= 0 0.00 n,p= 0 0.00 I recall seeing a similar bug report with OpenMP and -static. The problem is that glibc does not support a static TLS. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30613
[Bug fortran/30411] gfortran MODULE bug for non trivial data types
--- Comment #3 from kargl at gcc dot gnu dot org 2007-01-27 17:24 --- After fixing the code to some that even has a just to compile, I've compiled this with gfortran from the 4.1 branch, 4.2 branch, and trunk. Closing with 'works for me'. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30411
[Bug fortran/30278] Inconsistencies with backslash handling
--- Comment #8 from kargl at gcc dot gnu dot org 2007-01-27 17:16 --- Fixed in 4.1, 4.2, and trunk. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30278
[Bug fortran/30278] Inconsistencies with backslash handling
--- Comment #7 from kargl at gcc dot gnu dot org 2007-01-27 17:14 --- Subject: Bug 30278 Author: kargl Date: Sat Jan 27 17:14:06 2007 New Revision: 121234 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121234 Log: 2007-01-26 Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/30278 * gfortran.dg/backslash_3.f: New test. 2007-01-26 Steven Bosscher <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/30278 * fortran/io.c (next_char): Deal with backslash escaped characters. Issue warnings in non -std=gnu cases. * fortran/primary.c (next_string_char): Issue warnings in non Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/backslash_3.f Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/io.c branches/gcc-4_1-branch/gcc/fortran/primary.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30278
[Bug ada/30614] New: compiler puts the blame on in parameter mode, not pointer to constant, for assignment to component
gcc reports two different error messages, the second of them doesn't
seem to be correct. If it is somehow correct (I don't think so),
it is still misleading:
$ gnatmake -gnatv p.adb
gcc -c -gnatv p.adb
GNAT 4.3.0 20070127 (experimental)
Copyright 1992-2006, Free Software Foundation, Inc.
Compiling: p.adb (source file time stamp: 2007-01-27 13:38:37)
5. this.x := value;
|
>>> left hand side of assignment must be a variable
10. this.x := 42;
|
>>> assignment to "in" mode parameter not allowed
13 lines: 2 errors
gnatmake: "p.adb" compilation error
The first message is correct because "this" is a pointer to constant.
The second message should be the same because the parameter mode should
only affects the mode of the pointer parameter ("this") not the pointee.
(When T_Ptr is made access-to-variable, both lines compile fine.)
package P is
type T is tagged limited private;
type T_Ptr is access constant T; -- Note: constant
procedure reset(this: T_Ptr);
procedure set(this: T_Ptr; value: Integer);
private
type T is tagged limited record
x: Integer;
end record;
end P;
package body P is
procedure set(this: T_Ptr; value: Integer) is
begin
this.x := value;
end set;
procedure reset(this: T_Ptr) is
begin
this.x := 42;
end reset;
end P;
--
Summary: compiler puts the blame on in parameter mode, not
pointer to constant, for assignment to component
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bauhaus at futureapps dot de
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=30614
[Bug c/30610] huge memory consumption with -O3
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-01-27 17:07 --- It's of course caused by the new partial-antic stuff, but still something is out of a reasonable bound here (we're just iterating 2 times to solve partial antic). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30610
[Bug fortran/30613] New: gfortran -fopenmp -static produces bad executable
the command: gfortran -static -fopenmp -o xomp xomp.f works OK, but I when executing xomp it segfaults: export OMP_NUM_THREADS=2 ./xomp Segmentation fault if compiling with: gfortran -static -fopenmp -o xomp xomp.f everything is OK. This happens with any OpenMP program. Here is a simple example: PROGRAM OMPSTATIC !$OMP PARALLEL PRIVATE(n, p) p = omp_get_thread_num() n = OMP_GET_NUM_THREADS() write(*,*)'n,p=',n,p !$OMP END PARALLEL END PROGRAM I am using this: [EMAIL PROTECTED] ~/proj/g03 $ ~/gcc/bin/gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /home/milan/gcc-src/gcc-4.3-20070119/configure --prefix=/home/milan/gcc --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-shared --enable-threads=posix --enable-bootstrap --enable-__cxa_atexit --enable-languages=c,c++,fortran Thread model: posix gcc version 4.3.0 20070119 (experimental) -- Summary: gfortran -fopenmp -static produces bad executable Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: milan at cmm dot ki dot si http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30613
[Bug testsuite/30612] New: Testsuite cannot detect duplicated error/warning messages
We have seen several regressions and PRs with respect to this. It is possible
to workaround this by using:
/* { dg-bogus "message.*message" } */
/* { dg-warning "message" "" { target *-*-* } 1 } */
However, the test must be alone in one file. Otherwise, strange things may
happen.
This is obviously very cumbersome and not practical in the long run.
--
Summary: Testsuite cannot detect duplicated error/warning
messages
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30612
[Bug c/30610] huge memory consumption with -O3
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-27 16:51 --- All time is suck up in PRE: tree PRE : 36.36 (93%) usr 0.40 (95%) sys 36.85 (93%) wall 88918 kB (96%) ggc TOTAL : 39.03 0.4239.74 92276 kB though it uses only 512MB for me (and 36s) using a release-checking enabled build from 20070113. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30610
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-27 16:49 --- How would you test whether this is fixed? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug fortran/30611] New: Confusing error message for negative ncopies in REPEAT
The code is invalid (13.14.89 says about NCOPIES
"Its value should not be negative), but the
error message could definitely be improved :-)
$ cat rep.f90
program main
integer :: i
character(len=10) :: from
from = "-1"
read(unit=from, fmt="(I10)") i
print *,repeat ("a", i)
end program main
$ gfortran rep.f90
$ ./a.out
Fortran runtime error: Attempt to allocate a negative amount of memory.
--
Summary: Confusing error message for negative ncopies in REPEAT
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30611
[Bug fortran/30389] ACHAR() intrinsic gives erroneous errors in constant-folding.
--- Comment #5 from patchapp at dberlin dot org 2007-01-27 16:35 --- Subject: Bug number PR 30389 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02245.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30389
[Bug c/30610] huge memory consumption with -O3
--- Comment #1 from kcwu at csie dot org 2007-01-27 16:26 --- Created an attachment (id=12970) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12970&action=view) eats 1321MB memory and 8minutes to compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30610
[Bug c/30610] New: huge memory consumption with -O3
Happen with gcc43 snapshot 20070105 (experimental). gcc configured with: ./..//gcc-4.3-20070105/configure --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --with-gmp=/usr/local --program-suffix=43 --libdir=/usr/local/lib/gcc-4.3.0 --with-gxx-include-dir=/usr/local/lib/gcc-4.3.0/include/c++/ --infodir=/usr/local/info/gcc43 --disable-libgcj --prefix=/usr/local x86_64-portbld-freebsd6.2 $ time gcc43 -O3 -c f5.c -Wall user8m0.834s max memory usage 1321 MB. It takes too long time and huge memory to compile, compared to gcc4.2 or -O2: $ time gcc42 -O3 -c f5.c user0m0.575s $ time gcc43 -O2 -c f5.c -finline-functions -funswitch-loops -fgcse-after-reload user0m0.602s And the memory usage is less than 10 MB. -- Summary: huge memory consumption with -O3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kcwu at csie dot org GCC build triplet: x86_64-portbld-freebsd6.2 GCC host triplet: x86_64-portbld-freebsd6.2 GCC target triplet: x86_64-portbld-freebsd6.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30610
[Bug c/4076] -Wunused doesn't warn about static function only called by itself.
--- Comment #7 from manu at gcc dot gnu dot org 2007-01-27 16:04 --- So then, should I prepare two separated patches or just one for everything ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
[Bug c/4076] -Wunused doesn't warn about static function only called by itself.
--- Comment #6 from hubicka at gcc dot gnu dot org 2007-01-27 15:57 --- update_inlined_to_pointers is obviously no longer needed and can be safely removed now. Thanks for noticing it ;) Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
[Bug c/4076] -Wunused doesn't warn about static function only called by itself.
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-27 15:46 ---
Anyway, here is my current patch, perhaps someone can find some use for it:
Index: gcc/testsuite/gcc.dg/Wunused-function.c
===
--- gcc/testsuite/gcc.dg/Wunused-function.c (revision 0)
+++ gcc/testsuite/gcc.dg/Wunused-function.c (revision 0)
@@ -0,0 +1,6 @@
+/* PR c/4076 -Wunused doesn't warn about static function only called by
itself. */
+/* { dg-do compile } */
+/* { dg-options "-Wunused-function" } */
+
+static void foo (void) {} /* { dg-warning "'foo' defined but not used" } */
+static void bar (void) { bar (); } /* { dg-warning "'bar' defined but not
used" } */
Index: gcc/c-typeck.c
===
--- gcc/c-typeck.c (revision 121039)
+++ gcc/c-typeck.c (working copy)
@@ -2077,9 +2077,13 @@ build_external_ref (tree id, int fun, lo
if (TREE_DEPRECATED (ref))
warn_deprecated_use (ref);
- if (!skip_evaluation)
-assemble_external (ref);
- TREE_USED (ref) = 1;
+ /* Recursive calls does not count as usage. */
+ if (ref != current_function_decl)
+{
+ if (!skip_evaluation)
+ assemble_external (ref);
+ TREE_USED (ref) = 1;
+}
if (TREE_CODE (ref) == FUNCTION_DECL && !in_alignof)
{
Index: gcc/calls.c
===
--- gcc/calls.c (revision 121039)
+++ gcc/calls.c (working copy)
@@ -1449,7 +1449,7 @@ rtx_for_function_call (tree fndecl, tree
{
/* If this is the first use of the function, see if we need to
make an external definition for it. */
- if (! TREE_USED (fndecl))
+ if (!TREE_USED (fndecl) && fndecl != current_function_decl)
{
assemble_external (fndecl);
TREE_USED (fndecl) = 1;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
[Bug c/4076] -Wunused doesn't warn about static function only called by itself.
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-27 15:45 --- The funny thing is that if we fix this, bootstrap will break (with a warning treated as an error) on tree-optimize.c (update_inlined_to_pointers) since it seems that that function is only used by itself. Is it dead code that we can remove or there is something weird going on? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
[Bug fortran/30609] New: Calculating masks twice
In this, the expression a>0 is evaluated twice,
both in the *.original and the *.optimized dump:
function average(a, n)
real :: average
real :: a(n)
average = sum(a, a>0)/count(a>0)
end function average
$ cat average.f90.003t.original
average (a, n)
{
int4 ubound.0;
int4 size.1;
real4 __result_average;
int4 D.1012;
bit_size_type D.1013;
D.1014;
ubound.0 = *n;
size.1 = NON_LVALUE_EXPR ;
size.1 = size.1 >= 0 ? size.1 : 0;
D.1012 = size.1 - 1;
D.1013 = (bit_size_type) () size.1 * 32;
D.1014 = () size.1 * 4;
{
int4 D.1008;
int4 count.4;
int4 D.1004;
int4 D.1003;
real4 val.2;
val.2 = 0.0;
D.1003 = ubound.0;
D.1004 = ubound.0;
{
int4 S.3;
S.3 = 1;
while (1)
{
if (S.3 > ubound.0) goto L.1;
if ((*a)[S.3 + -1] > 0.0)
{
val.2 = val.2 + (*a)[S.3 + -1];
}
S.3 = S.3 + 1;
}
L.1:;
}
count.4 = 0;
D.1008 = ubound.0;
{
int4 S.5;
S.5 = 1;
while (1)
{
if (S.5 > ubound.0) goto L.2;
if ((*a)[S.5 + -1] > 0.0)
{
count.4 = count.4 + 1;
}
S.5 = S.5 + 1;
}
L.2:;
}
__result_average = val.2 / (real4) count.4;
}
return __result_average;
}
$ cat average.f90.113t.optimized
;; Function average (average_)
Analyzing Edge Insertions.
average (a, n)
{
ivtmp.49;
ivtmp.44;
real4 prephitmp.36;
real4 val.2;
int4 count.4;
int4 size.1;
real4 D.1020;
:
size.1 = *n;
if (size.1 <= 0) goto ; else goto ;
:;
val.2 = 0.0;
prephitmp.36 = 0.0;
goto (L.2);
:;
val.2 = 0.0;
ivtmp.49 = 1;
:;
D.1020 = MEM[base: a, index: () ivtmp.49, step: 4, offset:
0x0fffc];
if (D.1020 > 0.0) goto ; else goto ;
:;
val.2 = val.2 + D.1020;
:;
ivtmp.49 = ivtmp.49 + 1;
if (size.1 < (int4) ivtmp.49) goto ; else goto ;
:;
count.4 = 0;
ivtmp.44 = 1;
:;
if (MEM[base: a, index: () ivtmp.44, step: 4, offset:
0x0fffc] > 0.0) goto ; else goto ;
:;
count.4 = count.4 + 1;
:;
ivtmp.44 = ivtmp.44 + 1;
if (size.1 < (int4) ivtmp.44) goto ; else goto ;
:;
prephitmp.36 = (real4) count.4;
L.2:;
return val.2 / prephitmp.36;
}
--
Summary: Calculating masks twice
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30609
[Bug ada/30608] Segmentation fault : Error detected at ali.adb:2240:1
--- Comment #1 from mbo dot massimo at tiscali dot it 2007-01-27 14:33 --- Created an attachment (id=12969) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12969&action=view) configure and make logs configure and make logs produced during GCC generation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30608
[Bug ada/30608] New: Segmentation fault : Error detected at ali.adb:2240:1
During make of the version 4.3.0 20070112 of the GCC compiler I have the following error: /cygdrive/h/cross_compiler/compiler_gcc/./prev-gcc/xgcc -B/cygdrive/h/cross_compiler/compiler_gcc/./prev-gcc/ -B/usr/local/gcc-4.3-20070112/i686-pc-cygwin/bin/ -c -g -O2 -gnatpg -gnata -I- -I. -Iada -I../gcc-4.3-20070112/gcc/ada ../gcc-4.3-20070112/gcc/ada/ali.adb -o ada/ali.o +===GNAT BUG DETECTED==+ | 4.3.0 20070112 (experimental) (i686-pc-cygwin) Segmentation fault| | Error detected at ali.adb:2240:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | 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). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. ../gcc-4.3-20070112/gcc/ada/ali.adb ../gcc-4.3-20070112/gcc/ada/ali.ads ../gcc-4.3-20070112/gcc/ada/casing.ads ../gcc-4.3-20070112/gcc/ada/types.ads ../gcc-4.3-20070112/gcc/ada/gnatvsn.ads ../gcc-4.3-20070112/gcc/ada/rident.ads ../gcc-4.3-20070112/gcc/ada/table.ads ../gcc-4.3-20070112/gcc/ada/butil.ads ../gcc-4.3-20070112/gcc/ada/debug.ads ../gcc-4.3-20070112/gcc/ada/fname.ads ../gcc-4.3-20070112/gcc/ada/namet.ads ../gcc-4.3-20070112/gcc/ada/alloc.ads ../gcc-4.3-20070112/gcc/ada/hostparm.ads ../gcc-4.3-20070112/gcc/ada/opt.ads ../gcc-4.3-20070112/gcc/ada/osint.ads ../gcc-4.3-20070112/gcc/ada/output.ads ../gcc-4.3-20070112/gcc/ada/table.adb ../gcc-4.3-20070112/gcc/ada/tree_io.ads raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:393 It seems the same error encountered in the bug report Bug#: 30453 Configure command: gcc-4.3-20070112/configure --verbose \ --prefix=/usr/local/gcc-4.3-20070112 \ --enable-languages=c,c++,ada,fortran,java,objc \ --enable-threads=gnat \ --enable-shared \ -v 2>&1 | tee configure.log host PC windows XP home SP2 cygwin version: 1.5.23-2 host gcc version gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) with s-rident.ads aligned to versione 4.1.1 -- Summary: Segmentation fault : Error detected at ali.adb:2240:1 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mbo dot massimo at tiscali dot it GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30608
[Bug libgomp/30546] [4.2/4.3 regression] build fail in libgomp when building from SVN because makeinfo is missing
--- Comment #11 from dfranke at gcc dot gnu dot org 2007-01-27 13:46 --- When introducing this, I was in good faith that automake is capable to handle any issues that may arise. Since the *.info files are not kept in SVN, as `missing` seems to assume, the fail safe backfires. I will replace the automake generated targets by custom ones which employ the well known BUILD_INFO conditional as soon as possible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30546
[Bug c++/15787] Poor error message with if and blocks
--- Comment #6 from patchapp at dberlin dot org 2007-01-27 13:40 --- Subject: Bug number PR 15787 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02238.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15787
[Bug fortran/30512] MAXVAL() incorrect for zero-size int arrays, and for -HUGE-1 maximum values.
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-01-27 13:24 --- Here's a patch for the m4 part: Index: m4/iparm.m4 === --- m4/iparm.m4 (revision 121230) +++ m4/iparm.m4 (working copy) @@ -28,6 +28,6 @@ define_type(rtype, rtype_tmp)dnl define(rtype_qual,`_'rtype_kind)dnl ')dnl define(atype_max, atype_name`_HUGE')dnl -define(atype_min, `-'atype_max)dnl +define(atype_min,ifelse(rtype_letter,`i',`(-'atype_max`-1)',`-'atype_max))dnl define(name, regexp(regexp(file, `[^/]*$', `\&'), `^\([^_]*\)_', `\1'))dnl define(rtype_ccode,ifelse(rtype_letter,`i',rtype_kind,rtype_code))dnl -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30512
[Bug java/30607] gcj -I x -C doesn't include x as source dir search patch
--- Comment #1 from mtrudel at gmx dot ch 2007-01-27 10:12 --- I can confirm that. However, I don't know if it's a bug or just luck that it worked before. I think the correct command would be: gcj -C -Ix x/a.java (no space between -I" and "x") This way it works and I think (I'm absolutely not sure) this is the official way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30607
[Bug libgomp/30546] [4.2/4.3 regression] build fail in libgomp when building from SVN because makeinfo is missing
--- Comment #10 from dannysmith at users dot sourceforge dot net 2007-01-27 10:06 --- (In reply to comment #9) > (In reply to comment #8) > > So I still say we should just require makeinfo when building from > > SVN/snapshot. > > There is no reason not really. > > Yes there are reasons: for example, makeinfo does not easily build on mingw32, > and probably some other non-mainstream archs. > makeinfo does build easily using cygwin toolchain, and hence is available on windows for use with mingw. You can just download makeinfo binaries from cygwin/redhat/sourceware unless it against your religion. Or you could get makeinfo from MS as part of its POSIX emulation toolkit Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30546
[Bug c++/24924] front end and preprocessor pedantic_errors settings should agree
--- Comment #2 from patchapp at dberlin dot org 2007-01-27 09:15 --- Subject: Bug number PR24924 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02234.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24924
[Bug libgomp/30546] [4.2/4.3 regression] build fail in libgomp when building from SVN because makeinfo is missing
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-01-27 08:59 --- (In reply to comment #8) > So I still say we should just require makeinfo when building from > SVN/snapshot. > There is no reason not really. Yes there are reasons: for example, makeinfo does not easily build on mingw32, and probably some other non-mainstream archs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30546
