Re: Using inline assembly with specific register indices

2005-04-05 Thread Eric Christopher
> > Ok about the "r" convention I wrongfully used, it is assumed for the integer > register-file. > Correct. > I am currently using MIPS + soft-float + some other functionalities in > Coprocessor #2 with success (somewhat tested in a functional simulator). About > 10-12 special-purpose instruc

Re: Question about "#pragma pack(n)"

2005-04-05 Thread feng qiu
In c-pragma.c file, #pragma pack(n) set the value of "maximum_field_alignment". And in opts.c file,-fpack-struct set "flag_pack_struct = 1" . But I don't known the relation between them. It seems that they relate to the four ariables―― DECL_ALIGN,DECL_PACKED,TYPE_PACKED,and TYPE_ALIGN in stor-la

about alias analysis

2005-04-05 Thread zouq
i wonder whether there exists or not alias analysis for scalar variable, array variable, even pointers. thank you.

Re: Question about "#pragma pack(n)"

2005-04-05 Thread James E Wilson
feng qiu wrote: > I want to modify the gcc source code,what should I do? Look at the c-pragma.c file, search for pack. Also see -fpack-struct in common.opt and fpack_struct in opts.c. Then expand your search from there. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: gcc4, static array, SSE & alignement

2005-04-05 Thread James E Wilson
tbp wrote: Question: why do i get an unaligned array as soon as g++ (4.1.0 20050327, cygwin) finds out that it's static (i mean even if i try to fool it around a bit)? I would guess a limitation of cygwin binutils support, or perhaps of Windows itself. This seems to work fine on linux. If I comp

Re: Using inline assembly with specific register indices

2005-04-05 Thread nkavv
Quoting Eric Christopher <[EMAIL PROTECTED]>: > On Tue, 2005-04-05 at 22:25 +0100, Richard Sandiford wrote: > > [EMAIL PROTECTED] writes: > > > asm("cop2a %0, %1;", :: "r" (cp2rb(i)) : "r" (cp2rb(j))); > > > > In addition to Daniel's reply: you wouldn't want to use "r" here. > > That's for general

Re: 4.0-20050319 / 4-020050402 build error due to --enable-mapped location

2005-04-05 Thread James E Wilson
René Rebe wrote: ../../gcc/tree-cfg.c: In function `remove_bb': ../../gcc/tree-cfg.c:2062: error: invalid type argument of `unary *' This was fixed on mainline on March 7. Is --enable-mapped-location considered to be a functional in 4.0 ? Apparently no. The fixes have not been backported to the gc

Re: Obsoleting c4x last minute for 4.0

2005-04-05 Thread Mark Mitchell
Joe Buck wrote: Kazu Hirata wrote: I would like to propose that the c4x port be obsoleted for 4.0. ... The primary reason is that the port doesn't build. On Tue, Apr 05, 2005 at 02:44:38PM -0700, Mark Mitchell wrote: I'm unpersuaded by the arguments later in the thread that we should keep this po

Use normal section names for comdat group?

2005-04-05 Thread H. J. Lu
Gcc 4,0 generates .section .gnu.linkonce.t._ZN3FooC1Ev,"axG",@progbits,_ZN3FooC1Ev,comdat for comdat group. Can gcc use .section .text._ZN3FooC1Ev,"axG",@progbits,_ZN3FooC1Ev,comdat instead? At least, there will be less characters for linker to process. H.J.

Re: Obsoleting c4x last minute for 4.0

2005-04-05 Thread Joe Buck
Kazu Hirata wrote: > >I would like to propose that the c4x port be obsoleted for 4.0. > >... > > The primary reason is that the port doesn't build. On Tue, Apr 05, 2005 at 02:44:38PM -0700, Mark Mitchell wrote: > I'm unpersuaded by the arguments later in the thread that we should keep > this po

Re: call for testers!

2005-04-05 Thread John David Anglin
> I guess cc1 does use this file, so comparing the two cc1 executables > would fail too; but does it work if -pipe is used? I added -pipe to t-pa and t-pa64 and this bootstraps successfully on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11, respectively. However, comparison of cc1 fails in both ca

Re: Question about "#pragma pack(n)"

2005-04-05 Thread Mike Stump
On Apr 4, 2005, at 11:46 PM, feng qiu wrote: -fpack-struct and #pragma pack(2) are contraditctory instructions. Yup. And it seems to be never the intent to allow both. Seems kinda strong. I'd argue that #pragma's override what is on the command line. This is I think a change from status quo, bu

Re: Using inline assembly with specific register indices

