[Bug c++/30340] pure virtual function called on const & declared with previous declaration without a definition, const & assigned by temporary
--- Comment #5 from gdr at integrable-solutions dot net 2007-01-01 09:47 --- Subject: Re: pure virtual function called on const & declared with previous declaration without a definition, const & assigned by temporary "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | For the last question on this code: | C c(1, B()); | | What is the life time of the temp that holds B()? That temporary is destroyed at the of the declaration of "c" -- e.g. "right before the semicolon" if I'm allowed that expression. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30340
[Bug bootstrap/30341] New: Makefile using mv instead of ln not working on WinXP Cygwin Bash
I am compiling on WinXP using Cygwin's Bash - I compiled 4.1.1 OK but not 4.2.0 (CVS). The makefile works away for a long time and finally stops - unfinished. What I did to fix it: After you run the ./configure script there will be a makefile in your build directory. Open it in wordpad and also open the makefile from your 4.1.1 build in another wordpad window. Goto the wordpad with the 4.1.1 Makefile and search for the text "stage1-start::" . Do the same with the 4.2.0 Makefile. Rename the 4.2.0 "stage?-start::" sections to "Origonal-stage?-start::" and the 4.2.0 "stage?-end::" sections to "Origonal-stage?-end::". Now copy the 4.1.1 "stage?-start::" and 0 "stage?-end::" sections into the 4.2.0 Makefile at each appropriate place. Hope that is clear. You _could_ also fixup "stageprofile-start::" while you are there, I did in my Makefile but have not yet typed "make stageprofile" to test if profiled building is working in 4.2.0. Don't forget that 4.2.0 has an extra directory that is not in 4.1.1 (libdecnumber) so in each of the "stage?-start/end" sections you will need to add a couple of lines for the libdecnumber directory. I found that the 4.1.1 Makefile worked perfectly (for 4.1.1) and adding those sections into the 4.2.0 Makefile caused it to work correctly. Prior to making this fix I was unable to get make to build properly. It kept trying to coping the directories into each other instead of renaming them and shuffling them (if that is how it could best be described). The 4.2.0 Makefile says "We use mv on platforms where symlinks to directories do not work or are not reliable." I've not got to running down why the configure script chose the "mv method" but it breaks on Windows XP (for me). Other people claim to have done a cygwin build (with far fewer things enabled) but they might not have built it on Windows XP (where "ln" works fine and "mv" copies into the directory instead of overwriting the directory - it is not "dos" "copy"). If the maintainers where to use the 4.1.1 release version "style of operation" for the stages of the 4.2.0 (CVS) make then it would work properly (for me and I imagine for others too - not a lot of WinXP builds reported). Here is a tiny portion of one stage of the 4.2.0 makefile to further demonstrate: # * We build only C (and possibly Ada). .PHONY: stage1-start stage1-end Origonal-stage1-start:: @: $(MAKE); $(stage); \ echo stage1 > stage_current ; \ echo stage1 > stage_last; \ $(SHELL) $(srcdir)/mkinstalldirs $(HOST_SUBDIR) @cd $(HOST_SUBDIR); [ -d stage1-gcc ] || \ mkdir stage1-gcc; \ mv stage1-gcc gcc @cd $(HOST_SUBDIR); [ -d stage1-intl ] || \ mkdir stage1-intl; \ mv stage1-intl intl @cd $(HOST_SUBDIR); [ -d stage1-libcpp ] || \ mkdir stage1-libcpp; \ mv stage1-libcpp libcpp @cd $(HOST_SUBDIR); [ -d stage1-libdecnumber ] || \ mkdir stage1-libdecnumber; \ mv stage1-libdecnumber libdecnumber @cd $(HOST_SUBDIR); [ -d stage1-libiberty ] || \ mkdir stage1-libiberty; \ mv stage1-libiberty libiberty @cd $(HOST_SUBDIR); [ -d stage1-zlib ] || \ mkdir stage1-zlib; \ mv stage1-zlib zlib @[ -d stage1-$(TARGET_SUBDIR) ] || \ mkdir stage1-$(TARGET_SUBDIR); \ mv stage1-$(TARGET_SUBDIR) $(TARGET_SUBDIR) Origonal-stage1-end:: @if test -d $(HOST_SUBDIR)/gcc ; then \ cd $(HOST_SUBDIR); mv gcc stage1-gcc ; \ fi @if test -d $(HOST_SUBDIR)/intl ; then \ cd $(HOST_SUBDIR); mv intl stage1-intl ; \ fi @if test -d $(HOST_SUBDIR)/libcpp ; then \ cd $(HOST_SUBDIR); mv libcpp stage1-libcpp ; \ fi @if test -d $(HOST_SUBDIR)/libdecnumber ; then \ cd $(HOST_SUBDIR); mv libdecnumber stage1-libdecnumber ; \ fi @if test -d $(HOST_SUBDIR)/libiberty ; then \ cd $(HOST_SUBDIR); mv libiberty stage1-libiberty ; \ fi @if test -d $(HOST_SUBDIR)/zlib ; then \ cd $(HOST_SUBDIR); mv zlib stage1-zlib ; \ fi @if test -d $(TARGET_SUBDIR) ; then \ mv $(TARGET_SUBDIR) stage1-$(TARGET_SUBDIR) ; \ fi rm -f stage_current stage1-start:: @: $(MAKE); $(stage); \ echo stage1 > stage_current ; \ echo stage1 > stage_last; \ $(SHELL) $(srcdir)/mkinstalldirs $(HOST_SUBDIR) $(TARGET_SUBDIR) @cd $(HOST_SUBDIR); [ -d stage1-gcc ] || \ mkdir stage1-gcc; \ set stage1-gcc gcc ; \ ln -s $$1 $$2 @cd $(HOST_SUBDIR); [ -d stage1-intl ] || \ mkdir stage1-intl; \ set stage1-intl intl ; \ ln -s $$1 $$2 @cd $(HOST_SUBDIR); [ -d stage1-libcpp ] || \ mkdir stage1-libcpp; \ set stage1-libcpp libcpp ; \ ln -s $$1 $$2 @cd $(HOST_SUBDIR); [ -d stage1-libdecnumber ] || \
[Bug bootstrap/30342] New: Tough time building 4.2.0 (CVS) on WinXP with Cygwin
I had a lot of trouble getting __everything__ to work. I've tried rebuilding a few times this last month and have managed to get everything (really) working except I can not compile ada (I will try some more). Here is the output of gcc-v : Using built-in specs. Target: athlon_xp-pc-cygwin Configured with: /cygdrive/C/makecygwin/gcc-4_2-branch/configure --disable-werror --verbose --target=athlon_xp-pc-cygwin --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-static --enable-nls --enable-multilib --without-included-gettext --enable-version-specific-runtime-libs --with-gxx-include-dir=/include/c++/4.2.0 --enable-libstdcxx-debug --enable-libgcj --enable-libgcj-debug --enable-java-awt=gtk,xlib --enable-java-gc=boehm --enable-objc-gc --with-system-zlib --enable-threads=posix --without-tls --enable-sjlj-exceptions --enable-hash-synchronization --enable-libada --enable-libssp --enable-libmudflap --enable-win32-registry --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-cpu=athlon-xp --with-arch=athlon-xp --with-tune=athlon-xp athlon_xp-pc-cygwin Thread model: posix gcc version 4.2.0 20061225 (prerelease) I have mudflaps and gomp working on Windows XP. I also used --with-x . Here are some notes for any having trouble enabling every possible flag on WinXP (good for testing but it takes two days to compile). This may be verbose. These notes assume 80 columns - hope this input window does too. I try to fix them up. This is some info to encourage people to attempt to build gcc for Windows XP using the Cygwin environment (get setup program from: http://www.cygwin.com/) . The end result is a new compiler tool chain with "c" and "fortran" that pass almost every test, the "ada" will not build and there are quite a few errors in the other packages. I am enabling ssp, gomp, mudflap, awt - these are not working too badly, but need a maintainer to do some fixing. I have read http://gcc.gnu.org/install/specific.html#windows . It claims "GCC will build under Cygwin without modification". I did not find I was able to build either 4.1.1 release or 4.2.0 prerelease "as is". Hopefully the info that follows will point out some bugs / shortcomings and encourage others to try. The page http://gcc.gnu.org/gcc-4.2/buildstat.html is EMPTY! I will limit much of the following to 4.2.0 ONLY - but to build gcc with Cygwin you can only start from an old version of gcc. The Cygwin Setup program uses gcc 3.4.4-3 as the "newest" version. To go from gcc 3.4.4-3 (release) to 4.2.0 (prerelease) it is advisable to build 4.1.1 (release) along the way. The gcc 3.4.4-3 version is so old that it will reject many of the gcc options that the makefiles pass to it, you don't want to remove to many features. When jumping a "major" version number it is best to use a release version of the same version (4.1.1) to build an experimental version 4.2.0 (prerelease). I know that version 4.1.2 fixes many of the troubles with 4.1.1 but that version was not a 'release' version at the time of this writing and you are going to build 4.2.0 anyway so I do not suggest 4.1.2 but the choice is yours. Make sure you build gcc with "--enable-threads=posix" and NOT "--enable-threads=win32" on Cygwin / Windows XP or you'll find that many Linux / Unix programs will not compile properly. I am enabling (almost) every possible ./configure option possible in my build. If you want to use the same options as I did (to duplicate my test and fix whats broken - HINT to maintainers try compiling gcc for Windows XP) you will need to get the following (I hope this is a complete list - see the installation page http://gcc.gnu.org/install/index.html for more info): 1) Base - select to install everything 2) Devel - autoconf, automake, binutils, bison, byacc, cvs, cvsutils, dejagnu, doxygen, flex, gcc-* (everything starting with the words "gcc-"), gettext, gettext-devel, guile-1.6.7-4 (click the "S" box to get guile source code - don't use a newer version), make, pkg-config, readline, (hope I didn't miss anything). 3) Gnome - atk, glib, gtk, pango 3) Publishing - tetex-* 4) Utils - cygutils, file, patch, time, upx 5) X11- select to install everything 6) Other - goto http://www.gimp.org/~tml/gimp/win32/downloads.html and get the newest gimp. atk-1.12.3.zip, cairo-1.2.6.zip, glib-2.12.6.zip, gtk+-2.10.6.zip, pango-1.14.8.zip, libiconv-1.9.1.bin.woe32.zip, and gettext-0.14.5.zip. You need both the 'cygwin setup' versions and the 'gimp website' version. You'll need to write .pc files for them and use "cygcheck -c" to make sure they are found. In addition you may want to get "Mortens Cygwin X-L
[Bug libfortran/30162] I/O with named pipes does not work
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-01-01 15:17 --- (In reply to comment #7) > I have formatted named pipe I/O working, at least for the equivalent test > cases > given here. Great! If you want me to, I'll be willing to test your patch. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
[Bug c++/30340] pure virtual function called on const & declared with previous declaration without a definition, const & assigned by temporary
--- Comment #6 from fang at csl dot cornell dot edu 2007-01-01 16:42 --- You can confirm the lifetime of B() by printing something during its destruction, and during the constructor of C. You'll be left with a dangling reference to a temporary whose vptr has been invalidated, hence the error message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30340
[Bug c++/30340] pure virtual function called on const & declared with previous declaration without a definition, const & assigned by temporary
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-01-01 16:57 --- Invalid as the life time of B() ends after the assigmnet statement ends so the code is undefined after that point. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30340
[Bug libfortran/30162] I/O with named pipes does not work
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-01-01 17:51
---
Preliminary patch for formatted only.
Index: io/unix.c
===
*** io/unix.c (revision 120301)
--- io/unix.c (working copy)
*** fd_flush (unix_stream * s)
*** 349,355
size_t writelen;
if (s->ndirty == 0)
! return SUCCESS;;
if (s->physical_offset != s->dirty_offset &&
lseek (s->fd, s->dirty_offset, SEEK_SET) < 0)
--- 349,358
size_t writelen;
if (s->ndirty == 0)
! return SUCCESS;
!
! if (s->file_length == -1)
! return SUCCESS;
if (s->physical_offset != s->dirty_offset &&
lseek (s->fd, s->dirty_offset, SEEK_SET) < 0)
*** fd_sfree (unix_stream * s)
*** 562,567
--- 565,574
static try
fd_seek (unix_stream * s, gfc_offset offset)
{
+
+ if (s->file_length == -1)
+ return SUCCESS;
+
if (s->physical_offset == offset) /* Are we lucky and avoid syscall? */
{
s->logical_offset = offset;
*** static try
*** 583,589
fd_truncate (unix_stream * s)
{
if (lseek (s->fd, s->logical_offset, SEEK_SET) == -1)
! return FAILURE;
/* non-seekable files, like terminals and fifo's fail the lseek.
Using ftruncate on a seekable special file (like /dev/null)
--- 590,596
fd_truncate (unix_stream * s)
{
if (lseek (s->fd, s->logical_offset, SEEK_SET) == -1)
! return SUCCESS;
/* non-seekable files, like terminals and fifo's fail the lseek.
Using ftruncate on a seekable special file (like /dev/null)
*** fd_to_stream (int fd, int prot)
*** 1009,1015
/* Get the current length of the file. */
fstat (fd, &statbuf);
! s->file_length = S_ISREG (statbuf.st_mode) ? statbuf.st_size : -1;
s->special_file = !S_ISREG (statbuf.st_mode);
fd_open (s);
--- 1016,1027
/* Get the current length of the file. */
fstat (fd, &statbuf);
!
! if (lseek (fd, 0, SEEK_CUR) == (off_t) -1)
! s->file_length = -1;
! else
! s->file_length = S_ISREG (statbuf.st_mode) ? statbuf.st_size : -1;
!
s->special_file = !S_ISREG (statbuf.st_mode);
fd_open (s);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
[Bug target/29281] natPlainDatagramSocketImpl.cc:148: internal compiler error
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-01-01 18:27 --- No feedback in 3 months. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29281
[Bug c/30343] New: False positive: allocating zero-element array
Hi,
The following code produces a false positive warning "allocating zero-element
array".
template class Array
{
public:
Array() {
if (size) {
new T[size];
}
}
};
void foo() {
Array bar;
}
the new command is guarded by a if(size). So allocating a zero size array is
impossible. It would be really nice if gcc could check for this condition,
also.
Thanks,
Gregor
--
Summary: False positive: allocating zero-element array
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gjasny at web dot de
GCC build triplet: gcc version 4.2.0 20061217 (prerelease) (Debian 4.2-
20061217-1)
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30343
[Bug c++/30344] New: template type argument cannot be initialized by a default parameter
The following code sample is compiled by several other compilers. Gcc compiles
the following example, when the function f is put into the global scope.
The example can also be compiled, when v has only a single template parameter.
template
class v { };
class c2 {
void f(const v &t = v()) { }
};
int main() { }
The code cannot be compiled by gcc 3.4, 4.1.2 and 4.2
In the example it is of course essential that t is a _constant_ reference.
Bernd Donner
--
Summary: template type argument cannot be initialized by a
default parameter
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Bernd dot Donner at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30344
[Bug c++/30344] template type argument cannot be initialized by a default parameter
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-01 19:02 --- *** This bug has been marked as a duplicate of 57 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30344
[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument
--- Comment #33 from pinskia at gcc dot gnu dot org 2007-01-01 19:02 --- *** Bug 30344 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||Bernd dot Donner at gmx dot ||net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
[Bug c/30343] False positive: allocating zero-element array
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-01 19:03 --- *** This bug has been marked as a duplicate of 4210 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30343
[Bug middle-end/4210] should not warning with dead code
--- Comment #19 from pinskia at gcc dot gnu dot org 2007-01-01 19:03 --- *** Bug 30343 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gjasny at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
[Bug middle-end/30253] [4.3 Regression] ICE with statement expression inside a conditional
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-01-01 19:21 --- I am going to test this and then apply it as obvious once the testing is finished. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30253
[Bug c++/30340] pure virtual function called on const & declared with previous declaration without a definition, const & assigned by temporary
--- Comment #8 from mjtruog at fastmail dot ca 2007-01-01 20:34 --- Thank you for looking at this. My mistake. I didn't realize that when you assign a temporary to a const &, the object is still destroyed after the assignment (and should then not be used in such a way, since the contents is undefined). -- mjtruog at fastmail dot ca changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30340
[Bug middle-end/30322] ((-i-1) + i) +1) is turned into ~i + (i+1) and never into 0 on the tree level
--- Comment #3 from roger at eyesopen dot com 2007-01-01 20:46 --- Hi Richard (Happy New Year), I was wondering whether you could confirm whether the patch I committed fixes the loop termination conditions in tramp3d? It resolves the example code given in the description which now reduces to "return 0;", but I'm curious if this is sufficient to catch the underlying problem or whether we really need a tree combiner and/or reassociation in order to optimize these loops. Thanks in advance, Roger -- roger at eyesopen dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-01 20:46:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30322
[Bug fortran/25135] [4.2 and 4.1 only] Interface name does not conflict with subroutine name
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-01 20:47 --- I seem not to have taken this one on. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-02-26 20:07:48 |2007-01-01 20:47:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25135
[Bug target/30230] Incorrect ia64 EH info when an EH region ends in the middle of a bundle
--- Comment #4 from wilson at gcc dot gnu dot org 2007-01-01 21:00 --- Fixed by Jakub's patch for 4.1, 4.2, and mainline. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30230
[Bug preprocessor/29966] crash in cc1 with backtrace from free()
--- Comment #9 from patchapp at dberlin dot org 2007-01-01 21:53 --- Subject: Bug number PR preprocessor/29966 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01848.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
[Bug preprocessor/28165] _Pragma GCC system_header broken
--- Comment #3 from patchapp at dberlin dot org 2007-01-01 21:56 --- Subject: Bug number PR preprocessor/28165 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01850.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28165
[Bug preprocessor/19753] different LANG settings and ccache don't work together
--- Comment #2 from patchapp at dberlin dot org 2007-01-01 21:57 --- Subject: Bug number PR preprocessor/19753 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01851.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19753
[Bug preprocessor/28709] [4.0/4.1 regression] Bad diagnostic pasting tokens with ##
--- Comment #5 from patchapp at dberlin dot org 2007-01-01 21:57 --- Subject: Bug number PR preprocessor/28709 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01852.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28709
[Bug preprocessor/22168] #if #A == #B should have a diagnostic in ISO C mode
--- Comment #14 from patchapp at dberlin dot org 2007-01-01 21:57 --- Subject: Bug number PR preprocessor/22168 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01853.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22168
[Bug fortran/25080] ICE/missing error on different ranks for dummy and actual arguments
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-01 21:58 --- (In reply to comment #2) > We now reject the reporter's code as we should. We could still reject the code > in comment #1, but none of the other compilers I tried reject it. Marking this > as low priority (I think it will be fixed by Paul Thomas' patch for in-file > checking). > 12.4.1.1 Actual arguments associated with dummy data objects If the dummy argument is an assumed-shape array, the rank of the dummy argument shall agree with the rank of the actual argument. 12.4.1.4 Sequence association The rank and shape of the actual argument need not agree with the rank and shape of the dummy argument, but the number of elements in the dummy argument shall not exceed the number of elements in the element sequence of the actual argument. If the dummy argument is assumed-size, the number of elements in the dummy argument is exactly the number of elements in the element sequence. Apart from the requirement on the number of elements in the dummy (PR25071), gfortran complies with the standard and, as noted already, fixes the original bug. I am therefore marking this bug as fixed. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25080
[Bug target/29166] broken unwind information for many life variables resulting in register corruption
--- Comment #6 from schwab at gcc dot gnu dot org 2007-01-01 22:03 --- Subject: Bug 29166 Author: schwab Date: Mon Jan 1 22:03:23 2007 New Revision: 120319 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120319 Log: PR target/29166 * config/ia64/ia64.c (ia64_compute_frame_size): Account space for save of BR0 in extra_spill_size instead of spill_size. (ia64_expand_prologue): Save BR0 outside of the gr/br/fr spill area. (ia64_expand_epilogue): Restore BR0 from its new location. testsuite/: * g++.dg/eh/pr29166.C: New test. Added: trunk/gcc/testsuite/g++.dg/eh/pr29166.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/ia64.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29166
[Bug target/29166] broken unwind information for many life variables resulting in register corruption
--- Comment #7 from schwab at gcc dot gnu dot org 2007-01-01 22:07 --- Subject: Bug 29166 Author: schwab Date: Mon Jan 1 22:07:30 2007 New Revision: 120320 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120320 Log: PR target/29166 * config/ia64/ia64.c (ia64_compute_frame_size): Account space for save of BR0 in extra_spill_size instead of spill_size. (ia64_expand_prologue): Save BR0 outside of the gr/br/fr spill area. (ia64_expand_epilogue): Restore BR0 from its new location. testsuite/: * g++.dg/eh/pr29166.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/eh/pr29166.C Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/ia64/ia64.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29166
[Bug c++/30348] New: '#define false FALSE' undefines '#define FALSE false'
I ran into an issue where doing #define FALSE false followed by #define false
FALSE undefined the first FALSE which is not what I would expect.
Perhaps this is part of the standard, but in case not, I'm reporting it.
---
#define FALSE false
#define TRUE true
#ifndef true
#define true TRUE
#endif
#ifndef false
#define false FALSE
#endif
main() {
bool test1 = FALSE;
bool test2 = TRUE;
}
[envy viewer] g++ test.cc
test.cc: In function `int main()':
test.cc:13: error: `FALSE' undeclared (first use this function)
test.cc:13: error: (Each undeclared identifier is reported only once for each
function it appears in.)
test.cc:14: error: `TRUE' undeclared (first use this function)
--
Summary: '#define false FALSE' undefines '#define FALSE false'
Product: gcc
Version: 3.3.6
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h8_spam at sonic dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30348
[Bug target/29166] broken unwind information for many life variables resulting in register corruption
--- Comment #8 from schwab at suse dot de 2007-01-01 22:11 --- Fixed for 4.2+. -- schwab at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29166
[Bug middle-end/30253] [4.3 Regression] ICE with statement expression inside a conditional
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-01-01 22:20 --- Subject: Bug 30253 Author: pinskia Date: Mon Jan 1 22:19:58 2007 New Revision: 120321 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120321 Log: 2007-01-01 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/30253 * gimplify (voidify_wrapper_expr): Update for GIMPLIFY_MODIFY_STMT. 2007-01-01 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/30253 * gcc.c-torture/compile/statement-expression-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/statement-expression-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30253
[Bug middle-end/30253] [4.3 Regression] ICE with statement expression inside a conditional
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-01-01 22:21 --- Fixed. Thanks both for the report. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30253
[Bug c++/30348] '#define false FALSE' undefines '#define FALSE false'
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-01 22:34 ---
so what is happening here is the following:
#define FALSE false
#define false FALSE
bool a = FALSE;
So we get again:
bool a = FALSE;
This is the same problem as:
int b;
#define a b
#define b a
int main() {
int test2 = a;
}
also true/false are not defined in C++ but rather they are keywords
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30348
[Bug c++/30348] '#define false FALSE' undefines '#define FALSE false'
--- Comment #2 from h8_spam at sonic dot net 2007-01-01 22:43 --- Right, but since true and false are keywords, I would expect the #define true TRUE and false FALSE to be no-ops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30348
[Bug c++/30348] '#define false FALSE' undefines '#define FALSE false'
--- Comment #3 from h8_spam at sonic dot net 2007-01-01 22:44 --- So I would expect it NOT to be the same as the a b b a example you give. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30348
[Bug debug/8354] Incorrect DWARF-2/3 emitted for const + array
--- Comment #12 from gary at intrepid dot com 2007-01-01 22:47 --- Jim Wilson posted thi follow up to the GDB list: http://sourceware.org/ml/gdb/2007-01/msg7.html From: Jim Wilson Date: Mon, 01 Jan 2007 14:15:47 -0800 Subject: RE: how to support C type qualifiers applied to arrays? On Thu, 2006-12-14 at 12:22 -0800, Gary Funck wrote: > The main difficulty is that GCC doesn't create new qualified > types for declarations. Rather, it sets TREE_READONLY() > and TREE_THIS_VOLATILE() in the DECL node for declarations > such as: >volatile int A[10]; If you look at the types created by the C front end, they are OK. c_build_qualified_type knows how to handle an array correctly. The problem arises in the DWARF2 output code. gen_type_die calls type_main_variant for all types other than vector types, which strips off the const and volatile type modifiers. Then it clumsily tries to put them back later in gen_variable_die, except that for array types, it puts them back in the wrong place. This seems to answer the question I asked long ago. Why are we trying to put back qualifiers from the decl? Because gen_type_die stripped them off. This seems wrong. If we fix gen_type_die to stop calling type_main_variant, and if we fix gen_variable_die to stop adding back the type qualifiers, then I get the right result. So I think I was on the right track before, we just need another little change to gen_type_die in addition to what I already described. I haven't investigated this in detail yet. There may be other parts of the code that expect to see a type main variant here, so we might need other cascading fixes. This still seems fixable to me though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8354
[Bug preprocessor/21521] -finput-charset -save-temps converts characters twice
--- Comment #4 from patchapp at dberlin dot org 2007-01-01 22:55 --- Subject: Bug number PR preprocessor/21521 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00027.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21521
Re: [Bug c++/30348] '#define false FALSE' undefines '#define FALSE false'
On Mon, 2007-01-01 at 22:43 +, h8_spam at sonic dot net wrote: > Right, but since true and false are keywords, I would expect the > #define true > TRUE and false FALSE to be no-ops. How? Preprocessing happens before tokenazation happens. -- Pinski
[Bug c++/30348] '#define false FALSE' undefines '#define FALSE false'
--- Comment #4 from pinskia at gmail dot com 2007-01-01 23:37 --- Subject: Re: '#define false FALSE' undefines '#define FALSE false' On Mon, 2007-01-01 at 22:43 +, h8_spam at sonic dot net wrote: > Right, but since true and false are keywords, I would expect the > #define true > TRUE and false FALSE to be no-ops. How? Preprocessing happens before tokenazation happens. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30348
[Bug pch/13675] #including a precompiled header more than once in the same unit fails
--- Comment #14 from tim at klingt dot org 2007-01-01 23:53 --- this is still a problem in the 4.2 branch -- tim at klingt dot org changed: What|Removed |Added CC||tim at klingt dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13675
[Bug middle-end/30311] [4.3 regression] revision 120211 failed to compile perlbench
--- Comment #5 from jsm28 at gcc dot gnu dot org 2007-01-02 00:38 --- Subject: Bug 30311 Author: jsm28 Date: Tue Jan 2 00:38:21 2007 New Revision: 120329 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120329 Log: gcc: PR middle-end/30311 * caller-save.c (add_stored_regs): Only handle SUBREGs if inner REG is a hard register. Do not modify REG before calling subreg_nregs. * rtlanal.c (subreg_get_info): Don't assert size of XMODE is a multiple of the size of YMODE for certain lowpart cases. gcc/testsuite: * gcc.c-torture/compile/pr30311.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr30311.c Modified: trunk/gcc/ChangeLog trunk/gcc/caller-save.c trunk/gcc/rtlanal.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30311
[Bug middle-end/30349] New: gcc/libssp/ssp.c:177: ICE: in cgraph_expand_all_functions, at cgraphunit.c:1220
/test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu/gcc/gcc -4.3.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.3.0/hppa2.0w-hp-hpux11.11 /lib/ -isystem /opt/gnu/gcc/gcc-4.3.0/hppa2.0w-hp-hpux11.11/include -isystem /op t/gnu/gcc/gcc-4.3.0/hppa2.0w-hp-hpux11.11/sys-include -c -g -O2 -fPIC -mdisable- indexing -W -Wall -gnatpg a-nlcoty.ads -o a-nlcoty.o ../../../gcc/libssp/ssp.c: In function '__stack_chk_fail_local': ../../../gcc/libssp/ssp.c:177: warning: visibility attribute not supported in th is configuration; ignored ../../../gcc/libssp/ssp.c: At top level: ../../../gcc/libssp/ssp.c:177: internal compiler error: in cgraph_expand_all_fun ctions, at cgraphunit.c:1220 -- Summary: gcc/libssp/ssp.c:177: ICE: in cgraph_expand_all_functions, at cgraphunit.c:1220 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30349
Re: [Bug middle-end/30349] New: gcc/libssp/ssp.c:177: ICE: in cgraph_expand_all_functions, at cgraphunit.c:1220
This should have been fixed by: 2007-01-01 Jan Hubicka <[EMAIL PROTECTED]> Andrew Pinski <[EMAIL PROTECTED]> * cgraphunit.c (cgraph_optimize): Call cgraph_add_new_functions before starting IPA passes. -- Pinski
[Bug middle-end/30349] gcc/libssp/ssp.c:177: ICE: in cgraph_expand_all_functions, at cgraphunit.c:1220
--- Comment #1 from pinskia at gmail dot com 2007-01-02 01:12 --- Subject: Re: New: gcc/libssp/ssp.c:177: ICE: in cgraph_expand_all_functions, at cgraphunit.c:1220 This should have been fixed by: 2007-01-01 Jan Hubicka <[EMAIL PROTECTED]> Andrew Pinski <[EMAIL PROTECTED]> * cgraphunit.c (cgraph_optimize): Call cgraph_add_new_functions before starting IPA passes. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30349
[Bug target/29867] [4.3 Regression] building libgfortran fails because of multiple definitions gcc-4.3-20061111
--- Comment #18 from eesrjhc at bath dot ac dot uk 2007-01-02 01:14 --- (In reply to comment #17) > Created an attachment (id=12839) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12839&action=view) [edit] > fixincludes: find headers in distro-specfic paths Sorry about the delay in replying. I can confirm that with this patch I can now bootstrap successfully: === gfortran Summary === # of expected passes15820 # of expected failures 7 # of unsupported tests 17 /home/roger/src/gcc-svn/build_amber/gcc/testsuite/gfortran/../../gfortran version 4.3.0 20070101 (experimental) Thanks very much, I really appreciate your hard work. Roger. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867
[Bug c++/30303] [4.2/4.3 regression] ICE with invalid constructor definition
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-02 02:10 --- I am testing a slightly different patch which is closer to what the rest of the function does, in that return NULL_TREE instead of error_mark_node. This fixes the problem still and also removes the error "throws different exceptions" which seems like a good idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30303
[Bug middle-end/30349] gcc/libssp/ssp.c:177: ICE: in cgraph_expand_all_functions, at cgraphunit.c:1220
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-01-02 02:28 --- Subject: Re: gcc/libssp/ssp.c:177: ICE: in cgraph_expand_all_functions, at cgraphunit.c:1220 > This should have been fixed by: Will check. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30349
Re: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
On 1 Jan 2007 00:41:44 -, mark at codesourcery dot com <[EMAIL PROTECTED]> wrote: --- Comment #26 from mark at codesourcery dot com 2007-01-01 00:41 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should dberlin at gcc dot gnu dot org wrote: > If we add a placement_new_expr, and not try to revisit our interpretation of > the standard, we can just DTRT and fix placement new. This would be best for > optimizations, and IMHO, for users. I agree that treating placement new specially makes sense. The first argument to a placement new operator could be considered to have an unspecified dynamic type on entrance to the operator, while the return value has the dynamic type specified by the operator. (So that the pointer returned by "new (x) int" has type "int *".) Right. I'm not sure that placement_new_expr is the best way to accomplish this, but, maybe it is. Another possibility would be to define an attribute or attributes to specify the dynamic type of arguments and return types, and then have the C++ front end annotate all placement new operators with those attributes. It would be nice if we could transform those attributes on gimplification to something like an an "alias preserving cast" (or something of that nature) that states that the cast is type unioning for alias purposes (IE that the possible types of the result for TBAA/etc purposes is the union of the type of the cast and the type of the cast's operand).. Not a fully fleshed out idea, just something that popped into my head.
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #27 from dberlin at gcc dot gnu dot org 2007-01-02 03:01 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On 1 Jan 2007 00:41:44 -, mark at codesourcery dot com <[EMAIL PROTECTED]> wrote: > > > --- Comment #26 from mark at codesourcery dot com 2007-01-01 00:41 > --- > Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement > new does not change the dynamic type as it should > > dberlin at gcc dot gnu dot org wrote: > > > If we add a placement_new_expr, and not try to revisit our interpretation of > > the standard, we can just DTRT and fix placement new. This would be best for > > optimizations, and IMHO, for users. > > I agree that treating placement new specially makes sense. The first > argument to a placement new operator could be considered to have an > unspecified dynamic type on entrance to the operator, while the return > value has the dynamic type specified by the operator. (So that the > pointer returned by "new (x) int" has type "int *".) Right. > > I'm not sure that placement_new_expr is the best way to accomplish this, > but, maybe it is. Another possibility would be to define an attribute > or attributes to specify the dynamic type of arguments and return types, > and then have the C++ front end annotate all placement new operators > with those attributes. It would be nice if we could transform those attributes on gimplification to something like an an "alias preserving cast" (or something of that nature) that states that the cast is type unioning for alias purposes (IE that the possible types of the result for TBAA/etc purposes is the union of the type of the cast and the type of the cast's operand).. Not a fully fleshed out idea, just something that popped into my head. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #28 from mark at codesourcery dot com 2007-01-02 03:24 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should dberlin at dberlin dot org wrote: > It would be nice if we could transform those attributes on > gimplification to something like an > an "alias preserving cast" (or something of that nature) that states > that the cast is type unioning for alias purposes (IE that the > possible types of the result for TBAA/etc purposes is the union of the > type of the cast and the type of the cast's operand).. That sounds reasonable to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libfortran/24459] [4.1 Only] gfortran namelist problem
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2007-01-02 04:35 --- *** Bug 30193 has been marked as a duplicate of this bug. *** -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||mjw99 at ic dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24459
[Bug libfortran/30193] Namelist issues when reading in asterisk preceeded arrays
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-01-02 04:35 --- Already fixed *** This bug has been marked as a duplicate of 24459 *** -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30193
[Bug fortran/30170] The STATUS specified in OPEN statement at (1) cannot have the value SCRATCH if a FILE specifier is present
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-01-02 04:39 --- I see no need to provide this non-standard behavior. A simple edit of the source code of the user program will resolve this. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30170
[Bug libfortran/30056] Exceeding recl on direct access
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-01-02 04:42 --- No need to backport this further. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|[4.1 only] Exceeding recl on|Exceeding recl on direct |direct access |access Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30056
[Bug libfortran/30009] [4.1 only] Unformatted reads exceeding storage units gives EOF instead of ERR
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2007-01-02 04:48 --- Closing, we need to focus resources on current trunk if we can. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30009
[Bug fortran/29835] Error message of unknown edit descriptor needs improvement
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29835
[Bug fortran/25057] default initialization and DATA statement conflict
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-01-02 05:06 --- Still working on it! -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-06 14:03:02 |2007-01-02 05:06:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25057
