[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
--- Comment #14 from tkoenig at gcc dot gnu dot org 2005-10-31 07:52 --- Can we disable -fweb for 4.1.0 for fortran? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #7 from mark at codesourcery dot com 2005-10-31 07:44 --- Subject: Re: [3.4/4.0/4.1 Regression] bitfield layout change (regression?) steven at gcc dot gnu dot org wrote: > --- Comment #6 from steven at gcc dot gnu dot org 2005-10-31 07:21 > --- > This was not a show stopper for GCC 3.4 and GCC 4.0. Why is it a show stopper > now for GCC 4.1? > > And we can't unconditionally change it back now. We already have GCC 3.4 and > 4.0 based compilers in production environments. I suspect you didn't realize that the PR wasn't opened until July; I had no knowledge of it when 3.4 or 4.0 were released. If I had, I would have declared it a showstopper then. Now, it's a showstopper to figure out what happened and make an informed decision. If we conform to a published ABI where we did not before, maybe we do nothing; this is a bug fix. If we now fail to conform to a published ABI, maybe we add a switch. But, we certainly have to evaluate it before the release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #6 from steven at gcc dot gnu dot org 2005-10-31 07:21 --- This was not a show stopper for GCC 3.4 and GCC 4.0. Why is it a show stopper now for GCC 4.1? And we can't unconditionally change it back now. We already have GCC 3.4 and 4.0 based compilers in production environments. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug target/24374] [4.0/4.1 Regression] Sibcalling optimization is happening in main
--- Comment #6 from jkj at sco dot com 2005-10-31 07:12 --- rth has a completely different fix for this that is much more comprehensive. http://gcc.gnu.org/ml/gcc/2005-10/msg00412.html has the details. I'm still working on bringing my 4.1 tree up to speed so I can help him test this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24374
[Bug middle-end/24585] [3.4/4.0/4.1 Regression] spurious section conflict error while building linux kernel
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 06:45 --- This is a showstopper, unless we can convince ourselves that this is not a bug, or, at least, not a regression. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24585
[Bug c++/24582] [4.0/4.1 regression] ICE in decl_jump_unsafe
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 06:44 --- Leave as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24582
[Bug c++/24580] [3.4/4.0/4.1 Regression] virtual base class cause exception not to be caught
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 06:43 --- Wrong-code; showstopper. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24580
[Bug c++/24569] [4.0/4.1 regression] ICE in add_AT_specification, at dwarf2out.c:4966
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 06:42 --- Showstopper. Fortunately, I have a patch; just need to check it in. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24569
[Bug c++/24560] [3.4/4.0/4.1 Regression] "insufficient contextual information to determine type" is not a helpful error message
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 06:41 --- Leaving as P2; we shoudl fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24560
[Bug debug/24490] [4.1 Regression] gcc / gdb backtrace problem
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 06:40 --- Leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24490
[Bug gcov/profile/24487] [3.4/4.0/4.1 Regression] Basic block frequencies inaccurate
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 06:39 --- Rather than increasing the estimate for loops with unknown bounds or throttling the maximum for loops with known bounds, why not notice, when inlining, that we've mixed the two, and drop all frequency guesses in the resulting function? (This is the usual lattice arithmetic idea.) If we don't know, we just don't know. It's probably better to admit that we have no information than to pretend that we understand what's going on. (I have no evidence that my idea actually helps, though; it could be horrible.) Leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24487
[Bug tree-optimization/24483] [4.1 Regression] ICE in ivopts
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 06:35 --- ICE on reasonable code; showstopper. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24483
[Bug target/24476] [4.1 Regression] gcc.dg/tls/pr24428.c execution test and gcc.dg/tls/pr24428-2.c execution test fail on IA64
--- Comment #1 from mmitchel at gcc dot gnu dot org 2005-10-31 06:33 --- Leaving as P2, pending analysis. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24476
[Bug middle-end/24462] [4.1 Regression] packed-aligned structures are laid out differently
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-31 06:33 --- ABI breakage: showstopper. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24462
[Bug debug/24444] [4.1 regression] invalid register in debug info
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 06:32 --- I guess I'll leave this as P2, but I really do think we should find a fix before the next release, for the affected targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug middle-end/24408] [4.1 Regression] Invariant code no longer removed from loop when doing FDO.
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-31 06:30 --- Leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24408
[Bug middle-end/24590] Static function named "main" treated as the real main
--- Comment #1 from mmitchel at gcc dot gnu dot org 2005-10-31 06:29 --- Wrong code, easy fix -- showstopper. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24590
[Bug middle-end/24590] New: Static function named "main" treated as the real main
In tree_expand_cfg, we have:
if (DECL_NAME (current_function_decl)
&& MAIN_NAME_P (DECL_NAME (current_function_decl))
&& DECL_FILE_SCOPE_P (current_function_decl))
expand_main_function ();
This code should also check TREE_PUBLIC (c_f_d) (and the entire predicate
should probably be encapsulated in a macro or function).
Compiling this test case:
extern void f();
static int main () {
f();
}
int g() {
f();
}
on x86_64-unknown-linux-gnu with -m32 shows that the usual stack-alignment and
implicit return of zero code is generated for this "main" function, even though
it's not the real main function.
--
Summary: Static function named "main" treated as the real main
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mmitchel at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24590
[Bug target/24374] [4.0/4.1 Regression] Sibcalling optimization is happening in main
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 06:25 --- Kean, I think you need to check TREE_PUBLIC (decl) as well; a "static" main function isn't the main you're looking for. Note that a "static" main is permitted by gcc, with a warning, by default. (It looks like the same bug appears in cfgexpand.c, by the way. I'll open a new PR for that.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24374
[Bug tree-optimization/24365] [4.1 Regression] statement makes a memory store with complex
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 06:18 --- ICE on reasonable valid code; showstopper. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24365
[Bug tree-optimization/24351] [4.1 Regression] ICE in do_simple_structure_copy with some C++ code
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 06:16 --- Danny, when you refer to PR 24288, do you mean a different PR? I don't see the relevance of PR 24288, but I do remember discussing this issue with you and Jason. Anyhow, for the time being, I think it's fair to punish the C++ front-end by disabling this optimization logic there. The type information we're giving you really isn't right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24351
[Bug c/24329] [4.0/4.1 regression] segfault with -Wall and long integer literal
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 06:13 --- We need to analyze this. Unless this is a Darwin libc bug, this is a showstopper. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24329
[Bug tree-optimization/24309] [4.1 Regression] ICE with -O3 -ftree-loop-linear
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 06:12 --- Leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
[Bug target/24306] [3.4/4.0/4.1 Regression] va_arg gets confused when skipping over certain zero-sized types with -msse
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 06:10 --- This is a corner-case; we can leave this at P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24306
[Bug target/24265] [4.1 Regression] ICE: in extract_insn, at recog.c:2084 with -O -fgcse -fmove-loop-invariants -mtune=pentiumpro
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 06:07 --- Does the analysis in Comment #3 imply that -fmove-loop-invariants is really not ready for use by the general public? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24265
[Bug rtl-optimization/24257] [4.1 Regression] ICE: in extract_insn with -O -fgcse -fgcse-sm
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 06:05 --- How broken is -fgcse-sm? Is it broken enough that it should not only be disabled by default but also hard-wired off on release branches? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24257
[Bug target/24230] [4.1 Regression] ICE in extract_insn with altivec
--- Comment #19 from mmitchel at gcc dot gnu dot org 2005-10-31 06:04 --- Altivec is very popular; this is a showstopper. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
[Bug preprocessor/24202] [3.4/4.0/4.1 Regression] Segfault with #pragma once
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 06:02 --- I'm marking this as P1, at least until we do some analysis. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24202
[Bug rtl-optimization/24160] [4.1 Regression] ICE with -O1 -ftree-vectorize -msse
--- Comment #13 from mmitchel at gcc dot gnu dot org 2005-10-31 06:00 --- This is a showstopper. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24160
[Bug c++/24138] [4.1 regression] ICE with the code in PR 20407
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 05:58 --- I'm not sure whether we want to try to allow this in C++. (I think this is valid C99, using the flexible array extension, but I'm not certain.) Clearly, however, ICEing is bad; leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24138
[Bug c/24101] [3.4/4.0/4.1 Regression] Segfault with preprocessed source
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 05:57 --- Leaving as P2. This really should be fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24101
[Bug middle-end/24093] [4.1 Regression] cgraph exhausts virtual memory building 197.parser with -profile-use -O3
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 05:56 --- Should this be marked as fixed, or as 4.0-only, given the patch in Comment #8? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24093
[Bug c++/24037] [3.4/4.0/4.1 regression] C++ front-end does not print #include stack for parsering errors
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 05:54 --- Leaving as P2; we need to fix this or figure out why we can't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24037
[Bug preprocessor/24024] [3.4/4.0/4.1 Regression] gcc -E -C processes "\" incorrectly inside C comments
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 05:54 --- A bug in the -E -C output is never going to be release-critical. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24024
[Bug c++/24009] [4.0/4.1 regression] C++ fails to print #include stack
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 05:53 --- We should either fix this, or, at least, figure out why we can't; leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24009
[Bug middle-end/24003] [4.1 Regression] 17 ACATS regressions (fixed point or decimal artihmetic)
--- Comment #23 from mmitchel at gcc dot gnu dot org 2005-10-31 05:52 --- Do we have a C/C++ testcase for this problem? I'm going to leave this as P2 for now, given that we think it's not language-dependent, and given that we seem close to a fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
[Bug middle-end/23954] [4.1 regression] FAIL: gcc.c-torture/execute/20040709-1.c execution, -Os
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 05:50 --- This is a showstopper, at least until we analyze it better. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23954
[Bug tree-optimization/23948] [4.1 Regression] internal compiler error: verify_stmts failed
--- Comment #20 from mmitchel at gcc dot gnu dot org 2005-10-31 05:48 --- This is a showstopper. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23948
[Bug tree-optimization/23835] [4.1 Regression] case where gcc 4.1.0 -O3 compile takes two times longer earlier versions
--- Comment #22 from mmitchel at gcc dot gnu dot org 2005-10-31 05:46 --- Downgrading to P4. I'd like to see more progress for 4.1, but it's not going to be release-critical. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug tree-optimization/23821] [4.0/4.1 Regression] DOM and VRP creating harder to optimize code
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-31 05:42 --- Leaving as P2, pending investigation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug target/23775] [4.1 Regression] wrong code in argument passing
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 05:41 --- Yup, this is a showstoppper. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23775
[Bug rtl-optimization/23567] [3.4/4.0/4.1 regression] if-conversion causes wrong code
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 05:39 --- Elevating to P1; this is a serious wrong-code regression. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23567
[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-10-31 05:36 --- I don't think this PR is, in-and-of-itself, is very interesting, as it's a 1-byte size increase with -O2, which, as has been said, is not aimed at minimizing code size. So, I'm going to close this PR -- but, leave PR 23153 open, as there look to be interesting issues there. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23524
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complex
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 05:28 --- Certainly, the test-case in Comment #1 does depend on libstdc++ at all. Let's fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug middle-end/24589] [4.1 Regression] wrong code with zero sized structs on CONSTRUCTOR
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-31 05:26 --- This still fails as of today. I will repost and retest the patch later today. -- 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 Ever Confirmed|0 |1 Known to fail||4.1.0 Known to work||4.0.3 Last reconfirmed|-00-00 00:00:00 |2005-10-31 05:26:30 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24589
[Bug middle-end/24589] New: [4.1 Regression] wrong code with zero sized structs on CONSTRUCTOR
Testcase:
void abort (void);
int ii;
typedef struct {} raw_spinlock_t;
typedef struct {
raw_spinlock_t raw_lock;
} spinlock_t;
raw_spinlock_t one_raw_spinlock (void)
{
raw_spinlock_t raw_lock;
ii++;
return raw_lock;
}
int main(void)
{
spinlock_t lock = (spinlock_t) { .raw_lock = one_raw_spinlock() };
if (ii != 1)
abort ();
return 0;
}
---
Forwarded from:
http://gcc.gnu.org/ml/gcc/2005-09/msg00260.html
Patch which needs testing posted:
http://gcc.gnu.org/ml/gcc/2005-09/msg00286.html
--
Summary: [4.1 Regression] wrong code with zero sized structs on
CONSTRUCTOR
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24589
[Bug middle-end/23492] [4.1 Regression] ACATS c48009e SEGV in set_bb_for_stmt tree-cfg.c:2673 on x86_64
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 05:22 --- This patch is OK, assuming no objections within 24 hours. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23492
[Bug rtl-optimization/23490] [3.4/4.0/4.1 Regression] Long compile time for array initializer with inlined constructor
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 05:17 --- I'd like to see this fixed. Is there any throttling we can do here? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490
[Bug middle-end/23492] [4.1 Regression] ACATS c48009e SEGV in set_bb_for_stmt tree-cfg.c:2673 on x86_64
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-31 05:13 --- I decided against committing the patch as obvious. Anyways the patch was posted: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01770.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||10/msg01770.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23492
[Bug target/23488] [4.1 Regression] GCSE load PRE does not work with non sets
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-10-31 05:13 --- Leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
[Bug c++/23457] [3.4/4.0/4.1 Regression] compiler crash on huge object size with virtual base
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-31 05:09 --- Leaving as P2; we should fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23457
[Bug rtl-optimization/23453] [4.0/4.1 regression] miscompilation of PARI/GP on x86 with gcse after reload
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 05:09 --- Leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23453
[Bug target/23451] [3.4/4.0/4.1 regression] Redundant reloading from stack frame
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 05:05 --- We don't need speculation; we need facts. I'll leave this at P2, in the hopes that someone will analyze this properly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23451
[Bug rtl-optimization/23392] [4.1 Regression] foward-1.m fails with -funroll-loops -O3 -fgnu-runtime
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-10-31 05:03 --- Dale, would you please attach the C++ testcase for this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
[Bug tree-optimization/23382] [4.1 Regression] Does not remove the old HEAP virtual variables in clobbered
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 05:02 --- Leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23382
[Bug middle-end/23492] [4.1 Regression] ACATS c48009e SEGV in set_bb_for_stmt tree-cfg.c:2673 on x86_64
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-31 05:02 ---
Here is a C testcase (so that Mark does not lower this to P5):
struct f {};
struct g1 {struct f l;};
static inline void g(struct f a, int i){}
void h(void)
{
struct g1 t;
g(t.l , 1);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23492
[Bug target/23378] [4.1 Regression] code quality regression for complicated loop
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 05:01 --- Leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23378
[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-10-31 05:00 --- Leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug tree-optimization/23346] [4.1 Regression] FRE before DCE makes a mess of loads or need to sink loads
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-31 04:59 --- Subject: Re: [4.1 Regression] FRE before DCE makes a mess of loads or need to sink loads > > > > --- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 04:58 > --- > Why have we regressed relative to 4.0? Because passes were reordered in 4.1. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23346
[Bug tree-optimization/23346] [4.1 Regression] FRE before DCE makes a mess of loads or need to sink loads
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 04:58 --- Why have we regressed relative to 4.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23346
[Bug debug/23336] [3.4/4.0/4.1 Regression] enum constants not visible to gdb because of -feliminate-unused-debug-types
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 04:56 --- Leaving as P2; we should definitely fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23336
[Bug tree-optimization/23335] [4.0/4.1 Regression] copyrename does not coalesce different type variables (useless type conversion)
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 04:55 --- I'm going to resolve this as INVALID. If there's a bug here, we need a test case that shows that inferior code; then, we can reopen this bug. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23335
[Bug target/23524] [4.1 Regression]bigger version of mov + cmp produced
--- Comment #13 from dann at godzilla dot ics dot uci dot edu 2005-10-31 04:50 --- (In reply to comment #12) > A more interesting test would be to see the Linux kernel size difference, There's such a comparison now in comment #8 in PR23153. It confirms the size increase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23524
[Bug target/23322] [4.1 regression] performance regression, possibly related to caching
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 04:49 --- Do we have any analysis about why the register allocator is doing a worse job? Leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
[Bug target/23303] [4.1 Regression] 4.1 generates sall + addl instead of leal
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 04:45 --- Jan, what's your analysis on this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23303
[Bug target/23302] [4.1 Regression] extra move generated on x86
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 04:43 --- I think we should look for some solution to this problem, without reverting the previous patch. If this problem is amenable to a peephole, let's solve it that way. That said, I'm going to downgrade this to P4; if we can't fix it for 4.1, we'll look again for 4.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23302
[Bug c++/23287] [3.4/4.0/4.1 regression] Explicitly invoking destructor of template class in a template and is dependent
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 04:40 --- Leaving as P2. I'm only 75% sure this is valid, but we should at least investigate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
[Bug c++/23211] [3.4/4.0/4.1 regression] using dec in nested class doesn't import name
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 04:39 --- Leavinga s P2. We should at least look at this, and understand what's wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211
[Bug inline-asm/23200] [4.0/4.1 regression] rejects "i"(&var + 1)
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-10-31 04:37 --- Leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug middle-end/23181] [4.1 Regression] Slowdown of the bresenham line drawing by roughly 20%
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 04:36 --- So, Jeff, is it your opinion that this is just an inevitable case of optimizers-aren't-perfect? If so, would you please just close this PR? Leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23181
[Bug c++/23172] [4.1 Regression] ICE on integer initialization, GNU extension
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 04:31 --- Leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23172
[Bug c++/23171] [4.1 Regression] ICE on pointer initialization with C99 initializer
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 04:31 --- Leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23171
[Bug target/22017] [3.4/4.0/4.1 Regression] Error to pass struct parameter when compile with mingw's gcc.exe using "-march=i386 -mrtd" flags
--- Comment #7 from dannysmith at users dot sourceforge dot net 2005-10-31 04:30 --- This is an i386 bug, not specific to MS windows target. However, it is only a problem with -mtune=i386 -mrtd. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22017
[Bug middle-end/23155] [4.0/4.1 Regression] Gimplification failed for union cast
--- Comment #11 from mmitchel at gcc dot gnu dot org 2005-10-31 04:29 --- Leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23155
[Bug c/23144] [4.0/4.1 Regression] invalid parameter forward declarations not diagnosed
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 04:28 --- This will never be release-critical. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23144
[Bug tree-optimization/23115] [4.1 Regression] -ftree-vectorize generates wrong code
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 04:23 --- I'm on the fence as to whether to call this P1 or P2. People have really started to use -ftree-vectorize and it's a major advantage of the more recent compilers over 3.4.x, so I'd really like to see this fixed. On the other hand, I'm not quite willing to call this a showstopper, so ... P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23115
[Bug tree-optimization/23109] [4.1 Regression] compiler generates wrong code leading to spurious division by zero with -funsafe-math-optimizations (instead of -ftrapping-math)
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 04:20 --- This is a serious wrong-code problem; it's a showstopper. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23109
[Bug c/23104] [4.1 Regression] C does not reject the same function in two different TUs with -combine
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-31 04:19 --- (In reply to comment #7) > Downgraded to P4. If we can fix this great; otherwise, we'll look at it > again for 4.2. It is not like I did not post a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23104
[Bug c/23104] [4.1 Regression] C does not reject the same function in two different TUs with -combine
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 04:18 --- Downgraded to P4. If we can fix this great; otherwise, we'll look at it again for 4.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23104
[Bug c++/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Comment #20 from mmitchel at gcc dot gnu dot org 2005-10-31 04:15 --- This is a showstopper; ICE on simple, valid code. We need to resolve what approach (es) to use to fix this and get it done. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug target/23153] [4.1 Regression] [meta-bug] code size regression from 4.0 on x86
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2005-10-31 04:15 --- More data, the Linux kernel compiled for i686: size -f * textdata bss dec hex filename 2625471 534012 611768 3771251 398b73 vmlinux.4.0 3023306 429364 347384 3800054 39fbf6 vmlinux.4.1 It would be good if someone else can try to reproduce this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23153
[Bug c/22297] [4.0/4.1 Regression] missing uninitialization warning
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-31 04:13 --- (In reply to comment #3) > Andrew, what is your point about the C++ front-end? What is it you think is > wrong? There is no mention of the C++ front-end here at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22297
[Bug rtl-optimization/22563] [3.4/4.0/4.1 Regression] performance regression for gcc newer than 2.95
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 04:12 --- Leaving as P2. I've seen reports of similar bitfield problems on a variety of problems. This kind of code doesn't show up much in scientific computing, but it does show up in network applications, operating-system kernels, etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22563
[Bug ada/22533] [4.1 regression] ICE in get_base_var
--- Comment #22 from mmitchel at gcc dot gnu dot org 2005-10-31 04:10 --- Downgraded to P5. If this is not Ada-specific, please attach a C/C++ test case. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
--- Comment #13 from mmitchel at gcc dot gnu dot org 2005-10-31 04:08 --- I've set this to P5. If it's not Fortran-specific, Cc: me -- after attaching the C/C++ test-case. Or, just fix the bug. :-) -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug c++/22489] [4.0/4.1 Regression] ICE in dwarf2out_finish with using namespace in a local class and compiler built constructors
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 04:07 --- This will prevent compiling real programs with -g; it's a showstopper. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22489
[Bug middle-end/22456] [4.1 regression] missing "is used uninitialized" warning
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 04:07 --- This will never be release-critical. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22456
[Bug c++/22434] [3.4/4.0/4.1 regression] ICE in simplify_{,gen_}subreg
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 04:05 --- I'm not sure what's ging on here, but I know we should fix it... Leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22434
[Bug target/22432] [4.0/4.1 Regression] Wrong code generation using MMX intrinsics on amd64
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 04:04 --- This is a showstopper; wrong code on a primary platform. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22432
[Bug middle-end/22429] [4.1 Regression] -1073741824 <= n && n <= 1073741823 is true where n is 1073741824
--- Comment #12 from mmitchel at gcc dot gnu dot org 2005-10-31 04:03 --- This is a showstopper; wrong code on a primary platform using plausible inputs. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22429
[Bug c/22297] [4.0/4.1 Regression] missing uninitialization warning
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-31 04:02 --- The patch in Comment #1 has been applied. Andrew, what is your point about the C++ front-end? What is it you think is wrong? In any case, this will never be release critical. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22297
[Bug middle-end/22141] [4.0/4.1 Regression] Missing optimization when storing structures
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-31 03:59 --- (In reply to comment #2) > Leaving as P2. > Do we know what's different? Yes in 4.0 and above there is no CONSTRUCTOR so we don't see the full CONSTRUCTOR in expand so it could expand to just one integer store. >The structure type is byte-aligned. How did 2.95 justify using a 4-byte store? There is no strict alignment requirements for either PPC or x86 which is why GCC did it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 03:57 --- This is a showstopper; we need to at least understand why this changed and whether or not we should change it back. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug c++/22238] [4.0/4.1 regression] '#'obj_type_ref' not supported by dump_expr
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 03:55 --- Gaby, please apply the simple OBJ_TYPE_REF patch so that we can remove the regression markers from this PR. (I agree that a complete solution is difficult; my opinion continues to be that we should use carets, rather than trying to print out expressions.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22238
[Bug middle-end/22141] [4.0/4.1 Regression] Missing optimization when storing structures
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 03:54 --- Leaving as P2. Do we know what's different? The structure type is byte-aligned. How did 2.95 justify using a 4-byte store? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141
[Bug c++/22136] [4.1 regression] Rejects old-style using declaration
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 03:50 --- Leaving as P2; we should fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22136
[Bug middle-end/22127] [3.4/4.0/4.1 Regression] register window not preserved after getcontext call
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-10-31 03:49 --- Regardless of *where* getcontext() should be recognized, it's clear that the compiler should be aware that it has special behavior. This is a wrong-code regression on a primary platform with no non-default options in use; upgraded to P1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22127
[Bug preprocessor/22042] [3.4/4.0/4.1 Regression] stringification BUG
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-10-31 03:46 --- Leaving as P2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22042
[Bug target/22017] [3.4/4.0/4.1 Regression] Error to pass struct parameter when compile with mingw's gcc.exe using "-march=i386 -mrtd" flags
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 03:45 --- Leaving at P2, only because Cygwin is not a primary platform. (Otherwise, I'd make this P1.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22017
[Bug tree-optimization/20643] [4.0/4.1 Regression] Tree loop optimizer does worse job than RTL loop optimizer
--- Comment #6 from dberlin at gcc dot gnu dot org 2005-10-31 03:43 --- Realistically? No. I'm about to start solving it on the improved-aliasing branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20643