2005-04-05 Thread Eric Christopher
On Tue, 2005-04-05 at 22:25 +0100, Richard Sandiford wrote: > [EMAIL PROTECTED] writes: > > asm("cop2a %0, %1;", :: "r" (cp2rb(i)) : "r" (cp2rb(j))); > > In addition to Daniel's reply: you wouldn't want to use "r" here. > That's for general registers only. > > The MIPS port does in theory support

Re: Obsoleting c4x last minute for 4.0

2005-04-05 Thread Mark Mitchell
Kazu Hirata wrote: Hi, I would like to propose that the c4x port be obsoleted for 4.0. c4x-* tic4x-* The primary reason is that the port doesn't build. I'm unpersuaded by the arguments later in the thread that we should keep this port for its pedagogical value as a BITS_PER_UNIT != 8 port. I t

Re: GCC 4.0 Status Report (2005-04-05)

2005-04-05 Thread Mark Mitchell
Kelley Cook wrote: Mark, I nominate PR libgcj/20155 for a "less critical" bug since it is actually a bootstrap regression on numerous platforms albeit easily worked around with a configure --disable-libgcj. Yes, it would be good to get that fixed. Kelly, is your patch, attached to the PR, still a

Re: [gnu.org #222786] GCC Testsuite Tests Exclude List Contribution to FSF

2005-04-05 Thread toon via RT
Peter Brown via RT wrote: > Dear Swami, > > Sorry for our delay in responding to your request. FSF's Assignment > Administrator is currently unavailable, and we expect there to be a > delay in processing your request for at least another week. > > Please bear with us whilst we arrange for additi

Re: [gnu.org #222786] GCC Testsuite Tests Exclude List Contribution to FSF

2005-04-05 Thread toon via RT
Peter Brown via RT wrote: > Dear Swami, > > Sorry for our delay in responding to your request. FSF's Assignment > Administrator is currently unavailable, and we expect there to be a > delay in processing your request for at least another week. > > Please bear with us whilst we arrange for additi

Re: Using inline assembly with specific register indices

2005-04-05 Thread Richard Sandiford
[EMAIL PROTECTED] writes: > asm("cop2a %0, %1;", :: "r" (cp2rb(i)) : "r" (cp2rb(j))); In addition to Daniel's reply: you wouldn't want to use "r" here. That's for general registers only. The MIPS port does in theory support coprocessors, but the functionality isn't tested much (if at all). The c

Re: [gnu.org #222786] GCC Testsuite Tests Exclude List Contribution to FSF

2005-04-05 Thread Toon Moene
Peter Brown via RT wrote: Dear Swami, Sorry for our delay in responding to your request. FSF's Assignment Administrator is currently unavailable, and we expect there to be a delay in processing your request for at least another week. Please bear with us whilst we arrange for additional help. We (th

Re: Obsoleting c4x last minute for 4.0

2005-04-05 Thread Richard Sandiford
Kazu Hirata <[EMAIL PROTECTED]> writes: > I would like to propose that the c4x port be obsoleted for 4.0. > > c4x-* > tic4x-* > > The primary reason is that the port doesn't build. > > Richard Sandiford's recent patch allows us to go further during the > build process, but the port still does

Re: http://gcc.gnu.org/install/specific.html#*-*-solaris2*

2005-04-05 Thread Gerald Pfeifer
On Wed, 9 Mar 2005, Dimitri Papadopoulos-Orfanos wrote: > On this page: > http://gcc.gnu.org/install/specific.html > there's a link to: > #*-*-solaris2* > but it doesn't work. Instead from what I can undersatnd it should be: > #g_t*-*-solaris2* Hmm, that's interesting, so I'm Cc:

Re: Obsoleting c4x last minute for 4.0

2005-04-05 Thread Daniel Jacobowitz
On Tue, Apr 05, 2005 at 02:30:47PM -0400, Paul Schlie wrote: > > Kazu Hirata wrote: > > I would like to propose that the c4x port be obsoleted for 4.0. > > > > c4x-* > > tic4x-* > > > > The primary reason is that the port doesn't build. > > > > Richard Sandiford's recent patch allows us to go f

Re: Trying to build crosscompiler for Sparc Solaris 8 -> Sparc Solaris 10 (& others)...

2005-04-05 Thread Aaron Gaudio
(CCing this to [EMAIL PROTECTED] due to potential build bugs...) I'm encountering more woes than my original message (quoted below), which I figure are either bugs in the build mechanism or bugs in the user (me); either way if someone can enlighten me it would be much appreciated... I suspended m

RE: Obsoleting c4x last minute for 4.0

2005-04-05 Thread Dave Korn
Original Message >From: Paul Schlie >Sent: 05 April 2005 19:31 > Although personally believe Paul, the key in between the 'U' and the 'O' on your keyboard has been broken for many months now! cheers, DaveK -- Can't think of a witty .sigline today

Re: Obsoleting c4x last minute for 4.0

2005-04-05 Thread Paul Schlie
> Kazu Hirata wrote: > I would like to propose that the c4x port be obsoleted for 4.0. > > c4x-* > tic4x-* > > The primary reason is that the port doesn't build. > > Richard Sandiford's recent patch allows us to go further during the > build process, but the port still does not build. Althoug

Re: sparc.c:509:1: error: "TARGET_ASM_FILE_END" redefined...

2005-04-05 Thread Christian Joensson
On Apr 5, 2005 4:43 PM, Eric Botcazou <[EMAIL PROTECTED]> wrote: > > stage1/xgcc -Bstage1/ -B/usr/local/sparc-linux/bin/ -c -g -O2 > > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > > -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros > > -Wold-style-definition -Werror

[BUG mm] "fixed" i386 memcpy inlining buggy

2005-04-05 Thread Christophe Saout
Hi Denis, the new i386 memcpy macro is a ticking timebomb. I've been debugging a new mISDN crash, just to find out that a memcpy was not inlined correctly. Andrew, you should drop the fix-i386-memcpy.patch (or have it fixed). This source code: mISDN_pid_t pid; [...]

[gnu.org #222786] GCC Testsuite Tests Exclude List Contribution to FSF

2005-04-05 Thread Peter Brown via RT
Dear Swami, Sorry for our delay in responding to your request. FSF's Assignment Administrator is currently unavailable, and we expect there to be a delay in processing your request for at least another week. Please bear with us whilst we arrange for additional help. Regards -- Peter T. Brown E

Re: call for testers!

2005-04-05 Thread Kelley Cook
I'd really appreciate it if people on unusual host systems (AIX, HPPA, cygwin, etc.) could see what the effect of the patch in is on their bootstrap. I've gotten no responses at all, and I presume this means that lots of people have tri

Obsoleting c4x last minute for 4.0

2005-04-05 Thread Kazu Hirata
Hi, I would like to propose that the c4x port be obsoleted for 4.0. c4x-* tic4x-* The primary reason is that the port doesn't build. Richard Sandiford's recent patch allows us to go further during the build process, but the port still does not build. http://gcc.gnu.org/ml/gcc-patches

wiki changed to require fake logins

2005-04-05 Thread Daniel Berlin
in order to prevent being spammed, the wiki has been changed to require "bogo" logins before editing pages. You can use any WikiWord you like as a login name, and it will work (and you can set a password if you really like). So don't be thrown off when it asks you for a login name and password to

Re: sparc.c:509:1: error: "TARGET_ASM_FILE_END" redefined...

2005-04-05 Thread Eric Botcazou
> stage1/xgcc -Bstage1/ -B/usr/local/sparc-linux/bin/ -c -g -O2 > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros > -Wold-style-definition -Werror -fno-common -DHAVE_CONFIG_H-I. > -I. -I/usr/local/src/trunk/gcc/gcc

Re: GCC 4.0 Status Report (2005-04-05)

2005-04-05 Thread Kelley Cook
Mark, I nominate PR libgcj/20155 for a "less critical" bug since it is actually a bootstrap regression on numerous platforms albeit easily worked around with a configure --disable-libgcj. The root cause is the invocation of a ~90,000 character command line (which would be beyond my expectation

Re: RFC: #pragma optimization_level

2005-04-05 Thread Nix
[Cc: list drastically trimmed.] On Tue, 5 Apr 2005, Marcin Dalecki spake: > On 2005-04-05, at 01:28, Nix wrote: >> On 4 Apr 2005, Marcin Dalecki stipulated: >>> I don't agree with the argument presented by Geert Bosch. It's even more >>> difficult to >>> muddle through the atrocities of autoconf/

Re: GCC 4.0 Status Report (2005-04-05)

2005-04-05 Thread Giovanni Bajo
Mark Mitchell <[EMAIL PROTECTED]> wrote: >>> Earlier today, Andrew Haley posted a small C++ snippet showing an ABI >>> change >>> affecting gcj on PPC32: >>> http://gcc.gnu.org/ml/gcc/2005-04/msg00139.html >>> >>> I hope he'll open a PR soon, but you probably want to consider this >>> for 4.0. >>

Biagio Lucini [lucini@phys.ethz.ch] bouncing

2005-04-05 Thread jgrant
Hi, Biagio Lucini's email is bouncing, does anyone know a valid email contact for him? Could you let him know his email address is broken by another means? I was communicating with him about http://gcc.gnu.org/projects/gomp/ Kind regards Jonathan > The remote server does not support delivery sta

Re: GCC 4.0 Status Report (2005-04-05)

2005-04-05 Thread Paul Koning
> "Andrew" == Andrew Pinski <[EMAIL PROTECTED]> writes: Andrew> Yes it might be a silent miscompiling but there is an easy Andrew> work around, use a temporary variable, ... I'm not sure how there can ever be an "easy" workaround to silent miscompiles -- by definition you may not know there

sparc.c:509:1: error: "TARGET_ASM_FILE_END" redefined...

2005-04-05 Thread Christian Joensson
Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u: binutils-2.15.92.0.2-5.sparc bison-1.875c-2.sparc dejagnu-1.4.4-2.noarch expect-5.42.1-1.sparc gcc-3.4.2-6.fc3.sparc gcc4-4.0.0-0.8sparc.sparc glibc-2.3.3-99.sparc64 glibc-2.3.3-99.sparcv9 glibc-devel-2.3.3-99.sparc glibc-d

Re: RFC: #pragma optimization_level

2005-04-05 Thread Marcin Dalecki
On 2005-04-05, at 01:28, Nix wrote: On 4 Apr 2005, Marcin Dalecki stipulated: I don't agree with the argument presented by Geert Bosch. It's even more difficult to muddle through the atrocities of autoconf/automake to find the places where compiler switches get set in huge software projects What'

Re: [rtl-optimization] Improve Data Prefetch for IA-64

2005-04-05 Thread Steven Bosscher
On Apr 05, 2005 11:55 AM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: > > (IMHO the current RTL IV analysis is not very nice to work > > with, we could look into improving that first...) > > what problems do you have concretely in mind? It is hard to find and iterate over all IVs (including GIVs).

Re: [rtl-optimization] Improve Data Prefetch for IA-64

2005-04-05 Thread Zdenek Dvorak
Hello, > > Steven Bosscher <[EMAIL PROTECTED]>: > > > > > > > > What happens if you use the memory address unrolling > > patch, turn on > > > -fweb, and set the unrolling parameters properly? > > > > > > > The memory address unrolling patch can't work on IA- > > 64, > > Ah, no base+offset. It

Re: [rtl-optimization] Improve Data Prefetch for IA-64

2005-04-05 Thread Steven Bosscher
On Apr 05, 2005 11:47 AM, Canqun Yang <[EMAIL PROTECTED]> wrote: > Steven Bosscher <[EMAIL PROTECTED]>: > > > > > What happens if you use the memory address unrolling > patch, turn on > > -fweb, and set the unrolling parameters properly? > > > > The memory address unrolling patch can't work on

Re: [rtl-optimization] Improve Data Prefetch for IA-64

2005-04-05 Thread Canqun Yang
Steven Bosscher <[EMAIL PROTECTED]>: > > What happens if you use the memory address unrolling patch, turn on > -fweb, and set the unrolling parameters properly? > The memory address unrolling patch can't work on IA- 64, and the -fweb can improve the unroller, but still far away from the old one

Re: about "Alias Analysis for Intermediate Code"

2005-04-05 Thread zouq
but i don`t understand even if you propagate the alias analysis from the tree optimizers, the space won1t be saved, you still need many space to save the info. is it not as expansive as the alias analysis based on the RTL representation? what has it saved?thank you. Qo. Zou > On Monday 04 April 2

Re: [rtl-optimization] Improve Data Prefetch for IA-64

2005-04-05 Thread Steven Bosscher
On Tuesday 05 April 2005 09:24, Canqun Yang wrote: > >On Mon, 28 Mar 2005, James E Wilson wrote: > >> Steven Bosscher wrote: > >>> OK, so I know this is not a popular subject, but > > can we *please* stop > > >>> working on loop.c and focus on getting the new RTL and tree loop passes > >>> to do wh

Re: [rtl-optimization] Improve Data Prefetch for IA-64

2005-04-05 Thread Canqun Yang
>On Mon, 28 Mar 2005, James E Wilson wrote: >> Steven Bosscher wrote: >>> OK, so I know this is not a popular subject, but can we *please* stop >>> working on loop.c and focus on getting the new RTL and tree loop passes >>> to do what we want? >> I don't think anyone is objecting to this. [...] >