Ian Lance Taylor [EMAIL PROTECTED] writes:
[...]
| I believe the best option is
| going to be to take an case by case approach to selecting which
| optimizations should be enabled by default, and which optimizations
| should not be done except via a special
Ian Lance Taylor [EMAIL PROTECTED] writes:
I'm not entirely happy with what I take to be stampeding it by
introducing what I believe would be a completely inappropriate patch
to autoconf, rather than, say, opening a gcc bugzilla problem report
for the cases you feel gcc should handle
On 12/31/06, Richard Kenner [EMAIL PROTECTED] wrote:
Are you volunteering to audit the present cases and argue whether they
fall in the traditional cases?
I'm certainly willing to *help*, but I'm sure there will be some cases
that will require discussion to get a consensus.
Note that
On 1/1/07, Richard Kenner [EMAIL PROTECTED] wrote:
the seemingly prevalent attitude but it is undefined; but it is not
C is the opinion of the majority of middle-end maintainers.
Does anybody DISAGREE with that attitude? It isn't valid C to assume that
signed overflow wraps. I've heard
Richard Kenner wrote:
the seemingly prevalent attitude but it is undefined; but it is not
C is the opinion of the majority of middle-end maintainers.
Does anybody DISAGREE with that attitude? It isn't valid C to assume that
signed overflow wraps. I've heard nobody argue that it is. The
Hi,
Sorry for possibly causing confusion. I had tested the patch on my ICE
testcase and bootstrapped for -enable-languages=C, but didn't run the
full bootstrap. Bootstrapping the latest Andrew's patch on ppc-linux
and testing it on SPU.
Vladimir,
I bootstrapped/regtested the patch myself on
On Dec 31, 2006, at 19:13, Daniel Berlin wrote:
Note the distinct drop in performance across almost all the benchmarks
on Dec 30, including popular programs like bzip2 and gzip.
Not so.
To my eyes, the specint 2000 mean went UP by about 1% for the
base -O3 compilation. The peak enabled more
Paul Eggert [EMAIL PROTECTED] writes:
Ralf Wildenhues suggested bugzilla originally, but Andrew Pinski
responded http://gcc.gnu.org/ml/gcc/2006-12/msg00460.html that the
problem has been observed many, many times and talked about a lot of
time on this list and implied strongly that the issue
On Mon, 1 Jan 2007, Geert Bosch wrote:
As undefined execution can result in arbitrary badness,
this is really at odds with the increasing need for many
programs to be secure. Since it is almost impossible to
prove that programs do not have signed integer overflow,
it makes far more sense to
Geert Bosch wrote:
As undefined execution can result in arbitrary badness,
this is really at odds with the increasing need for many
programs to be secure. Since it is almost impossible to
prove that programs do not have signed integer overflow,
That seems a bit pessimistic, given the work
Ian Lance Taylor wrote:
...
I don't personally see that as the question. This code is
undefined, and, therefore, is in some sense not C. If we take
any other attitude, then we will be defining and supporting
a different language. I think that relatively few people want
the language C
Still, in practical terms, it is true that overflow
being undefined is unpleasant. In Ada terms, it would
have seemed better in the C standard to reign in the
effect of overflow, for instance, merely saying that
the result is an implementation defined value of the
type, or the program is
I've bootstrapped OK C/C++/Fortran on PPC. make check-gcc is running now
Thanks,
Vladimir
On 1/1/07, Jan Hubicka [EMAIL PROTECTED] wrote:
Hi,
Sorry for possibly causing confusion. I had tested the patch on my ICE
testcase and bootstrapped for -enable-languages=C, but didn't run the
full
Ian Lance Taylor [EMAIL PROTECTED] writes:
Also, it does not make sense to me to lump together all potentially
troublesome optimizations under a single name.
As a compiler developer, you see the trees. But most users just see a
forest and want things to be simple. Even adding a single binary
Ian Lance Taylor [EMAIL PROTECTED] writes:
| Gabriel Dos Reis [EMAIL PROTECTED] writes:
|
| I do hope your and Richard G's constructive search for middle ground
| will find echoes within the middle-end maintainers.
|
| This seems likely, since Richard and I are two of the three middle-end
|
On Mon, 2007-01-01 at 10:00 -0800, Paul Eggert wrote:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Also, it does not make sense to me to lump together all potentially
troublesome optimizations under a single name.
As a compiler developer, you see the trees. But most users just see a
Andrew Pinski wrote:
Look at Fortran argument aliasing, we get almost no bugs about that
undefinedness. We have an option to change the way argument aliasing
works, in the same way we have an option for signed overflow. I don't
see why overflow will be any different from argument aliasing.
More important, we don't yet have an easy way to characterize the
cases where (2) would apply. For (2), we need a simple, documented
rule that programmers can easily understand, so that they can easily
verify that C code is safe
I'm not sure what you mean: there's the C standard. That says
On Mon, Jan 01, 2007 at 10:24:36AM -0800, Andrew Pinski wrote:
Then the question is why does C developers act differently than Fortran
developers when it comes to undefinedness?
In the case of int overflow wrapping, I think it's because the Bell Labs
folks appeared to assume wrapping semantics
On Mon, Jan 01, 2007 at 07:33:06AM -0500, Richard Kenner wrote:
the seemingly prevalent attitude but it is undefined; but it is not
C is the opinion of the majority of middle-end maintainers.
Does anybody DISAGREE with that attitude? It isn't valid C to assume that
signed overflow wraps.
On Tue, 12 Dec 2006, Mark Mitchell wrote:
If you want to make a patch, and Gerald approves it, it's fine by me.
But, fwprop is described as a new feature (faster compiler, better
code), and the build system affects people building the compiler. The
change we're talking about seems to affect
Daniel Berlin wrote:
Sorry, but it's rather impossible to argue against someone who seems
to believe users should not be responsible and held responsible for
knowing the rules of the language they are programming in. Down this
path, madness lies.
strict aliasing is really just what the
On Tue, 19 Dec 2006, Ian Lance Taylor wrote:
Here is a quick list of optimizations that mainline gcc performs which
rely on the idea that signed overflow is undefined. All the types
are, of course, signed. I made have made some mistakes. I think this
gives a good feel for the sorts of
Hi,
I've commited the following patch that fixes the obvious problem of
calling emit_insn_1 for INSN_LIST argument. It seems to solve the
problems I can reproduce and it bootstraps x86_64-linux/i686-linux and
Darwin (thanks to andreast). The patch was preaproved by Ian. This is
meant as fast
I don't agree with this point. There is a substantial number of
application developers who would prefer -failsafe. There is a
substantial number who would prefer -frisky. We don't know which set
is larger. We get a lot of bug reports about missed optimizations.
six vs. half a dozen.
Currently our documentation on -fwrapv is rather short and does not
provide examples or anything to provide such a feel:
This option instructs the compiler to assume that signed arithmetic
overflow of addition, subtraction and multiplication wraps around
using twos-complement
Changing syntax and semantics should not be impossible (it's being done),
What change? There has never been a version of the C language, all the
way from KRv1 to the present, that defined signed overflow.
The problem is the previous compilers never took advantage of the permission
to make it
Richard Kenner wrote:
I'm not sure what you mean: there's the C standard.
We have many standards, starting with KRv1 through the current draft.
Which do you call, the C standard?
The current one. All others are previous C standards. However, it
doesn't matter in this case since ALL of them
Mark Mitchell [EMAIL PROTECTED] writes:
* Dan Berlin says that xlc assumes signed overflow never occurs, gets
much better performance as a result, and that nobody has complained.
Most likely xlc and icc have been used to compile the gnulib
mktime-checking code many times without incident
[EMAIL PROTECTED] (Richard Kenner) writes:
More important, we don't yet have an easy way to characterize the
cases where (2) would apply. For (2), we need a simple, documented
rule that programmers can easily understand, so that they can easily
verify that C code is safe
I'm not sure what
Gfortran has achieved many milestones this year and hopefully the
contributors can continue to move forward with bug fixes, conformance
to Fortran 95 standard, and the implementation of Fortran 2003 features.
A few highlights from the past year are:
1) Jakub Jelinek committed the front end
Bruce Korb [EMAIL PROTECTED] writes:
WRT strict aliasing, I've never seen any data that indicated that the
language change was compelling. Consequently, as best I can tell it
was a marginal optimization improvement. So, I doubt its value.
Still, it should have had compiler warnings in
Bruce Korb [EMAIL PROTECTED] writes:
2) Add an option like -fstrict-signed-overflow which controls those
cases which appear to be risky. Turn on that option at -O2.
Not a good plan. -O2 should be constrained to disrupting very few
applications. (e.g. loop unrolling seems unlikely to
Douglas B Rupp wrote:
I'm happy to try writing a patch, but my version of gcc/configure
doesn't look like what you described.
I tried a build with the gcc-4.1.x branch, and gcc/nm is computed
correctly, so the problem I described on mainline does not exist here.
Unfortunately, I wasn't able
On 1/1/07, Paul Eggert [EMAIL PROTECTED] wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
* Dan Berlin says that xlc assumes signed overflow never occurs, gets
much better performance as a result, and that nobody has complained.
Most likely xlc and icc have been used to compile the gnulib
Daniel Berlin wrote:
Richard Guenther added -fwrapv to the December 30 run of SPEC at
http://www.suse.de/~gcctest/SPEC/CFP/sb-vangelis-head-64/recent.html
and
http://www.suse.de/~gcctest/SPEC/CINT/sb-vangelis-head-64/recent.html.
Daniel Berlin and Geert Bosch disagreed about how to interpret
No offense, but all enabling wrapv at O2 or less would do is cause
more bug reports about
1. Getting different program behavior between O2 and O3
2. Missed optimizations at O2
It also doesn't fit with what we have chosen to differentiate
optimization levels based on.
IMHO, it's just not
Richard Kenner wrote:
Where there are reasonable positions on both sides, nobody ever
accurately predicts what the majority of a hugely diverse population
of language users is going to want, and almost everyone believes
they are in that majority.
I agree. That's why I support a
Jim Wilson wrote:
Douglas B Rupp wrote:
I'm happy to try writing a patch, but my version of gcc/configure
doesn't look like what you described.
I tried a build with the gcc-4.1.x branch, and gcc/nm is computed
correctly, so the problem I described on mainline does not exist here.
Mark Mitchell [EMAIL PROTECTED] writes:
let's disable the assumption about signed overflow not wrapping for
VRP, but leave it in place for loop analysis.
As far as I know this will work for all the wrapv-assuming code that
we've found, so it should be an improvement. Thanks to all for
helping
[EMAIL PROTECTED] (Richard Kenner) writes:
The question that I'd like to understand the answer to is what kinds of
optimizations DO we get by having VRP optimized signed overflow. Is it just
the elimination of tests on overflow? If so, then it strikes me as
definitely wrong since those
Here I'd like to demur, since I think it's useful to document
something that users can rely on.
I'm not asking that we document every possible wrapv-assuming code
that happens to work. I'm only asking for enough so that users can
easily write code that tests for signed integer overflow, or
On Mon, Jan 01, 2007 at 06:19:08PM -0800, Douglas B Rupp wrote:
configure:4811: /home/rupp/ngnat/buildxppcaix/./gcc/xgcc
-B/home/rupp/ngnat/buildxppcaix/./gcc/
-B/home/rupp/gnat/powerpc-ibm-aix5.2.0.0/bin/
-B/home/rupp/gnat/powerpc-ibm-aix5.2.0.0/lib/ -isystem
Paul Eggert [EMAIL PROTECTED] writes:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Also, it does not make sense to me to lump together all potentially
troublesome optimizations under a single name.
As a compiler developer, you see the trees. But most users just see a
forest and want
Ian Lance Taylor wrote:
I don't think -frisky is a good name for that option. A better name
would be -fstrict.
or perhaps -fstandard
which says my program is 100% compliant ISO C. please mr. compiler
make any assumptions you like based on knowing this is the case. If
my claim that I am 100%
VRP as currently written adjust limits out to infinity of an
appropriate sign for variables which are changed in loops. It then
assumes that the (signed) variable will not wrap past that point,
since that would constitute undefined signed overflow.
But isn't that fine since OTHER code is
On Mon, 2007-01-01 at 22:21 -0500, Richard Kenner wrote:
Of course, this is an example where either the programmer is doing
something
very silly or else is expecting overflow and depending on wrap
semantics.
or it comes from inlining of something like get() which has bounds
checking.
--
[EMAIL PROTECTED] (Richard Kenner) writes:
[...]
|for (i = 1; i m; ++i)
| {
|if (i 0)
| bar ();
| }
|
| Of course, this is an example where either the programmer is doing something
| very silly or else is expecting overflow and depending on wrap semantics, so
| it
--- 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
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
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
--- 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
--
--- 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
--- 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
--- 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)
***
--- 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 T, int size = 0 class Array
{
public:
Array() {
if (size) {
new T[size];
}
}
};
void foo() {
Arrayint bar;
}
the new command is guarded by a if(size). So allocating a zero
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 T1, class T2
class v { };
class c2 {
void
--- 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
--- 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
--- 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
--
--- 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
--
--- 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
--
--- 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
--
--- 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
--
--- 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
--- 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=gccview=revrev=120319
Log:
PR target/29166
* config/ia64/ia64.c
--- 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=gccview=revrev=120320
Log:
PR target/29166
* config/ia64/ia64.c
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.
---
--- 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=gccview=revrev=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() {
--- 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 wilson at specifix dot com
Date: Mon, 01 Jan 2007 14:15:47 -0800
Subject: RE: how to support C
--- 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
--
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
--- 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=gccview=revrev=120329
Log:
gcc:
PR middle-end/30311
* caller-save.c
/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
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
/../../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
--- 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
--- 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
--- 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
1 - 100 of 104 matches
Mail list logo
