Brooks Moses wrote:
Now, if your argument is that following the LIA-1 standard will prevent
optimizations that could otherwise be made if one followed only the C
standard, that's a reasonable argument, but it should not be couched as
if it implies that preventing the optimizations would not
Robert Dewar writes:
Brooks Moses wrote:
Now, if your argument is that following the LIA-1 standard will
prevent optimizations that could otherwise be made if one
followed only the C standard, that's a reasonable argument, but
it should not be couched as if it implies that
Andrew Haley wrote:
Robert Dewar writes:
Brooks Moses wrote:
Now, if your argument is that following the LIA-1 standard will
prevent optimizations that could otherwise be made if one
followed only the C standard, that's a reasonable argument, but
it should not be couched as if
On Tue, 2006-12-19 at 03:42 -0500, Robert Dewar wrote:
When I worked on SPITBOL, people all the time were suggesting
optimizations in letters to the SPITBOL newsletter. I imposed
a rule saying that no one could propose an optimization unless
they could show ONE example program where the
Andrew Pinski wrote:
I don't have the number of times this shows up or how much it helps but
it does help out on being able to vectorize this loop.
Just to be clear, when I ask for quantitative data, it is precisely
data about how much it helps. It is always easy enough to show
cases where
Ralf Wildenhues [EMAIL PROTECTED] writes:
Maybe it's also just an unintended bug I happened to observe
(and take for given behavior)?
I read up a bit more and it looks like it is intended behavior.
However, this disruptive change isn't documented in
http://gcc.gnu.org/gcc-4.2/changes.html,
Robert Dewar writes:
Andrew Haley wrote:
We've already defined `-fwrapv' for people who need nonstandard
arithmetic.
Nonstandard implies that the result does not conform with the standard,
I don't think it does; it merely implies that any program which
requires -fwrapv for correct
Does the test hang forever?
No, the timeout works.
So the app builds. But it has latent bugs. Wonderful.
Is the performance gain by this change to gcc -O2 really worth all
this software engineering hassle and breakage for typical
applications? I'm talking about apps like 'date', 'touch',
Mark Mitchell wrote:
Paolo --
The GCC SC has appointed you as a co-maintainer of the build machinery.
Please add an appropriate MAINTAINERS entry.
Congratulations, and thank you for accepting this position!
Thanks very much, I committed the following.
2006-12-19 Paolo Bonzini [EMAIL
Hi, Jan,
Thanks for fast response!
I've tested the change you proposed and we still failed in the assert
checking that the number of SCRATCHes being too large (30) while
copying the REG_NOTES of the instruction (see below) using just 9
SCRATCH registers.
Thanks,
Vladimir
On 12/18/06, Jan
Hi all,
I am working with GCC 4.1.1.
By using the function name, is it possible to get the declaration tree
node of that function.
e.g. using maybe_get_identifier(name), i get the identifier node.
similarly are there any functions or macros available to get the
declaration tree node.
Regards,
Hi, Jan,
Thanks for fast response!
I've tested the change you proposed and we still failed in the assert
checking that the number of SCRATCHes being too large (30) while
copying the REG_NOTES of the instruction (see below) using just 9
SCRATCH registers.
Hi,
apparently there seems to be
Andrew Haley [EMAIL PROTECTED] writes:
| Robert Dewar writes:
| Andrew Haley wrote:
|
|We've already defined `-fwrapv' for people who need nonstandard
|arithmetic.
|
| Nonstandard implies that the result does not conform with the standard,
|
| I don't think it does; it merely
Gabriel Dos Reis writes:
Andrew Haley [EMAIL PROTECTED] writes:
| Robert Dewar writes:
| Andrew Haley wrote:
|
|We've already defined `-fwrapv' for people who need nonstandard
|arithmetic.
|
| Nonstandard implies that the result does not conform with the
* Andrew Pinski:
A simple loop like:
int foo ()
{
int a[N];
int i;
int n;
for (i = 0; i = n; i++)
ca[i] = 2;
}
we cannot find how many iterations it runs without knowing that signed
types overflow.
In this case, the assumption is not needed because the lack of
overflow
By the way, as I've tried to describe here:
http://cert.uni-stuttgart.de/advisories/c-integer-overflow.php
variable range tracking can result in reintroduction of
supposedly-fixed security vulnerabilities. 8-(
Interesting read. I agree with the proposed fix; however, note that GCC
does not
Andrew Haley [EMAIL PROTECTED] writes:
| Gabriel Dos Reis writes:
| Andrew Haley [EMAIL PROTECTED] writes:
|
| | Robert Dewar writes:
| | Andrew Haley wrote:
| |
| |We've already defined `-fwrapv' for people who need nonstandard
| |arithmetic.
| |
| |
Andrew Haley wrote:
Robert Dewar writes:
Andrew Haley wrote:
We've already defined `-fwrapv' for people who need nonstandard
arithmetic.
Nonstandard implies that the result does not conform with the standard,
I don't think it does; it merely implies that any program which
Gabriel Dos Reis wrote:
Andrew Haley [EMAIL PROTECTED] writes:
| Robert Dewar writes:
| Andrew Haley wrote:
|
|We've already defined `-fwrapv' for people who need nonstandard
|arithmetic.
|
| Nonstandard implies that the result does not conform with the standard,
|
| I don't
Andrew Haley wrote:
I suspect the actual argument must be somewhere else.
I'm sure it is. The only purpose of my mail was to clarify what I
meant by nonstandard, which in this case was not strictly
conforming. I didn't intend to imply anything else.
But a compiler that implements wrap
* Paolo Bonzini:
Interesting read. I agree with the proposed fix; however, note that
GCC does not make the result of overflowing signed left-shifts
undefined, exactly because in this case the overflow is relied upon by
too many existing programs
Is this documented somewhere? Without
Florian Weimer wrote:
* Paolo Bonzini:
Interesting read. I agree with the proposed fix; however, note that
GCC does not make the result of overflowing signed left-shifts
undefined, exactly because in this case the overflow is relied upon by
too many existing programs
Is this documented
Hello,
Now, if your argument is that following the LIA-1 standard will prevent
optimizations that could otherwise be made if one followed only the C
standard, that's a reasonable argument, but it should not be couched as
if it implies that preventing the optimizations would not be
Zdenek Dvorak wrote:
IMHO, using loops relying on the behavior of overflow of an
induction variable (*) is an ugly hack and whoever writes such a code
does not deserve for his program to work.
I suspect everyone would agree on this, and in practice I would
guess that
a) there are no programs
On Tue, 19 Dec 2006, Florian Weimer wrote:
* Paolo Bonzini:
Interesting read. I agree with the proposed fix; however, note that
GCC does not make the result of overflowing signed left-shifts
undefined, exactly because in this case the overflow is relied upon by
too many existing
Joseph S. Myers wrote:
On Tue, 19 Dec 2006, Florian Weimer wrote:
* Paolo Bonzini:
Interesting read. I agree with the proposed fix; however, note that
GCC does not make the result of overflowing signed left-shifts
undefined, exactly because in this case the overflow is relied upon by
too
* Joseph S. Myers:
On Tue, 19 Dec 2006, Florian Weimer wrote:
* Paolo Bonzini:
Interesting read. I agree with the proposed fix; however, note that
GCC does not make the result of overflowing signed left-shifts
undefined, exactly because in this case the overflow is relied upon by
We've optimized expressions such as (a*2)/2 on the basis of overflow
being undefined for a very long time, not just loops.
What is (a*2)/2 optimized to? certainly it has the value a if you wrap,
so you are not necessarily depending on undefined here.
No, it has not. For example, if a is
* Robert Dewar:
What is (a*2)/2 optimized to? certainly it has the value a if you
wrap,
Huh? Isn't (INT_MAX*2)/2 negative (and thus not equal to INT_MAX) in
2-complement arithmetic?
Florian Weimer wrote:
Something like:
GCC does not use the latitude given in C99 only to treat
certain aspects of signed @samp{} as undefined: If the right
operand @var{n} is non-negative and less than the width of the
left operand @var{val}, the resulting value
On Tue, 19 Dec 2006, Robert Dewar wrote:
GCC does not use the latitude given in C99 only to treat certain
aspects of signed @samp{} as undefined, but this is subject to
change.
That hardly seems sufficient documentation, when documenting undefined,
you had better say what
Paolo Bonzini wrote:
No, it has not. For example, if a is 0x4000 in a 32 bit type and
arithmetic wraps, a*2 = -0x8000 (overflow), and hence (a*2)/2 =
-0x4000 = -1073741824.
Paolo
Yes indeed, my mistake, I was thinking unsigned :-(
and of course signed is the whole point here!
Paolo Bonzini wrote:
We've optimized expressions such as (a*2)/2 on the basis of overflow
being undefined for a very long time, not just loops.
What is (a*2)/2 optimized to? certainly it has the value a if you wrap,
so you are not necessarily depending on undefined here.
it's interesting that
tree fn_decl;
tree fn_id;
fn_id = get_identifier(test_fn_call);
fn_decl = lookup_name(fn_id); /* returns you a pointer to the function
declaration tree */
On 12/19/06, Rohit Arul Raj [EMAIL PROTECTED] wrote:
Hi all,
I am working with GCC 4.1.1.
By using the function name, is it possible to
Java 5 has an extended class file format for annotations. We have to
support that in gcj-compiled code too, and it requires an ABI change.
Tom Tromey, I'd appreciate it if you'd have a quick check of this one.
We should probably port the code that throws a ClassFormatError if
we're not
Joseph S. Myers [EMAIL PROTECTED] writes:
Encapsulate reliable overflow checks for the various
arithmetic operations and types in functions or macros in
gnulib (for long long multiply, in this case).
That might be the best approach in the long run, but it
would take a lot of painstaking
On Tuesday 19 December 2006 11:37, Paolo Bonzini wrote:
By the way, as I've tried to describe here:
http://cert.uni-stuttgart.de/advisories/c-integer-overflow.php
variable range tracking can result in reintroduction of
supposedly-fixed security vulnerabilities. 8-(
Interesting read.
Denis Vlasenko writes:
I wrote this just a few days ago:
do {
int32_t v1 = v 1;
if (v 0) v1 ^= mask;
v = v1;
printf(%10u: %08x\n, c++, v);
} while (v != 1);
I would become rather sad if this
Paul Eggert [EMAIL PROTECTED] writes:
| Joseph S. Myers [EMAIL PROTECTED] writes:
|
| Encapsulate reliable overflow checks for the various
| arithmetic operations and types in functions or macros in
| gnulib (for long long multiply, in this case).
|
| That might be the best approach in the
Paul Eggert [EMAIL PROTECTED] writes:
What worries me is code like this (taken from GNU expr; the vars are
long long int):
val = l-u.i * r-u.i;
if (! (l-u.i == 0 || r-u.i == 0
|| ((val 0) == ((l-u.i 0) ^ (r-u.i 0))
val
On Tue, Dec 19, 2006 at 12:05:44PM -0800, 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
On Tuesday 19 December 2006 20:05, Andrew Haley wrote:
Denis Vlasenko writes:
I wrote this just a few days ago:
do {
int32_t v1 = v 1;
if (v 0) v1 ^= mask;
v = v1;
printf(%10u: %08x\n, c++, v);
Compiler can optimize it any way it wants,
as long as result is the same as unoptimized one.
We have an option for that. It's called -O0.
Pretty much all optimization will change the behavior of your program. The
important distinction is whether that difference is observable in valid
Paul Eggert wrote:
Compiling everything with -fwrapv is simple. It has
optimization drawbacks, but if that's the best we can do
now, then we'll probably do it. And once we do it, human
nature suggests that we will generally not bother with the
painstaking analysis needed to omit -fwrapv.
On Tue, Dec 19, 2006 at 10:25:41PM +0100, Denis Vlasenko wrote:
... It's not about standards. It's about sanity.
So what happens when two different people's concept of sanity differs?
That's why we have standards, so both can consult a reference and
wind up with the same concept, even though one
((char)x) = ((char)( ((int)((char)x)) ((int)c) ) ) ::
((char)x) = ((char)( ((char)x) ((int)c) ) )
if the shift count ((int)x) is semantically preserved.
thereby conditionally shifting left ((char)x) by ((int)c) if c is less
than
the smaller of it's shifted operand's or target's
On Tuesday 19 December 2006 22:46, Paul Brook wrote:
Compiler can optimize it any way it wants,
as long as result is the same as unoptimized one.
We have an option for that. It's called -O0.
Pretty much all optimization will change the behavior of your program.
Even x*2 - x+x? Or
Hi all,
I spent the last couple of hours tracking down PR29867 through fixincludes.
Now, as the actual problem is identified, I lack the knowledge to fix it
appropriately. Could someone more involved with fixincludes comment on this?
Thanks.
The problem: fixes glibc_c99_inline_1 and
On 17 December 2006 12:56, Manuel López-Ibáñez wrote:
Currently Wextra warns about a pointer compared against integer zero
with , =, , or =. This warning is not available in C++ (the
documentation does not say this) and it is implemented in
gcc/c-typeck.c (build_binary_op) in this manner:
On 20/12/06, Dave Korn [EMAIL PROTECTED] wrote:
On 17 December 2006 12:56, Manuel López-Ibáñez wrote:
For me, the
best would be to NOT enable the warning for Wextra, so I don't need to
come up with a name for this warning flag. Otherwise, we would have to
document that the warning is enabled
On 20 December 2006 00:39, Manuel López-Ibáñez wrote:
On 20/12/06, Dave Korn [EMAIL PROTECTED] wrote:
Heh. Or you could always make it a divide-by-zero error instead :)
Oh, sorry. I didn't get this. If you would be so kind to elaborate...
Possibly the world's only attempt ever at C
I'm tying to hunt down the cause of a bug I'm experiencing and it all
boils down to a possible misunderstanding
on my part on the semantics of the 'aligned' attribute.
Is the 'aligned' attribute supposed to work for objects allocated on
the stack (I'm on x86_64, gcc 4.1.1)?
The only caveat
On Dec 19, 2006, at 5:31 PM, Maurizio Vitale wrote:
I'm tying to hunt down the cause of a bug I'm experiencing and it
all boils down to a possible misunderstanding on my part on the
semantics of the 'aligned' attribute.
Is the 'aligned' attribute supposed to work for objects allocated
on
On Tuesday 19 December 2006 22:39, Denis Vlasenko wrote:
On Tuesday 19 December 2006 22:46, Paul Brook wrote:
Compiler can optimize it any way it wants,
as long as result is the same as unoptimized one.
We have an option for that. It's called -O0.
Pretty much all optimization will
On Mon, 18 Dec 2006, Andrew Pinski wrote:
On Tue, [EMAIL PROTECTED]:54 +0100, Ralf Wildenhues wrote:
Wheeeoo! That optimization is going to break a _lot_ of GNU
software. (Silently. Oh my.)
Just like say strict aliasing? :)
I find an analogy with -ffast-math much less far-fetched than
Denis Vlasenko wrote:
I want sane compiler. One in which N-bit integer variables stay exactly N-bit.
Without magic N+1 bit which is there somethimes. a*2/2:
If I say multiply by 2 and _after that_ divide by 2,
I meant that. Compiler can optimize it any way it wants,
as long as result is the
Paul Brook wrote:
Compiler can optimize it any way it wants,
as long as result is the same as unoptimized one.
We have an option for that. It's called -O0.
Pretty much all optimization will change the behavior of your program.
Now that's a bit TOO strong a statement, critical optimizations
Richard B. Kreckel wrote:
By the same token it would be wise to refrain from turning on any
optimization that breaks programs which depend on wrapping signed
integers. Silently breaking LIA-1 semantics is imprudent.
I am not so sure about that conclusion, which I why I would like to
see more
Paul Brook wrote:
Compiler can optimize it any way it wants,
as long as result is the same as unoptimized one.
We have an option for that. It's called -O0.
Pretty much all optimization will change the behavior of your program.
Now that's a bit TOO strong a statement, critical
On 20 December 2006 02:28, Andrew Pinski wrote:
Paul Brook wrote:
Compiler can optimize it any way it wants,
as long as result is the same as unoptimized one.
We have an option for that. It's called -O0.
Pretty much all optimization will change the behavior of your program.
Now that's
On Dec 19, 2006, at 6:33 PM, Dave Korn wrote:
On 20 December 2006 02:28, Andrew Pinski wrote:
Paul Brook wrote:
Compiler can optimize it any way it wants,
as long as result is the same as unoptimized one.
We have an option for that. It's called -O0.
Pretty much all optimization will change
Actually they will with multi threaded program, since you can have a case
where it works and now it is broken because one thread has speed up so
much it writes to a variable which had a copy on another thread's stack.
Why isn't that just a buggy program with wilful disregard for the use
On 20 December 2006 02:40, Mike Stump wrote:
On Dec 19, 2006, at 6:33 PM, Dave Korn wrote:
On 20 December 2006 02:28, Andrew Pinski wrote:
Paul Brook wrote:
Compiler can optimize it any way it wants,
as long as result is the same as unoptimized one.
We have an option for that. It's
Andrew Pinski wrote:
Actually they will with multi threaded program, since you can have a case
where it works and now it is broken because one thread has speed up so much it
writes to a variable which had a copy on another thread's stack. So the
argument
about it being too strong is wrong
Dave Korn wrote:
Why isn't that just a buggy program with wilful disregard for the use of
correct synchronisation techniques?
Right, I think most people would agree it is.
But for sure, if you consider that making the code go faster is itself
a change in behavior, then obviously all
Paul Brook wrote:
As opposed to a buggy program with wilful disregard for signed overflow
semantics? ;-)
I know there is a smiley there, but in fact I think it is useful to
distinguish these two cases.
Dorit Nuzman wrote:
Paul Schlie wrote:
((char)x) = ((char)( ((int)((char)x)) ((int)c) ) ) ::
((char)x) = ((char)( ((char)x) ((int)c) ) )
if the shift count ((int)c) is semantically preserved.
thereby conditionally shifting left ((char)x) by ((int)c) if c
is less than the smaller
Various folks wrote:
Compiler can optimize it any way it wants,
as long as result is the same as unoptimized one.
We have an option for that. It's called -O0.
Pretty much all optimization will change the behavior of your program.
Now that's a bit TOO strong a statement, critical
Hi all,
I am working with gcc 4.1.1.
I have a target dependent function attribute to check the function mode.
Before emitting the call instruction, i just want to check the
function attribute and depending on that i need to emit the call
instruction.
After making the modifications, while
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-12-19 08:28
---
Subject: Bug 29779
Author: pinskia
Date: Tue Dec 19 08:28:46 2006
New Revision: 120045
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120045
Log:
2006-12-18 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-12-19 08:29
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-19 08:30 ---
My patch for this needs to be rewritten, not because it was wrong but because
it can be cleaned up.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23983
--- Comment #6 from ismail at pardus dot org dot tr 2006-12-19 09:31
---
Another MPlayer bug exposed by gcc, sorry guys!
--
ismail at pardus dot org dot tr changed:
What|Removed |Added
--- Comment #7 from bonzini at gnu dot org 2006-12-19 11:01 ---
Subject: Bug 29544
Author: bonzini
Date: Tue Dec 19 11:01:36 2006
New Revision: 120048
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120048
Log:
2006-12-19 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #3 from belyshev at depni dot sinp dot msu dot ru 2006-12-19
11:11 ---
This does not fail on mainline since mem-ssa merge (r119760).
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
--- Comment #2 from h dot b dot furuseth at usit dot uio dot no 2006-12-19
11:27 ---
Subject: Re: -fno-inline-functions does not work, and doc bugs
pinskia at gcc dot gnu dot org writes:
You want -fno-inline-functions-called-once which was added in 4.2.0
IIRC (...)
I see.
--- Comment #3 from h dot b dot furuseth at usit dot uio dot no 2006-12-19
11:31 ---
Subject: Re: -fno-inline-functions does not work, and doc bugs
I just noticed another doc bug:
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options
That page says:
-O2
--- Comment #7 from dcb314 at hotmail dot com 2006-12-19 12:34 ---
(In reply to comment #6)
In that case, you might want to read the C++ standard text to
appreciate the facts.
There is a strange sort of echo in this bug report ;-
I accept the point that the code is undefined,
--- Comment #2 from pault at gcc dot gnu dot org 2006-12-19 12:48 ---
Created an attachment (id=12827)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12827action=view)
Fix for the problem
With all the interface patches in place, to allow the overloading of
random_seed, the
--- Comment #40 from jv244 at cam dot ac dot uk 2006-12-19 12:49 ---
I've now checked that gcc trunk (revision 120045) compiles CP2K (at -O3
-ftree-vectorize -ffast-math -march=opteron) and that the numerical results
seem acceptable. Great job... I hope the the original file is kept
--- Comment #10 from amylaar at gcc dot gnu dot org 2006-12-19 12:57
---
(In reply to comment #9)
OK, so it looks like this is not a testsuite problem: the problem really is
with the program being tested.
It is also a testsuite problem when the tests are randonly passing or failing;
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2006-12-19 13:32
---
Hi!
Sorry for the late response.
The scheduler fails to process a basic block with barrier inside it.
The basic block looks like this:
- Basic block 2 - begin -
some insns
(insn:HI 14 12 16 2 (set
--- Comment #8 from jh at suse dot cz 2006-12-19 13:39 ---
Subject: Re: [4.2/4.3 regression] ICE with scheduling and __builtin_trap
Hi,
barrier in the middle of basic block is invalid and should be noticed by
verify_flow_info and ICE. What part of my patch you quote is supposed
to
--- Comment #1 from dnovillo at gcc dot gnu dot org 2006-12-19 13:49
---
This is not a valid bug report. You have failed to include even the bare
minimal information needed. Read http://gcc.gnu.org/bugs.html.
--
dnovillo at gcc dot gnu dot org changed:
What
--- Comment #9 from mkuvyrkov at gcc dot gnu dot org 2006-12-19 14:00
---
(In reply to comment #8)
Subject: Re: [4.2/4.3 regression] ICE with scheduling and __builtin_trap
Hi,
barrier in the middle of basic block is invalid and should be noticed by
verify_flow_info and ICE.
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2006-12-19
14:04 ---
The nan_inf_fmt.f90 failures also occur in gcc 4.2 branch. Can we apply this
fix there as well?
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed
--- Comment #10 from jh at suse dot cz 2006-12-19 14:12 ---
Subject: Re: [4.2/4.3 regression] ICE with scheduling and __builtin_trap
cfgrtl.c: rtl_verify_flow_info () makes the same statement as
control_flow_insn_p ():
/* We may have a barrier inside a basic block before dead
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-12-19 14:30 ---
Is it reasonable and prudent to have tests like if (n == 0)
optimised away at the -O2 optimisation level ?
Yes
We should remember that -O2 is heavily used by lots of
customers.
And they expect a lot from
--- Comment #2 from hanwen at xs4all dot nl 2006-12-19 14:48 ---
Debian Bug#403628, resolution:
**
Sarge (and glibc 2.3.2) does not support gcc-4.1, though it is possible
get it working on some architectures.
If you want to have gcc-4.1, please upgrade to Etch (testing), or uses
at
--- Comment #8 from ian at airs dot com 2006-12-19 14:57 ---
I think I agree that if we spill an 80387 register to the stack, and then load
the value back into an 80387 register, that we should spill all 80 bits, rather
than implicitly converting to DFmode or SFmode.
This would
Hi everyone,
while running the regression tests for a x86_64 cross-toolchain build under
Cygwin lots of profiler tests went FAIL or UNRESOLVED. The first FAILed while
generating inliner-1.x01:
/usr/local/build-root/build-sles10-64/x86_64-pc-linux-gcc/gcc/xgcc
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2006-12-19 15:24
---
I would suggest put that hunk in (it was probably just merge omision
from my side) and try to remove the verify_flow_info bit and see if
everything works. I can do it tonight or tomorrow unless you beat me.
--- Comment #9 from whaley at cs dot utsa dot edu 2006-12-19 16:04 ---
Ian,
Thanks for the info. I see I failed to consider the cross-register moves you
mentioned. However, can't those be moved through memory, where something
destined for a 64-bit register is first written from the
--- Comment #9 from dcb314 at hotmail dot com 2006-12-19 16:37 ---
(In reply to comment #8)
And they expect a lot from our optimizers.
Surely not at the -O2 level ?
I thought folks serious about optimisation used -O3
and / or a bunch of other flags like -fsomething ?
The problem is
--- Comment #4 from pault at gcc dot gnu dot org 2006-12-19 17:02 ---
Subject: Bug 30236
Author: pault
Date: Tue Dec 19 17:02:20 2006
New Revision: 120052
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120052
Log:
2006-12-19 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #5 from pault at gcc dot gnu dot org 2006-12-19 17:06 ---
Brooks,
I did as you suggested to altreturn_3.f90. I added a couple of tests to make
sure that the alternate returns were indeed threading their way through the
programme by selection on the correct values. That
--- Comment #3 from pault at gcc dot gnu dot org 2006-12-19 17:09 ---
(In reply to comment #2)
With all the interface patches in place, to allow the overloading of
random_seed, the following gives the right errors in the right places
In fact, I would like to get some of the
--- Comment #7 from burnus at gcc dot gnu dot org 2006-12-19 17:15 ---
Subject: Bug 30022
Author: burnus
Date: Tue Dec 19 17:14:22 2006
New Revision: 120053
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120053
Log:
Merged revisions 119412-119459 via svnmerge from
--- Comment #37 from burnus at gcc dot gnu dot org 2006-12-19 17:15 ---
Subject: Bug 29568
Author: burnus
Date: Tue Dec 19 17:14:22 2006
New Revision: 120053
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120053
Log:
Merged revisions 119412-119459 via svnmerge from
--- Comment #8 from burnus at gcc dot gnu dot org 2006-12-19 17:15 ---
Subject: Bug 30040
Author: burnus
Date: Tue Dec 19 17:14:22 2006
New Revision: 120053
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120053
Log:
Merged revisions 119412-119459 via svnmerge from
1 - 100 of 142 matches
Mail list logo
