Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| >Maybe that is the case for Ada; for the C or C++ standards, you'll
| > have to define "good reason". -- Gaby
| >
| Again, I suggest that vague high level discussion is a waste of time
| here,
I wholeheartly agree, that is w
Gabriel Dos Reis wrote:
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| >Maybe that is the case for Ada; for the C or C++ standards, you'll
| > have to define "good reason". -- Gaby
| >
| Again, I suggest that vague high level discussion is a waste of time
| here,
I
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| >Robert Dewar <[EMAIL PROTECTED]> writes:
| >
| >| Gabriel Dos Reis wrote:
| > | | >Maybe that is the case for Ada; for the C or C++ standards,
| > you'll
| >| > have to define "good reason". -- Gaby
| >| >
| >| Again, I sugge
Gabriel Dos Reis wrote:
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| >Robert Dewar <[EMAIL PROTECTED]> writes:
| >
| >| Gabriel Dos Reis wrote:
| > | | >Maybe that is the case for Ada; for the C or C++ standards,
| > you'll
| >| > have to define "good reason". -- Gab
I am not sure if the original poster meant the same as I do. What I have
in mind is optimizations opportunities like the one of the following
linked list:
struct list_element
{
struct list_element *p_next;
int *p_value;
};
int sum_list_values(const struct list_element *p_list)
c;
}
printf ("%d\n",sum);
if (sum != 1)
abort();
return 0;
}
.file "t.c"
# GNU C version 4.2.0 20060101 (experimental) (x86_64-unknown-linux-gnu)
# compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux).
# GGC heuristics: --param ggc-mi
Happy 2006!
I was compiling LZMA SDK (http://www.7-zip.org/, LzmaDecode.c) and just
for curiosity I looked at output assembler. I noted that when PIC is
enabled (-fpic, Linux Intel) ebx is reserved to global pointer. However
LzmaDecode do not access any global data and do not call other functions
> Gabriel Dos Reis wrote:
> I predict we will end up changing nothing for GCC; I also predict that
> he'll be unsatisfied with unsupported claims; then, there is a high
> chance the discussion will be restarted again in a different form
> (hey, this is not the first time you, Paul and me are involv
> From: Robert Dewar <[EMAIL PROTECTED]>>
> though Paul's mention of saturating arithmetic seems way out of left field to
> me, since very few common architectures implement saturating arithmetic at the
> hardware level.
- Only every single dsp, and an increasing number of otherwise conventional
Steven Bosscher wrote:
> Hi rth,
>
> The stack space sharing you added to cfgexpand.c breaks RTL alias
> analysis.
>
> For example, the attached test case breaks for pentiumpro at -O2.
> The problem apparently is that the second store to c is moved up
> before before the load.
My guess at a sol
> Steven Bosscher wrote:
> > Hi rth,
> >
> > The stack space sharing you added to cfgexpand.c breaks RTL alias
> > analysis.
> >
> > For example, the attached test case breaks for pentiumpro at -O2.
> > The problem apparently is that the second store to c is moved up
> > before before the load.
> From: Michael Veksler wrote:
> I am not sure if the original poster meant the same as I do. What I have
> in mind is optimizations opportunities like the one of the following
> linked list:
(for reference: http://gcc.gnu.org/ml/gcc/2006-01/msg7.html )
- although not specifically what I was
E:\msys\1.0\home\gcc>gcc -v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.1-20051223/configure --host=mingw32 --build=mingw32 --
target=mingw32 --enable-threads --disable-nls --enable-optimize --enable-languag
es=c,c++ --prefix=e:/mingw4
Thread model: win32
gcc version 4.1.0 20051
Paul Schlie wrote:
Gabriel Dos Reis wrote:
I predict we will end up changing nothing for GCC; I also predict that
he'll be unsatisfied with unsupported claims; then, there is a high
chance the discussion will be restarted again in a different form
(hey, this is not the first time you, Paul and m
On Sun, 2006-01-01 at 10:22 -0800, Mark Mitchell wrote:
> Steven Bosscher wrote:
> > Hi rth,
> >
> > The stack space sharing you added to cfgexpand.c breaks RTL alias
> > analysis.
> >
> > For example, the attached test case breaks for pentiumpro at -O2.
> > The problem apparently is that the se
EXTEIDE is freeware. Anyone can download now.
Please visit http://www.exteide.com
Thanks.
--
Sent from the gcc - Dev forum at Nabble.com:
http://www.nabble.com/The-Extension-IDE---EXTEIDE-t835749.html#a2166859
16 matches
Mail list logo
