[Bug c/32520] C/C++ programs segfault at runtime if arrays larger than 8MB are declared.
--- Comment #1 from pluto at agmk dot net 2007-06-27 07:28 --- the 8MB array overflows stack and gcc has nothing to do here because stack size is controlled by operating system. use ulimit -s [stack size in kB] to workaround this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32520
[Bug fortran/32439] hard-coded memory limit ? f951: out of memory with '-O1 -fbounds-check'
--- Comment #5 from jv244 at cam dot ac dot uk 2007-06-27 07:31 --- could be similar to PR32514 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32439
[Bug middle-end/32514] out of memory using -fprofile-generate
--- Comment #1 from jv244 at cam dot ac dot uk 2007-06-27 07:35 --- this is for: Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_trunk/gcc/configure --prefix=/data03/vondele/gcc_trunk/build --with-gmp=/data03/vondele/ --with-mpfr=/data03/vondele/ --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20070626 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32514
[Bug target/28904] operand out of range on Linux/PowerPC
--- Comment #7 from srm at schokokeks dot org 2007-06-27 08:06 --- I have checked with 4.2.0 and it produces the same error. Maybe i'd like to rebuild python too with 4.2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28904
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #119 from jv244 at cam dot ac dot uk 2007-06-27 08:24 --- Testing gcc 4.2.0 I unfortunately found that it miscompiles CP2K. The following testcase: tests/DFTB/regtest-scc/h2o-1.inp yields incorrect results. Should be similar to: Total energy: -130.561836 whereas one gets Total energy: -127.642599 This is a very large difference beyond numerics. The miscompilation is triggered by: # BUG FCFLAGS = -O3 -ffast-math -ftree-vectorize -march=native but not # OK FCFLAGS = -O3 -ffast-math -march=native # OK FCFLAGS = -O3 -funroll-loops -ftree-vectorize -march=native I might try to find out which module gets miscompiled, but this could be a bit of a slow process. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/32439] hard-coded memory limit ? f951: out of memory with '-O1 -fbounds-check'
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-06-27 08:51 --- (In reply to comment #3) So, it looks like something inside gcc is hard-coded to just 1Gb of memory, instead of the available memory. That's probably a stupid thing to ask, but you don't have any shell limits (as reported per ulimit -a) that would match this number, do you? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32439
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-06-27 08:58 --- (In reply to comment #3) basically, you need -O2 and -march=native to trigger the bug I can't reproduce that, what is your processor exactly? (ie what is native for you) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug c/32520] C/C++ programs segfault at runtime if arrays larger than 8MB are declared.
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-27 08:59 --- Adjust your available stack size. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32520
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #120 from pinskia at gmail dot com 2007-06-27 09:37 --- Subject: Re: [meta-bugs] ICEs with CP2K On 27 Jun 2007 08:24:46 -, jv244 at cam dot ac dot uk [EMAIL PROTECTED] wrote: # BUG FCFLAGS = -O3 -ffast-math -ftree-vectorize -march=native So -ffast-math with vectorizer changes the results. I bet this is due to reduction which is done for -ffast-math with -ftree-vectorize. Which case it might not be a bug. Yes 3 out of 130 is actually huge but if the values are huge to begin with, it might be the case this is just a percussion issue. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #5 from jv244 at cam dot ac dot uk 2007-06-27 10:34 --- (In reply to comment #4) (In reply to comment #3) basically, you need -O2 and -march=native to trigger the bug I can't reproduce that, what is your processor exactly? (ie what is native for you) ... here is a suggestion for the gcc crew ... what about having gfortran -v also print the value fo -march=native. Honestly, I often don't now the precise CPU I'm running on (that's why I find -march=native useful in the first place). In this case, it is either on a intel core 2 duo or on an opteron. I'll see if I can figure out where I did these runs -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug rtl-optimization/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor
--- Comment #4 from ubizjak at gmail dot com 2007-06-27 11:24 --- (In reply to comment #3) The problem is in -ftree-vectorize The difference is, that without -ftree-vectorize the inner loop (do k = 1, 9) is completely unrolled, but with vectorization, the loop is vectorized, but _not_ unrolled. Since the vectorization factor is only 2 for V2DF mode vectors, we loose big time at this point. My best guess for unroller problems would be rtl-optimization. -- ubizjak at gmail dot com changed: What|Removed |Added CC|dorit at gcc dot gnu dot org| Component|tree-optimization |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-27 11:25 --- ... here is a suggestion for the gcc crew ... what about having gfortran -v When you invoke gfortran with -v march=native and with a source file, it will show the values. This is the recommended way of showing how you involved gcc/gfortran anyways. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-06-27 11:38 --- (In reply to comment #6) When you invoke gfortran with -v march=native and with a source file, it will show the values. This is the recommended way of showing how you involved gcc/gfortran anyways. Yes, that works fine: $ gcc -c -v -march=native a.c [...] /path/to/cc1 -quiet -v a.c -march=k8 -msahf --param l1-cache-size=1024 --param l1-cache-line-size=64 -mtune=k8 -quiet -dumpbase a.c -auxbase a -version -o /tmp/ccYMbEr2.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug rtl-optimization/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor
--- Comment #5 from dorit at il dot ibm dot com 2007-06-27 11:57 --- (In reply to comment #4) (In reply to comment #3) The problem is in -ftree-vectorize The difference is, that without -ftree-vectorize the inner loop (do k = 1, 9) is completely unrolled, but with vectorization, the loop is vectorized, but _not_ unrolled. Since the vectorization factor is only 2 for V2DF mode vectors, we loose big time at this point. My best guess for unroller problems would be rtl-optimization. Could it be the tree-level complete unroller? (does the vectorizer peel the loop to handle a misaligned store by any chance? if so, and if the misalignment amount is unknown, then the number of iterations of the vectorized loop is unknown, in which case the complete unroller wouldn't work). In autovect-branch the tree-level complete unroller is before the vectorizer - wonder what happens there. Another thing to consider is using -fvect-cost-model (it's very perliminary and hasn't been tuned much, but this could be a good data point for whoever wants to tune the vectorizer cost-model for x86_64). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #8 from jv244 at cam dot ac dot uk 2007-06-27 12:15 --- (In reply to comment #7) (In reply to comment #6) When you invoke gfortran with -v march=native and with a source file, it will right.. that shows: gfortran --verbose -O2 -march=native -pg all.f90 Driving: gfortran -v -O2 -march=native -pg all.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /data/vondele/gcc_trunk/gcc/configure --prefix=/data/vondele/gcc_trunk/build --enable-languages=c,fortran --with-mpfr=/data/programs/mpfr/ Thread model: posix gcc version 4.3.0 20070626 (experimental) /data/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951 all.f90 -march=core2 -mcx16 -msahf --param l1-cache-size=512 --param l1-cache-line-size=64 -mtune=core2 -quiet -dumpbase all.f90 -auxbase all -O2 -version -p -fintrinsic-modules-path /data/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/finclude -o /tmp/ccLxqkOP.s GNU F95 version 4.3.0 20070626 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.0 20070626 (experimental), GMP version 4.1.4, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 and that also leads to the executable which fails as: bench02 ../src/cp2k.sopt JAC_gen.inp CP2K| Stopped by processor number 0 CP2K| cp_log_handling:cp_add_default_loggertoo many default loggers, increase max_stack_pointer in cp_log_handling CP2K| Error number was 100 STOP mp_stop -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug fortran/32439] hard-coded memory limit ? f951: out of memory with '-O1 -fbounds-check'
--- Comment #7 from jv244 at cam dot ac dot uk 2007-06-27 12:18 --- (In reply to comment #6) (In reply to comment #3) So, it looks like something inside gcc is hard-coded to just 1Gb of memory, instead of the available memory. That's probably a stupid thing to ask, but you don't have any shell limits (as reported per ulimit -a) that would match this number, do you? I don't think so. We run large memory jobs on that machine (that's why we have it in the first place). I get the following output: ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 529920 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 529920 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32439
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #121 from jv244 at cam dot ac dot uk 2007-06-27 12:47 --- (In reply to comment #119) I might try to find out which module gets miscompiled, but this could be a bit of a slow process. miscompilation happens with the module qs_neighbor_lists. It is a module with lots of dependencies, so I don't think I will get a reduced testcase for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #122 from jv244 at cam dot ac dot uk 2007-06-27 12:51 --- (In reply to comment #120) I bet this is due to reduction which is done for -ffast-math with -ftree-vectorize. Which case it might not be a bug. Yes 3 out of 130 is actually huge but if the values are huge to begin with, it might be the case this is just a percussion issue. I don't think there is code in the module mentioned before that would be sensitive to changes in the way reductions are done. It is likely something else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #123 from jv244 at cam dot ac dot uk 2007-06-27 13:54 --- (In reply to comment #121) (In reply to comment #119) I might try to find out which module gets miscompiled, but this could be a bit of a slow process. miscompilation happens with the module qs_neighbor_lists. It is a module with lots of dependencies, so I don't think I will get a reduced testcase for this. Compiling that module under valgrind gives an error: valgrind --tool=memcheck /data03/vondele/gcc_4_2_0/build/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951 qs_neighbor_lists.f90 -march=k8 -mtune=k8 -quiet -dumpbase qs_neighbor_lists.f90 -auxbase qs_neighbor_lists -O3 -version -ffast-math -ftree-vectorize -ftree-vectorizer-verbose=1 -I /data03/vondele/gcc_4_2_0/build/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude -o /tmp/ccoFFIrV.s ==30523== Conditional jump or move depends on uninitialised value(s) ==30523==at 0x706E08: vrp_evaluate_conditional_warnv (tree-vrp.c:4186) ==30523==by 0x706F9C: vrp_evaluate_conditional (tree-vrp.c:4318) ==30523==by 0x4B6E9F: substitute_and_fold (tree-ssa-propagate.c:1053) ==30523==by 0x700F04: execute_vrp (tree-vrp.c:5318) ==30523==by 0x6F9F27: execute_one_pass (passes.c:881) ==30523==by 0x6FA08B: execute_pass_list (passes.c:932) ==30523==by 0x6FA09D: execute_pass_list (passes.c:933) ==30523==by 0x48CCCD: tree_rest_of_compilation (tree-optimize.c:463) ==30523==by 0x742363: cgraph_expand_function (cgraphunit.c:1244) ==30523==by 0x742C8D: cgraph_optimize (cgraphunit.c:1309) ==30523==by 0x4633DC: gfc_be_parse_file (f95-lang.c:307) ==30523==by 0x6DBF92: toplev_main (toplev.c:1033) also, I checked all vectorized loops in the code path that gets executed for the testcase, and there is only one trivial one (zeroing a freshly allocated array).Rewriting that bit so that it doesn't get vectorized still somehow triggers the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug middle-end/32492] [4.3 Regression] attribute always_inline - sorry, unimplemented: recursive inlining
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-06-27 14:01 --- Subject: Bug 32492 Author: rguenth Date: Wed Jun 27 14:01:27 2007 New Revision: 126054 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126054 Log: 2007-06-27 Richard Guenther [EMAIL PROTECTED] PR middle-end/32492 * tree.h (fold_convertible_p): Declare. * fold-const.c (fold_convertible_p): New function. * gimplify.c (gimplify_call_expr): Use fold_convertible_p instead of lang_hooks.types_compatible_p. * gcc.dg/inline-22.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/inline-22.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32492
[Bug c/32493] gcc-20070624 fails linux-kernel due to changed gcc-inlining
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-27 14:17 ---
Reduced testcase:
static inline __attribute__((always_inline)) void __check_printsym_format(const
char *fmt, ...)
{
}
static inline __attribute__((always_inline)) void print_symbol(const char *fmt,
unsigned long addr)
{
__check_printsym_format(fmt, );
}
void do_initcalls(void **call)
{
print_symbol(: %s(), (unsigned long) *call);
}
Now, if we make use of the passed variable arguments we would have hit
t2.i: In function '__check_printsym_format':
t2.i:2: sorry, unimplemented: function '__check_printsym_format' can never be
inlined because it uses variable argument lists
that we now hit this even if the varargs are unused is ... unfortunate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32493
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #124 from jv244 at cam dot ac dot uk 2007-06-27 14:21 --- (In reply to comment #123) and there is no valgrind error if I remove -ftree-vectorize from the options. Which, I guess, explains why things get compiled correctly in that case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #19 from richard at codesourcery dot com 2007-06-27 14:37
---
Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
Kenneth Zadeck [EMAIL PROTECTED] writes:
2007-06-23 Kenneth Zadeck [EMAIL PROTECTED]
PR middle-end/32437
*dce.c (deletable_insn_p): Add extra parameter and recurse if insn
is a PARALLEL.
(prescan_insns_for_dce): Add extra parameter.
Kenny found that this patch introduced problems on x86 (I think it was)
because it applied the special handling for bare CLOBBERs to those
inside PARALLELs as well. We don't want that; bare USEs and CLOBBERs
are special DF markers, but USEs and CLOBBERs inside PARALLELs are parts
of asms or define_insns.
Kenny pre-approved the patch below. Bootstrapped regression-tested
on x86_64-linux-gnu. Applied to mainline.
Richard
gcc/
* dce.c (deletable_insn_p_1): New function, split out from...
(deletable_insn_p): ...here. Only treat bare USEs and CLOBBERs
specially, not those inside PARALLELs. Remove BODY argument
and adjust recursive call accordingly.
(prescan_insns_for_dce): Update call to delete_insn_p.
Index: gcc/dce.c
===
--- gcc/dce.c (revision 126053)
+++ gcc/dce.c (working copy)
@@ -58,16 +58,15 @@ static VEC(rtx,heap) *worklist;
static sbitmap marked = NULL;
-/* Return true if INSN with BODY is a normal instruction that can be
- deleted by the DCE pass. */
+/* A subroutine for which BODY is part of the instruction being tested;
+ either the top-level pattern, or an element of a PARALLEL. The
+ instruction is known not to be a bare USE or CLOBBER. */
static bool
-deletable_insn_p (rtx insn, rtx body, bool fast)
+deletable_insn_p_1 (rtx body)
{
- rtx x;
switch (GET_CODE (body))
{
-case USE:
case PREFETCH:
case TRAP_IF:
/* The UNSPEC case was added here because the ia-64 claims that
@@ -79,6 +78,35 @@ deletable_insn_p (rtx insn, rtx body, bo
case UNSPEC:
return false;
+default:
+ if (volatile_insn_p (body))
+ return false;
+
+ if (flag_non_call_exceptions may_trap_p (body))
+ return false;
+
+ return true;
+}
+}
+
+/* Return true if INSN is a normal instruction that can be deleted by
+ the DCE pass. */
+
+static bool
+deletable_insn_p (rtx insn, bool fast)
+{
+ rtx body, x;
+ int i;
+
+ if (!NONJUMP_INSN_P (insn))
+return false;
+
+ body = PATTERN (insn);
+ switch (GET_CODE (body))
+{
+case USE:
+ return false;
+
case CLOBBER:
if (fast)
{
@@ -88,32 +116,20 @@ deletable_insn_p (rtx insn, rtx body, bo
x = XEXP (body, 0);
return REG_P (x) (!HARD_REGISTER_P (x) || reload_completed);
}
- else
+ else
/* Because of the way that use-def chains are built, it is not
possible to tell if the clobber is dead because it can
never be the target of a use-def chain. */
return false;
case PARALLEL:
- {
- int i;
- for (i = XVECLEN (body, 0) - 1; i = 0; i--)
- if (!deletable_insn_p (insn, XVECEXP (body, 0, i), fast))
- return false;
- return true;
- }
+ for (i = XVECLEN (body, 0) - 1; i = 0; i--)
+ if (!deletable_insn_p_1 (XVECEXP (body, 0, i)))
+ return false;
+ return true;
default:
- if (!NONJUMP_INSN_P (insn))
- return false;
-
- if (volatile_insn_p (body))
- return false;
-
- if (flag_non_call_exceptions may_trap_p (body))
- return false;
-
- return true;
+ return deletable_insn_p_1 (body);
}
}
@@ -369,7 +385,7 @@ prescan_insns_for_dce (bool fast)
rtx note = find_reg_note (insn, REG_LIBCALL_ID, NULL_RTX);
if (note)
mark_libcall (insn, fast);
-else if (deletable_insn_p (insn, PATTERN (insn), fast))
+else if (deletable_insn_p (insn, fast))
mark_nonreg_stores (PATTERN (insn), insn, fast);
else
mark_insn (insn, fast);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #20 from zadeck at naturalbridge dot com 2007-06-27 14:39
---
Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
richard at codesourcery dot com wrote:
--- Comment #19 from richard at codesourcery dot com 2007-06-27 14:37
---
Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
Kenneth Zadeck [EMAIL PROTECTED] writes:
2007-06-23 Kenneth Zadeck [EMAIL PROTECTED]
PR middle-end/32437
*dce.c (deletable_insn_p): Add extra parameter and recurse if insn
is a PARALLEL.
(prescan_insns_for_dce): Add extra parameter.
Kenny found that this patch introduced problems on x86 (I think it was)
because it applied the special handling for bare CLOBBERs to those
inside PARALLELs as well. We don't want that; bare USEs and CLOBBERs
are special DF markers, but USEs and CLOBBERs inside PARALLELs are parts
of asms or define_insns.
Kenny pre-approved the patch below. Bootstrapped regression-tested
on x86_64-linux-gnu. Applied to mainline.
Richard
gcc/
* dce.c (deletable_insn_p_1): New function, split out from...
(deletable_insn_p): ...here. Only treat bare USEs and CLOBBERs
specially, not those inside PARALLELs. Remove BODY argument
and adjust recursive call accordingly.
(prescan_insns_for_dce): Update call to delete_insn_p.
Index: gcc/dce.c
===
--- gcc/dce.c (revision 126053)
+++ gcc/dce.c (working copy)
@@ -58,16 +58,15 @@ static VEC(rtx,heap) *worklist;
static sbitmap marked = NULL;
-/* Return true if INSN with BODY is a normal instruction that can be
- deleted by the DCE pass. */
+/* A subroutine for which BODY is part of the instruction being tested;
+ either the top-level pattern, or an element of a PARALLEL. The
+ instruction is known not to be a bare USE or CLOBBER. */
static bool
-deletable_insn_p (rtx insn, rtx body, bool fast)
+deletable_insn_p_1 (rtx body)
{
- rtx x;
switch (GET_CODE (body))
{
-case USE:
case PREFETCH:
case TRAP_IF:
/* The UNSPEC case was added here because the ia-64 claims that
@@ -79,6 +78,35 @@ deletable_insn_p (rtx insn, rtx body, bo
case UNSPEC:
return false;
+default:
+ if (volatile_insn_p (body))
+ return false;
+
+ if (flag_non_call_exceptions may_trap_p (body))
+ return false;
+
+ return true;
+}
+}
+
+/* Return true if INSN is a normal instruction that can be deleted by
+ the DCE pass. */
+
+static bool
+deletable_insn_p (rtx insn, bool fast)
+{
+ rtx body, x;
+ int i;
+
+ if (!NONJUMP_INSN_P (insn))
+return false;
+
+ body = PATTERN (insn);
+ switch (GET_CODE (body))
+{
+case USE:
+ return false;
+
case CLOBBER:
if (fast)
{
@@ -88,32 +116,20 @@ deletable_insn_p (rtx insn, rtx body, bo
x = XEXP (body, 0);
return REG_P (x) (!HARD_REGISTER_P (x) || reload_completed);
}
- else
+ else
/* Because of the way that use-def chains are built, it is not
possible to tell if the clobber is dead because it can
never be the target of a use-def chain. */
return false;
case PARALLEL:
- {
- int i;
- for (i = XVECLEN (body, 0) - 1; i = 0; i--)
- if (!deletable_insn_p (insn, XVECEXP (body, 0, i), fast))
- return false;
- return true;
- }
+ for (i = XVECLEN (body, 0) - 1; i = 0; i--)
+ if (!deletable_insn_p_1 (XVECEXP (body, 0, i)))
+ return false;
+ return true;
default:
- if (!NONJUMP_INSN_P (insn))
- return false;
-
- if (volatile_insn_p (body))
- return false;
-
- if (flag_non_call_exceptions may_trap_p (body))
- return false;
-
- return true;
+ return deletable_insn_p_1 (body);
}
}
@@ -369,7 +385,7 @@ prescan_insns_for_dce (bool fast)
rtx note = find_reg_note (insn, REG_LIBCALL_ID, NULL_RTX);
if (note)
mark_libcall (insn, fast);
-else if (deletable_insn_p (insn, PATTERN (insn), fast))
+else if (deletable_insn_p (insn, fast))
mark_nonreg_stores (PATTERN (insn), insn, fast);
else
mark_insn (insn, fast);
thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug middle-end/32521] New: [4.2] vrp_evaluate_conditional_warnv (tree-vrp.c:4186) at -O3 -ffast-math -ftree-vectorize -march=native
as discussed in PR 29975 CP2K gets miscompiled by gfortran 4.2.0 (see comments 119 to 125). sources (src/all.f90) can be obtained from: http://www.pci.unizh.ch/vandevondele/tmp/CP2K_gcc_2007_06.tgz and are miscompiled with -O3 -ffast-math -ftree-vectorize -march=native the module that gets miscompiled is qs_neighbor_lists. under valgrind, compilation of that module shows: valgrind --tool=memcheck /data03/vondele/gcc_4_2_0/build/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951 qs_neighbor_lists.f90 -march=k8 -mtune=k8 -quiet -dumpbase qs_neighbor_lists.f90 -auxbase qs_neighbor_lists -O3 -version -ffast-math -ftree-vectorize -ftree-vectorizer-verbose=1 -I /data03/vondele/gcc_4_2_0/build/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude -o /tmp/ccoFFIrV.s ==30523== Conditional jump or move depends on uninitialised value(s) ==30523==at 0x706E08: vrp_evaluate_conditional_warnv (tree-vrp.c:4186) ==30523==by 0x706F9C: vrp_evaluate_conditional (tree-vrp.c:4318) ==30523==by 0x4B6E9F: substitute_and_fold (tree-ssa-propagate.c:1053) ==30523==by 0x700F04: execute_vrp (tree-vrp.c:5318) ==30523==by 0x6F9F27: execute_one_pass (passes.c:881) ==30523==by 0x6FA08B: execute_pass_list (passes.c:932) ==30523==by 0x6FA09D: execute_pass_list (passes.c:933) ==30523==by 0x48CCCD: tree_rest_of_compilation (tree-optimize.c:463) ==30523==by 0x742363: cgraph_expand_function (cgraphunit.c:1244) ==30523==by 0x742C8D: cgraph_optimize (cgraphunit.c:1309) ==30523==by 0x4633DC: gfc_be_parse_file (f95-lang.c:307) ==30523==by 0x6DBF92: toplev_main (toplev.c:1033) as discussed in PR29975, the combination of options above is needed to trigger the bug. -- Summary: [4.2] vrp_evaluate_conditional_warnv (tree-vrp.c:4186) at -O3 -ffast-math -ftree-vectorize -march=native Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32521
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #125 from jv244 at cam dot ac dot uk 2007-06-27 14:45 --- (In reply to comment #119) Testing gcc 4.2.0 I unfortunately found that it miscompiles CP2K. filed as PR 32521 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #19 from jb at gcc dot gnu dot org 2007-06-27 14:49 --- gfortran does inline most array intrinsics, but only if the result is a scalar. For most array intrinsics this isn't that much of a problem since usually one uses the variant that returns a scalar, but MINLOC is different in that usually one wants to use the version that returns an array. If one implements this I guess it would be straightforward to replicate the solution to many other array intrinsics as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug c++/31309] g++ 4.2.0 amd64 codegen issue with -O0. 6 byte assignment at end of structure reads/writes past end of structure causing SEGV when that memory is not accessable.
--- Comment #4 from peeterj at ca dot ibm dot com 2007-06-27 14:49 --- removing Taavi from the CC list. Any update on getting this resolved? -- peeterj at ca dot ibm dot com changed: What|Removed |Added CC|taavib at ca dot ibm dot com| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug middle-end/32521] [4.2] vrp_evaluate_conditional_warnv (tree-vrp.c:4186) at -O3 -ffast-math -ftree-vectorize -march=native
--- Comment #1 from jv244 at cam dot ac dot uk 2007-06-27 14:59 --- this could be similar to PR 32006 as it had a similar valgrind trace. That bug was marked as a duplicate of another cp2k bug PR 32018 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32521
Re: [Bug target/32450] -pg seemingly causes miscompilation
When you invoke gfortran with -v march=native and with a source file, it will show the values. This is the recommended way of showing how you involved gcc/gfortran anyways. I get: f951: error: unrecognized command line option -march=native with [karma] bug/timing% gfc -v -march=native -O3 time_trans.f90 Driving: gfc -mmacosx-version-min=10.3 -v -march=native -O3 time_trans.f90 -lgfortranbegin -lgfortran -shared-libgcc Using built-in specs. Target: powerpc-apple-darwin7 Configured with: ../gcc-4.3-20070623/configure --prefix=/sw --prefix=/sw/lib/gcc4 --disable-multilib --enable-languages=c,c++,fortran,objc,java --infodir='/sw/lib/gcc4/share/info' --with-gmp=/sw --with-included-gettext --build=powerpc-apple-darwin7 --host=powerpc-apple-darwin7 --with-as=/sw/lib/odcctools/bin/as --with-ld=/sw/lib/odcctools/bin/ld --with-nm=/sw/lib/odcctools/bin/nm --with-ar=/sw/lib/odcctools/bin/ar --with-strip=/sw/lib/odcctools/bin/strip --with-ranlib=/sw/lib/odcctools/bin/ranlib Thread model: posix gcc version 4.3.0 20070622 (experimental) /sw/lib/gcc4/libexec/gcc/powerpc-apple-darwin7/4.3.0/f951 time_trans.f90 -fPIC -quiet -dumpbase time_trans.f90 -mmacosx-version-min=10.3 -march=native -auxbase time_trans -O3 -version -fintrinsic-modules-path /sw/lib/gcc4/lib/gcc/powerpc-apple-darwin7/4.3.0/finclude -o /var/tmp//ccEbNJW4.s f951: error: unrecognized command line option -march=native GNU F95 version 4.3.0 20070622 (experimental) (powerpc-apple-darwin7) compiled by GNU C version 4.3.0 20070622 (experimental), GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 without -march=native, I get karma] bug/timing% gfc -v -O3 time_trans.f90 Driving: gfc -mmacosx-version-min=10.3 -v -O3 time_trans.f90 -lgfortranbegin -lgfortran -shared-libgcc Using built-in specs. Target: powerpc-apple-darwin7 Configured with: ../gcc-4.3-20070623/configure --prefix=/sw --prefix=/sw/lib/gcc4 --disable-multilib --enable-languages=c,c++,fortran,objc,java --infodir='/sw/lib/gcc4/share/info' --with-gmp=/sw --with-included-gettext --build=powerpc-apple-darwin7 --host=powerpc-apple-darwin7 --with-as=/sw/lib/odcctools/bin/as --with-ld=/sw/lib/odcctools/bin/ld --with-nm=/sw/lib/odcctools/bin/nm --with-ar=/sw/lib/odcctools/bin/ar --with-strip=/sw/lib/odcctools/bin/strip --with-ranlib=/sw/lib/odcctools/bin/ranlib Thread model: posix gcc version 4.3.0 20070622 (experimental) /sw/lib/gcc4/libexec/gcc/powerpc-apple-darwin7/4.3.0/f951 time_trans.f90 -fPIC -quiet -dumpbase time_trans.f90 -mmacosx-version-min=10.3 -auxbase time_trans -O3 -version -fintrinsic-modules-path /sw/lib/gcc4/lib/gcc/powerpc-apple-darwin7/4.3.0/finclude -o /var/tmp//ccOSY3Yn.s GNU F95 version 4.3.0 20070622 (experimental) (powerpc-apple-darwin7) compiled by GNU C version 4.3.0 20070622 (experimental), GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 /sw/lib/odcctools/bin/as -arch ppc -o /var/tmp//ccFAndJ8.o /var/tmp//ccOSY3Yn.s /sw/lib/gcc4/libexec/gcc/powerpc-apple-darwin7/4.3.0/collect2 -dynamic -arch ppc -macosx_version_min 10.3 -multiply_defined suppress -weak_reference_mismatches non-weak -o a.out -lcrt1.o /sw/lib/gcc4/lib/gcc/powerpc-apple-darwin7/4.3.0/crt2.o /sw/lib/gcc4/lib/gcc/powerpc-apple-darwin7/4.3.0/crt3.o -L/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin7/4.3.0 -L/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin7/4.3.0/../../.. /var/tmp//ccFAndJ8.o -lgfortranbegin -lgfortran -lgcc_s.10.4 -lgcc -lSystem -lmx Dominique
[Bug middle-end/32492] [4.3 Regression] attribute always_inline - sorry, unimplemented: recursive inlining
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-06-27 15:05 --- Fixed. Sort of. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32492
Re: [Bug target/32450] -pg seemingly causes miscompilation
On 6/27/07, Dominique Dhumieres [EMAIL PROTECTED] wrote: When you invoke gfortran with -v march=native and with a source file, it will show the values. This is the recommended way of showing how you involved gcc/gfortran anyways. I get: f951: error: unrecognized command line option -march=native with [karma] bug/timing% gfc -v -march=native -O3 time_trans.f90 Driving: gfc -mmacosx-version-min=10.3 -v -march=native -O3 time_trans.f90 -lgfortranbegin -lgfortran -shared-libgcc Using built-in specs. Target: powerpc-apple-darwin7 That is because -m options are target specific and -march=native (really -mcpu=native) have not been implemented for PowerPC yet. Though it could by reading the processor description bit. -- Pinski
[Bug middle-end/32399] [4.3 Regression] ICE in build2_stat, at tree.c:3074
--- Comment #7 from falk at debian dot org 2007-06-27 15:37 ---
This makes bootstrap fail on alphaev68-linux:
/src/gcc-2007.06.27/build/./gcc/xgcc -B/src/gcc-2007.06.27/build/./gcc/
-B/usr/local/alphaev68-unknown-linux-gnu/bin/
-B/usr/local/alphaev68-unknown-linux-gnu/lib/ -isystem
/usr/local/alphaev68-unknown-linux-gnu/include -isystem
/usr/local/alphaev68-unknown-linux-gnu/sys-include -g -fkeep-inline-functions
-O2 -O2 -g -O2 -mieee -DIN_GCC-W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -fPIC -mieee -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../libgcc
-I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include -o
_gcov_execl.o -MT _gcov_execl.o -MD -MP -MF _gcov_execl.dep -DL_gcov_execl -c
../../../libgcc/../gcc/libgcov.c
../../../libgcc/../gcc/libgcov.c: In function '__gcov_execl':
../../../libgcc/../gcc/libgcov.c:838: internal compiler error: in build2_stat,
at tree.c:3074
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make[3]: *** [_gcov_execl.o] Error 1
make[3]: Leaving directory
`/src/gcc-2007.06.27/build/alphaev68-unknown-linux-gnu/libgcc'
This happens as soon as varargs are used:
$ cat test.c
void f(int x, ...) {
__builtin_va_list ap;
__builtin_va_start(ap, x);
}
$ /src/gcc-2007.06.27/build/gcc/xgcc -B/src/gcc-2007.06.27/build/gcc/ -c test.c
test.c: In function 'f':
test.c:3: internal compiler error: in build2_stat, at tree.c:3074
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
[Bug middle-end/32399] [4.3 Regression] ICE in build2_stat, at tree.c:3074
--- Comment #8 from pinskia at gmail dot com 2007-06-27 15:41 --- Subject: Re: [4.3 Regression] ICE in build2_stat, at tree.c:3074 On 27 Jun 2007 15:37:26 -, falk at debian dot org [EMAIL PROTECTED] wrote: --- Comment #7 from falk at debian dot org 2007-06-27 15:37 --- This makes bootstrap fail on alphaev68-linux: This is a different bug, related to the alpha backend was not fix up for pointer plus. Please file seperately. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
[Bug bootstrap/32522] New: Bootstrap failure on Alpha due to pointer-plus changes
src/gcc-2007.06.27/build/./gcc/xgcc -B/src/gcc-2007.06.27/build/./gcc/
-B/usr/local/alphaev68-unknown-linux-gnu/bin/
-B/usr/local/alphaev68-unknown-linux-gnu/lib/ -isystem
/usr/local/alphaev68-unknown-linux-gnu/include -isystem
/usr/local/alphaev68-unknown-linux-gnu/sys-include -g -fkeep-inline-functions
-O2 -O2 -g -O2 -mieee -DIN_GCC-W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -fPIC -mieee -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../libgcc
-I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include -o
_gcov_execl.o -MT _gcov_execl.o -MD -MP -MF _gcov_execl.dep -DL_gcov_execl -c
../../../libgcc/../gcc/libgcov.c
../../../libgcc/../gcc/libgcov.c: In function '__gcov_execl':
../../../libgcc/../gcc/libgcov.c:838: internal compiler error: in build2_stat,
at tree.c:3074
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make[3]: *** [_gcov_execl.o] Error 1
make[3]: Leaving directory
`/src/gcc-2007.06.27/build/alphaev68-unknown-linux-gnu/libgcc'
This happens as soon as varargs are used:
$ cat test.c
void f(int x, ...) {
__builtin_va_list ap;
__builtin_va_start(ap, x);
}
$ /src/gcc-2007.06.27/build/gcc/xgcc -B/src/gcc-2007.06.27/build/gcc/ -c test.c
test.c: In function 'f':
test.c:3: internal compiler error: in build2_stat, at tree.c:3074
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Apparently, the Alpha backend needs to adapt to the pointer-plus changes.
--
Summary: Bootstrap failure on Alpha due to pointer-plus changes
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
GCC build triplet: alphaev68-unknown-linux-gnu
GCC host triplet: alphaev68-unknown-linux-gnu
GCC target triplet: alphaev68-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32522
[Bug fortran/31205] aliased operator assignment produces wrong result
--- Comment #4 from pault at gcc dot gnu dot org 2007-06-27 15:56 --- (In reply to comment #2) This is related to PR 14771, most likely the parentheses are being ignored. The parentheses are being ignored - in fact they disappear completely; I presume that gfc_simplify_expr is the culprit. In addition, a temporary needs to be made for intent(out), derived types with a default initializer and the initialization applied to that, when the variable is aliassed. I note that other compilers apply the initialization in the callee, whereas gfortran leaves that duty to the caller. I think that the former is cleaner in some sense and that we should make the change. Thus, this little beauty comprises at least two bugs and should probably be three PRs:-) I propose that, for the sake of tractability, it should be left as it is. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31205
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #7 from jb at gcc dot gnu dot org 2007-06-27 15:56 --- (In reply to comment #5) I can see two ways to address this issue (both of them worth pursuing): a) For allocatable arrays, we can always assume stride=1. But this helps only locally in the procedure where the array is declared. If you call another procedure with an explicit interface, that procedure cannot assume that stride==1. I wonder, would it make sense to generate code like if (stride ==1) then some array operation, simplified for the case stride==1 else general case end if Then at least the stride==1 case could be vectorized, and presumably that is also the overwhelmingly common case. Of course it would imply some code bloat. Or is this something the middle-end could do for us? Of course, with IPA this problem could be solved by looking at all the callers.. :) b) We can tell the middle-end that our random number generator doesn't modify the array descriptor (similar to PR 20165). Once we've fixed PR 20165, this should be easy, but I don't see anybody working on it. Another question, do we at the moment tell the middle-end anything about Fortran aliasing rules? E.g. that after the call to random_number (or any other procedure) the a-data is not reachable via some other variable? Or is this another manifestation of the pointer escaping thing from PR 20165? But I would assume some support exists for C99 restrict, which is similar? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug c/32523] New: disastrous scheduling for POWER5
Hi, On the POWER5, gcc 4.2 gets roughly half the performance of gcc 3.3.3 on the best ATLAS DGEMM kernel. By throwing the flags -fno-schedule-insns -fno-rerun-loop-opt I'm able to get most of that performance back. The most important flag is the no-schedule-insns, so I suspect the scheduler was rewritten between these releases. I will append a tarfile that will build a simplified kernel so you can see the affects yourself. This kernel is simplified, so it doesn't have quite the performance of the best one, but the general trend is the same (the best kernel is way to complicated to use). One thing that you might scope out is a feature we have found on the PowerPC970FX (the direct decendent of the POWER5): I went from 69% of peak to 85% by scheduling like instructions in sets of 4 (i.e. do 4 loads, then 4 fmacs, etc, even when this hurts advancing loads). Instruction alignment is also important on this architecture, despite it being putatitively RISC. I think both these features are results of it's complicated front-end, which does something similar to RISC-to-VLIW translation on the fly. I suspect the sets-of-4 rule helps in tracking the groups, but I don't know for sure . . . This scheduling seems to hurt the POWER4 only slightly. I have been trying to install gcc 4.2 on PowerPC970FX, but so far no luck (it doesn't seem to like MacOSX). I will let you know if I get results for the PowerPC970FX. Let me know if there is something else you need. Cheers, Clint -- Summary: disastrous scheduling for POWER5 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: whaley at cs dot utsa dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32523
[Bug c/32523] disastrous scheduling for POWER5
--- Comment #1 from whaley at cs dot utsa dot edu 2007-06-27 16:21 --- Created an attachment (id=13794) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13794action=view) Makefile and source demonstrating problem Creates directory MMBENCH_PPC. Edit the Makefile and set GCC3 and GCC4 macros, and the do make all to see performance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32523
[Bug target/32523] disastrous scheduling for POWER5
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-27 16:25 --- PowerPC970FX is not a direct descendent of Power5. It is a descendent of the 970 which is a heavily modified Power4. Power5 is the direct descendent of the Power4 though, at least in terms of scheduling (I don't know if in terms of the hardware itself). So at best they are siblings rather than descendents of one another. The main thing is that you turned off the first scheduling pass which is before the register allocator so I think the case is the register allocator is messing up (which is already known). The other thing is what options are you using to invoke GCC with? Power5 support inside GCC was not added until at least 3.4 (maybe it was 4.0). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32523
[Bug target/32523] disastrous scheduling for POWER5
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-27 16:27 --- I have been trying to install gcc 4.2 on PowerPC970FX, but so far no luck (it doesn't seem to like MacOSX). I have no problems installing GCC on Mac OS X 10.4.8/9/10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32523
[Bug c/32493] gcc-20070624 fails linux-kernel due to changed gcc-inlining
--- Comment #3 from malitzke at metronets dot com 2007-06-27 16:44 --- I read that the last word ___unfortunate___ means that to hell with the users; We hold fast to our principles So now we have two cases that gcc-4.3.x pretty irrelevant. The is that inane transformation of subtraction in a division (the udivdi3 case) and now this one. Well, there exist three paths open to the user community: 1) The blas-atlas that just termed the whole gcc-3.x.y unusable for their purposes. 2) The xfree86-xorg fork. It might be instructive to check the top 25 distribution as ranked by Distrowatch as to who still uses xfree86 in the table of packages used by each distribution (just click on the name of the distribution in the right hand collunm). They all use xorg; but check for yourself. Personally I might be persuaded to in forming such a group. 3) Somebody with greater perspective might read the introduction to rationale for International Standard Programming Languages C revison 5.10, April-2003 (google C99 std rationale) and draw appropriate conclusion. BTW doesn't the the reduced case make into confirmed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32493
[Bug c/32524] New: unable to build 4.2 on OS X G5
Hi, I successfully installed gcc 4.1.1 on the same machine, but can't seem to get gcc 4.2 to go. My install always dies with the following error message during the compile phase: /usr/bin/libtool: unknown option character `m' in: -macosx_version_min Here's my configure command (using mpfr and gmp I installed for 4.1.1): ../configure --prefix=/home/whaley/local/gcc-4.2 --with-gmp=/home/whaley/local/ --with-mpfr=/home/whaley/local --enable-languages=c Can anyone give me a pointer on what I'm doing wrong, assuming the problem is on my end? I include a more substantial snip of my bad install below. Here's the output of uname -a: Darwin etl-g52.cs.utsa.edu 8.9.0 Darwin Kernel Version 8.9.0: Thu Feb 22 20:54:07 PST 2007; root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh powerpc Thanks, Clint | /Users/whaley/TEST/gcc-4.2.0/MyObj/./gcc/xgcc -B/Users/whaley/TEST/gcc-4.2.0/MyObj/./gcc/ -B/home/whaley/local/gcc-4.2/powerpc-apple-darwin8.9.0/bin/ -B/home/whaley/local/gcc-4.2/powerpc-apple-darwin8.9.0/lib/ -isystem /home/whaley/local/gcc-4.2/powerpc-apple-darwin8.9.0/include -isystem /home/whaley/local/gcc-4.2/powerpc-apple-darwin8.9.0/sys-include -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include -I/home/whaley/local//include -I/home/whaley/local/include -I../../gcc/../libdecnumber -I../libdecnumber -E -xassembler-with-cpp -; \ } | gawk -f ../../gcc/mkmap-flat.awk -v leading_underscore=1 libgcc/./tmp-libgcc.map mv 'libgcc/./tmp-libgcc.map' libgcc/./libgcc.map /Users/whaley/TEST/gcc-4.2.0/MyObj/./gcc/xgcc -B/Users/whaley/TEST/gcc-4.2.0/MyObj/./gcc/ -B/home/whaley/local/gcc-4.2/powerpc-apple-darwin8.9.0/bin/ -B/home/whaley/local/gcc-4.2/powerpc-apple-darwin8.9.0/lib/ -isystem /home/whaley/local/gcc-4.2/powerpc-apple-darwin8.9.0/include -isystem /home/whaley/local/gcc-4.2/powerpc-apple-darwin8.9.0/sys-include -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -dynamiclib -nodefaultlibs -Wl,-install_name,/home/whaley/local/gcc-4.2/lib/libgcc_s`if test . = ppc64 ; then echo _. ; fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp -Wl,-exported_symbols_list,libgcc/./libgcc.map -compatibility_version 1 -current_version 1.0 libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunsxfsi_s.o libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_floatdisf_s.o libgcc/./_floatundisf_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunsdfdi_s.o libgcc/./_floatdidf_s.o libgcc/./_floatundidf_s.o libgcc/./_fixxfdi_s.o libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_floatundixf_s.o libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o libgcc/./_floatunditf_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o libgcc/./darwin-tramp_s.o libgcc/./ppc64-fp_s.o libgcc/./darwin-64_s.o libgcc/./darwin-ldouble_s.o libgcc/./darwin-world_s.o libgcc/./unwind-dw2_s.o libgcc/./unwind-dw2-fde-darwin_s.o libgcc/./unwind-sjlj_s.o libgcc/./unwind-c_s.o libgcc/./darwin-fallback_s.o -lc /usr/bin/libtool: unknown option character `m' in: -macosx_version_min Usage: /usr/bin/libtool -static [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-sacLT] Usage: /usr/bin/libtool -dynamic [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-o output] [-install_name name] [-compatibility_version #] [-current_version #] [-seg1addr 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#]
[Bug target/32524] unable to build 4.2 on OS X G5
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-27 16:48 --- /usr/bin/libtool: unknown option character `m' in: -macosx_version_min You need to make sure you have the latest version of Xcode installed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32524
[Bug c/32523] disastrous scheduling for POWER5
--- Comment #4 from whaley at cs dot utsa dot edu 2007-06-27 17:00 --- Andrew, PowerPC970FX is not a direct descendent of Power5 Sorry, completely misremembered this. Since Power4 didn't suffer as bad as Power5 (I think it lost maybe 10% rather than 50), maybe the 970 will also not die. so I think the case is the register allocator is messing up (which is already known) OK, can you point me to the bug report? Is there some way to confirm this is the problem, rather than the scheduling pass itself? The other thing is what options are you using to invoke GCC with? My Makefile shows them. The gcc3-derived flags are: -mcpu=power5 -mtune=power5 -O3 -m64 for gcc4, I get most of my performance back if I add: -fno-schedule-insns -fno-rerun-loop-opt I include below example output and arch info on the machine I created the benchmark on (forgot to include it before, sorry). Thanks, Clint r78n04 noibm122/TEST uname -a Linux r78n04 2.6.5-7.244-pseries64 #1 SMP Mon Dec 12 18:32:25 UTC 2005 ppc64 ppc64 ppc64 GNU/Linux r78n04 noibm122/TEST /usr/bin/gcc -v Reading specs from /usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/specs Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada --disable-checking --libdir=/usr/lib --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --host=powerpc-suse-linux --build=powerpc-suse-linux --target=powerpc-suse-linux --enable-targets=powerpc64-suse-linux --enable-biarch Thread model: posix gcc version 3.3.3 (SuSE Linux) r78n04 noibm122/TEST gcc -v Using built-in specs. Target: powerpc64-unknown-linux-gnu Configured with: ../configure --prefix=/home/whaley/local/linux --enable-languages=c --with-gmp=/u/noibm122/local/linux --with-mpfr-lib=/u/noibm122/local/linux/lib --with-mpfr-include=/u/noibm122/local/linux/include Thread model: posix gcc version 4.2.0 r78n04 TEST/MMBENCH_PPC make all /usr/bin/gcc -DREPS=1000 -DWALL -mcpu=power5 -mtune=power5 -O3 -m64 -c mmbench.c /usr/bin/gcc -DREPS=1000 -DWALL -mcpu=power5 -mtune=power5 -O3 -m64 -c dgemm_atlas.c /usr/bin/gcc -DREPS=1000 -DWALL -mcpu=power5 -mtune=power5 -O3 -m64 -o xdmm_gcc3 mmbench.o dgemm_atlas.o rm -f *.o /u/noibm122/local/linux/home/whaley/local/linux/bin/gcc -DREPS=1000 -DWALL -mcpu=power5 -mtune=power5 -O3 -m64 -c mmbench.c /u/noibm122/local/linux/home/whaley/local/linux/bin/gcc -DREPS=1000 -DWALL -mcpu=power5 -mtune=power5 -O3 -m64 -c dgemm_atlas.c /u/noibm122/local/linux/home/whaley/local/linux/bin/gcc -DREPS=1000 -DWALL -mcpu=power5 -mtune=power5 -O3 -m64 -o xdmm_gcc4 mmbench.o dgemm_atlas.o rm -f *.o /u/noibm122/local/linux/home/whaley/local/linux/bin/gcc -DREPS=1000 -DWALL -mcpu=power5 -mtune=power5 -O3 -m64 -c mmbench.c /u/noibm122/local/linux/home/whaley/local/linux/bin/gcc -DREPS=1000 -DWALL -mcpu=power5 -mtune=power5 -O3 -m64 -fno-schedule-insns -fno-rerun-loop-opt -c \ dgemm_atlas.c /u/noibm122/local/linux/home/whaley/local/linux/bin/gcc -DREPS=1000 -DWALL -mcpu=power5 -mtune=power5 -O3 -m64 -o xdmm_gcc4_nosched mmbench.o dgemm_atlas.o rm -f *.o echo GCC 3.x performance: GCC 3.x performance: ./xdmm_gcc3 ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 40 1000 0.026 4998.24 echo GCC 4.2 performance: GCC 4.2 performance: ./xdmm_gcc4 ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 40 1000 0.034 3806.35 echo GCC 4.2 w/o scheduling performance: GCC 4.2 w/o scheduling performance: ./xdmm_gcc4_nosched ALGORITHM NB REPSTIME MFLOPS = = = == == atlasmm 40 1000 0.025 5044.53 -- whaley at cs dot utsa dot edu changed: What|Removed |Added Component|target |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32523
[Bug target/32523] disastrous scheduling for POWER5
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-27 17:05 --- Well the 3.3.3 you are using is a heavy modified 3.3.3 which has the power5 backported and many other stuff. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32523
[Bug middle-end/32493] [4.3 Regression] Fails to inline varargs function with unused arguments
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-27 17:22 --- Sure it does. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Known to work||4.2.0 Last reconfirmed|-00-00 00:00:00 |2007-06-27 17:22:59 date|| Summary|gcc-20070624 fails linux- |[4.3 Regression] Fails to |kernel due to changed gcc- |inline varargs function with |inlining|unused arguments Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32493
[Bug target/32418] [4.3 Regression] ICE in global_alloc, at global.c:514
--- Comment #15 from zadeck at naturalbridge dot com 2007-06-27 18:04 --- it does not look like you ever dealt with the issue of EH_RETURN_STACKADJ_RTX that i pointed out. That code is clearly wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug middle-end/32493] [4.3 Regression] Fails to inline varargs function with unused arguments
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-27 18:07 --- I could thought we never inlined varargs even in 4.2.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||missed-optimization, ||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32493
[Bug c++/32525] New: Request for new warning: useless dynamic_casts
It might be useful for GCC to warn about dynamic_casts which are not necessary.
For instance a dynamic_castT*(T*), or a dynamic_cast from a derived class to
a base class (there might be some corner cases here with multiple
inheritance?). I do see that such dynamic_casts are no-op'ed away (even without
any optimization flags! (at least in my toy test program)), which is certainly
positive. However it would be nice if the programmer was notified about them,
since even if there is no run-time cost, there is a source-level increase in
complexity which can easily be avoided (and there may well be run-time costs
involved with other compilers).
A quick example of the sort of thing I have in mind:
class base
{
public:
virtual int f() = 0;
virtual ~base() {}
};
class derived : public base
{
public:
int f() { return 1; }
};
#include stdio.h
int main()
{
derived* obj = new derived();
base* baseptr = dynamic_castbase*(obj); // warn: to a base class
derived* sametype = dynamic_castderived*(obj); // warn: same type
derived* from_base = dynamic_castderived*(baseptr); // ok
printf(%d %d %d %d\n,
obj-f(), baseptr-f(), sametype-f(), from_base-f());
}
(Compiling this on x86-64 shows GCC 4.1.0 is no-op'ing the first two
dynamic_casts, with or without optimization).
--
Summary: Request for new warning: useless dynamic_casts
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32525
[Bug c++/32525] Request for new warning: useless dynamic_casts
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-27 18:14 ---
However it would be nice if the programmer was notified about them,
since even if there is no run-time cost, there is a source-level increase in
complexity which can easily be avoided (and there may well be run-time costs
involved with other compilers).
If this warning comes into GCC, we should disable it for templates. The main
reason why I say that is because if you do:
templatetypename A, typename B
A* f(B *b)
{
return dynamic_castA*(b);
}
And then instanitite it where typename A == typename B, it is hard to avoid the
warning in this case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32525
[Bug target/32481] ICE in df_refs_verify, at df-scan.c:4058
--- Comment #10 from spark at gcc dot gnu dot org 2007-06-27 18:17 --- Subject: Bug 32481 Author: spark Date: Wed Jun 27 18:17:15 2007 New Revision: 126058 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126058 Log: 2007-06-27 Seongbae Park [EMAIL PROTECTED] PR rtl-optimization/32481 * combine.c (adjust_for_new_dest): Rescan the changed insn. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32481
[Bug middle-end/32521] [4.2] vrp_evaluate_conditional_warnv (tree-vrp.c:4186) at -O3 -ffast-math -ftree-vectorize -march=native
--- Comment #2 from jv244 at cam dot ac dot uk 2007-06-27 18:33 --- Reduced testcase: [EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/obj/Linux-x86-64-gfortran/sopt cat test.f90 SUBROUTINE build_qs_neighbor_lists() INTEGER, PARAMETER :: dp=KIND(0.0D0) REAL(dp), ALLOCATABLE, DIMENSION(:) :: c_radius INTEGER :: nkind,istat REAL(dp) :: alpha ALLOCATE (c_radius(nkind),STAT=istat) IF (istat /= 0) CALL stop_memory() c_radius = 0.5_dp*SQRT(-LOG(3.5_dp*alpha**3*1.e-12_dp))/alpha END SUBROUTINE build_qs_neighbor_lists valgrind --tool=memcheck /data03/vondele/gcc_4_2_0/build/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951 test.f90 -march=k8 -mtune=k8 -quiet -dumpbase test.f90 -auxbase qs_neighbor_lists -O3 -version -ffast-math -ftree-vectorize -I /data03/vondele/gcc_4_2_0/build/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude ==3990== Memcheck, a memory error detector. ==3990== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==3990== Using LibVEX rev 1732, a library for dynamic binary translation. ==3990== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==3990== Using valgrind-3.2.3, a dynamic binary instrumentation framework. ==3990== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==3990== For more details, rerun with: -v ==3990== GNU F95 version 4.2.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.2.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ==3990== Conditional jump or move depends on uninitialised value(s) ==3990==at 0x706E08: vrp_evaluate_conditional_warnv (tree-vrp.c:4186) ==3990==by 0x706F9C: vrp_evaluate_conditional (tree-vrp.c:4318) ==3990==by 0x4B6E9F: substitute_and_fold (tree-ssa-propagate.c:1053) ==3990==by 0x700F04: execute_vrp (tree-vrp.c:5318) ==3990==by 0x6F9F27: execute_one_pass (passes.c:881) ==3990==by 0x6FA08B: execute_pass_list (passes.c:932) ==3990==by 0x6FA09D: execute_pass_list (passes.c:933) ==3990==by 0x48CCCD: tree_rest_of_compilation (tree-optimize.c:463) ==3990==by 0x742363: cgraph_expand_function (cgraphunit.c:1244) ==3990==by 0x742C8D: cgraph_optimize (cgraphunit.c:1309) ==3990==by 0x4633DC: gfc_be_parse_file (f95-lang.c:307) ==3990==by 0x6DBF92: toplev_main (toplev.c:1033) ==3990== -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32521
[Bug middle-end/32096] [4.3 Regression] ICE (segfault) in vrp_evaluate_conditional_warnv
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32096
[Bug c++/32525] Request for new warning: useless dynamic_casts
--- Comment #2 from bangerth at dealii dot org 2007-06-27 18:53 --- This strikes me as one of the things that hardly anybody would ever find useful. I mean, yes it happens, but no, it doesn't hurt, and I haven't seen such code written in the first place ever. Warnings are for cases where either code may not do what you expect, or where a certain way of coding has a significant cost that can be avoided. I doubt anyone will ever implement this. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32525
[Bug middle-end/32521] [4.2] vrp_evaluate_conditional_warnv (tree-vrp.c:4186) at -O3 -ffast-math -ftree-vectorize -march=native
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-27 18:54 --- This was fixed in 4.2.1 already by: 2007-05-30 Ralf Wildenhues [EMAIL PROTECTED] * tree-vrp.c (compare_names): Initialize sop. Which was applied for PR 32096. *** This bug has been marked as a duplicate of 32096 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32521
[Bug middle-end/32096] [4.3 Regression] ICE (segfault) in vrp_evaluate_conditional_warnv
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-27 18:54 --- *** Bug 32521 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32096
[Bug c++/32519] [4.1/4.2/4.3 regression] g++ allows access to protected template member functions of base class
--- Comment #1 from bangerth at dealii dot org 2007-06-27 19:01 --- Confirmed, a regression apparently introduced in 3.4.x. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Known to fail||3.4.3 4.1.0 Known to work||2.95.3 3.2.3 3.3.6 Last reconfirmed|-00-00 00:00:00 |2007-06-27 19:01:01 date|| Summary|g++ allows access to|[4.1/4.2/4.3 regression] g++ |protected template member |allows access to protected |functions of base class |template member functions of ||base class Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32519
[Bug c++/32525] Request for new warning: useless dynamic_casts
--- Comment #3 from lloyd at randombit dot net 2007-06-27 19:06 --- I haven't seen such code written in the first place ever. Neither had I, until I found out it is endemic in a large project at work. I'd just as soon write a script to find these cases, but figuring out what the type of the casted-from pointer/reference is can be somewhat nontrivial. Warnings are for cases where either code may not do what you expect, or where a certain way of coding has a significant cost that can be avoided. I think that's a good definition. My impression is that dynamic_cast is fairly expensive, and while it is great that GCC noops out this case I suspect not all compilers will do the same; at this point I'm not even sure that GCC does it consistently. So I'd figure it a reasonable case for a warning as per your second condition. I doubt anyone will ever implement this. I've gotten used to that. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32525
[Bug target/32523] disastrous scheduling for POWER5
--- Comment #6 from whaley at cs dot utsa dot edu 2007-06-27 19:09 --- Andrew, OK, I installed stock gnu gcc 3.4.6: 78n04 TEST/MMBENCH_PPC ~/local/gcc-3.4.6/bin/gcc -v Reading specs from /u/noibm122/local/gcc-3.4.6/lib/gcc/powerpc64-unknown-linux-gnu/3.4.6/specs Configured with: ../configure --prefix=/u/noibm122/local/gcc-3.4.6 --enable-languages=c Thread model: posix gcc version 3.4.6 and I get the exact same behavior as with the modified gcc 3 (it accepts the power5 flags and everything). So, it would seem something that used to work in the stock gcc is now broken . . . Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32523
[Bug fortran/32526] New: Spurious error: Name 'x' at (1) is an ambiguous reference to 'x' from module 'y'
When I compile the modules listed below I get the following error message: e.f90:51.30: use poly_Personnel_class 1 Error: Name 'new' at (1) is an ambiguous reference to 'new' from module 'student_class' Compaq Fortran, Lahey Fortran, and g95 do not produce an error. module Personnel_class implicit none private :: init_Personnel interface new module procedure init_Personnel end interface contains subroutine init_Personnel(this) integer, intent (in) :: this end subroutine init_Personnel end module Personnel_class module Student_class use Personnel_class implicit none private :: init_Student type Student private integer :: personnel end type Student interface new module procedure init_Student end interface contains subroutine init_Student(this) type (Student), intent (in) :: this call new(this%personnel) end subroutine init_Student end module Student_class module Teacher_class use Personnel_class implicit none private :: init_Teacher type Teacher private integer :: personnel end type Teacher interface new module procedure init_Teacher end interface contains subroutine init_Teacher(this) type (Teacher), intent (in) :: this call new(this%personnel) end subroutine init_Teacher end module Teacher_class module poly_Personnel_class use Student_class use Teacher_class end module poly_Personnel_class module Database_class use poly_Personnel_class end module Database_class -- Summary: Spurious error: Name 'x' at (1) is an ambiguous reference to 'x' from module 'y' Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32526
[Bug target/32418] [4.3 Regression] ICE in global_alloc, at global.c:514
--- Comment #16 from rask at sygehus dot dk 2007-06-27 19:15 ---
What's wrong with the patch at the top of comment 9? FWIW, I can now build the
m32c after this configure command:
$ /n/12/rask/src/all/configure --target=m32c-unknown-elf
--enable-languages=c,c++ --enable-cxx-flags=-O2 --with-newlib --enable-sim
--disable-{multilib,nls,gdb}
where --disable-multilib is due to bug 32441 and --enable-cxx-flags=-O2 hides
the unrelated reload failure in comment 9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug c++/32525] Request for new warning: useless dynamic_casts
--- Comment #4 from bangerth at dealii dot org 2007-06-27 19:17 --- (In reply to comment #3) I think that's a good definition. My impression is that dynamic_cast is fairly expensive, But only if the compiler can't know the actual type of an object (which is exactly the case that you want to treat). If the actual type of an object is known or if you are casting to a base class, dynamic_cast is as cheap as static_cast. I doubt anyone will ever implement this. I've gotten used to that. :) Well, people implement what they consider important to them. PRs about uninteresting things will lie dormant until there are no interesting things left to implement. I think everyone's time would be better used if you tried to find cases where gcc doesn't produce a no-op for the constructs you want to warn about. That would be a missed-optimization, rather than a more or less uninteresting warning, and would receive more interest. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32525
[Bug rtl-optimization/32466] illegal loop store motion of bitfield
--- Comment #2 from mrs at apple dot com 2007-06-27 19:18 --- Radar 5276895 -- mrs at apple dot com changed: What|Removed |Added CC||mrs at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32466
[Bug target/32418] [4.3 Regression] ICE in global_alloc, at global.c:514
--- Comment #17 from zadeck at naturalbridge dot com 2007-06-27 19:30
---
Subject: Re: [4.3 Regression] ICE in global_alloc, at global.c:514
rask at sygehus dot dk wrote:
--- Comment #16 from rask at sygehus dot dk 2007-06-27 19:15 ---
What's wrong with the patch at the top of comment 9? FWIW, I can now build the
m32c after this configure command:
$ /n/12/rask/src/all/configure --target=m32c-unknown-elf
--enable-languages=c,c++ --enable-cxx-flags=-O2 --with-newlib --enable-sim
--disable-{multilib,nls,gdb}
where --disable-multilib is due to bug 32441 and --enable-cxx-flags=-O2 hides
the unrelated reload failure in comment 9.
i am sorry for being dense. but i have completely lost track of this bug.
if i pull the latest code down from the trunk, this patch is not there.
Is there still a bug related to dataflow on this platform if everything
that needs to be done has been done?
Kenny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug c++/32525] Request for new warning: useless dynamic_casts
--- Comment #5 from lloyd at randombit dot net 2007-06-27 19:33 --- I filed the bug because it seems like this would be at least marginally useful, and this way people can find it / read the discussion / whatever. Even if the end result is WONTFIX, that at least lets anyone in the future who searches the bug database know what the situation is. I'm sorry if I made it sound like I was expecting this to be implemented immediately or anything like that. That is not the case at all; even serious problems like code miscompilations can go a good while without being analyzed or fixed due to time and resource constraints, and something like this naturally falls much (much) deeper into the queue of things to work on. Thus my comment about being used to it, I know there is are many more interesting/important things to work on in GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32525
[Bug target/32418] [4.3 Regression] ICE in global_alloc, at global.c:514
--- Comment #18 from rask at sygehus dot dk 2007-06-27 19:48 --- It has not been committed yet because I feared that it was causing the reload failure. I have now verified that the reload failure still happens with a pre-dataflow checkout, so I'll submit the patch. I think that concludes the dataflow related changes. -- rask at sygehus dot dk changed: What|Removed |Added BugsThisDependsOn|32441 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug c++/27492] [4.0/4.1/4.2 regression] ICE on invalid covariant return type
--- Comment #7 from simartin at gcc dot gnu dot org 2007-06-27 19:53 --- Subject: Bug 27492 Author: simartin Date: Wed Jun 27 19:53:45 2007 New Revision: 126061 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126061 Log: gcc/cp/ 2007-06-27 Simon Martin [EMAIL PROTECTED] PR c++/27492 * decl.c (duplicate_decls): Don't reset DECL_INVALID_OVERRIDER_P for function decls. gcc/testsuite/ 2007-06-27 Simon Martin [EMAIL PROTECTED] PR c++/27492 * g++.dg/inherit/covariant15.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/inherit/covariant15.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/decl.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27492
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #126 from jv244 at cam dot ac dot uk 2007-06-27 19:55 --- As Andrew pointed out in PR 32521 the valgrind warning was fixed in 4.2.1 (prerelease). I've now built the 4.2_branch, and the warning is indeed gone, but unfortunately the same qs_neighbor_lists module is still miscompiled (i.e. same wrong answers obtained from 4.2_branch). The fact that the miscompilation is now completely silent makes it a bit harder to find I'm afraid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug target/32418] [4.3 Regression] ICE in global_alloc, at global.c:514
--- Comment #19 from zadeck at naturalbridge dot com 2007-06-27 19:56 --- Subject: Re: [4.3 Regression] ICE in global_alloc, at global.c:514 rask at sygehus dot dk wrote: --- Comment #18 from rask at sygehus dot dk 2007-06-27 19:48 --- It has not been committed yet because I feared that it was causing the reload failure. I have now verified that the reload failure still happens with a pre-dataflow checkout, so I'll submit the patch. I think that concludes the dataflow related changes. thanks, this was what i suspected. kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug c++/27492] [4.0/4.1 regression] ICE on invalid covariant return type
--- Comment #8 from simartin at gcc dot gnu dot org 2007-06-27 19:59 --- Fixed in 4.2 as well. -- simartin at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE on |on invalid covariant return |invalid covariant return |type|type http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27492
[Bug fortran/32467] structure containing allocatable array is accepted in COPYIN clause
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-06-27 20:03 --- Subject: Bug 32467 Author: dfranke Date: Wed Jun 27 20:02:31 2007 New Revision: 126063 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126063 Log: gcc/fortran: 2007-06-24 Daniel Franke [EMAIL PROTECTED] PR fortran/32467 * openmp.c (resolve_omp_clauses): Emit error on allocatable components in COPYIN, COPYPRIVATE, FIRSTPRIVATE and LASTPRIVATE clauses. gcc/testsuite: 2007-06-24 Daniel Franke [EMAIL PROTECTED] PR fortran/32467 * gfortran.dg/gomp/allocatable_components_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/allocatable_components_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/openmp.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32467
[Bug fortran/32467] structure containing allocatable array is accepted in COPYIN clause
--- Comment #9 from dfranke at gcc dot gnu dot org 2007-06-27 20:04 --- Fixed in trunk. Not a regression, thus no backport to 4.2. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Keywords|wrong-code |accepts-invalid Known to fail|4.2.1 4.3.0 |4.2.1 Known to work||4.3.0 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32467
[Bug fortran/32526] Spurious error: Name 'x' at (1) is an ambiguous reference to 'x' from module 'y'
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-27 20:10 --- Which version of gfortran and which flags are you using? I tried 4.1.2, 4.2 and a recent svn (20070622), neither gave the error on the code you quote. All I get is: $ gfortran-svn -g -Wall -std=f95 -c pr32526.f90 pr32526.f90:8.39: subroutine init_Personnel(this) 1 Warning: Unused variable this declared at (1) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32526
[Bug target/32418] [4.3 Regression] ICE in global_alloc, at global.c:514
--- Comment #20 from zadeck at naturalbridge dot com 2007-06-27 20:15 --- I believe that rask is going to submit the patch at the end of comment #9 to close this bug. -- zadeck at naturalbridge dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug fortran/32526] Spurious error: Name 'x' at (1) is an ambiguous reference to 'x' from module 'y'
--- Comment #2 from mrichmond at mscmail dot gsfc dot nasa dot gov 2007-06-27 20:21 --- Subject: RE: Spurious error: Name 'x' at (1) is an ambiguous reference to 'x' from module 'y' I downloaded the latest snapshot. The bug does not occur with older versions, so I believe it is a regression from a recent fix. --- Original Message --- From: dfranke at gcc dot gnu dot org[mailto:[EMAIL PROTECTED] Sent: 6/27/2007 4:10:15 PM To : [EMAIL PROTECTED] Cc : Subject : RE: [Bug fortran/32526] Spurious error: Name 'x' at (1) is an ambiguous reference to 'x' from module 'y' --- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-27 20:10 --- Which version of gfortran and which flags are you using? I tried 4.1.2, 4.2 and a recent svn (20070622), neither gave the error on the code you quote. All I get is: $ gfortran-svn -g -Wall -std=f95 -c pr32526.f90 pr32526.f90:8.39: subroutine init_Personnel(this) 1 Warning: Unused variable this declared at (1) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32526 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32526
[Bug fortran/32527] New: [Optimization] ICE in build2_stat, at tree.c:3074
Hi, the attached file crashes gfortran when compiling with -O and -Os, but passes with -O0, -O2 and -O3. % gfortran -O -c gfcbug65.f90 gfcbug65.f90: In function 'nf90_put_var_7d_fourbyteint': gfcbug65.f90:1: internal compiler error: in build2_stat, at tree.c:3074 ... -- Summary: [Optimization] ICE in build2_stat, at tree.c:3074 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32527
[Bug middle-end/32493] [4.3 Regression] Fails to inline varargs function with unused arguments
--- Comment #6 from malitzke at metronets dot com 2007-06-27 20:43 --- This appears to be the essence of what I wanted note per 3) in comment 3 In going from pdf to html via pdftohtml I was forced to do some realigning and erase special symbols by hand. If you do not trust go to the actual document. If this is what bound the standardization committee it is certainly binding on myself the GCC apparently feels differently. The Xfree86-xorg inspires me to believe that reason will prevail one way or another. The original X3J11 charter clearly mandated codifying common existing practice, and the C89 Committee held fast to precedent wherever that was clear and unambiguous. The vast majority of the language defined by C89 was precisely the same as defined in Appendix A of the first edition of The C Programming Language by Brian Kernighan and Dennis Ritchie, and as was implemented in almost all C translators of the time. (That document is hereinafter referred to asKR.) KR was not the only source of existing practice. Much work had been done over the years to improve the C language by addressing its weaknesses, and the C89 Committee formalized enhancements of proven value which had become part of the various dialects of C. This practice has continued in the present Committee. Existing practice, however, has not always been consistent. Various dialects of C have approached problems in different and sometimes diametrically opposed ways. This divergence has happened for several reasons. First, KR, which once served as the language specification for almost all C translators, is imprecise in some areas (thereby allowing divergent interpretations), and it does not address some issues (such as a complete specification of a library) important for code portability. Second, as the language has matured over the years, various extensions have been added in different dialects to address limitations and weaknesses of the language; but these extensions have not been consistent across dialects. One of the C89 Committee's goals was to consider such areas of divergence and to establish a set of clear, unambiguous rules consistent with the rest of the language. This effort included the consideration of extensions made in various C dialects, the specification of a complete set of required library functions, and the development of a complete, correct syntax for C. Much of the Committee's work has always been in large part a balancing act. The C89 Committee tried to improve portability while retaining the definition of certain features of C as machine-dependent, it attempted to incorporate valuable new ideas without disrupting the basic structure and fabric of the language, and it tried to develop a clear and consistent language without invalidating existing programs. All of the goals were important and each decision was weighed in the light of sometimes contradictory requirements in an attempt to reach a workable compromise. In specifying a standard language, the C89 Committee used several principles which continue to guide our deliberations today. The most important of these are: Existing code is important, existing implementations are not. A large body of C code exists of considerable commercial value. Every attempt has been made to ensure that the bulk of this code will be acceptable to any implementation conforming to the Standard. The C89 Committee did not want to force most programmers to modify their C programs just to have them accepted by a conforming translator. On the other hand, no one implementation was held up as the exemplar by which to define C. It was assumed that all existing implementations must change somewhat to conform to the Standard. C code can be portable. Although the C language was originally born with the UNIX operating system on the PDP-11, it has since been implemented on a wide variety of computers and operating systems. It has also seen considerable use in cross-compilation of code for embedded systems to be executed in a free-standing environment. The C89 Committee attempted to specify the language and the library to be as widely implementable as possible, while recognizing that a system must meet certain minimum criteria to be considered a viable host or target for the language. C code can be non-portable. Although it strove to give programmers the opportunity to write truly portable programs, the C89 Committee did not want to force programmers into writing portably, to preclude the use of C as a high-level assembler: the ability to write machine-specific code is one of the strengths of C. It is this principle which largely motivates drawing the distinction between strictly conforming program and conforming program . Avoid quiet changes. Any change to widespread practice altering the meaning of existing code causes problems. Changes that cause code to be so ill-formed as to require diagnostic messages are at least easy to detect. As much as seemed possible consistent with
[Bug fortran/32527] [Optimization] ICE in build2_stat, at tree.c:3074
--- Comment #1 from anlauf at gmx dot de 2007-06-27 20:44 --- Created an attachment (id=13795) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13795action=view) Demo code, extracted from netcdf-3.6.1 Compile with -O or -Os -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32527
[Bug middle-end/32493] [4.3 Regression] Fails to inline varargs function with unused arguments
--- Comment #7 from rguenther at suse dot de 2007-06-27 20:50 --- Subject: Re: [4.3 Regression] Fails to inline varargs function with unused arguments On Wed, 27 Jun 2007, malitzke at metronets dot com wrote: --- Comment #6 from malitzke at metronets dot com 2007-06-27 20:43 --- [lots of irrelevant stuff snipped] You should save yourself the time writing all this stuff. The development trunk of GCC is a moving target, there are (and will be) bugs popping up and going. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32493
[Bug fortran/32526] [4.3 regression] Spurious error: Name 'x' at (1) is an ambiguous reference to 'x' from module 'y'
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-06-27 21:05 --- Confirmed after updating to 20070627 (r126063). Most likely introduced by: r126000 | pault | 2007-06-25 20:27:59 +0200 (Mo, 25 Jun 2007) | 21 lines (r125988 still works and r126005 gives the error). Adding Paul as CC. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.3.0 Known to work||4.2.1 Last reconfirmed|-00-00 00:00:00 |2007-06-27 21:05:26 date|| Summary|Spurious error: Name 'x' at |[4.3 regression] Spurious |(1) is an ambiguous |error: Name 'x' at (1) is an |reference to 'x' from module|ambiguous reference to 'x' |'y' |from module 'y' http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32526
[Bug tree-optimization/32527] [4.3 Regression] ICE in build2_stat, at tree.c:3074
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-27 21:07 ---
#0 internal_error (gmsgid=0x8757d7f in %s, at %s:%d) at
/home/apinski/src/gcc-fsf/work/gcc/gcc/diagnostic.c:596
#1 0x0816ae5f in fancy_abort (file=Could not find the frame base for
fancy_abort.
) at /home/apinski/src/gcc-fsf/work/gcc/gcc/diagnostic.c:656
#2 0x0848f810 in build2_stat (code=MULT_EXPR, tt=0xb7ce5d80, arg0=0xb7d9b6c0,
arg1=0xb7d983b8) at /home/apinski/src/gcc-fsf/work/gcc/gcc/tree.c:3074
#3 0x086a8cdf in aff_combination_scale (comb=0xbfca537c, scale={low = 4, high
= 0}) at /home/apinski/src/gcc-fsf/work/gcc/gcc/tree-affine.c:122
#4 0x086a9651 in tree_to_aff_combination (expr=0xb7d9caf8, type=0xb7ce5d80,
comb=0xbfca537c) at /home/apinski/src/gcc-fsf/work/gcc/gcc/tree-affine.c:304
#5 0x086a914a in tree_to_aff_combination (expr=0xb7d9b160, type=0xb7ce5d80,
comb=0xbfca560c) at /home/apinski/src/gcc-fsf/work/gcc/gcc/tree-affine.c:337
#6 0x083f2e7d in get_computation_aff (loop=0xb7d8b508, use=Variable use is
not available.
) at /home/apinski/src/gcc-fsf/work/gcc/gcc/tree-ssa-loop-ivopts.c:2654
#7 0x083f4c22 in rewrite_use_address (data=0xbfca5820, use=0x891e340,
cand=0x89636f0) at
/home/apinski/src/gcc-fsf/work/gcc/gcc/tree-ssa-loop-ivopts.c:5086
#8 0x083f5603 in rewrite_uses (data=0xbfca5820) at
/home/apinski/src/gcc-fsf/work/gcc/gcc/tree-ssa-loop-ivopts.c:5147
#9 0x083f7ded in tree_ssa_iv_optimize_loop (data=0xbfca5820, loop=Variable
loop is not available.
) at /home/apinski/src/gcc-fsf/work/gcc/gcc/tree-ssa-loop-ivopts.c:5346
#10 0x083f836e in tree_ssa_iv_optimize () at
/home/apinski/src/gcc-fsf/work/gcc/gcc/tree-ssa-loop-ivopts.c:5379
#11 0x08406285 in tree_ssa_loop_ivopts () at
/home/apinski/src/gcc-fsf/work/gcc/gcc/tree-ssa-loop.c:514
#12 0x082a0e6f in execute_one_pass (pass=0x8830780) at
/home/apinski/src/gcc-fsf/work/gcc/gcc/passes.c:1125
#13 0x082a106f in execute_pass_list (pass=0x8830780) at
/home/apinski/src/gcc-fsf/work/gcc/gcc/passes.c:1178
#14 0x082a1082 in execute_pass_list (pass=0x8830400) at
/home/apinski/src/gcc-fsf/work/gcc/gcc/passes.c:1179
#15 0x082a1082 in execute_pass_list (pass=0x882fc00) at
/home/apinski/src/gcc-fsf/work/gcc/gcc/passes.c:1179
#16 0x0837f88c in tree_rest_of_compilation (fndecl=0xb7d53d80) at
/home/apinski/src/gcc-fsf/work/gcc/gcc/tree-optimize.c:406
#17 0x084eabc0 in cgraph_expand_function (node=0xb7d53f00) at
/home/apinski/src/gcc-fsf/work/gcc/gcc/cgraphunit.c:1073
#18 0x084ed32c in cgraph_optimize () at
/home/apinski/src/gcc-fsf/work/gcc/gcc/cgraphunit.c:1142
#19 0x080b2cf5 in gfc_be_parse_file (set_yydebug=0) at
/home/apinski/src/gcc-fsf/work/gcc/gcc/fortran/f95-lang.c:305
#20 0x08323458 in toplev_main (argc=14, argv=0xbfca5a64) at
/home/apinski/src/gcc-fsf/work/gcc/gcc/toplev.c:1051
#21 0x080f8b8f in main (argc=1701147252, argv=0x632e) at
/home/apinski/src/gcc-fsf/work/gcc/gcc/main.c:35
Mine.
--
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
Component|fortran |tree-optimization
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2007-06-27 21:07:44
date||
Summary|[Optimization] ICE in |[4.3 Regression] ICE in
|build2_stat, at tree.c:3074 |build2_stat, at tree.c:3074
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32527
[Bug target/32418] [4.3 Regression] ICE in global_alloc, at global.c:514
--- Comment #21 from dj at redhat dot com 2007-06-27 21:28 --- Subject: Re: [4.3 Regression] ICE in global_alloc, at global.c:514 The patch in comment #9 is OK with me, please commit it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug middle-end/32493] [4.3 Regression] Fails to inline varargs function with unused arguments
--- Comment #8 from malitzke at metronets dot com 2007-06-27 21:34 --- Glad it hit the spot and hopefully alerted the user community as to what is going on. Now, how about doing something about transforming a clearly expressed subtraction into a udivdi3. To the best of my knowledge and research the kernel does not even make the minuend or the subtrahend into a long-long and still the udivdi3 is rammed down the user community's throat. In my toy program (because of the GCC maintainers insistence that everything be reduced I resorted to long-long). This udivdi3 issue was swept by you, Mr. Guenther under the rug by making it an enhancement of severity less than trivial. As I was clearly rejected by the GCC insiders in my attempts to help make the C compiler more attuned to the spirit of the C99 committee; I am now forced to alert the user community of what is happening with near monopoly. And why is a GCC maintainer, with priveledged access to GCC's bugzilla, and hence a spokesperson for the GCC community claiming again and again on GCC's bugzilla that Mr Linus Torvalds is wrong, instead of having the guts to confront Mr torvalds directly. I do not work for Mr Torvalds nor am I part of the the kernel community to deliver an inane message to somebody of the stature of Mr Torvalds. Actually it is evidently clear that Mr Linus Torvalds and Mr Andrew Morton do not need my help. I am actually pursuing this on my own as part of a larger picture. As an outsider GCC's bugzilla is the equivalent to the leads of the good old EE black box. You use use the tools available. Signed Ray Malitzke. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32493
[Bug target/32479] [sh] ICE in cse_extended_basic_block, at cse.c:6117
--- Comment #4 from kkojima at gcc dot gnu dot org 2007-06-27 21:40 --- Subject: Bug 32479 Author: kkojima Date: Wed Jun 27 21:40:19 2007 New Revision: 126065 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126065 Log: PR target/32479 * config/sh/sh.md (udivsi3): Don't wrap the sequence with REG_LIBCALL and REG_RETVAL notes. (divsi3, mulsi3): Likewise. (mulhisi3): Likewise. Use emit_libcall_block. (umulhisi3, smulsi3_highpart, umulsi3_highpart_i): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32479
[Bug target/32479] [sh] ICE in cse_extended_basic_block, at cse.c:6117
--- Comment #5 from kkojima at gcc dot gnu dot org 2007-06-27 22:22 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32479
[Bug target/32418] [4.3 Regression] ICE in global_alloc, at global.c:514
--- Comment #22 from rask at gcc dot gnu dot org 2007-06-27 22:23 --- Subject: Bug 32418 Author: rask Date: Wed Jun 27 22:23:35 2007 New Revision: 126067 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126067 Log: 2007-06-27 Rask Ingemann Lambertsen [EMAIL PROTECTED] PR target/32418 * config/m32c/m32c.c (m32c_eh_return_stackadj_rtx): Dataflow fix: Use a call clobbered hard reg instead of a pseudo reg. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m32c/m32c.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug target/32522] [4.3 Regression] Bootstrap failure on Alpha due to pointer-plus changes
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-27 22:57 --- I already gave Falk a patch to try. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |target Keywords||ice-on-valid-code Summary|Bootstrap failure on Alpha |[4.3 Regression] Bootstrap |due to pointer-plus changes |failure on Alpha due to ||pointer-plus changes Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32522
[Bug other/31400] enable static linking of support libraries through -static-libXY
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-06-27 22:58 --- Subject: Bug 31400 Author: fxcoudert Date: Wed Jun 27 22:58:37 2007 New Revision: 126068 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126068 Log: PR other/31400 * gcc.c (process_command): Recognize the new -static-libgfortran option. * lang.opt (static-libgfortran): New option. * gfortranspec.c (ADD_ARG_LIBGFORTRAN): New macro. (Option): Add OPTION_static and OPTION_static_libgfortran. (lookup_option): Handle the new -static-libgfortran option. (lang_specific_driver): Check whether -static is passed. Handle the new -static-libgfortran option. * options.c (gfc_handle_option): If -static-libgfortran is passed and isn't supported on this configuration, error out. Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortranspec.c trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/gcc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31400
[Bug other/31400] enable static linking of support libraries through -static-libXY
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-06-27 23:00 --- Fixed on mainline. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31400
[Bug c/32528] New: -save-temps when compiling standard input fails
This looks like a trivial bug in options processing. It's been not working for
a long time.
===
[EMAIL PROTECTED]:~/exp-save-temps-dash$ cat hello.c
#include stdio.h
int main()
{
printf(Hello, world\n);
return 0;
}
[EMAIL PROTECTED]:~/exp-save-temps-dash$ cat hello.c |
/home/mec/gcc-3.4.6/install/bin/gcc -save-temps -x c -
cc1: error: unrecognized command line option -.i
[EMAIL PROTECTED]:~/exp-save-temps-dash$ cat hello.c |
/home/mec/gcc-4.0.4/install/bin/gcc -save-temps -x c -
cc1: error: unrecognized command line option -.i
[EMAIL PROTECTED]:~/exp-save-temps-dash$ cat hello.c |
/home/mec/gcc-4.1.2/install/bin/gcc -save-temps -x c -
cc1: error: unrecognized command line option -.i
[EMAIL PROTECTED]:~/exp-save-temps-dash$ cat hello.c |
/home/mec/gcc-4.2.0/install/bin/gcc -save-temps -x c -
cc1: error: unrecognized command line option -.i
[EMAIL PROTECTED]:~/exp-save-temps-dash$ cat hello.c |
/home/mec/gcc-4.3-20070622/install/bin/gcc -save-temps -x c -
cc1: error: unrecognized command line option -.i
[EMAIL PROTECTED]:~/exp-save-temps-dash$
--
Summary: -save-temps when compiling standard input fails
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google dot com
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=32528
[Bug rtl-optimization/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor
--- Comment #6 from harsha dot jagasia at amd dot com 2007-06-28 00:41 --- Created an attachment (id=13796) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13796action=view) vectorizer dump with cost model on -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
[Bug rtl-optimization/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor
--- Comment #7 from harsha dot jagasia at amd dot com 2007-06-28 00:41 --- This is what I get without -ftree-vectorize, with -ftree-vectorize (default cost model off) and with -ftree-vectorize -fvect-cost-model respectively on an AMD x86-64 (with trunk plus the patch posted by Dorit at http://gcc.gnu.org/ml/gcc-patches/2007-06/txt00156.txt ) Case 1: (no vectorization) gfortran -static -march=opteron -msse3 -O3 -ffast-math -funroll-loops pr32084.f90 -o 4.3.novect.out time ./4.3.novect.out real0m4.414s user0m4.312s sys 0m0.000s Case 2: (vectorization without cost model) gfortran -static -ftree-vectorize -march=opteron -msse3 -O3 -ffast-math -funroll-loops -fdump-tree-vect-details -fno-show-column pr32084.f90 -o 4.3.nocost.out time ./4.3.nocost.out real0m4.776s user0m4.668s sys 0m0.004s Case 3: (vectorization with cost model) gfortran -static -ftree-vectorize -fvect-cost-model -march=opteron -msse3 -O3 -ffast-math -funroll-loops -fdump-tree-vect-details -fno-show-column pr32084.f90 -o 4.3.cost.out time ./4.3.cost.out real0m4.403s user0m4.300s sys 0m0.000s In short, the 8% advantage that the scalar version has over the vector version disappears with the cost model. Unless I am missing something, the inner loops at lines 207 and 319 (do k = 1, 9) dont get vectorized (irrespective of the cost model). Looking at the dumps, the lines being vectorized without the cost model are the calls to TRANSPOSE and DOT_PRODUCT (line no 335, 333, 288, 223, 221 and 176). And the cost model determines that it's not profitable to vectorize these resorting to the scalar version instead. The dumps are attached. Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /home/hjagasia/autovect/src-trunk/gcc/configure --prefix=/local/hjagasia/autovect/obj-trunk-nobootstrap --enable-languages=c,c++,fortran --enable-multilib --disable-bootstrap Thread model: posix gcc version 4.3.0 20070627 (experimental) Thanks, Harsha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
[Bug rtl-optimization/32084] gfortran 4.3 13%-18% slower for induct.f90 than gcc 4.0-based competitor
--- Comment #8 from harsha dot jagasia at amd dot com 2007-06-28 00:42 --- Created an attachment (id=13797) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13797action=view) vectorizer dump with cost model off -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
[Bug c/32529] New: ICE, typedef of function taking VLA
cat ice99.c typedef int (*matrix_handler)(int n, double M[restrict n][n]); gcc -c -std=c99 ice99.c ice99.c:1: internal compiler error: Segmentation fault -- Summary: ICE, typedef of function taking VLA Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pa at panix dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32529
[Bug c/32529] ICE, typedef of function taking VLA
--- Comment #1 from pa at panix dot com 2007-06-28 01:15 --- Created an attachment (id=13798) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13798action=view) preprocessed input -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32529
[Bug c/32529] ICE, typedef of function taking VLA
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-28 01:26 --- *** This bug has been marked as a duplicate of 28504 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32529
[Bug c/28504] [4.0/4.1 regression] ICE with variable sized array
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-28 01:26 --- *** Bug 32529 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pa at panix dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28504
[Bug objc/32530] New: @try/@throw/@catch/@finally usage without -fexeceptions compiles without warning/error
Test case:
$ cat except.m
#include objc/Object.h
@interface E: Object
@end
@implementation E
@end
int main(int argc, char* argv[])
{
@try {
@throw [E new];
} @catch(E *e) {
}
return 0;
}
$ gcc -Wall -O2 -g -lobjc except.m -o except
$ ./except
Aborted (core dumped)
$
No warnings or errors a compile time and a completely unexpected runtime
failure.
pinskia told me to link to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11813
--
Summary: @try/@throw/@catch/@finally usage without -fexeceptions
compiles without warning/error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nmiell at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32530
[Bug c/32531] New: erroneous enum comparison results
$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)
$ uname -a
Linux localhost.localdomain 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 15:37:31 EDT
2007 i686 i686 i386 GNU/Linux
the following code:
#include stdio.h
enum X
{
A = 3,
B = 1,
C,
D,
E
};
int main()
{
printf(%d;\n, B == A);
printf(%d;\n, C == A);
printf(%d;\n, D == A);
printf(%d;\n, E == A);
return 0;
}
compiled with:
$ gcc -Wall -Wextra -ansi -pedantic -save-temps -o foo foo.c
gives as output:
$ ./foo
0;
0;
1;
0;
--
Summary: erroneous enum comparison results
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: entrophage at gmail dot com
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32531
