[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double
--- Comment #29 from mmitchel at gcc dot gnu dot org 2010-08-31 17:41 --- Jason -- I can't argue with that as a literal reading of the standard, but is there any reason why the standard doesn't allow const float variables in (not necessarily integral) constant expressions just as we allow const int variables? -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated
--- Comment #4 from mmitchel at gcc dot gnu dot org 2010-08-17 14:41 --- I have no object to the FE removing trivial code if it can do so -- but I also think that the middle-end should be able to deduce that a function is pure later in the process and eliminate it then. I don't understand Richard's comment about -Wuninitialized; I don't see any comments from Jakub in this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45307
[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated
--- Comment #10 from mmitchel at gcc dot gnu dot org 2010-08-17 17:50 --- The problem with -Wuninitialized might be the same problem I've been sermonizing about for years -- we're trying to issue sensible warnings from our optimizers, which means that as the optimizers are perturbed, the set of warnings will change in various ways. But, there's no reason for -Wuninitialized to warn about a use of an empty structure, so I don't see why removing the stores is unreasonable. I certainly think that the front-end could safely optimize away such stores, and that it would be reasonably easy to do so in the trivial cases. (Obviously, the optimizers would be responsible for more complex cases where things are not perhaps immediately obvious to the front-end.) I don't think there's any reason we don't do that in the front-end; it's just something we haven't done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45307
[Bug c++/43680] [DR 1022] G++ is too aggressive in optimizing away bounds checking with enums
--- Comment #13 from mmitchel at gcc dot gnu dot org 2010-04-20 20:43 --- I think this optimization is valuable in some cases, so I think this is a question of defaults, rather than of behavior per se. While it may be useful for some security-related applications not to eliminate the checks, but it is clearly useful in other contexts to eliminate the checks. Optimizing away bounds checking is certainly not in and of itself a bug. In some sense, this is similar to strict-aliasing, or signed-does-not-overflow optimization. There's a lot of code out there that depends on something that's not portable. It's not useful to break that code, but it is useful to be able to optimize. (One case where I think this optimization is likely to be valuable is in switch/if statements where you're cascading through values; this optimization can allow you to eliminate the catch-all case at the end, which is certainly a win for code-size.) I think the standard should say that you get an indeterminate value when you convert an out-or-range input to an enum (and that such value may be outside the bounds of the enum range), but that the program is not allowed to go and reformat your disk. Ada has a notion of errors like this; the damage is bounded. This doesn't need to be in the dereference NULL pointer category of behavior, but neither should it have any guaranteed semantics, including that the value is masked down. So, I think we should have a C++ front-end option that says interpret enums strictly. I think it should be off by default for compatibility with existing code. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43680
[Bug c++/19159] [4.3/4.4/4.5 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info
--- Comment #47 from mmitchel at gcc dot gnu dot org 2010-03-21 16:47 --- Closed at request of submitter. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19159
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #22 from mmitchel at gcc dot gnu dot org 2010-02-28 17:08 --- Subject: Bug 42748 Author: mmitchel Date: Sun Feb 28 17:07:54 2010 New Revision: 157124 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157124 Log: 2010-02-27 Mark Mitchell m...@codesourcery.com PR c++/42748 * cp-tree.h (push_tinst_level): Declare. (pop_tinst_level): Likewise. * pt.c (push_tinst_level): Give it external linkage. (pop_tinst_level): Likewise. * mangle.c (mangle_decl_string): Set the source location to that of the decl while mangling. 2010-02-27 Mark Mitchell m...@codesourcery.com PR c++/42748 * g++.dg/abi/mangle11.C: Adjust mangling warning locations. * g++.dg/abi/mangle12.C: Likewise. * g++.dg/abi/mangle20-2.C: Likewise. * g++.dg/abi/mangle17.C: Likewise. * g++.dg/template/cond2.C: Likewise. * g++.dg/template/pr35240.C: Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/mangle.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/abi/mangle11.C trunk/gcc/testsuite/g++.dg/abi/mangle12.C trunk/gcc/testsuite/g++.dg/abi/mangle17.C trunk/gcc/testsuite/g++.dg/abi/mangle20-2.C trunk/gcc/testsuite/g++.dg/template/cond2.C trunk/gcc/testsuite/g++.dg/template/pr35240.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug other/43132] installation directory defaults do not match documentation, Coding Standards
--- Comment #6 from mmitchel at gcc dot gnu dot org 2010-02-24 16:28 --- Ralf -- I think the key question here is whether it is possible to build/install a new version of GCC, getting the same directory layout as was the default in previous versions. It's OK if it takes command-line options, but I think it should be *possible*. If not, then I think it is a regression. Do you know the answer? Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132
[Bug other/43132] installation directory defaults do not match documentation, Coding Standards
--- Comment #4 from mmitchel at gcc dot gnu dot org 2010-02-22 23:23 --- I don't think this should be P1, as getting the old behavior is apparently doable by hand, but I'm a big fan of backwards-compatibility and if the GCS haven't been updated then I think that GCC (as a GNU package) ought to try to follow that. Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #18 from mmitchel at gcc dot gnu dot org 2010-02-18 15:13 --- Paolo -- I think libsupc++ is just as much a system library as libstdc++. It doesn't have an ISO-standard API, of course, but that's not the point; it's just as much a part of the system/implementation as libstdc++. To the extent a program is going to use a header that we ship from libsupc++, that program certainly doesn't want to get random warnings about those headers. However, Julian Brown warns me that he's been playing with this and that it doesn't entirely solve the problem. It may be that my earlier patch to arm.c is insufficient in some cases. So, I'd like the libstdc++ maintainers to make the change to the libsupc++ headers -- unless someone can articulate a good reason not to do so of course -- but there may still be more work to do. We will continue to investigate the possible non-workingness of the patch. Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #31 from mmitchel at gcc dot gnu dot org 2010-02-17 16:49 --- I still have no idea what this PR is about. Someone needs to make a clear statement of what they believe the ABI to be. There are some simple questions: * Can we expect that the stack is 16-byte aligned, or not? * If we cannot (because of legacy requirements), then is there any reason to try to align the stack automatically at entry to every function, or at every call site? I can see that this might be useful as an option, but it does not seem like a sensible default to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #22 from mmitchel at gcc dot gnu dot org 2010-02-17 16:52 --- I don't think we really know enough yet to understand whether this is a bug, or if it is a bug, where the bug might lie. So, we certainly can't make it P1, ignoring even the fact that this test is in Fortran. But, it would be good if we could understand the situation better. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug debug/42648] [4.5 Regression] gcc.dg/guality/pr41353-1.c FAILs at -On, n 0
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42648
[Bug tree-optimization/42729] [4.5 Regression] -fcompare-debug failure with -O1 -fgraphite-identity
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42729
[Bug target/42886] [4.5 Regression] GCC is not relocatable anymore on Windows (mingw32)
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42886
[Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory
--- Comment #7 from mmitchel at gcc dot gnu dot org 2010-02-17 16:56 --- I think this is a critical problem. If var-tracking is causing factor-of-N increases in memory usage, then we need an algorithmic change that prevents that, even if that means inferior debug information. We're not going to win friends and influence people by giving them a compiler that can't compile things on their system, or takes much longer to do it, even if their debugging experience is better. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
[Bug tree-optimization/43065] [4.5 Regression] gcc.c-torture/execute/20051215-1.c is miscompiled with -fgraphite-identity
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43065
[Bug tree-optimization/43065] [4.5 Regression] gcc.c-torture/execute/20051215-1.c is miscompiled with -fgraphite-identity
--- Comment #1 from mmitchel at gcc dot gnu dot org 2010-02-17 16:58 --- I take the P1 setting back; I failed to recognize the use of -fgraphite-identity. As long as that's not a default setting, I don't think problems there should be P1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43065
[Bug c++/43070] [4.5 Regression] g++.dg/ext/label2.C fails to compile at -O1
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43070
[Bug tree-optimization/43083] [4.5 Regression] ICE: SIGSEGV with -fgraphite-identity
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43083
[Bug ada/43096] [4.5 Regression] ACATS c37105a wrong-code on arm-linux
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43096
[Bug tree-optimization/43097] [4.5 Regression] ICE in rename_map_elt_info for Graphite, vect in 173.applu
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43097
[Bug target/27016] [4.3/4.4/4.5 Regression] ARM optimizer produces severely suboptimal code
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27016
[Bug target/40332] [4.5 Regression] (.eh_frame); no .eh_frame_hdr table will be created.
--- Comment #13 from mmitchel at gcc dot gnu dot org 2010-02-17 17:15 --- I reluctantly agree with Ian's comment in: http://gcc.gnu.org/ml/gcc/2010-01/msg00332.html that: I think it would be troubling if a gcc release required a very new binutils release on a popular platform like x86_64. I actually think we should be unsympathetic to this kind of mixing of components. GCC is the only major compiler that does not consider the compiler, assembler, and linker to be a single unit. We've made the problem harder for ourselves than it needs to be, for the dubious benefit that users can download a new GCC release without having to get a new assembler and linker. However, even though I think our policy is counterproductive, it is in fact our policy. We shouldn't change the policy by accident; we should change it through conscious decision. Until then, we should indeed to as Ian suggests and: modify the configure test for gcc_cv_as_cfi_directive to avoid the problem when using an older binutils -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40332
[Bug tree-optimization/41089] [4.5 Regression] stdarg pass produces wrong code
--- Comment #44 from mmitchel at gcc dot gnu dot org 2010-02-17 17:20 --- As I understand it, this is an Alpha-specific problem. It may have an Alpha-independent solution, but only users on Alpha will be affected. So, I've downgraded this to P5. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug rtl-optimization/42502] [4.4/4.5 Regression] Bad register allocation in a very simple code
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42502
[Bug middle-end/42505] [4.4/4.5 Regression] loop canonicalization causes a lot of unnecessary temporary variables
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42505
[Bug middle-end/42837] [4.5 Regression] FAIL: g++.dg/abi/packed1.C execution test
--- Comment #5 from mmitchel at gcc dot gnu dot org 2010-02-17 17:27 --- Do we have any evidence that this is actually a regression? If this test has never worked on IA64/HPPA, then this is not a regression. It should then be XFAIL'd on those platforms, with this PR left open. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42837
[Bug rtl-optimization/42839] [4.5 Regression] gcc.target/mips/octeon-bbit-2.c failing for -mabi=64
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839
[Bug fortran/42851] [4.3/4.4/4.5] ICE (segfault) at gfc_trans_pointer_assignment for subpointer
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42851
[Bug java/43055] [4.3/4.4/4.5 Regression] 'jc1: internal compiler error: Segmentation fault' using gcj -fprofile-arcs
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43055
[Bug c++/43069] [4.5 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'overload' in set_decl_namespace, at cp/name-lookup.c:3105
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43069
[Bug c++/43076] [4.3/4.4/4.5 Regression] ICE: SIGSEGV with invalid C++ code after giving diagnostics
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43076
[Bug tree-optimization/43084] [4.5 Regression] ICE: in find_new_var_of_type, at ipa-struct-reorg.c:604 with -fipa-struct-reorg -g
--- Comment #3 from mmitchel at gcc dot gnu dot org 2010-02-17 17:38 --- I think we need to understand Steven's comment that ipa-struct-reorg is broken. This pass isn't on by default, AFAICT, so that decreases it's risk. But, if it's broken-by-design, as opposed to has-a-few-bugs, then we should indeed consider disabling it, at least on the release branch. The argument that it's good for us to enable people to test things is not strong if in fact we already know that the thing being tested is badly broken. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43084
[Bug c++/43101] [4.4/4.5 regression] Rejects template with const static data member used in return type
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43101
[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug tree-optimization/43074] [4.4/4.5 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:3491
--- Comment #3 from mmitchel at gcc dot gnu dot org 2010-02-17 17:42 --- Richard, is this fixed now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43074
[Bug tree-optimization/43066] [4.5 Regression] ICE: SIGFPE with empty struct and va_arg
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43066
[Bug c++/43079] [4.5 Regression] ICE with incompatible pointer-to-member-function as template parameter
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43079
[Bug c++/43093] [4.5 Regression] internal compiler error: Segmentation fault when compiling Firefox
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43093
[Bug c++/43075] 20_util/bind/ref2.cc FAILs
--- Comment #10 from mmitchel at gcc dot gnu dot org 2010-02-17 17:51 --- IIUC, this is not a regression. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Summary|[4.5 Regression]|20_util/bind/ref2.cc FAILs |20_util/bind/ref2.cc FAILs | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43075
[Bug java/42143] [4.3/4.4/4.5 Regression] gcj creates dummy variables
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42143
[Bug middle-end/42749] [4.5 Regression] -O2 and verify_stmts failed again
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug target/42431] [4.5 Regression] wrong code for 200.sixtrack with vectorization and -fdata-sections
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42431
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #16 from mmitchel at gcc dot gnu dot org 2010-02-18 04:40 --- Paolo -- I don't understand why all libstdc++ headers should not have #pragma GCC system_header in them. Would you please explain that? I think there's a semantic hair that we could split about whether they are system headers or compiler headers, but in either case, we never want to warn about them. If we made this note into a warning, we would still warn because we would still see that this is not a system header. Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #5 from mmitchel at gcc dot gnu dot org 2010-01-25 03:14 --- Subject: Bug 42748 Author: mmitchel Date: Mon Jan 25 03:14:25 2010 New Revision: 156202 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156202 Log: PR c++/42748 * config/arm/arm.c (arm_mangle_type): Do not warn about changes to mangling of va_list in system headers. PR c++/42748 * g++.dg/abi/arm_va_list2.C: New test. * g++.dg/abi/arm_va_list2.h: Companion header file. Added: trunk/gcc/testsuite/g++.dg/abi/arm_va_list2.C trunk/gcc/testsuite/g++.dg/abi/arm_va_list2.h Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #6 from mmitchel at gcc dot gnu dot org 2010-01-25 03:16 --- Fixed. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #2 from mmitchel at gcc dot gnu dot org 2010-01-14 19:22 --- Paolo -- I think that the warning is accurate; the mangling of va_list has indeed changed on ARM in GCC 4.4 in order to conform to the ARM ABI specifications. There is an option to turn off warnings about PSABI issues; -Wno-psabi. I think that option (if not some stronger option) should be used. Oh, wait. Maybe we should not warn about this in a system header. That's probably the right choice and a trivial change to arm_mangle_type. Do you agree? -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #4 from mmitchel at gcc dot gnu dot org 2010-01-15 00:17 --- OK, I will fix this one. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug tree-optimization/39251] FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 = .* \+ -
--- Comment #8 from mmitchel at gcc dot gnu dot org 2010-01-15 03:26 --- Ramana -- If I'm reading the log correctly for PR36633 the change that Jason made there didn't actually fix the bug; it was just a cleanup. He commented that something else had changed which made the bug go away. However, if this is behaving different on ARM from (say) x86, I think that the ABI is a likely cause because, as you say, the C++ ABI for these bits is subtly different. Do we know that this is ARM-specific? Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39251
[Bug c++/41153] [4.4 Regression] ICE in building Qt4 src/core
--- Comment #12 from mmitchel at gcc dot gnu dot org 2009-09-01 13:54 --- I think the question is whether the use of __optimize__ is in a standard Qt release. If it is, then I'm quite concerned; it's bad if GCC 4.4.2 can't build Qt/KDE. (TBH, I'm concerned anyhow; if __optimize__ is unreliable, then perhaps we should be ignoring/warning about it in 4.4.x until we get it solid...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41153
[Bug ada/40775] [4.4/4.5 Regression] Ada on ARM ICE in find_valid_class, at reload.c:701
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40775
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #4 from mmitchel at gcc dot gnu dot org 2009-08-31 21:47 --- HJ, this doesn't make sense. Either we can assume 16-byte stack alignment, or we can't. Which is it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc gcc-4.2.x
--- Comment #32 from mmitchel at gcc dot gnu dot org 2009-08-31 21:48 --- Can anyone confirm that this is fixed? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug c++/40808] [4.4/4.5 regression] member template specialization causes ICE
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40808
[Bug c++/41038] [4.4/4.5 regression] Parsing error related to qualified name id
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41038
[Bug c++/41153] [4.4 Regression] ICE in building Qt4 src/core
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41153
[Bug middle-end/40500] [4.5 Regression] Revision 148512 failed to build binutils
--- Comment #9 from mmitchel at gcc dot gnu dot org 2009-08-24 16:10 --- I think maybe it's time for me to get a brain transplant. I had totally forgotten the previous conversation, and read through this entire issue yesterday, and then spent some time thinking about the issue, and clearly reached a totally opposite conclusion. I guess since me and anti-me have different opinions, that just comes out to a zero. I think the opinion I expressed in the previous message holds in general, though; we shouldn't treat adding a warning to -Wall as inherently bad, even though of course every new warning will break some build that uses -Wall -Werror. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40500
[Bug c++/41020] [4.5 Regression] Can't declare an extern C friend.
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug tree-optimization/41112] [4.5 regression] ACATS c43205b fails at -O2 (tree-sra)
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41112
[Bug middle-end/40500] [4.5 Regression] Revision 148512 failed to build binutils
--- Comment #7 from mmitchel at gcc dot gnu dot org 2009-08-24 01:03 --- I think we should leave this warning out of -Wall. There's a lot of legacy C code that may do this kind of stuff. In C++, it's always been invalid, and there's more of an expectation of structured initialization and finalization. Certainly for classes, but even for scalars. I think it's useful to have this warning in C, but I don't think it should be part of -Wall. Anyhow, I've made this P2; it's not a huge issue, but I think we should resolve it one way or the other before 4.5.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40500
[Bug fortran/41043] [4.4/4.5 Regression] virtual memory exhausted: Cannot allocate memory
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41043
[Bug middle-end/41086] [4.5 Regression]: gcc.dg/pr34668-1.c, failing fix for PR41047
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41086
[Bug fortran/41139] [4.5 Regression] a procedure pointer call as actual argument
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41139
[Bug middle-end/40965] [4.5 Regression][graphite] slow compilation
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40965
[Bug tree-optimization/39999] [4.4/4.5 Regression] gcc 4.4.0 compiles in infinite loop
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug bootstrap/39929] [4.5 Regression] Bootstrapping fails at stage 1 on powerpc-ibm-aix
--- Comment #16 from mmitchel at gcc dot gnu dot org 2009-05-05 15:13 --- Jules, is the ARM GNU/Linux build still broken? David, how about AIX? Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.5 Regression]|[4.5 Regression] |Bootstrapping fails at stage|Bootstrapping fails at stage |1 on powerpc-apple-darwin9 |1 on powerpc-ibm-aix |and powerpc-ibm-aix | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929
[Bug libgcj/39747] [4.4/4.5 Regression] Installation documentation should suggest building libgmp as PIC
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Summary|[4.4/4.5 Regression]|[4.4/4.5 Regression] |libjavamath is linking |Installation documentation |against libgmp |should suggest building ||libgmp as PIC http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747
[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to inferior CSE
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Summary|[4.3/4.4/4.5 regression] CSE|[4.3/4.4/4.5 regression] |doesn't work|Code size increase on ARM ||due to inferior CSE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871
[Bug middle-end/39898] [4.5 regression] Revision 146763 caused g++.dg/tree-ssa/ehcleanup-1.C
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39898
[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c
--- Comment #12 from mmitchel at gcc dot gnu dot org 2009-05-05 15:48 --- Yes, we've been discussing the interaction between attributes and the type system for at least a decade. :-) In type-theoretic terms, the address of a packed int has type pointer-to-packed-int, not pointer-to-int. And the latter can be safely converted to the former, but the former cannot be safely converted to the latter. Michael, unfortunately, if it was your change that introduced this regression, you are responsible for solving the problem. The Right Answer, as you suggest, is to include the packed attribute in the type system, but I suspect that will be a major effort. Unfortunately, I don't know what else to suggest... -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
[Bug middle-end/39958] [4.5 Regression] OMP tasking creates invalid gimple
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39958
[Bug tree-optimization/39974] [4.5 regression] Bogus array subscript is below array bounds warning in compiler generated code
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39974
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39978
[Bug c++/39987] [4.3/4.4/4.5 Regression] Rejects default argument that is a template via access failure
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39987
[Bug c/40026] [4.5 Regression] ICE during gimplify_init_constructor
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40026
[Bug target/39856] [4.4/4.5 Regression] ICE in subst_stack_regs_pat, at reg-stack.c:1386
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39856
[Bug c++/39862] [4.5 Regression] verify_eh_tree failed with -O2
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39862
[Bug middle-end/39886] [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2274
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39886
[Bug c/39959] [4.5 Regression] IMA is broken
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39959
[Bug tree-optimization/39960] [4.5 Regression] struct-reorg is broken
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39960
[Bug bootstrap/39977] [4.5 Regression] r146817 broke bootstrap on PA
--- Comment #8 from mmitchel at gcc dot gnu dot org 2009-05-05 16:00 --- Steve -- Is there still an issue here? -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39977
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug middle-end/39666] [4.3/4.4/4.5 Regression] spurious warning with ranged-switch statements
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39666
[Bug middle-end/39927] [4.5 Regression]: build breakage for cris-elf building libstdc++-v3
--- Comment #12 from mmitchel at gcc dot gnu dot org 2009-05-05 16:09 --- HP, is this still a problem? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39927
[Bug tree-optimization/39955] [4.5 Regression] struct-layout-1 test failures passing struct containing _Decimal32
--- Comment #14 from mmitchel at gcc dot gnu dot org 2009-05-05 16:10 --- Janis, is this still an issue? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39955
[Bug middle-end/40022] [4.4 Regression] Alpine miscompilation
--- Comment #11 from mmitchel at gcc dot gnu dot org 2009-05-05 16:11 --- Richard, can this be closed now? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, mmitchel at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug target/30210] [4.5 Regression] Altivec builtins have inaccurate return types
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug middle-end/40022] [4.4 Regression] Alpine miscompilation
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/39801] New: Builtins are assumed not to throw exceptions, even with -fnon-call-exceptions
Some builtin functions are marked as not throwing exceptions, even when -fnon-call-exceptions is in use. As a result, the compiler will assume these functions will not throw exceptions -- but they might. For example, the buitin va_arg might cause a SEGV, which would become an exception, if the pointer provided was invalid. Even builtins which call external library routines might do so, if the routines have themselves been compiled with -fnon-call-exceptions. For more background, see: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00920.html and follow-ups thereto. -- Summary: Builtins are assumed not to throw exceptions, even with -fnon-call-exceptions Product: gcc Version: 4.5.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=39801
[Bug c++/26266] [4.2/4.3/4.4 regression] Trouble with static const data members in template classes
--- Comment #24 from mmitchel at gcc dot gnu dot org 2009-02-21 22:26 --- The problem isn't the database schema; it's keeping it up to date. I'm not actively working on this issue any more, so I've unassigned myself. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26266
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #4 from mmitchel at gcc dot gnu dot org 2009-02-17 02:53 --- The key question is whether the bogus warning could indicate a potential for miscompilation. If it's just a bogus warning, then it's going to annoy and confuse people, but not result in too much damage. But, if this means that we're likely to miscompile things, then we have a worse problem. Of course, until someone demonstrates an actual miscompilation, that's perhaps something of a theoretical problem. I'll leave this as P3 until we know more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39202] [4.4 Regression] internal compiler error: in collapse_rest_of_var, at tree-ssa-structalias.c:3296
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39202
[Bug tree-optimization/39204] [4.4 Regression] ICE in compute_attic
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39204
[Bug libgcj/5303] Undocumented java programs
--- Comment #14 from mmitchel at gcc dot gnu dot org 2009-02-09 16:20 --- Would the Java maintainers accept a patch to remove addr2name.awk? As far as I can tell, it is no longer used after: 2002-08-24 Mark Wielaard m...@klomp.org * Makefile.am (libgcj_la_SOURCES): Remove name-finder.cc. (core_java_source_files): Add VMThrowable.java and NameFinder.java (nat_source_files): Remove natThrowable.cc, add natVMThrowable.cc and natNameFinder.cc. * Makefile.in: Regenerate. * name-finder.cc: Removed. The original introduction was: 2000-03-24 Andrew Haley a...@cygnus.com * Makefile.am: Add file addr2name.awk. * Makefile.in: Rebuilt. * addr2name.awk: New file. * name-finder.cc (_Jv_name_finder): Call addr2name.awk to do name lookups on ia64. I can't find any references to addr2name.awk in the current sourcebase. If it's OK, may I check in the obvious patch to remove all traces from Makefile.am and remove the file itself? Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org, aph at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5303
[Bug libgcj/5303] Undocumented java programs
--- Comment #16 from mmitchel at gcc dot gnu dot org 2009-02-09 22:45 --- Patch to remove addr2name.awk now available here: http://gcc.gnu.org/ml/java-patches/2009-q1/msg00013.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5303
[Bug libgcj/5303] Undocumented java programs
--- Comment #17 from mmitchel at gcc dot gnu dot org 2009-02-09 22:53 --- The patch to remove addr2name.awk has now been committed to mainline. I am not sure what else, if anything, remains on this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5303
[Bug c++/28501] ICE with __real__ and implicit type conversion
--- Comment #5 from mmitchel at gcc dot gnu dot org 2009-02-08 20:53
---
Paolo --
I didn't realize that something like __real__ 3 was valid GNU C; I thought
that the argument had to have complex type. But, it looks like that is not the
case.
Given that, yes, I think the test case should be accepted, as a GNU extension.
When __real__ (or __imag__) is applied to an expression with class type, we
should see if the expression can be converted to any of the built-in types to
which __real__ can ordinarily be applied. If there is only one such type, then
we should use that conversion; if there is more than one, then we should report
the same kind of error used when we have an ambiguous overload. I don't think
we should be trying to deduce anything from the context in which the __real__
expression is being used.
So, your patch looks like a fine start. I'm not sure what it will do for cases
like:
struct A {
operator int();
operator __complex__ double();
template typename T operator __complex__ T();
};
though. As above, I think those cases should be errors, since there's no way
to know which conversion operator to prefer.
-- Mark
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
CC||mmitchel at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28501
[Bug c++/34397] [4.2/4.3/4.4 regression] ICE on invalid default template parameter
--- Comment #21 from mmitchel at gcc dot gnu dot org 2009-02-08 22:35 --- Paolo -- My earlier suggestion to try grok_array_decl may indeed have been misguided. Some of the grok_* functions do more parser-style analysis than we want when processing templates. In theory, the way this ought to work is that we parse for a while, until we know what the user meant, and then call a function that actually generates code. When processing a template, we call that same underlying function after substitution. But, in practice, we may not always have organized things that tidily. In that case, the best fix is to factor out syntactic dismabiguation bits from grok_array_decl, and make a new underlying function that is called from both the parser and the template machinery. -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34397
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
--- Comment #46 from mmitchel at gcc dot gnu dot org 2009-02-02 22:00 --- As I understand it, the complaint here is that GCC_EXEC_PREFIX being set affects HOSTCC, when HOSTCC is itself some other GCC. But, we have to make sure that the newly built compiler searches the right directory. That's why GCC_EXEC_PREFIX is set. (You can fix this by arranging to fix GCC's build process, so that components are installed within the build tree in the same way they would be at install time, and then you can forget all about GCC_EXEC_PREFIX, -B options, and everything else. But, it's a huge project.) HOSTCC is an arbitrary compiler. It need not even be a GNU compiler. DejaGNU, make check, etc. set all manner of random environment variables. Therefore, if you want to be robust, HOSTCC needs to set/unset any environment variables relevant to its operation. -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
