[Bug bootstrap/15212] [4.0/4.1/4.2 Regression] bootstrap fails on interix3
--- Comment #19 from neroden at gcc dot gnu dot org 2006-05-26 18:34 --- I'm afraid I've become very busy and my priorities have changed; I'm not going to get this bug fixed. Unassigning. -- neroden at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|neroden at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
[Bug libstdc++/24712] [4.0 Regression] Accidental ABI change between 4.0.1 and 4.0.2?
--- Comment #5 from neroden at gcc dot gnu dot org 2005-11-08 22:56 --- So Debian is planning to revert allocator choice to fix this, I believe. :-) Technically it's not 'critical' according to the analysis, incidentally. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24712
[Bug libstdc++/24712] New: Accidental ABI change between 4.0.1 and 4.0.2?
:_S_get_pool()::_S_pool +V guard variable for __gnu_cxx::__common_pool<__gnu_cxx::__pool, true>::_S_get_pool()::_S_pool W QValueList::detachInternal() W KonqSoundPlayer::~KonqSoundPlayer() W KonqSoundPlayer::~KonqSoundPlayer() @@ -26,7 +26,7 @@ T KonqSoundPlayerImpl::~KonqSoundPlayerImpl() W __gnu_cxx::__mt_alloc >::deallocate(Arts::TraderOffer*, unsigned int) W __gnu_cxx::__mt_alloc >::deallocate(std::string*, unsigned int) -W __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true>::_S_get_pool() +W __gnu_cxx::__common_pool<__gnu_cxx::__pool, true>::_S_get_pool() W KLibFactory::metaObject() const W QGList::count() const W QObject::metaObject() const @@ -42,4 +42,4 @@ V vtable for KonqSoundFactory V vtable for KonqSoundPlayerImpl V vtable for QGList -V __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true>::_S_get_pool()::_S_pool +V __gnu_cxx::__common_pool<__gnu_cxx::__pool, true>::_S_get_pool()::_S_pool So there's some change going on with __common_pool vs. __common_pool_policy which amounts to a backwards-incompatible change. :-P -- Summary: Accidental ABI change between 4.0.1 and 4.0.2? Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: neroden at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24712
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is out of line and called even for single threaded applications using std::string
--- Comment #2 from neroden at gcc dot gnu dot org 2005-11-07 15:15 --- True, enhancement request. -- neroden at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-07 15:15:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/6257] C-library symbols enter global namespace
--- Comment #15 from neroden at gcc dot gnu dot org 2005-10-03 03:42 --- So there's a problem with the multiple-include-protection in glibc! We actually want to include the headers twice, potentially -- once when included via et al, with everything in namespaces, and once when included directly via et al, with everything outside them. They actually shouldn't conflict because that's the whole *point* of putting stuff in a namespace. But we can't do this in any manner because they have multiple-include protection which can't tell the difference. I think this should be solved in glibc. Feel free to forward this suggestion and this code (which I donate to the public domain) to somewhere appropriate. At the beginning of stdio.h, instead of: #ifndef _STDIO_H #define _STDIO_H we would have: #if ( ( defined __cplusplus && defined _GLIBCPP_USE_NAMESPACES ) \ && ! defined _STDIO_H_WITH_NAMESPACES ) \ || ( (! defined __cplusplus || ! defined _GLIBCPP_USE_NAMESPACES )\ && ! defined _STDIO_H ) #if defined __cplusplus && defined _GLIBCPP_USE_NAMESPACES # define _STDIO_H_WITH_NAMESPACES #else # define _STDIO_H #endif For glibc, _GLIPCPP_USE_NAMESPACES could be defined in before the inclusion of stdio.h and undefined afterwards. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From neroden at gcc dot gnu dot org 2005-07-15
05:50 ---
OK, so in X.org, the key area where this is hit is the definition of
MMIO_IN8 in compiler.h. For alpha, sparc, and powerpc, inline volatile
ASM is used instead (much better in some ways).
The vanishing line is:
(void) minb(hwp->IOBase + VGA_IN_STAT_1_OFFSET);
This expands in preprocessing to:
(void) MMIO_IN8(hwp->MMIOBase, (hwp->MMIOOffset + (hwp->IOBase +
VGA_IN_STAT_1_OFFSET)))
which further expands in preprocessing in compiler.h (except for
sparc, alpha and powerpc) to:
(void) *(volatile CARD8 *)( (CARD8*)(hwp->MMIOBase) + hwp->MMIOOffset +
hwp->IOBase + VGA_IN_STAT_1_OFFSET)
The key expansion is this one:
# define MMIO_IN8(base, offset) \
*(volatile CARD8 *)(((CARD8*)(base)) + (offset))
This obviously doesn't work and perhaps it shouldn't work. But what is a
good alternative implementation? Essentially, we're trying to force a read
of an arbitrary memory address. If the "underlying object" has
to be volatile, how do we make it volatile? Can we simply create a new
"underlying object" by throwing in a temporary pointer variable? Is something
like the following sufficient to force an access?
static inline unsigned char myMmioIn8(volatile void* base,
const unsigned long offset)
{
volatile CARD8 * tmp = (CARD8*)base + offset;
return *tmp;
}
# define MMIO_IN8(base, offset) myMmioIn8(base, offset)
If that's not sufficient, I don't see any way to accomplish the required
behavior under gcc 4.0 (without massive rewriting of the X.org code), so I
hope it is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug ada/20270] [4.1 Regression] Link error: unsatisfied symbols
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-16 11:59 --- Subject: Bug 20270 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-16 11:58:49 Modified files: gcc/ada: Makefile.in ChangeLog Log message: PR ada/20270 * Makefile.in: Make TGT_LIB behave correctly. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/Makefile.in.diff?cvsroot=gcc&r1=1.116&r2=1.117 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gcc&r1=1.662&r2=1.663 --- Additional Comments From neroden at gcc dot gnu dot org 2005-05-16 11:59 --- Committed fix to mainline. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20270
[Bug ada/20270] [4.1 Regression] Link error: unsatisfied symbols
--- Additional Comments From neroden at gcc dot gnu dot org 2005-05-03 01:33 --- I'm waiting for feedback here; because this is a port-specific proble I can't test fixes on my own. Patch in bug trail. -- What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20270
[Bug ada/20270] [4.1 Regression] Link error: unsatisfied symbols
--- Additional Comments From neroden at gcc dot gnu dot org 2005-04-26 03:59 --- Try this patch for ada/Makefile.in: it's the "dumb solution" which might work. --- Makefile.in 7 Apr 2005 19:07:41 - 1.116 +++ Makefile.in 26 Apr 2005 03:58:11 - @@ -245,7 +245,9 @@ # and the system's installed libraries. LIBS = $(LIBINTL) $(LIBIBERTY) $(SYSLIBS) LIBDEPS = $(LIBINTL_DEP) $(LIBIBERTY) -TOOLS_LIBS = $(LIBGNAT) $(EXTRA_GNATTOOLS_OBJS) link.o ../../../libiberty/libiberty.a $(SYSLIBS) +# Default is no TGT_LIB; one might be passed down or something +TGT_LIB = +TOOLS_LIBS = $(LIBGNAT) $(EXTRA_GNATTOOLS_OBJS) link.o ../../../libiberty/libiberty.a $(SYSLIBS) $(TGT_LIB) # Specify the directories to be searched for header files. # Both . and srcdir are used, in that order, -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |neroden at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20270
[Bug middle-end/18628] [4.0 regression] miscompilation of switch statement in loop
-- What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18628
[Bug rtl-optimization/15584] Ada build with stage1 bootstrap compiler fails.
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-13 07:19 --- Looking at the assembly generated for duplicate_insn_chain in cfglayout.c is the next step. (And the intermediate dumps, of course.) I'm highly suspicious, given that the code there features a switch inside a loop, that this is actually an instance of bug #18628. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15584
[Bug target/15780] bootstrap fails on crtstuff
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-13 06:57 --- Subtarget-specific, setting component etc. -- What|Removed |Added Component|bootstrap |target GCC build triplet|i686-pc-linux-gnu |athlon-xp (i686-pc-linux- ||gnu) GCC host triplet|i686-pc-linux-gnu |athlon-xp (i686-pc-linux- ||gnu) GCC target triplet|i686-pc-linux-gnu |athlon-xp (i686-pc-linux- ||gnu) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15780
[Bug regression/19813] [4.0 Regression] gcc 4.0 regression: bad code generation?? due to inlining??
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08 18:58 --- Isn't this most likely to be an out-of-memory issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19813
[Bug bootstrap/17383] [4.0 Regression] Building in src dir fails
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08 18:53 --- I have considered doing this in the truly parallel way: namely, introducing HOST_SUBDIR to go along with BUILD_SUBDIR and TARGET_SUBDIR. It requires mangling of '..'s in many subdirectories, which is why I haven't done it. But if it's done it allows some genuine, major simplifications. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17383
[Bug bootstrap/19420] make install fails if not preceded by make all
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08 18:51 --- This has never worked. It is recommended by the GNU coding standards, but it also requires truly substantial work to get right without forcing rebuilds if 'make all' is followed by 'make install'. Reducing priority and severity. -- What|Removed |Added Severity|normal |enhancement Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19420
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08 18:30 --- >Is a fix likely to get into 4.0? Yes, the hackish fix is in. I hope to get the cleaner fix in, but who knows. >FYI Once I am able to build, the next issue is that the Ada libraries >do not look into newlib's headers and do not have a way to let a >target add specific include directories. See gcc/config/t-rtems for >the OS specific newlib include directory we need. With that resolved, >I think it could build in a single pass. I wouldn't want to touch this until substantially more of the branch went in, so that's probably a 4.1 issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08 17:26 --- Shouldn't the warning killer for system header errors apply to this sort of thing? Apparently it doesn't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-07 23:15 --- Closing. Laurent, I may ask you to test my alternate solution later (when it's ready) though, OK? -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-03 00:57 --- Joel, I'm suspicious that the result you got on the branch should also be happening on mainline; it's happening in a code section which I haven't touched. There's a suspicious-looking difference between Arnaud's configure output for the GCC subdir and yours: Arnauds: checking for .preinit_array/.init_array/.fini_array support... yes Yours: checking for .preinit_array/.init_array/.fini_array support... no -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-03 00:18 --- >Do I need to regenerate configure stuff after your patch (I don't know >how to do it): Yes, you need to run "autoconf" in the gcc subdir. Sorry I forgot to mention that. If you can't do that, I can provide a patch to the generated file, but it's long and tedious. -- Joel, thanks for the branch log. That is indeed an unrelated bug -- almost certainly due to entirely different things I was doing on the branch -- but unfortunately one which shows up earlier in the build. :-( I will try to assemble a patch corresponding to what I would propose to merge from the branch to mainline, since it wouldn't include such changes. Unfortunately I can't seem to figure out how to grab a snapshot of a branch as of a certain date (CVS sucks, I guess), so I'll have to piece it together by hand. More tagging in future. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19489] gnat tools not buildable cross
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |neroden at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-02 04:32 --- Oh -- while we're at it, please make sure that the "gnattools-cross" target is being invoked from the libada directory, and that it is invoking the targets which crash. If it isn't -- if they're being invoked by gnattools-native, for instance -- there's a whole different sort of bug going on. The partial build log did not make that clear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-02 04:22 --- Sorry, that's "gcc/libada-mk", not "gcc/libada.mk". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-02 04:21 --- Oh, drat, I may have figured it out. I need the gcc/libada.mk file produced during the build. I believe there's something wrong with it, but until I see what's produced, I don't know exactly what. Please attach to bug report. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From neroden at gcc dot gnu dot org 2005-01-29 22:19 --- >You may try adding a gnattools directory, whose makefile and configury is based >on libada's, but which is a host module rather than a target module. Correct (dammit). :-) I've already done this on the libada-gnattools-branch, but I've also done some other things there, which wouldn't be suitable for stage 3. Please try a snapshot of the libada-gnattools-branch from... hmm, let's see... December 1, 2004. If it works correctly (and I know it works correctly for native tools), it's safe enough to merge to mainline even in stage 3. I would have done so already, but without a bug report, it wasn't stage-3-suitable. If it doesn't, come back to me; I expect that there's some incremental change on top of it which should sort out any remaining problems. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-29 22:19:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch
--- Additional Comments From neroden at gcc dot gnu dot org 2004-12-10 17:09 --- Oh, cool. :-) Did you get the patch linked up? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019
[Bug bootstrap/15212] [3.4/4.0 Regression] bootstrap fails on interix3
-- What|Removed |Added Status|WAITING |ASSIGNED Last reconfirmed|2004-04-29 21:27:43 |2004-12-10 16:59:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch
--- Additional Comments From neroden at gcc dot gnu dot org 2004-12-02 03:35 --- Jan's message quoted in the previous comment seems to be orthogonal to the main problem in this bug. The problem is that a word fetch is being generated which *reads out of bounds memory*. If the last byte in a page is being fetched, you must not extend that to fetch the next byte; if the first byte in a page is being fetched, you must not extend that to fetch the previous byte. Those are the key failure situations which must be prevented, regardless of whether this is -Os, -O2, or -O0. It doesn't appear to me that the changes proposed in Jan's message actually address that, since none of them seem to feature a alignment or other type of correctness check before converting a QImode move into a (possibly illegal) SImode move. In particular, this statement looks like it's wrong: >while for >TARGET_PARTIAL_REG_STALL/TARGET_PARTIAL_REG_DEPENDENCY we can still use >the full moves as long as they don't encode longer. I believe a check is required that the full moves don't cause a segmentation violation. An alignment check would be sufficient (it would prohibit more cases than strictly necessary, but this is a correctness issue, and I haven't thought of a better check). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019
[Bug bootstrap/15212] [3.4/4.0 Regression] bootstrap fails on interix3
--- Additional Comments From neroden at gcc dot gnu dot org 2004-12-02 03:10 --- I'm taking a look at this. Since I don't have interix, I need help from the bug reporter. Could you try the following? Replace the gcc/config/x-interix file with an empty file (or a file just containing comments), and try bootstrapping. Attach the log. Please try on mainline CVS if possible. Thanks. -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
[Bug preprocessor/17651] [3.4 Regression] Erroneous preprocessor output with -g when generating dependencies
--- Additional Comments From neroden at gcc dot gnu dot org 2004-12-02 02:37 --- fix in 3.4 branch -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17651
[Bug preprocessor/17610] [3.4 Regression] Empty #include statement halts gcc
--- Additional Comments From neroden at gcc dot gnu dot org 2004-12-02 02:37 --- fix in 3.4 -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17610
[Bug preprocessor/17651] [3.4 Regression] Erroneous preprocessor output with -g when generating dependencies
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-28 23:05 --- Aargh wrong bug. -- What|Removed |Added Known to fail|3.4.0 |3.4.0 4.0.0 Known to work|3.3.1 4.0.0 |3.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17651
[Bug tree-optimization/18693] ivopts regression metabug
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-28 23:04 --- Clearly too few to worry about. :-) -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18693
[Bug preprocessor/17651] [3.4 Regression] Erroneous preprocessor output with -g when generating dependencies
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-28 22:33 --- Fix committed to mainline; working on 3.4 backport. -- What|Removed |Added Known to fail|3.4.0 4.0.0 |3.4.0 Known to work|3.3.1 |3.3.1 4.0.0 Summary|[3.4/4.0 Regression]|[3.4 Regression] Erroneous |Erroneous preprocessor |preprocessor output with -g |output with -g when |when generating dependencies |generating dependencies | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17651
[Bug preprocessor/15220] [3.3/3.4/4.0 regression] "gcc -E -MM -MG" reports missing system headers in source directory
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-27 23:18 --- Ow. The dependencies are emitted in open_file_failed in libcpp/files.c; but that routine *doesn't know* whether the file was called for in a <> or a "" directive. Fixing this requires some restructuring of libcpp code so that the dependencies are emitted in a place which does know (perhaps the same place, but that requires a lot of extra information passing). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15220
[Bug preprocessor/17610] [3.4/4.0 Regression] Empty #include statement halts gcc
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-27 22:50 --- I took this. Patch is at http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02423. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17610
[Bug tree-optimization/18048] [4.0 Regression] mgrid loop performance regression with ivopts
-- What|Removed |Added OtherBugsDependingO||18693 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18048
[Bug tree-optimization/17474] [4.0 Regression] Compiling at -01 yields different results
-- What|Removed |Added OtherBugsDependingO||18693 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17474
[Bug middle-end/17549] [4.0 Regression] 35% increase in codesize with C code
-- What|Removed |Added OtherBugsDependingO||18693 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17549
[Bug tree-optimization/18219] [4.0 Regression] gcc-4.0.0 bloats code by 31%
-- What|Removed |Added OtherBugsDependingO||18693 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18219
[Bug tree-optimization/18040] [4.0 Regression] ICE in for_each_index, at tree-ssa-loop-im.c:178
-- What|Removed |Added OtherBugsDependingO||18693 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18040
[Bug tree-optimization/17790] [4.0 Regression] Significant compile time increases for sixtrack with tree LICM and IV optimization
-- What|Removed |Added OtherBugsDependingO||18693 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17790
[Bug tree-optimization/18595] [4.0 Regression] IV-OPTS is O(N^3)
-- What|Removed |Added OtherBugsDependingO||18693 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18595
[Bug tree-optimization/18693] New: ivopts regression metabug
For counting purposes. -- Summary: ivopts regression metabug Product: gcc Version: 3.4.0 Status: UNCONFIRMED Keywords: meta-bug Severity: enhancement Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: neroden at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org BugsThisDependsOn: 17474,17549,17790,18040,18048,18219,18595 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18693
[Bug preprocessor/17610] [3.4/4.0 Regression] Empty #include statement halts gcc
-- What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2004-09-22 21:18:20 |2004-11-27 20:30:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17610
[Bug preprocessor/16621] [4.0 Regression] C4x fails miserably
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-27
18:44 ---
libcpp no longer uses HOST_WIDE_INT.
The computation which leads to the error is done in c-decl.c in "target
arithmetic" as follows:
/* Compute the maximum valid index, that is, size
- 1. Do the calculation in index_type, so that
if it is a variable the computations will be
done in the proper mode. */
itype = fold (build2 (MINUS_EXPR, index_type,
convert (index_type, size),
convert (index_type,
size_one_node)));
/* If that overflowed, the array is too big. ???
While a size of INT_MAX+1 technically shouldn't
cause an overflow (because we subtract 1), the
overflow is recorded during the conversion to
index_type, before the subtraction. Handling
this case seems like an unnecessary
complication. */
if (TREE_OVERFLOW (itype))
{
error ("size of array %qs is too large", name);
type = error_mark_node;
continue;
}
This looks OK.
Steven, can you possibly check to see whether this bug still exists in
mainline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16621
[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-27 18:28 --- I suggest excising the TARGET_PARTIAL clauses ASAP, and reinstating them only when alignment checking (and/or something else) is used in them to verify that the transform is safe. That seems to be the most correct thing to do. If someone is up to writing the alignment checking right now, of course, that's great, but I'm not! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019
[Bug preprocessor/13726] [3.3/3.4/4.0 regression]cpp -C -dI loses comments on same line as #include directives
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-27 02:39 --- libcpp turns off save_comments in start_directive, near the start of _cpp_handle_directive (all in directives.c). This is arguably mistaken, but there's probably a reason for it, so I'm loathe to just remove it unconditionally. :-P -- What|Removed |Added Known to fail|4.0 3.4.0 |4.0.0 3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13726
[Bug tree-optimization/17474] [4.0 Regression] Compiling at -01 yields different results
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-27 02:14 --- One of the patches is in; the other one generated a lot of debate and is apparently not sufficient, so removing patch tag. -- What|Removed |Added Keywords|patch | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17474
[Bug target/17224] [3.4/4.0 Regression]: relocation truncated to fit: GPREL22
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-27 02:05 --- Does the back end need a "number too big for the assembler" hook? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17224
[Bug preprocessor/17651] [3.4/4.0 Regression] Erroneous preprocessor output with -g when generating dependencies
-- What|Removed |Added Keywords||patch Last reconfirmed|2004-11-27 01:31:48 |2004-11-27 01:32:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17651
[Bug preprocessor/17651] [3.4/4.0 Regression] Erroneous preprocessor output with -g when generating dependencies
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-27 01:31 --- Created an attachment (id=7615) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7615&action=view) Fix The line marker is suppressable (unsurprisingly) with -P. It also shows up with -dM, etc. I'm pretty sure the correct solution is to check flag_no_output whereever flag_no_line_commands is checked, which is to say precisely one missing place. Patch attached. I'm going to run this through full regression testing and submit it. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |neroden at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17651
[Bug middle-end/17564] [4.0 Regression] New treatment of function pointers when used with equality operators, when casts are involved
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-27 00:53 --- I'm going to guess that one solution is to canonicalize any function pointer any time it's cast to a void pointer. (Or do you really, really want noncanonicalized pointers, which is likely to be harder?) This probably requires recognition at tree level that casts from function pointer to void pointer may be necessary (among other things). >From tree_ssa_useless_type_conversion_1 in tree_ssa.c: /* If both types are pointers and the outer type is a (void *), then the conversion is not necessary. The opposite is not true since that conversion would result in a loss of information if the equivalence was used. Consider an indirect function call where we need to know the exact type of the function to correctly implement the ABI. */ else if (POINTER_TYPE_P (inner_type) && POINTER_TYPE_P (outer_type) && TYPE_MODE (inner_type) == TYPE_MODE (outer_type) && TYPE_REF_CAN_ALIAS_ALL (inner_type) == TYPE_REF_CAN_ALIAS_ALL (outer_type) && TREE_CODE (TREE_TYPE (outer_type)) == VOID_TYPE) return true; So it seems that this type conversion isn't useless when converting from a function pointer to a void pointer (on targets where function pointers need canonicalization); it requires a canonicalization. (Or a forcing of non-canonicalization, which sounds harder.) Confirming. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-27 00:53:19 date|| Summary|[4.0 Regression] New|[4.0 Regression] New |treatment of function |treatment of function |pointers when used with |pointers when used with |equality operators |equality operators, when ||casts are involved http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17564
[Bug middle-end/17982] [4.0 regression] asm declaration ignored due to conflict with previous rename
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-27 00:30 --- HJ's latest patch probably doesn't fix the problem entirely :-(, but it is certainly correct to allow "renames" which don't change anything. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug c++/18514] [3.4/4.0 Regression] Alternate "asm" name ignored for redeclared builtin function imported into namespace std
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-27 00:20 --- In 3.4.2 (Debian's version), I can import into *any* namespace (xxx, for instance) and get the same "problem". However, it *is* essential that the function be "snprintf", and not "bar". fancy_snprintf is invoked if gcc is invoked with -fno-builtin-snprintf. So this looks like an issue with builtins; the builtin is not being overridden by the explicit declaration. I believe this is semi-documented behavior, though I suppose it could be documented better. In 4.0.0, this indeed only happens when importing into std (otherwise fancy_snprintf is used). It still must be "snprintf" rather than, for instance, "bar", and the problem still goes away when -fno-builtin-snprintf is used. So it still seems to be a problem with builtins, but for some reason 4.0 treats importing a builtin into std differently from importing it into xxx, while 3.4 doesn't (so this bug should be hit *more* in 3.4). Resummarizing to note that this is strictly a builtin issue. -- What|Removed |Added Known to fail||3.4.2 4.0.0 Last reconfirmed|2004-11-16 04:37:01 |2004-11-27 00:20:57 date|| Summary|[3.4/4.0 Regression]|[3.4/4.0 Regression] |Alternate "asm" name ignored|Alternate "asm" name ignored |for function imported into |for redeclared builtin |namespace std |function imported into ||namespace std http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18514
[Bug c++/17053] [4.0 Regression] Repo functionality partially broken on AIX (collect2.c)
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-26 23:28 --- DJE said he'd develop the collect2 fix, so assigning... -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dje at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Summary|[4.0 Regression] Repo |[4.0 Regression] Repo |functionality partially |functionality partially |broken on AIX |broken on AIX (collect2.c) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17053
[Bug c++/15674] [3.3/3.4/4.0 Regression] [DR214] template argument binding differs between member and static fumctions
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-26 23:22 --- Nathan's conclusion was that neither case was a regression (although both were wrong-code bugs). Should the "Regression" tag be removed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15674
[Bug c/14635] [3.3 Regression] nan functions should not be C90 built-ins
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-26 23:07 --- This bug is fixed on mainline and 3.4.x; nan functions are not currently C90 builtins. Please open a different bug if there are other problems with nan builtin handling on mainline; meanwhile I'm marking 3.4.3 and 4.0.0 as known-to-work. I believe this is currently open solely for the 3.3.x branch? -- What|Removed |Added Known to work||3.4.3 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14635
