headers
Giovanni Bajo | 1 Mar 2004 01:41
Picon
Favicon

Re: __attribute__ ((regparm(...))) in function declaration and gcc 3.4.0

Nicholas Nethercote wrote:

>> Why this fails to compile with gcc 3.4.0 (i686-pc-linux-gnu,
>> 20030229)?
>>
>> $ cat > test.h
>> int plus (int a, int b)  __attribute__ ((regparm (2)));
>> $ cat > test.c
>> #include "test.h"
>>
>> int plus (int a, int b)
>> {
>> return a + b;
>> }
>> $ gcc -c test.c
>> test.c:4: error: conflicting types for 'plus'
>> test.h:1: error: previous declaration of 'plus' was here
>> test.c:4: error: conflicting types for 'plus'
>> test.h:1: error: previous declaration of 'plus' was here
>
> Try adding the __attribute__((regparm(2))) to the function definition
> as well.  It seems this behaviour is new with 3.4.0.

Yes, but I don't know if this is intended. Maybe someone can clarify this?
Otherwise we should file a bugreport.

Giovanni Bajo
Permalink | Reply | 1 comment |
headers
Andrew Pinski | 1 Mar 2004 01:43
Picon

gcc and compiling speed

Marc,
Now I know you have been asked before every time you bring up on the
GCC's mailing list about a set of preprocessed source for openbsd so
that the speed of GCC will improve.  It seems like you are ignoring
them and still complain about the compile time speed regressions in
GCC.  If you (or some from the openbsd project) submit a bug with
numbers and a way to reproduce it with say the openbsd's kernel
sources, we will no longer disagree with you and fix the problem
in GCC.

Thanks,
Andrew Pinski
a gcc bug master and libobjc maintainer
Permalink | Reply | 46 comments |
headers
H. J. Lu | 1 Mar 2004 01:46

Re: What to call Intel ia32e processor?

On Sun, Feb 29, 2004 at 08:40:15PM +0100, Gerald Pfeifer wrote:
> On Fri, 27 Feb 2004, H. J. Lu wrote:
> > Currently, when you configure gcc for x86_64-linux, it will tune for
> > K8. I want a new target, which will tune for Intel ia32e processor by
> > default. I am using ia32e-linux for the time being.
> 
> That way a lot of software won't recognize that beast at _all_, neither
> as i386 nor as amd64 compatible.

I only want it for gcc and you have to use it by hand like

# ../configure ia32e-linux

which will configure gcc to tune for Intel ia32e processor by default.
Nothing else will be affected.

H.J.
Permalink | Reply | 3 comments |
headers
Diego Novillo | 1 Mar 2004 02:09
Picon
Favicon

Re: [tree-ssa] Mainline merge plan

On Sun, 2004-02-29 at 17:35, Al Stone wrote:
> By the same token, if there's anything I can do to
> help with ia64-unknown-linux-gnu, let me know.
> 
Thanks.  We already have daily tests for ia64 linux, but more testers
can't hurt.  Note that currently the branch doesn't bootstrap on ia64. 
I *think* it's because of mainline problems at the previous merge, but
I'm not sure.

Diego.
Permalink | Reply | 4 comments |
headers
Al Stone | 1 Mar 2004 02:12
Picon

Munging gcc-testresults <at> messages

I was trying to get a clear picture of what is going
on with GCC on all the various branches and all the
various platforms.  Subscribing to gcc-testresults <at> 
(and sending data to it) was interesting, but it was
taking too long to digest everything.  And, getting
trend data was just plain painful.

So, I wrote some python scripts to munge through all
the stuff sent to gcc-testresults <at>  and generate some
HTML tables for me.  The goal (based on a suggestion
from Geoff Keating) was to try to see at a glance whether
a particular branch, for a particular triplet, was
getting better, worse, or not changing.  What I came
up with can be seen at:

http://free.linux.external.hp.com/~ahs3/gcc/new_results.html

