Hello!
I just got interested and did a test myself. Comparing gcc 4.0 (-O2
-funroll-loops -D__NO_MATH_INLINES -ffast-math -march=pentium4
-mfpmath=sse -ftree-vectorize)
and icc 9.0 beta (-O3 -xW -ip):
Here are the results of scimark with '-O3 -march=pentium4 -mfpmath=...
-funroll-loops -ftree-
I am thinking of including a front-end for INTERCAL for
GCC. INTERCAL is an estoric programming langauge that was
created in 1972 with the goal of having nothing in common
with other langauges (see http://catb.org/~esr/intercal).
There is a C implementation of INTERCAL (called C-INTERCAL)
th
In attempting to configure a target limited to 32-bit C type support, it
became obvious that exception support seems to be unconditionally required,
and defaults to assuming target support for 64-bit data types although not
necessarily configured to support data types this large?
- is this intenti
I have had no trouble specifiying the linker script using the -T
switch to gcc. I am now trying to specify the linker script from a
specs file like so:
%rename link old_link
*link:
-Thello.ld%s %(old_link)
gcc complains though about linking Thumb code against ARM libraries --
I've specified -mthu
On Thu, Feb 24, 2005 at 03:23:53PM -0800, Shaun Jackman wrote:
> When -Ttext is used in combination with -mthumb it causes a relocation
> truncated to fit message. What does this mean, and how do I fix it?
>
> Please cc me in your reply. Thanks,
> Shaun
Don't use -Ttext with an ELF toolchain; use
Hello,
Regarding the testcase I mentioned before, I have been checking out the
Intel compiler to see if it would generate better code. Interestingly
enough, it displays EXACTLY the same run-times as gcc for the two tests
(0.2s for math in if-block, 1.0s for math out of if-block).
So this is r
When -Ttext is used in combination with -mthumb it causes a relocation
truncated to fit message. What does this mean, and how do I fix it?
Please cc me in your reply. Thanks,
Shaun
$ arm-elf-gcc --version | head -1
arm-elf-gcc (GCC) 3.4.0
$ cat hello.c
int main() { return 0; }
$ arm-elf-gcc -Ttex
My assumption here was that if I gave you a few pointers, you would try
to debug the problem yourself. If you want someone else to debug it for
you, then you need to give much better info. See for instance
http://gcc.gnu.org/bugs.html
which gives info on how to properly report a bug. I have t
Is it possible by hacking the specs file to change the target for
arm-elf-gcc from -marm to -mthumb? I tried a few obvious things like
changing marm in *multilib_defaults to mthumb, but this did not have
the desired effect.
Please cc me in your reply. Thanks!
Shaun
On Thu, 2005-02-24 at 22:28 +0100, Steven Bosscher wrote:
> On Thursday 24 February 2005 21:59, Andrew Pinski wrote:
> > On Feb 24, 2005, at 3:55 PM, Tarun Kawatra wrote:
> > > Actually I am trying to extend PRE implementation so that it performs
> > > strength reduction as well. it requires multip
On Thu, 24 Feb 2005, James E Wilson wrote:
On Thu, 2005-02-24 at 12:55, Tarun Kawatra wrote:
You are write here that if some expr doesn't get into hash table, it will
^^
right.
-tarun
not get optimized.
That was an assumption on my part. You shouldn't take it as the literal
On Thu, 24 Feb 2005, Andrew Pinski wrote:
On Feb 24, 2005, at 3:55 PM, Tarun Kawatra wrote:
Actually I am trying to extend PRE implementation so that it performs
strength reduction as well. it requires multiplication expressions to get
into hash table.
Why do you want to do that?
Strength reducti
On Thursday 24 February 2005 21:59, Andrew Pinski wrote:
> On Feb 24, 2005, at 3:55 PM, Tarun Kawatra wrote:
> > Actually I am trying to extend PRE implementation so that it performs
> > strength reduction as well. it requires multiplication expressions to
> > get into hash table.
>
> Why do you wa
On Thursday 24 February 2005 21:16, James E Wilson wrote:
> On Thu, 2005-02-24 at 03:15, Steven Bosscher wrote:
> > On Feb 24, 2005 11:13 AM, Tarun Kawatra <[EMAIL PROTECTED]> wrote:
> > Does GCSE look into stuff in PARALLELs at all? From gcse.c:
>
> Shrug. The code in hash_scan_set seems to be d
On Thu, 2005-02-24 at 12:55, Tarun Kawatra wrote:
> You are write here that if some expr doesn't get into hash table, it will
> not get optimized.
That was an assumption on my part. You shouldn't take it as the literal
truth. I'm not an expert on all implementation details of the gcse.c
pass.
On Thu, 24 Feb 2005, James E Wilson wrote:
On Thu, 2005-02-24 at 03:15, Steven Bosscher wrote:
On Feb 24, 2005 11:13 AM, Tarun Kawatra <[EMAIL PROTECTED]> wrote:
Does GCSE look into stuff in PARALLELs at all? From gcse.c:
Shrug. The code in hash_scan_set seems to be doing something
reasonable.
Th
On Thu, 2005-02-24 at 15:59 -0500, Andrew Pinski wrote:
> On Feb 24, 2005, at 3:55 PM, Tarun Kawatra wrote:
>
> > Actually I am trying to extend PRE implementation so that it performs
> > strength reduction as well. it requires multiplication expressions to
> > get into hash table.
>
> Why do y
On Feb 24, 2005, at 3:55 PM, Tarun Kawatra wrote:
Actually I am trying to extend PRE implementation so that it performs
strength reduction as well. it requires multiplication expressions to
get into hash table.
Why do you want to do that?
Strength reduction is done already in loop.c.
Thanks,
Andr
On Thu, 24 Feb 2005, James E Wilson wrote:
On Thu, 2005-02-24 at 03:15, Steven Bosscher wrote:
On Feb 24, 2005 11:13 AM, Tarun Kawatra <[EMAIL PROTECTED]> wrote:
Does GCSE look into stuff in PARALLELs at all? From gcse.c:
Shrug. The code in hash_scan_set seems to be doing something
reasonable.
Th
>From here:
http://gcc.gnu.org/ml/gcc/2005-02/msg00923.html
I so want this. I've created a bugzilla entry for this as an enhancement so
this does not get lost.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20201
-benjamin
On Thu, 2005-02-24 at 03:15, Steven Bosscher wrote:
> On Feb 24, 2005 11:13 AM, Tarun Kawatra <[EMAIL PROTECTED]> wrote:
> Does GCSE look into stuff in PARALLELs at all? From gcse.c:
Shrug. The code in hash_scan_set seems to be doing something
reasonable.
The problem I saw wasn't with finding e
On Thu, 2005-02-24 at 09:20, Tarun Kawatra wrote:
> On Wed, 23 Feb 2005, James E Wilson wrote:
> > While looking at this, I noticed can_assign_to_reg_p does something silly.
> ^^^
> I could not find this function anywhere in gc
On Thu, 2005-02-24 at 02:13, Tarun Kawatra wrote:
> If that is the reason, then even plus expression (shown below) should not
> be subjected to PRE as it also clobbers a hard register(CC). But it is being
> subjected to PRE. Multiplication expression while it looks same does not
> get even in hash
On Thu, 24 Feb 2005 20:05:37 +0100, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> Jan Hubicka wrote:
>
> >>Also, for the simple function
> >>
> >>double foo1(double x)
> >>{
> >>return x;
> >>}
> >>
> >>we return 4 as a cost, because we have
> >>
> >> double tmp = x;
> >> return tmp;
>
Jan Hubicka wrote:
Also, for the simple function
double foo1(double x)
{
return x;
}
we return 4 as a cost, because we have
double tmp = x;
return tmp;
and count the move cost (MODIFY_EXPR) twice. We could fix this
by not walking (i.e. ignoring) RETURN_EXPR.
That would work, yes. I wa
Those of you who read my status reports closely will recognize that
today is the day I announced as the day on which I would create the 4.0
release branch. I still plan to do that sometime today, where "today"
is generously defined as "before I go to sleep tonight here in California".
I've rec
On Sat, 11 Dec 2004, Gerald Pfeifer wrote:
>>> http://gcc.gnu.org/cgi-bin/cvsweb.cgi/old-gcc/PROBLEMS?annotate=1.1
>> The thing matching "PR" must be a little overzealous :)
> Yup. I think I know how to fix this and hope to do it in the next few
> days (after some other technical issues have been
Janis Johnson wrote:
On Thu, Feb 24, 2005 at 11:46:20AM +0100, Volker Reichelt wrote:
Regressions that cause ICE's on invalid code often go unnoticed in the
testsuite, since regular errors and ICE's both match { dg-error "" }.
See for example g++.dg/parse/error16.C which ICE's since yesterday,
but
Is there a patch for the following problem?
I am having problems with _M_fill_initialize in deque on the powerpc
version compiled at -O2.
template
void
deque<_Tp,_Alloc>::
_M_fill_initialize(const value_type& __value)
{
_Map_pointer __cur;
try
{
for
On Thu, Feb 24, 2005 at 11:46:20AM +0100, Volker Reichelt wrote:
> Regressions that cause ICE's on invalid code often go unnoticed in the
> testsuite, since regular errors and ICE's both match { dg-error "" }.
> See for example g++.dg/parse/error16.C which ICE's since yesterday,
> but the testsuite
On Wed, 23 Feb 2005, James E Wilson wrote:
Tarun Kawatra wrote:
During expression hash table construction in gcse pass(gcc vercion 3.4.1),
expressions like a*b does not get included into the expression hash table.
Such expressions occur in PARALLEL along with clobbers.
You didn't mention the targ
On Thursday 24 February 2005 17.06, Richard Guenther wrote:
> I just got interested and did a test myself. Comparing gcc 4.0 (-O2
> -funroll-loops -D__NO_MATH_INLINES -ffast-math -march=pentium4
> -mfpmath=sse -ftree-vectorize)
> and icc 9.0 beta (-O3 -xW -ip):
>
On Thu, 24 Feb 2005 17:09:46 +0100, Biagio Lucini <[EMAIL PROTECTED]> wrote:
> On Thursday 24 February 2005 16.52, Paolo Bonzini wrote:
> >
> > Try these five combinations:
> >
> [...]
> >
> > -O3 -fomit-frame-pointer -ffast-math -fno-tree-pre
>
> [...]
>
> This + 387 math is the one with the lar
> Regressions that cause ICE's on invalid code often go unnoticed in the
> testsuite, since regular errors and ICE's both match { dg-error "" }.
> See for example g++.dg/parse/error16.C which ICE's since yesterday,
> but the testsuite still reports "PASS":
>
>Executing on host:
> /Work/reich
On Thursday 24 February 2005 16.52, Paolo Bonzini wrote:
>
> Try these five combinations:
>
[...]
>
> -O3 -fomit-frame-pointer -ffast-math -fno-tree-pre
[...]
This + 387 math is the one with the larger impact: it rises MC to around 80,
but composite is still 279 (vs. ~ 345 for GCC 3.4). I will t
I just got interested and did a test myself. Comparing gcc 4.0 (-O2
-funroll-loops -D__NO_MATH_INLINES -ffast-math -march=pentium4
-mfpmath=sse -ftree-vectorize)
and icc 9.0 beta (-O3 -xW -ip):
gcc 4.0 icc 9.0
Composite Score: 543.65609.20
FFT
For GCC, I used in both cases the flags
-march=pentium4 -mfpmath=sse -O3 -fomit-frame-pointer -ffast-math
>
As for gcc4 vs gcc3.4, degradataion on x86 architecture is most
probably because of higher register pressure created with more
aggressive SSA optimizations in gcc4.
Try these five combinat
It is my pleasure to announce that the steering committee has appointed
James A. Morrison maintainer of our treelang frontend; Jim has been
working on that for some time now.
We'd also like to take the opportunity and thank Tim Josling for the
time and effort he has spent on this frontend.
Ple
Biagio Lucini wrote:
I run for my personal pleasure (since I am a number cruncher) the
Scimark2 tests on my P4 Linux machine. I tested GCC 4.0 (today's CVS) vs. GCC
3.4.1 vs. Intel's ICC 8.1
For GCC, I used in both cases the flags
-march=pentium4 -mfpmath=sse -O3 -fomit-frame-pointer -ffast-math
On Thu, 24 Feb 2005 10:13:11 -0500, Andrew Pinski
<[EMAIL PROTECTED]> wrote:
>
> On Feb 24, 2005, at 10:07 AM, Richard Guenther wrote:
>
> > Hi!
> >
> > In estimate_num_insns_1 we currently have:
> >
> > /* Recognize assignments of large structures and constructors of
> >big arrays.
On Feb 24, 2005, at 10:07 AM, Richard Guenther wrote:
Hi!
In estimate_num_insns_1 we currently have:
/* Recognize assignments of large structures and constructors of
big arrays. */
case INIT_EXPR:
case MODIFY_EXPR:
x = TREE_OPERAND (x, 0);
/* FALLTHRU */
case TAR
> Hi!
>
> I'm looking at improving inlining heuristics at the moment,
> especially by questioning the estimate_num_insns. All uses
> of that function assume it to return a size cost, not a computation
> cost - is that correct? If so, why do we penaltize f.i. EXACT_DIV_EXPR
> compared to MULT_EXP
Hi!
In estimate_num_insns_1 we currently have:
/* Recognize assignments of large structures and constructors of
big arrays. */
case INIT_EXPR:
case MODIFY_EXPR:
x = TREE_OPERAND (x, 0);
/* FALLTHRU */
case TARGET_EXPR:
case CONSTRUCTOR:
{
HOST
> Kai Ruottu writes:
Kai> In the crossgcc list was a problem with gcc-3.4 generating the opcode
Kai> 'mfcr' with '-mcpu=power' for the second created multilib, when the
Kai> GCC target is 'rs6000-ibm-aix4.3'. The other multilibs produced as
Kai> default are for '-pthread', '-mcpu=powerpc' and
I run for my personal pleasure (since I am a number cruncher) the
Scimark2 tests on my P4 Linux machine. I tested GCC 4.0 (today's CVS) vs. GCC
3.4.1 vs. Intel's ICC 8.1
For GCC, I used in both cases the flags
-march=pentium4 -mfpmath=sse -O3 -fomit-frame-pointer -ffast-math
Should be of some in
Andrew Haley writes:
> Jakub Jelinek writes:
>
> > > > While I still like using dl_iterate_phdr instead of
> > > > __register_frame_info_bases for totally aesthetic reasons, there
> > > > have been changes made to the dl_iterate_phdr interface since the
> > > > gcc support was writte
On Thu, 24 Feb 2005, Steven Bosscher wrote:
> On Feb 24, 2005 01:58 PM, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > I'm looking at improving inlining heuristics at the moment,
> > especially by questioning the estimate_num_insns.
>
> Good. There is lots of room for improvement there.
>
> > A
On Feb 24, 2005 01:58 PM, Richard Guenther <[EMAIL PROTECTED]> wrote:
> I'm looking at improving inlining heuristics at the moment,
> especially by questioning the estimate_num_insns.
Good. There is lots of room for improvement there.
> All uses
> of that function assume it to return a size cos
Hi!
I'm looking at improving inlining heuristics at the moment,
especially by questioning the estimate_num_insns. All uses
of that function assume it to return a size cost, not a computation
cost - is that correct? If so, why do we penaltize f.i. EXACT_DIV_EXPR
compared to MULT_EXPR?
Also, for
In the crossgcc list was a problem with gcc-3.4 generating the opcode
'mfcr' with '-mcpu=power' for the second created multilib, when the
GCC target is 'rs6000-ibm-aix4.3'. The other multilibs produced as
default are for '-pthread', '-mcpu=powerpc' and '-maix64'... The AIX
users could judge if all
On Feb 24, 2005 11:13 AM, Tarun Kawatra <[EMAIL PROTECTED]> wrote:
> >> Such expressions occur in PARALLEL along with clobbers.
> >
> > You didn't mention the target, or exactly what the mult looks like.
>
> Target is i386 and the mult instruction looks like the following in RTL
>
> (insn 22 21 2
Regressions that cause ICE's on invalid code often go unnoticed in the
testsuite, since regular errors and ICE's both match { dg-error "" }.
See for example g++.dg/parse/error16.C which ICE's since yesterday,
but the testsuite still reports "PASS":
Executing on host: /Work/reichelt/gccbuild/src-
On Wed, 23 Feb 2005 10:36:07 -0800, Benjamin Redelings I
<[EMAIL PROTECTED]> wrote:
> Hi,
> I have a C++ program that runs slower under 4.0 CVS than 3.4. So, I
> am
> trying to make some test-cases that might help deduce the reason.
> However, when I reduced this testcase sufficiently, it
On Wed, 23 Feb 2005, James E Wilson wrote:
Tarun Kawatra wrote:
During expression hash table construction in gcse pass(gcc vercion 3.4.1),
expressions like a*b does not get included into the expression hash table.
Such expressions occur in PARALLEL along with clobbers.
You didn't mention the targ
Hi!
When working with unit tests I frequently have the need to override a
function or variable in a shared library. This works just as I want for
global symbols, but if the symbol is local (declared static) I have to
modify the source (remove the static using a STATIC preprocessor define)
to ma
55 matches
Mail list logo
