On Oct 31, 2006, at 12:49 PM, Igor Bukanov wrote:
-- Forwarded message --
From: Igor Bukanov <[EMAIL PROTECTED]>
Date: Oct 31, 2006 9:48 PM
Subject: Re: return void from void function is allowed.
To: Mike Stump <[EMAIL PROTECTED]>
On 10/31/06, Mike Stump <[EMAIL PROTECTED]> wr
On Nov 7, 2006, at 11:47 AM, Douglas Gregor wrote:
I just read Nathan's discussion [1] on changing GCC's type system
to use canonical type nodes, where the comparison between two types
requires only a pointer comparison. Right now, we use "comptypes",
which typically needs to do deep struc
On Nov 7, 2006, at 3:05 PM, Gabriel Dos Reis wrote:
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
[...]
| In C, there are several other sources of intransitivity, such as
| incomplete array types (int[10] and int[5] both compatible with
int[] but
I'm sure we can (and probably must) specic
On Nov 9, 2006, at 4:54 PM, Mike Stump wrote:
On Nov 8, 2006, at 7:14 AM, Ian Lance Taylor wrote:
The way to canonicalize them is to have all equivalent types point to
a single canonical type for the equivalence set. The comparison is
one memory dereference and one pointer comparison, not the
On Nov 11, 2006, at 10:45 PM, Howard Chu wrote:
Andrew Pinski wrote:
On Sat, 2006-11-11 at 22:18 -0800, Ian Lance Taylor wrote:
Your code will be safe on all counts if you change buf from int[] to
char[]. The language standard grants a special exemption to char*
pointers. Without that exem
On Dec 12, 2006, at 11:42 AM, David Edelsohn wrote:
Joslwah writes:
Joslwah> Looking at the Linux 32bit PowerPC ABI spec, it appears to
me that
Joslwah> floats in excess of those that are passed in registers are
supposed to
Joslwah> be promoted to doubles and passed on the stack. Examin
On Dec 12, 2006, at 12:07 PM, David Edelsohn wrote:
Dale Johannesen writes:
Dale> It may have been intended to allow the callee to be a K&R-
style or
Dale> varargs function, where all float args get promoted to double.
Dale> In particular, printf was often called without b
On Mar 1, 2007, at 12:57 AM, Tehila Meyzels wrote:
Revital Eres wrote on 01/03/2007 10:37:36:
Hello,
I wonder why this order (non-consecutive, decreasing) of Altivec
registers
was chosen when specifying the allocation order in REG_ALLOC_ORDER.
(taken from rs6000.h)
/* AltiVec registers
On Apr 17, 2007, at 4:20 PM, Eric Christopher wrote:
increase code size? I feel I must be missing something really
obvious... is
it just that the other optimisations that become possible on
inline code
usually compensate?
That or the savings from not having to save/restore registers, s
On Feb 27, 2005, at 12:56 PM, Mike Hearn wrote:
Are these compatibility patches available in discrete diff form
anywhere?
No.
The branch's name is apple-ppc-branch, and changes are marked
as APPLE LOCAL.
On Feb 28, 2005, at 4:43 AM, Joern RENNECKE wrote:
Dale Johannesen wrote:
Well, no, what is supposed to happen (I haven't tried it for a
while, so I don't promise
this still works) is code like this:
.hotsection:
loop:
conditional branch (i?==1000) to L2
L1:
/* do stuff *
On Feb 28, 2005, at 10:19 AM, Joern RENNECKE wrote:
Dale Johannesen wrote:
Certainly. In general it will make the total size bigger, as does
inlining. If you have good
information about what's hot and cold, it should reduce the number of
pages that actually
get swapped in. The inform
On Mar 14, 2005, at 10:30 AM, Joe Buck wrote:
Steven Bosscher <[EMAIL PROTECTED]> wrote:
system.h:#define abort() fancy_abort (__FILE__, __LINE__,
__FUNCTION__)
I agree that this is the best technical solution, even if cross-jumping
were not an issue.
This invokes undefined behavior in a pro
Consider the following:
static inline int a() __attribute((always_inline));
static inline int b() __attribute((always_inline));
static inline int b() { a(); }
static inline int a() { }
int c() { b(); }
This compiles fine at -O2. At -O0 we get the baffling error
sorry, unimplemented: inlining fai
On Mar 15, 2005, at 10:32 AM, Zack Weinberg wrote:
Dale Johannesen <[EMAIL PROTECTED]> writes:
Consider the following:
static inline int a() __attribute((always_inline));
static inline int b() __attribute((always_inline));
static inline int b() { a(); }
static inline int a() { }
int c
On Mar 22, 2005, at 8:14 AM, Kazu Hirata wrote:
After all, all we need in get_callee_fndecl seems to be
addr = TREE_OPERAND (call_expr, 0);
return ((TREE_CODE (addr) == ADDR_EXPR
&& TREE_CODE (TREE_OPERAND (addr, 0)) == FUNCTION_DECL)
? TREE_OPERAND (addr, 0) : NULL_TREE;
T
On Mar 22, 2005, at 10:21 AM, Kazu Hirata wrote:
Hi Dale,
After all, all we need in get_callee_fndecl seems to be
addr = TREE_OPERAND (call_expr, 0);
return ((TREE_CODE (addr) == ADDR_EXPR
&& TREE_CODE (TREE_OPERAND (addr, 0)) == FUNCTION_DECL)
? TREE_OPERAND (addr, 0) : NU
I'm interested in fixing this, but could use some help from somebody
knowledgeable about how x86 EH is supposed to work. In particular,
what's the expected relationship between SP at the point of a throwing
call, and when it gets back to the landing pad?
On Mar 24, 2005, at 12:35 PM, James E Wilson wrote:
Dale Johannesen wrote:
I'm interested in fixing this, but could use some help from somebody
knowledgeable about how x86 EH is supposed to work. In particular,
what's the expected relationship between SP at the point of a throwing
call
On Mar 24, 2005, at 3:08 PM, James E Wilson wrote:
Richard Henderson wrote:
19255 EH bug on IA32 when using heavy optimization
Typo in pr number?
I think that is supposed to be 19225, for which I have already
suggested a solution though not a patch (disable deferred argument
popping when a call c
On Mar 31, 2005, at 12:18 PM, Mike Stump wrote:
On Mar 31, 2005, at 10:54 AM, Fariborz Jahanian wrote:
Today, I tried bootstrapping gcc mainline on/for apple-ppc-darwin. It
fails in stage1.
I can see the problem also... :-(
I doubt if the person that broke it knows about it. It was working
just
On Mar 31, 2005, at 12:23 PM, Dale Johannesen wrote:
On Mar 31, 2005, at 12:18 PM, Mike Stump wrote:
On Mar 31, 2005, at 10:54 AM, Fariborz Jahanian wrote:
Today, I tried bootstrapping gcc mainline on/for apple-ppc-darwin.
It fails in stage1.
I can see the problem also... :-(
I doubt if the
I've currently got the job of implementing pragma(s) to change
optimization level in the middle of a file. This has come up a few
times before,
http://gcc.gnu.org/ml/gcc/2001-06/msg01275.html
http://gcc.gnu.org/ml/gcc/2002-09/msg01171.html
http://gcc.gnu.org/ml/gcc/2003-01/msg00557.html
and so f
On Apr 1, 2005, at 11:24 AM, Mark Mitchell wrote:
Dale Johannesen wrote:
So I guess question 1 is, Mark, do you feel negatively enough about
this
feature to block its acceptance in mainline?
I'm not sure that I *could* block it, but, no, I don't feel that
negatively.
Well, in theory
On Apr 3, 2005, at 5:31 PM, Geert Bosch wrote:
On Apr 1, 2005, at 16:36, Mark Mitchell wrote:
In fact, I've long said that GCC had too many knobs.
(For example, I just had a discussion with a customer where I
explained that the various optimization passes, while theoretically
orthogonal, are not
On Apr 4, 2005, at 2:32 PM, Alexandre Oliva wrote:
On Mar 26, 2005, Graham Stott <[EMAIL PROTECTED]> wrote:
I do regular bootstraps of mainline all languages on FC3
i686-pc-linuux-gnu and haven't seen any problemss upto Friday. I'm
using --enable-checking=tree,misc,rtl,rtlflag which might make a
di
On Apr 4, 2005, at 3:21 PM, Alexandre Oliva wrote:
On Apr 4, 2005, Dale Johannesen <[EMAIL PROTECTED]> wrote:
On Apr 4, 2005, at 2:32 PM, Alexandre Oliva wrote:
On Mar 26, 2005, Graham Stott <[EMAIL PROTECTED]> wrote:
I do regular bootstraps of mainline all languages on FC3
i686-pc-li
On Apr 7, 2005, at 11:58 AM, Virender Kashyap wrote:
hi
i made some changes in gcc code. when i try to comile it using
make , i get the following error ( last few lines from output ). Pls
help me in removing this error.
The command line you show is the built compiler trying to build gcc's
l
On Apr 8, 2005, at 4:40 PM, Mark Mitchell wrote:
Daniel Berlin wrote:
Your transform is correct.
The FE is not. The variable is not read only.
It is write once, then read-only.
Diego, your analysis is exactly correct about what is happenning.
I agree, in principle. The C++ FE should not set TREE_R
On Apr 14, 2005, at 7:14 AM, Andrew Pinski wrote:
Does this bug look familiar? 20629 is ICEing in the same spot, but
it looks like theirs was reproducible after preprocessing. Is there
any more information that I provide that would be helpful? I've
attached the command line, specs and a stacktra
On Apr 15, 2005, at 8:27 AM, E. Weddington wrote:
Ralf Corsepius wrote:
Hi,
I just tripped over this snipped below in a piece of code, I didn't
write and which I don't understand:
...
struct somestruct {
struct entrystruct *e1 __attribute__ ((packed));
struct entrystruct *e2 __attribute__ ((packe
On Apr 24, 2005, at 6:43 AM, Mike Stump wrote:
On Saturday, April 23, 2005, at 05:05 PM, Philip George wrote:
What's the smallest size I can squeeze gcc down to and how would I go
about compiling it in such a way?
My take:
#define optimize 0
"optimize" is a variable and "int 0" won't parse, so th
On May 3, 2005, at 7:41 AM, Nathan Sidwell wrote:
Mike Stump wrote:
int avail;
int main() {
while (*(volatile int *)&avail == 0)
continue;
return 0;
}
Ok, so, the question is, should gcc produce code that infinitely
loops, or should it be obligated to actually fetch from memory?
Hint,
On May 3, 2005, at 11:03 AM, Nathan Sidwell wrote:
Dale Johannesen wrote:
However, as a QOI issue, I believe the compiler should treat the
reference as
volatile if either the object or the lvalue is volatile. That is
obviously the
user's intent.
I'm not disagreeing with you, but I
On May 3, 2005, at 11:21 AM, Paul Koning wrote:
This change bothers me a lot. It seems likely that this will break
existing code possibly in subtle ways.
It did, that is why Mike is asking about it. :)
On May 3, 2005, at 11:52 AM, Nathan Sidwell wrote:
Dale Johannesen wrote:
On May 3, 2005, at 11:03 AM, Nathan Sidwell wrote:
Seeing through the const-stripping cast is a useful optimization.
It is? Why would somebody write that?
perhaps a function, which returned a non-const reference that
On May 4, 2005, at 5:06 AM, Gabriel Dos Reis wrote:
Andrew Haley <[EMAIL PROTECTED]> writes:
| Nathan Sidwell writes:
| > Dale Johannesen wrote:
| >
| > > And we don't have to document the behavior at all; it is not
documented
| > > now.
| > I disagree. It&#x
On May 5, 2005, at 5:23 AM, Kai Henningsen wrote:
[EMAIL PROTECTED] (Nathan Sidwell) wrote on 03.05.05 in
<[EMAIL PROTECTED]>:
Mike Stump wrote:
int avail;
int main() {
while (*(volatile int *)&avail == 0)
continue;
return 0;
}
Ok, so, the question is, should gcc produce code that infinit
On May 11, 2005, at 11:42 AM, Mark Mitchell wrote:
Kenny and I had a long conversation about the aliasing issue, and
reached the following proposed solution.
In short, the issue is, when given the following code:
struct A {...};
struct B { ...; struct A a; ...; };
void f() {
B b;
g(
On May 24, 2005, at 9:43 AM, Joe Buck wrote:
On Tue, May 24, 2005 at 05:03:27PM +0200, Andreas Schwab wrote:
Paul Koning <[EMAIL PROTECTED]> writes:
I hope that doesn't require (void *) casts for pointer arguments
passed to the likes of memcpy...
Only the (void*) -> (any*) direction requires
On May 27, 2005, at 11:05 AM, Diego Novillo wrote:
This is happening in gcc.dg/tree-ssa/20040121-1.c. The test
specifically tests that (p!=0) + (q!=0) should be computed as
int:
char *foo(char *p, char *q) {
int x = (p !=0) + (q != 0);
...
}
Is this program legal C?
!= is defined
On Jun 6, 2005, at 12:17 PM, Samuel Smythe wrote:
It is well-known that Apple has been a significant provider of GCC
enhancements. But it is also probably now well-known that they have
opted to drop the PPC architecture in favor of an x86-based
architecture. Will Apple continue to contribute t
On Jun 9, 2005, at 12:43 PM, Pat Haugen wrote:
cc1: warnings being treated as errors
/home/pthaugen/work/src/mainline/gcc/gcc/config/rs6000/rs6000.c:12538:
warning: ‘rs6000_invalid_within_doloop’ defined but not used
Problem is Adrian changed TARGET_INSN_VALID_WITHIN_DOLOOP to
TARGET_INVAL
On Jun 17, 2005, at 5:59 PM, Paul Schlie wrote:
From: Andrew Pinski <[EMAIL PROTECTED]>
On Jun 17, 2005, at 8:20 PM, Paul Schlie wrote:
["undefined" only provides liberties within the constrains of what
is specifically specified as being undefined, but none beyond
that.]
That is not tr
On Jun 29, 2005, at 3:46 PM, Steven Bosscher wrote:
I have a question about the scheduler. Forgive me if I'm totally
missing the point here, this scheduling business is not my thing ;-)
Consider the following snippet that I've derived from PR17808 with a
few hacks in the compiler to renumber in
Compiling a simple function like
double foo(double x) { return x+1.0; }
on x86 with -O2 -march=pentium4 -mtune=prescott -mfpmath=sse -fpic, the
load of 1.0 is done as
cvtss2sd[EMAIL PROTECTED](%ecx), %xmm0
(this is Linux, the same happens on Darwin).
This is not really a
On Jul 13, 2005, at 4:29 PM, Joe Buck wrote:
On Thu, Jul 14, 2005 at 08:16:07AM +0900, Hiroshi Fujishima wrote:
Eric Botcazou <[EMAIL PROTECTED]> writes:
The configure script which is included in rrdtool[1] checks whether
the system has isinf() as below.
#include
int
main ()
{
float f = 0.0;
Darwin's memcmp has semantics that are an extension of the language
standard:
The memcmp() function returns zero if the two strings are
identical, oth-
erwise returns the difference between the first two differing bytes
(treated as unsigned char values, so that `\200' is greater
On Jul 16, 2005, at 10:34 AM, Andrew Haley wrote:
6.3.2.1: when an object is said to have a particular type, the type
is
specified by the lvalue used to designate the object.
I don't have a standard here, but I will point out that IF this
sentence is
interpreted to mean
the type of an
While fighting with the x86-darwin alignment rules, I noticed that
-malign-double
doesn't seem to affect __alignof__(double). This seems like a bug, but
the
alignof doc has so many qualifications I'm not sure exactly what it's
supposed to
do. Is this broken? Thanks.
On Jul 21, 2005, at 4:36 PM, Tabony, Charles wrote:
Hi,
I am working on a port for a processor that has 32 bit registers but
can
only load 16 bit immediates.
""
"%0.h = #HI(%1)")
What are the semantics of this? Low bits zeroed, or untouched?
If the former, your semantics are identical
On x86 currently the alignments of double and long long are linked:
they are either 4 or 8 depending on whether -malign-double is set.
This follows the documentation of -malign-double. But it's wrong for
what we want the Darwin ABI to be: the default should be that double
is 4 bytes and long lon
On Jul 21, 2005, at 5:04 PM, Tabony, Charles wrote:
From: Dale Johannesen [mailto:[EMAIL PROTECTED]
On Jul 21, 2005, at 4:36 PM, Tabony, Charles wrote:
Hi,
I am working on a port for a processor that has 32 bit registers but
can
only load 16 bit immediates.
""
"%0.h = #
On Jul 21, 2005, at 5:00 PM, Richard Henderson wrote:
On Thu, Jul 21, 2005 at 04:56:01PM -0700, Dale Johannesen wrote:
- Have flags work as now: -malign-double makes both 8,
-mno-align-double
makes both 4. Problem with that is the default is neither of these,
and
this doesn't fit n
On Jul 22, 2005, at 11:07 AM, Chris Lattner wrote:
Hi All,
I'm trying to determine (in target-independent code) what the
*minimum* target alignment of a type is. For example, on darwin,
double's are normally 4-byte aligned, but are 8-byte aligned in some
cases (e.g. when they are the firs
On Jul 23, 2005, at 6:40 AM, Tobias Schlüter wrote:
I have a strong suspicion there is a reason why the two are linked,
and that that reason is FORTRAN. A lot of FORTRAN code assumes
EQUIVALENCE of floating-point and integer types of equal size. Such
code will in all likelyhood break if those
On Jul 25, 2005, at 1:58 AM, Paolo Carlini wrote:
Richard Guenther wrote:
Btw, this list is for the development _of_ gcc, not with gcc.
Use gcc-help for that.
By the way, since we have to point out that *so often*, maybe there is
something wrong on our part: I wonder whether changing the n
O Jul 25, 2005, at 3:50 PM, Robert Dewar wrote:
The unoptimized version completed a 401,900 transaction test with no
problem. All day, I've been playing with different things,
there are many bugs, most notably uninitialed vars, that show
up only when you turn on optimization.
Also violations
With -march=pentium4 -mfpmath=sse -O2, we get an extra move for code
like
double d = atof(foo);
int i = d;
callatof
fstpl -8(%ebp)
movsd -8(%ebp), %xmm0
cvttsd2si %xmm0, %eax
(This is Linux, Darwin is similar.) I think the difficulty is th
On Jul 26, 2005, at 12:51 AM, Paolo Bonzini wrote:
Dale Johannesen wrote:
With -march=pentium4 -mfpmath=sse -O2, we get an extra move for code
like
double d = atof(foo);
int i = d;
callatof
fstpl -8(%ebp)
movsd -8(%ebp), %xmm0
cvttsd2si
On Jul 26, 2005, at 3:34 PM, Dale Johannesen wrote:
I think the RA may be missing the concept that memory might be faster
than any possible register
will dig further.
Yes, it is. The following fixes my problem, and causes a couple of
3DNow-specific regressions
in the testsuite which I
On Jul 27, 2005, at 2:18 PM, Richard Henderson wrote:
On Tue, Jul 26, 2005 at 11:10:56PM -0700, Dale Johannesen wrote:
Yes, it is. The following fixes my problem, and causes a couple of
3DNow-specific regressions
in the testsuite which I need to look at, but nothing serious; I think
it&#
On Jul 27, 2005, at 2:18 PM, Richard Henderson wrote:
On Tue, Jul 26, 2005 at 11:10:56PM -0700, Dale Johannesen wrote:
Yes, it is. The following fixes my problem, and causes a couple of
3DNow-specific regressions
in the testsuite which I need to look at, but nothing serious; I think
it&#
On Jul 31, 2005, at 9:51 AM, Uros Bizjak wrote:
Hello!
With -march=pentium4 -mfpmath=sse -O2, we get an extra move for code
like
double d = atof(foo);
int i = d;
callatof
fstpl -8(%ebp)
movsd -8(%ebp), %xmm0
cvttsd2si %xmm0, %eax
(This is
On Aug 10, 2005, at 12:43 PM, Fariborz Jahanian wrote:
Following patch has exposed an optimization shortcoming:
2005-07-12 Dale Johannesen <[EMAIL PROTECTED]>
* expr.c (compress_float_constant): Add cost check.
* config/rs6000.c (rs6000_rtx_cost): Adjust FLOAT_EXTEND cost.
This
Fariborz is having trouble with his mailer and has asked me to forward his response.
On Aug 10, 2005, at 2:35 PM, Dale Johannesen wrote:
On Aug 10, 2005, at 12:43 PM, Fariborz Jahanian wrote:
Following patch has exposed an optimization shortcoming:
2005-07-12 Dale Johannesen <[EMAIL PROTEC
We had a situation come up here where things are like this (simplified,
obviously):
c() { char x[100]; }
a() { b(); c(); }
b() { a(); c(); }
c() is a leaf. Without inlining, no problem. WIth c() inlined into
a() and/or b(),
a few mutually recursive calls to a() and b() blow out the stack
On Aug 12, 2005, at 12:25 PM, Paul Koning wrote:
"Mike" == Mike Stump <[EMAIL PROTECTED]> writes:
Mike> On Aug 12, 2005, at 10:39 AM, Dale Johannesen wrote:
We had a situation come up here where things are like this
(simplified, obviously):
c() { char x[100]; }
Fariborz is still having problems with his mailer and has asked me to forward this.
On Aug 10, 2005, at 2:35 PM, Dale Johannesen wrote:
On Aug 10, 2005, at 12:43 PM, Fariborz Jahanian wrote:
Following patch has exposed an optimization shortcoming:
2005-07-12 Dale Johannesen <[EMAIL PROTEC
There is some clever code in convert_to_real that converts
double d;
(float)floor(d)
to
floorf((float)d)
(on targets where floor and floorf are considered builtins.)
This is wrong, because the (float)d conversion normally uses
round-to-nearest and can round up to the next integer. For example
On Aug 23, 2005, at 9:53 AM, Richard Henderson wrote:
On Tue, Aug 23, 2005 at 09:28:50AM -0600, Roger Sayle wrote:
Good catch. This is indeed a -ffast-math (or more precisely a
flag_unsafe_math_optimizations) transformation. I'd prefer to
keep these transformations with -ffast-math, as Jan d
The following demonstrates a bug in combine
(x86 -mtune=pentiumpro -O2):
struct Flags {
int filler[18];
unsigned int a:14;
unsigned int b:14;
unsigned int c:1;
unsigned int d:1;
unsigned int e:1;
unsigned int f:1;
};
extern int bar(int), baz();
int foo (struct Flags *f) {
if (f->
We noticed that the simple loop here
extern int a[];
int foo(int w) {
int n = w;
while (n >= 512)
{
a[n] = 42;
n -= 256;
}
}
was being treated as ineligible for the doloop modification. I think
this is
a simple pasto; this code was evidently copied from the previous blo
extern int a[];
int foo(int w) {
int n = w;
while (n >= 512)
{
a[n] = 42;
n -= 256;
}
}
On Aug 30, 2005, at 9:25 AM, Sebastian Pop wrote:
Thanks for looking at this. But...
Dale Johannesen wrote:
I think this is a simple pasto; this code was evidently copied from
the previous block:
I do
On Sep 11, 2005, at 8:09 AM, shreyas krishnan wrote:
Hi,
Can anyone tell me if there is a way to find out roughly the
source line no of a particular rtl instruction (if there is ) ? I
believe tree has a link to the source line no, in which case how do I
find out the source tree node for a
Consider the following SSE code
(-march=pentium4 -mtune=prescott -O2 -mfpmath=sse -msse2)
#include
__m128i foo3(__m128i z, __m128i a, int N) {
int i;
for (i=0; i
The first inner loop compiles to
paddq %xmm0, %xmm1
Good. The second compiles to
movdqa %xmm2,
On Sep 14, 2005, at 9:50 PM, Andrew Pinski wrote:
On Sep 14, 2005, at 9:21 PM, Dale Johannesen wrote:
Consider the following SSE code
(-march=pentium4 -mtune=prescott -O2 -mfpmath=sse -msse2)
<4256776a.c>
The first inner loop compiles to
paddq %xmm0, %xmm1
Good. The
Just to review, the second function here was the problem:
(-march=pentium4 -mtune=prescott -O2 -mfpmath=sse -msse2)
#include
__m128i foo3(__m128i z, __m128i a, int N) {
int i;
for (i=0; i
where the inner loop compiles to
movdqa %xmm2, %xmm0
paddw %xmm1, %xmm0
On Sep 19, 2005, at 5:30 PM, Richard Henderson wrote:
(define_insn "*addmixed3"
[(set (match_operand:V2DI 0 "register_operand" "=x")
(subreg:V2DI (plus:SSEMODE124
(match_operand:SSEMODE124 2 "nonimmediate_operand" "xm")
(subreg:SSEMODE124 (match_operand:V2DI 1 "nonimmediat
On Sep 19, 2005, at 9:15 PM, Richard Henderson wrote:
On Mon, Sep 19, 2005 at 05:33:54PM -0700, Dale Johannesen wrote:
Do you have any constructive suggestions for how the RA might be
fixed,
then?
Short term? No. But I don't see this as a short term problem.
OK. Unfortunately, it
The C constraint on x86 is defined, in both the doc and the comments, as
"constant that can be easily constructed in SSE register without loading
from memory". Currently the only one handled is 0, but there is at
least
one more, all 1 bits, which is constructed by
pcmpeqd %xmm, %xmm
Unfor
On Sep 30, 2005, at 4:17 PM, Jan Hubicka wrote:
The C constraint on x86 is defined, in both the doc and the comments,
as
"constant that can be easily constructed in SSE register without
loading
from memory". Currently the only one handled is 0, but there is at
least
one more, all 1 bits, wh
In C++, when we have an automatic array with variable initializers:
void bar(char[4]);
void foo(char a, char b, char c, char d) {
char x[4] = { a, b, c, d };
bar(x);
}
the C++ FE generates 32-bit store(s) of 0 for the entire array,
followed by stores
of the individual elements. In the case
On Oct 1, 2005, at 7:29 PM, Andrew Pinski wrote:
I don't think this will work for the following code:
void foo(char a, char b) {
char x[4] = { a, b } ;
if (x[3] != 0)
abort ();
}
Duh. I thought that was too easy.
But better fix would be not call split_nonconstant_init_1 for
local de
On Oct 3, 2005, at 3:49 PM, Andrew Pinski wrote:
On Oct 3, 2005, at 6:41 PM, Evan Cheng wrote:
But according to the manual -msse3 does not turn on generation of
SSE3 instructions:
The manual is semi-confusing I had forgot about that.
There is a bug about the issue recorded as PR 23809:
http://
On Oct 1, 2005, at 8:41 PM, Andrew Pinski wrote:
On Oct 1, 2005, at 11:10 PM, Dale Johannesen wrote:
But better fix would be not call split_nonconstant_init_1 for
local decls and have the front-end produce a CONSTRUCTOR which is
just like what the C front-end produces.
I'll try it.
My question is: where and how would you suggest we do this
optimization. With peephole2? Or in combine? In i386.md, I see pattern
*subsi_2 looks like what I'd like to combine these two insn into:
(define_insn "*subsi_2"
[(set (reg FLAGS_REG)
(compare
(minus:SI (match_operand:SI 1
On Oct 25, 2005, at 5:40 PM, Joe Buck wrote:
The problem, I think, is that the behavior of both GCC *and* the
other compilers does not serve the users.
The reason is that there simply isn't any reason why a user would
use a backslash to continue a C++ comment on purpose, and plenty of
reason wh
On Nov 17, 2005, at 3:09 PM, Robert Dewar wrote:
Richard Earnshaw wrote:
We spend a lot of time printing out the results of compilation as
assembly language, only to have to parse it all again in the
assembler.
I never like arguments which have loaded words like "lot" without
quantification
On Dec 5, 2005, at 12:03 AM, Giovanni Bajo wrote:
Jack Howarth <[EMAIL PROTECTED]> wrote:
What exactly is the implication of having a hundred or more of this in
an application being built with gcc/g++ 4.x at -O3? Does it only risk
random crashes in the generated code or does it also impact the
q
On Dec 16, 2005, at 10:31 AM, Dan Kegel wrote:
Ronny Peine wrote:
-ftree-loop-linear is removed from the testingflags in gcc-4.0.2
because
it leads to an endless loop in neural net in nbench.
Could you fill a bug report for this one?
Done.
This is probably the same as 20256.
Your PR i
On Jan 26, 2006, at 4:05 PM, [EMAIL PROTECTED] wrote:
I really need correct profile information before PRE. By moving
rest_of_handle_branch_prob() just before rest_of_handle_gcse() have I
violated some critical assumptions which is causing the profile
information to be occasionally corrupted ?
r_stmt signs_all[2] = (int) sz <= 0 >>>;
While the C front-end is producing:
const int signs_all[4] = {(int) sx <= 0, (int) sy <= 0, (int) sz <= 0,
0};
Dale Johannesen and I came up with a patch to the C++ front-end
for this except it did not work with some C++ cases.
On Feb 23, 2006, at 8:54 AM, H. J. Lu wrote:
When I use -O2 -mtune=pentium4 -ffast-math on SPEC CPU 2K on Linux/x86
with gcc 4.2, I get
*** Miscompare of 200.s, see
/export/spec/src/2000/spec/benchspec/CINT2000/176.gcc/run/0004/
200.s.mis
*** Miscompare of scilab.s, see
/export/spec/src/
On Mar 7, 2006, at 12:28 AM, Yang Yang wrote:
Recently, I'm very interested in the inlining model of gcc.I need a
detailed documentation describing how the inlining is implemented in
gcc 4.0. Anybody who has been or is working on it please send me a
documentation. I'd really appreciate your hel
On Apr 17, 2006, at 11:52 AM, Mark Mitchell wrote:
Dan Berlin and I exchanged some email about PR 26435, which concerns a
bug in -ftree-loop-linear, and we now think it would make sense to
have
a broader discussion.
The PR in question is about an ice-on-valid regression in 4.1, when
using -O1
On Apr 17, 2006, at 2:31 PM, Richard Guenther wrote:
On 4/18/06, Ivan Novick <[EMAIL PROTECTED]> wrote:
I am a gcc user at a fininancial institution and IMHO it would not
be a
good idea to have non-production ready functionality in gcc. We are
trying to use gcc for mission critical function
On Apr 19, 2006, at 12:04 AM, Kai Henningsen wrote:
[EMAIL PROTECTED] (Daniel Berlin) wrote on 18.04.06 in
<[EMAIL PROTECTED]>:
This is in fact, not terribly surprising, since the algorithm used
was the
result of Sebastian and I sitting at my whiteboard for 30 minutes
trying to
figure ou
On Apr 19, 2006, at 11:52 AM, Daniel Berlin wrote:
So is this an object lesson for why optimizing for benchmarks is
a bad
idea?
If you're inclined to believe this, you could find a confirming
instance here, but there are other lessons that could be drawn. If
you go back to the original threa
On May 19, 2006, at 12:48 PM, sean yang wrote:
Although "BASIC_BLOCK array contains BBs in an unspecified order"
as the GCC internal doc says, can I assume that the final virtual
address for an instruction in BB_m is always higher than the
virtual address for an instruction in BB_n, when m
1 - 100 of 110 matches
Mail list logo