I make _no_ claims to be any good at all with HTML,
so there's probably lots of room for improvement.  And
there's probably a much simpler way to present the
material -- I'm open to suggestions.  So far, this is
working for me and if it can help out elsewhere, so
much the better.  There's roughly a month's worth of
emails from gcc-testresults <at>  represented right now,
and the data gets updated roughly every four hours.

BTW, all the scripts and a brief README are kept in:

http://free.linux.external.hp.com/~ahs3/gcc
(Continue reading)

Permalink | Reply | 1 comment |
headers
Al Stone | 1 Mar 2004 02:19
Picon

Re: [tree-ssa] Mainline merge plan

Probably true.  Mainline has not bootstrapped on
ia64 for a couple of weeks; the day job has been
getting in the way of hunting this down, though
I'm hoping to get a chance to spend some time on
it this coming week...

On Sun, 2004-02-29 at 18:09, Diego Novillo wrote:
> On Sun, 2004-02-29 at 17:35, Al Stone wrote:
> > By the same token, if there's anything I can do to
> > help with ia64-unknown-linux-gnu, let me know.
> > 
> Thanks.  We already have daily tests for ia64 linux, but more testers
> can't hurt.  Note that currently the branch doesn't bootstrap on ia64. 
> I *think* it's because of mainline problems at the previous merge, but
> I'm not sure.
> 
> 
> Diego.
--

-- 
Ciao,
al
----------------------------
Al Stone
Linux & Open Source Lab
Hewlett-Packard Company
E-mail: ahs3 <at> fc.hp.com
----------------------------
Permalink | Reply | 3 comments |
headers
Daniel Jacobowitz | 1 Mar 2004 02:29

Re: What to call Intel ia32e processor?

On Sun, Feb 29, 2004 at 04:46:14PM -0800, H. J. Lu wrote:
> On Sun, Feb 29, 2004 at 08:40:15PM +0100, Gerald Pfeifer wrote:
> > On Fri, 27 Feb 2004, H. J. Lu wrote:
> > > Currently, when you configure gcc for x86_64-linux, it will tune for
> > > K8. I want a new target, which will tune for Intel ia32e processor by
> > > default. I am using ia32e-linux for the time being.
> > 
> > That way a lot of software won't recognize that beast at _all_, neither
> > as i386 nor as amd64 compatible.
> 
> I only want it for gcc and you have to use it by hand like
> 
> # ../configure ia32e-linux
> 
> which will configure gcc to tune for Intel ia32e processor by default.
> Nothing else will be affected.

You could do this the way _EVERY OTHER TARGET_ besides x86 does it,
with --with-cpu.  Which works for x86, by the way.

--

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer
Permalink | Reply | 0 comments |
headers
Mark Mitchell | 1 Mar 2004 03:29

Vector problems with GCC 3.4


Aldy --

There are three PRs relating to problems with vector instructions in
GCC 3.4:

  PR 11983
  PR 14219
  PR 14343

All of these are pretty serious problems: they're going to impact real
people using the compiler.  Would you please take a look and see if
you can address any of these issues?

--
Mark Mitchell
CodeSourcery, LLC
mark <at> codesourcery.com
Permalink | Reply | 5 comments |
headers
Mark Mitchell | 1 Mar 2004 03:32

Problems with cp_expr_size and friends in GCC 3.4


Jason --

These are three C++ PRs assigned to you for G++ 3.4:

  PR 13170
  PR 13294
  PR 13944

Would you please take a look at these and see if you can get fixes for
them?

--
Mark Mitchell
CodeSourcery, LLC
mark <at> codesourcery.com
Permalink | Reply | 0 comments |
headers
William Reading | 1 Mar 2004 03:39
Picon
Favicon

Obsolete mn10200?

Howdy,

I was curious as to what would be required to keep this from becoming 
obsoleted.

Regards,
William Reading
Permalink | Reply | 1 comment |

Gmane