--- 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
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 o
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
Configu
--- 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.g
--- 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
--- 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 |Adde
--- 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
--- 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
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
impossib
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()) {
--- 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
-
--- 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
-
--- 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
---
--- 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
-
--- 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
--- 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 conten
--- 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 redu
--- 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
-
--- 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
--- 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.o
--- 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.o
--- 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.o
--- 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.o
--- 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.
--- 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 w
--- 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_comp
--- 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_comp
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.
---
#de
--- 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
--- 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
--- 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
---
--- 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() {
i
--- 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
--- 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
--- 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 ar
--- 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.o
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
--- 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 t
--- 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
--- 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_sto
/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
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
--- 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 P
uite/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
--- 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 diff
--- 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
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 d
--- 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 #2
--- 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
--- 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
-
--- 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
--- 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
--- 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
--
--- 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
---
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29835
--- 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
A
56 matches
Mail list logo
