Re: In current gcc trunk: warning: dereferencing type-punned pointer will break strict-aliasing rules

[Nathan Sidwell]

Christian Joensson wrote:

I'd just like to ask if this is noticed:

/usr/local/src/trunk/gcc/gcc/unwind-dw2.c:324: warning: dereferencing
type-punned pointer will break strict-aliasing rules
/usr/local/src/trunk/gcc/gcc/unwind-dw2.c:789: warning: dereferencing
type-punned pointer will break strict-aliasing rules
/usr/local/src/trunk/gcc/gcc/unwind-dw2.c:1005: warning: dereferencing
type-punned pointer will break strict-aliasing rules
/usr/local/src/trunk/gcc/gcc/unwind-dw2-fde.c:1024: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/usr/local/src/trunk/gcc/gcc/unwind-dw2-fde-glibc.c:393: warning:
dereferencing type-punned pointer will break strict-aliasing rules


I had not noticed this, but looking at the first one it must have been caused by 
my patch to the type punning warning.  It also appears to be a correct warning, 
in that we are breaking aliasing.


I shall look for a solution.

nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: Software pipelining capabilities

[David Edelsohn]

> Vasanth  writes:

Vasanth> My question is, am I expecting the wrong version of GCC to be doing
Vasanth> this. I saw the following thread about SMS.

Vasanth> http://gcc.gnu.org/ml/gcc/2003-09/msg00954.html

Vasanth> that seems relevant. Would GCC 4.x be a better version for my
Vasanth> requirement? If not, any ideas would be greatly appreciated.

SMS is available in GCC 4.0, not GCC 3.4.1.  GCC 4.1 development
incoporates further improvements.  GCC based on GCC 4.x is requirement for
software pipelining capabilities.

David

strange double comparison results with -O[12] on x86(-32)

[Christian Bodenstedt]

Hello,

last weekend I got some strange results from a C-program doing some
comparisons on double-values. I know, usually it's no good idea to
compare two doubles with "==". But when they are calculated from the
same values with the same operations, both doubles should have the
same value, shouldn't they?

I tracked this down to the attached sourcecode (fault1.c). I don't
know if this shows a compiler bug or if it's just my fault. I think
the interesting part is:

| void foobar(int *num, int *den); /* modifies at least one value */
|
| main(){
|   int x, y, i, j, m, n;
|   double d, e, f;
| 
| /* ... give x and y some values ... */
| 
|   d=(double)(x)/(double)(y);
|   
|   i=x; 
|   j=y; 
|   foobar(&i,&j);
|   e=(d - (double)(i)/(double)(j));
|
|   m=x;
|   n=y;
|   foobar(&m,&n);
|   f=(d - (double)(m)/(double)(n));
|
|   if (f != e) printf("NEVER REACHED?\n");

The integers "i" and "m" are equal, so are "j" and "n". Double "d"
doesn't change, so "e" and "f" should be equal as well. Compiled with
"-O0" printf isn't called (as expected). But with "-O1" or "-O2"
printf is called! What's happening? I found this behaviour on any
32-bit x86 I tested and with any installed version of gcc. 

My desktop PC (Celeron Northwood "P4-alike"):
  2.95.4
  3.0.4
  gcc-3.2 (GCC) 3.2.3 (Debian)
  gcc-3.3 (GCC) 3.3.5 (Debian 1:3.3.5-13)
  gcc-3.4 (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)
on an Athlon-XP with:
  2.95.4
  gcc-3.2 (GCC) 3.2.3 (Debian)
  gcc-3.3 (GCC) 3.3.5 (Debian 1:3.3.5-12)
  gcc-3.4 (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-12)
an Athlon with:
  gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
an old Pentium-1 with Debian-Woody: gcc-2.95.4

Systems where this "bug" doesn't seem to happen:
- Dual Opteron with:  "gcc (GCC) 3.2.2 (SuSE Linux)"
- Powerstack II Pro4000 with: "gcc.real (GCC) 3.3.2 (Debian)"


On my desktop-PC the "bug" disappears when I use "-O3", "-O1
-finline-functions" or "-O1 -march=pentium4 -mfpmath=sse" (printf
isn't called then, didn't test on other systems). "fault2.c" does the
same calculation like "fault1.c" does, but has some macros added to
play around with.


Bye,

Christian Bodenstedt#include 

void foobar(int *num, int *den)
{
int n1 = (*num);
int d1 = (*den);
/* just change (at least) one value */
(*num)=(n1+1);
(*den)=d1;
}


int main(int argc, char **argv){
  int x, y, i, j, m, n;
  double d, e, f;
  int min, max;
  
  min = 1;
  max = 10;

  for (x=min; x <= max; x++){
for (y=min; y <= max; y++){
  d=(double)(x)/(double)(y);
  
  i=x; 
  j=y; 
  foobar(&i,&j);
  e=(d - (double)(i)/(double)(j));
  
  m=x; 
  n=y;
  foobar(&m,&n);
  f=(d - (double)(m)/(double)(n));

  if ( e != f ){
/*(IMHO) this should NEVER be reached, since "e" and "f" are
  calculated from the same values and thus should be equal. So
  this program shouldn't generate any output, but compiled
  with "-O1" or "-O2" it does!
*/
printf("NEVER REACHED? x=%d, y=%d, ", x, y);
if (i==m) printf("i=m=%d, ", i);
else printf("really never reached. %d=i != m=%d, ", i, m);
if (j==n) printf("j=n=%d.\n", j);
else printf("really never reached. %d=j != n=%d.\n", j, n);
return 1;
  }
}
  }
  return 0;
}
#include 

/** "FUNNY" changes the comparison from  (e != f) to (e - f != 0). If it's   */
/**   defined, "e-f" will be printed as non-zero value, otherwise zero.  */
/* #define FUNNY */

/** If "VERBOSE" is not defined, "main()" will print the combinations of x   */
/**   and y each time (e!=f). If it is defined, the programs stops after the */
/**   first time (e!=f) but prints more details. */
/* #define VERBOSE */

/** "HEXADECIMAL": print out doubles in hex-format. (How can this be done*/
/**   without producing a compiler warning?) */
/* #define HEXADECIMAL */

/** Moving the line marked with (#1) after the second call to "foobar()" */
/*[marked (#2)], the "bug" will disappear*/
/* #define SWITCH_OFF_BUG */

#ifdef FUNNY
#ifndef VERBOSE
#define VERBOSE
#endif
#endif

void foobar(int *num, int *den)
{
int n1 = (*num);
int d1 = (*den);
/* just change (at least) one value */
(*num)=(n1+1);
(*den)=d1;
}


int main(int argc, char **argv){
  int x, y, i, j, m, n;
  double d, e, f;
  int min, max;
  int bug=0;
  
  min = 1;
  max = 10;

  for (x=min; x <= max; x++){
for (y=min; y <= max; y++){
  d=(double)(x)/(double)(y);
  
  i=x; 
  j=y; 
  foobar(&i,&j);
#ifndef SWITCH_OFF_BUG
  e=(d - (double)(i)/(double)(j)); /*(#1)*/
#endif  
  m=x; 
  n=y;
  foobar(&m,&n);
#ifdef SWITCH_OFF_BUG
  e=(d - (double)(i)/(double)(j)); /*(#2)*/
#endif  
  f=(d - (double)(m)/(double)(n));

  /*
if ( e != f) // shouldn't happen IMHO. If it does, produce some out

Re: strange double comparison results with -O[12] on x86(-32)

[Andrew Pinski]

On Jun 13, 2005, at 10:21 AM, Christian Bodenstedt wrote:



last weekend I got some strange results from a C-program doing some
comparisons on double-values. I know, usually it's no good idea to
compare two doubles with "==". But when they are calculated from the
same values with the same operations, both doubles should have the
same value, shouldn't they?


Did you read the non-bug section in ?

This is known as GCC PR 323 which is not a bug: 
.



-- Pinski

Re: strange double comparison results with -O[12] on x86(-32)

[Vincent Lefevre]

On 2005-06-13 10:22:34 -0400, Andrew Pinski wrote:
> On Jun 13, 2005, at 10:21 AM, Christian Bodenstedt wrote:
> >last weekend I got some strange results from a C-program doing some
> >comparisons on double-values. I know, usually it's no good idea to
> >compare two doubles with "==". But when they are calculated from the
> >same values with the same operations, both doubles should have the
> >same value, shouldn't they?

Not necessarily.

> Did you read the non-bug section in ?
> 
> This is known as GCC PR 323 which is not a bug: 
> .

It is a bug.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

RFA: Integrate ABI testsuite in GCC

[Michael Matz]

Hi,

I have this x86-64 ABI testsuite I worked on lately again (after some 
years lingering around, it was first written when we did the port on 
simulators still).  It currently lies on cvs.x86-64.org in the 'abitest' 
module, for the curious (it has anoncvs too).

I would like to somehow integrate this into GCC, so that it is run 
automatically when doing a make check.  I've pondered about several ways 
to do this:
  1) add something like --with-abitest=/dir/to/abitest to gccs configure
 make check could then use this external path to run the ABI testsuite
  2) mirror the testsuite somehow inside GCC's CVS to be tighly integrated

I'm not sure which way is best.  The second one has the advantage that you 
can't miss running it, when just checking out GCC and developing on it.
The first one has the advantage the GCC's CVS would not be clobbered with 
something external, and very architecture specific.

Currently the testsuite contains some testcase generators written in C, 
and some hand-written testcases.  I'm thinking about rewriting the 
generators at least in something better suited to text manipulation, i.e. 
bash or perl.  What would be the feeling having such kind of stuff in 
GCC's CVS?

Basically I'm looking for some consensus how to make my above goal happen.  
So anyone any suggestions, ideas, flames?


Ciao,
Michael.

Re: strange double comparison results with -O[12] on x86(-32)

[Florian Weimer]

* Andrew Pinski:

> This is known as GCC PR 323 which is not a bug: 
> .

It is a bug in GCC, the C standard, or the x86 FP hardware.  I'm
leaning towards the C standard or the hardware. 8-)

RE: Big differences on SpecFP results for gcc and icc

[Menezes, Evandro]

Steven, 

> > An interesting examples are:
> > -177.mesa (this is a c test), where icc is almost 40% faster
> 
> It would be interesting to look into this one.

A combination of SSE instead of x87, vectorization, vectorized math library, 
and very good whole-program IPA.


-- 
___
Evandro MenezesAMD   Austin, TX

Re: Big differences on SpecFP results for gcc and icc

[Diego Novillo]

On Mon, Jun 13, 2005 at 11:20:24AM -0500, Menezes, Evandro wrote:

> A combination of SSE instead of x87, vectorization, vectorized
> math library,
>
Yes.

> and very good whole-program IPA.
> 
Not at -O2.


Diego.

RE: Big differences on SpecFP results for gcc and icc

[Menezes, Evandro]

Robert, 

> > I know that these graphs don't show the results of most aggresive 
> > optimization options for gcc, but that is also the case 
> with icc (only 
> > -O2). However, it looks that gcc and icc are not even in the same 
> > class regarding FP performance. Perhaps there is some critical 
> > optimizations, that are not present in gcc?
> 
> Or perhaps icc has spent much more effort in optimizing the 
> spec tests specifically.
> 
> > I think I'm not the only person, that finds these results rather 
> > "dissapointing". As Scott is currently writing a paper on gcc's FP 
> > performance, perhaps someone has an explanation, why gcc's 
> results are 
> > so low on Pentium4 for these tests?
> 
> I suggest doing more general benchmarks than just the spec 
> tests, which are rather notorious targets for targetted optimization.

I agree with you.  Each HPC application tends to be unlike others, making it 
difficult to optimize GCC for an elusive typical FP application.  Not that 
there isn't room for improvement though.


-- 
___
Evandro MenezesAMD   Austin, TX

GCC 4.0.1 Status (2005-06-13)

[Mark Mitchell]

Those who have been watching carefully will note that there is no sign 
of an actual 4.0.1 release.


There are two blocking issues at the moment:

1. Benjamin Kosnik reports that there are ABI and/or version-symbol 
problems between 3.4.x and 4.0.x version of libstdc++, and is trying to 
sort out a solution.


2. Jakub Jelinek reports that we're miscompiling GLIBC.

The latter problem seems to me to be as severe as the KDE bug that was 
the impetus for this release.  The libstdc++ problem also seems serious. 
 In particular, Benjamin reports a mangling change that sounds like 
something that should perhaps have been controlled by -fabi-version, but 
I have not received a test case for that problem.


(I should confess that I am so skeptical about the likelihood that we 
have maintained full libstdc++ compatibility anyhow that I am not 
entirely convinced that we are not just seeing one of several problems...)


We're in a holding pattern (branch frozen) until we resolve these issues.

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: Big differences on SpecFP results for gcc and icc

[Scott Robert Ladd]

Menezes, Evandro wrote:
> Each HPC application tends to be unlike others, making it difficult
> to optimize GCC for an elusive typical FP application.  Not that
> there isn't room for improvement though.

The performance of almost any HPC application can be isolated to
specific key loops, and every critical loop has different optimization
characteristics -- what improves performance on algorithm A may degrade
performance on algorithm B. See my Acovea work for many supporting examples.

My conclusion is the composite switches like -O2 are good only for
general-purpose code. Anyone explicitly interested in squeezing out the
most performance needs to do analysis and use application-specific switches.

..Scott

Re: GCC 4.0.1 Status (2005-06-13)

[Scott Robert Ladd]

Mark Mitchell wrote:
> 2. Jakub Jelinek reports that we're miscompiling GLIBC.
> 
> The latter problem seems to me to be as severe as the KDE bug that was
> the impetus for this release.  The libstdc++ problem also seems serious.

Agreed. I've had mixed reports from folks over in the Gentoo universe
about glibc; perhaps this page might be of interest:

http://process-of-elimination.net/?q=gentoo_and_gcc_4_0_0_tips_and_tricks

..Scott

GCC port for the TI TMS320C5{4,5}x

[Jonathan Bastien-Filiatrault]

Hello,
We are currently looking for experienced GCC hackers to help
implement and complete a GCC port for the Texas Instruments TMS320C54x.
This chip is used in the Neuros music player, as well as in the Nokia
770 internet tablet. Joe Born of NeurosAudio is ready to compensate
porters for their time. Meanwhile, me and other people who have very
little experience with GCC have put some code together in an effort to
have a fully working port, the project homepage is at
http://gcc-c54x.berlios.de. However, our lack of experience is catching
up with us, there is a lot that we do not understand at this point, we
need somebody who is willing to act as a mentor to this project, at
least long enough to get it off the ground.

Any help/advice is welcome,

Cheers,
Jonathan Bastien-Filiatrault


signature.asc
Description: OpenPGP digital signature

RE: strange double comparison results with -O[12] on x86(-32)

[Dave Korn]

Original Message
>From: Florian Weimer
>Sent: 13 June 2005 16:08

> * Andrew Pinski:
> 
>> This is known as GCC PR 323 which is not a bug:
>> .
> 
> It is a bug in GCC, the C standard, or the x86 FP hardware.  I'm
> leaning towards the C standard or the hardware. 8-)


  ... or it's a bug in the libc/crt-startup, which is where the hardware
rounding mode is (or should be) set up ...



cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: strange double comparison results with -O[12] on x86(-32)

[Florian Weimer]

* Dave Korn:

>> It is a bug in GCC, the C standard, or the x86 FP hardware.  I'm
>> leaning towards the C standard or the hardware. 8-)
>
>
>   ... or it's a bug in the libc/crt-startup, which is where the
> hardware rounding mode is (or should be) set up ...

I think you'd still experience latent excess precision for floats,
though.

Problem with recompute_tree_invarant_for_addr_expr

[Zdenek Dvorak]

Hello,

I have run into the following problem:

recompute_tree_invarant_for_addr_expr says that address of a decl
is invariant if it is a decl in the current function:

if (decl_function_context (node) == current_function_decl)
  ... /* set TREE_INVARIANT  */

This has a small flaw -- in case NODE has variable size, it gets
allocated on stack dynamically, it may be allocated and deallocated
several times, and its address is no longer an invariant.

So I tried to fix the code as follows:

if (decl_function_context (node) == current_function_decl
&& TREE_CONSTANT (DECL_SIZE (node))
  ... /* set TREE_INVARIANT  */

The problem is that tree-nested.c builds frame_decl, adds fields to
it one by one, sometimes takes its address, and only in the end lays it
out.  This means that at the point the address is taken, DECL_SIZE is
not yet known and it is NULL.  In fact, in the moment the address is
taken, there seems to be no way how to tell whether the size of
frame_decl will be variable or not.

So I tried a conservative variant:

if (decl_function_context (node) == current_function_decl
&& DECL_SIZE (node)
&& TREE_CONSTANT (DECL_SIZE (node))
  ... /* set TREE_INVARIANT  */

This works up to moment verify_stmts is called, which ends with
"invariant not recomputed when ADDR_EXPR changed" (because now
frame_decl is laid out, and we know its size is constant, and that the
address is invariant).

Other possibility would be to be "optimistic":

if (decl_function_context (node) == current_function_decl
&& (!DECL_SIZE (node)
|| TREE_CONSTANT (DECL_SIZE (node)))
  ... /* set TREE_INVARIANT  */

which would probably work for frame_decl, as it should be allocated just
once (I hope), but is not very safe and still would ICE in
"invariant not recomputed when ADDR_EXPR changed", this time in case
if frame_decl were variable-sized.

It might be possible to special-case frame_decl in
recompute_tree_invarant_for_addr_expr, but it would be quite ugly hack,
and it is not somehow terribly simple to do anyway.

The other possibility is to somehow remember the list of places where
we take address of something based on frame_decl, and recompute
TREE_INVARIANT for them once frame_decl is laid out.

Any simpler idea how to solve this problem?

Zdenek

Re: Tracking down source of libgcc_s.so compatibility?

[Mike Hearn]

On Thu, 09 Jun 2005 15:47:31 +0200, Marcin Dalecki wrote:
> NTPL vers. non NTPL signal handling differences. The FC3 compiler contains
> some "backward compatibility" shims at quite a few places, which are
> allowing old binaries to execute. However stuff compiled with the FC3
> version of the compiler, which contains some "features" not seen otherwise
> will be of course inconsistent with anything else.

Do you have any details on this? Exception unwinding doesn't seem all that
related to signal handling to a non-guru ...

thanks -mike

Re: Problem with recompute_tree_invarant_for_addr_expr

[Richard Henderson]

On Mon, Jun 13, 2005 at 07:39:33PM +0200, Zdenek Dvorak wrote:
> This has a small flaw -- in case NODE has variable size, it gets
> allocated on stack dynamically, it may be allocated and deallocated
> several times, and its address is no longer an invariant.
> 
> So I tried to fix the code as follows:
> 
> if (decl_function_context (node) == current_function_decl
> && TREE_CONSTANT (DECL_SIZE (node))
>   ... /* set TREE_INVARIANT  */

Such nodes should never be seen having their address taken.  They
should be completely removed during gimplification.  So I think we
should stop here and figure out why you care about such nodes.


r~

Re: GCC 4.0.1 Status (2005-06-13)

[Daniel Kegel]

Scott Robert Ladd wrote:

Mark Mitchell wrote:

2. Jakub Jelinek reports that we're miscompiling GLIBC.


[I think this is http://gcc.gnu.org/PR22043 ]



The latter problem seems to me to be as severe as the KDE bug that was
the impetus for this release.  ...


Agreed. I've had mixed reports from folks over in the Gentoo universe
about glibc; perhaps this page might be of interest:

http://process-of-elimination.net/?q=gentoo_and_gcc_4_0_0_tips_and_tricks


I think that's a different issue.
Jakub's almost certainly building glibc-cvs, not glibc-2.3.5,
and in PR22043, he says it seems to compile fine, but the resulting
code is broken.

The gentoo issue is probably just that glibc-2.3.5 won't compile with gcc-4.0.0.
That's well known; it needs fixes
(e.g. 
http://kegel.com/crosstool/current/patches/glibc-2.3.5/glibc-2.3.4-allow-gcc-4.0-iconvdata.patch).
Fixes for all these compatibility problems are in glibc-cvs, I think.
(Interestingly, the fixes in glibc-cvs seem to have been made in such a way 
that the
new glibc won't be compilable by older versions of gcc, like gcc-3.4.4.
I guess the thinking is that everyone should be using the latest gcc?)
- Dan

Re: Problem with recompute_tree_invarant_for_addr_expr

[Zdenek Dvorak]

Hello,

> On Mon, Jun 13, 2005 at 07:39:33PM +0200, Zdenek Dvorak wrote:
> > This has a small flaw -- in case NODE has variable size, it gets
> > allocated on stack dynamically, it may be allocated and deallocated
> > several times, and its address is no longer an invariant.
> > 
> > So I tried to fix the code as follows:
> > 
> > if (decl_function_context (node) == current_function_decl
> > && TREE_CONSTANT (DECL_SIZE (node))
> >   ... /* set TREE_INVARIANT  */
> 
> Such nodes should never be seen having their address taken.  They
> should be completely removed during gimplification.  So I think we
> should stop here and figure out why you care about such nodes.

good point, thanks (I don't precisely remember why I thought this change
was necessary; I did it while working on some changes to gimplification,
so perhaps I broke something there).

Zdenek

Re: rationale for bss patterns in default_section_type_flags ?

[Mike Stump]

On Jun 10, 2005, at 6:04 PM, Brett Porter wrote:

Doing an exact match on that name in default_section_type_flags_1
is a nice solution for our needs.


Ok, sounds good.

The reason for our query was twofold: are there standards (of any  
form :) that such a choice would be incompatible with?


If google doesn't hit on the name...  :-)

; would anything more general be appropriate (thus the suffix  
question)?


Ultimately this will be up to the person OKing your change, but from  
my perspective, I don't see a nice fit to something more general.
People have been playing with persistence for decades, and yet, I  
don't know of anything much coming down the pike that offers the  
opportunity to unify much in this area.  I'm sure I'm just ignorant,  
others in the know would have to say.

PATCH: Explicitly pass --64 to assembler on AMD64 targets

[Mark Mitchell]

This patch makes x86-64.h pass "--64" to the assembler when compiling
in 64-bit mode.

There are several advantages:

1. For a bi-arch compiler for which 32-bit code is the default, we no
   longer need to override ASM_SPEC.

2. We get earlier failure and better error messages from the assembler
   if the user tries to use a 64-bit compiler with a 32-bit assembler.

OK?

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]

2005-06-13  Mark Mitchell  <[EMAIL PROTECTED]>

* config/i386/x86-64.h (ASM_SPEC): Explicitly pass --64 to the
assembler in 64-bit mode.

Index: gcc/config/i386/x86-64.h
===
RCS file: /cvs/gcc/gcc/gcc/config/i386/x86-64.h,v
retrieving revision 1.9.10.1
diff -c -5 -p -r1.9.10.1 x86-64.h
*** gcc/config/i386/x86-64.h31 Dec 2003 00:44:22 -  1.9.10.1
--- gcc/config/i386/x86-64.h13 Jun 2005 15:50:35 -
*** Boston, MA 02111-1307, USA.  */
*** 47,57 
  #undef CC1_SPEC
  #define CC1_SPEC "%(cc1_cpu) %{profile:-p}"
  
  #undef ASM_SPEC
  #define ASM_SPEC "%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} \
!  %{Wa,*:%*} %{m32:--32}"
  
  #define ASM_OUTPUT_ALIGNED_BSS(FILE, DECL, NAME, SIZE, ALIGN) \
asm_output_aligned_bss (FILE, DECL, NAME, SIZE, ALIGN)
  
  /* This is used to align code labels according to Intel recommendations.  */
--- 47,57 
  #undef CC1_SPEC
  #define CC1_SPEC "%(cc1_cpu) %{profile:-p}"
  
  #undef ASM_SPEC
  #define ASM_SPEC "%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} \
!  %{Wa,*:%*} %{m32:--32} %{m64:--64}"
  
  #define ASM_OUTPUT_ALIGNED_BSS(FILE, DECL, NAME, SIZE, ALIGN) \
asm_output_aligned_bss (FILE, DECL, NAME, SIZE, ALIGN)
  
  /* This is used to align code labels according to Intel recommendations.  */

Re: Tracking down source of libgcc_s.so compatibility?

[Daniel Kegel]

Mike Hearn  wrote:

On Thu, 09 Jun 2005 15:47:31 +0200, Marcin Dalecki wrote:

NTPL vers. non NTPL signal handling differences. The FC3 compiler contains
some "backward compatibility" shims at quite a few places, which are
allowing old binaries to execute. However stuff compiled with the FC3
version of the compiler, which contains some "features" not seen otherwise
will be of course inconsistent with anything else.


Do you have any details on this? Exception unwinding doesn't seem all that
related to signal handling to a non-guru ...


I'm interested, too.

FWIW:
I gave up trying to track down the details, and went with the easy way out:
I installed the fc3 libstdc++.so.6 rpm and updated to the fc3 libgcc_s.so rpm.
(Now apt-get is unhappy that I have two libstdc++'s installed,
so I may have to repackage fc3's libstdc++ to keep it happy...)

One of these days I'd like to understand the details, but for now I seem
to be happy.
- Dan

Re: Big differences on SpecFP results for gcc and icc

[Sebastian Pop]

Scott Robert Ladd wrote:
> 
> My conclusion is the composite switches like -O2 are good only for
> general-purpose code. Anyone explicitly interested in squeezing out the
> most performance needs to do analysis and use application-specific switches.
> 

Probably this situation is created by the fact that code
transformations are applied based on heuristic functions that were
written, well, in a very artisanal way.

http://www-osl.cs.umass.edu/~cavazos/thesis.ps describes how to
automatize the tuning of heuristic functions based on dynamic feedback
and pattern matching.  The only difficulty remaining to the charge of
the compiler constructor is to effectively characterize the
fingerprints of programs with respect to a given transformation.  Lots
of engineering, and cool speedups...

Sebastian

Re: rationale for bss patterns in default_section_type_flags ?

[Brett Porter]

Mike,

Thanks for the feedback. We'll continue along the path we seem to agree
upon... hoping we don't run into any hitches.

Brett

[PATCH] Change bb-reorder.c to use succ block frequency

[Pat Haugen]

The following patch fixes the code to match the commentary of the algorithm
such that block frequency is used instead of edge frequency.  The change is
pretty much neutral on SPEC, max differences of +/- 1% with most showing no
difference.

Bootstrapped and regtested on powerpc64-unknown-linux-gnu with no failures.
OK for mainline?

-Pat


(See attached file: patch.bb-reorder)

patch.bb-reorder
Description: Binary data

Re: ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option

[Sam Lauber]

> Sigh.  #2 doesn't work as the compiler can synthesize common 
> variables that you can't control, and when it does this, things 
> won't work.  Forcing people to use -single_module strikes me as 
> wrong.
I don't know why it was set up like that.  Come to think of it, this would
probably be a really good thread to forward to the Darwin mailing lists.  They
would probably know ;-).  

> So, from the standpoint of good advice, -fno-common is the only answer.
But if you already have good code (who would make a shared library out of
poorly written code?), then you should use -single_module because the only
visible influence on the resulting library is linker diagnostics, but a good
shared library wouldn't trigger any linker errors.  (And plus, the linker does 
a 
good job of finding errors before the library even gets stored to disk, unless
you use options like `-undefined dynamic_lookup').  

Samuel Lauber

-- 
___
Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com

Powered by Outblaze

Re: In current gcc trunk: warning: dereferencing type-punned pointer will break strict-aliasing rules

[Giovanni Bajo]

Nathan Sidwell <[EMAIL PROTECTED]> wrote:

> Christian Joensson wrote:
>> I'd just like to ask if this is noticed:
>>
>> /usr/local/src/trunk/gcc/gcc/unwind-dw2.c:324: warning: dereferencing
>> type-punned pointer will break strict-aliasing rules
>> /usr/local/src/trunk/gcc/gcc/unwind-dw2.c:789: warning: dereferencing
>> type-punned pointer will break strict-aliasing rules
>> /usr/local/src/trunk/gcc/gcc/unwind-dw2.c:1005: warning:
>> dereferencing type-punned pointer will break strict-aliasing rules
>> /usr/local/src/trunk/gcc/gcc/unwind-dw2-fde.c:1024: warning:
>> dereferencing type-punned pointer will break strict-aliasing rules
>> /usr/local/src/trunk/gcc/gcc/unwind-dw2-fde-glibc.c:393: warning:
>> dereferencing type-punned pointer will break strict-aliasing rules
>
> I had not noticed this, but looking at the first one it must have
> been caused by my patch to the type punning warning.  It also appears
> to be a correct warning, in that we are breaking aliasing.

I see also these in my builds:

../../../gcc/libmudflap/mf-runtime.c:320: warning: dereferencing type-punned
pointer will break strict-aliasing rules
../../../gcc/libmudflap/mf-runtime.c:323: warning: dereferencing type-punned
pointer will break strict-aliasing rules
../../../gcc/libmudflap/mf-runtime.c:326: warning: dereferencing type-punned
pointer will break strict-aliasing rules
../../../gcc/libmudflap/mf-runtime.c:329: warning: dereferencing type-punned
pointer will break strict-aliasing rules
../../../gcc/libmudflap/mf-runtime.c:333: warning: dereferencing type-punned
pointer will break strict-aliasing rules
../../../gcc/libmudflap/mf-runtime.c:336: warning: dereferencing type-punned
pointer will break strict-aliasing rules
../../../gcc/libmudflap/mf-runtime.c:339: warning: dereferencing type-punned
pointer will break strict-aliasing rules
../../../gcc/libmudflap/mf-runtime.c:342: warning: dereferencing type-punned
pointer will break strict-aliasing rules

The code is accessing a variable of enum type through an unsigned pointer.

Giovanni Bajo

Re: RFA: Integrate ABI testsuite in GCC

[Sam Lauber]

> I have this x86-64 ABI testsuite I worked on lately again (after some
> years lingering around, it was first written when we did the port on
> simulators still).  It currently lies on cvs.x86-64.org in the 'abitest'
> module, for the curious (it has anoncvs too).
> I would like to somehow integrate this into GCC, so that it is run
> automatically when doing a make check.  I've pondered about several ways
> to do this:
>1) add something like --with-abitest=/dir/to/abitest to gccs configure
>   make check could then use this external path to run the ABI testsuite
>2) mirror the testsuite somehow inside GCC's CVS to be tighly integrated
> 
> I'm not sure which way is best.  The second one has the advantage that you
> can't miss running it, when just checking out GCC and developing on it.
> The first one has the advantage the GCC's CVS would not be clobbered with
> something external, and very architecture specific.
> 
> Currently the testsuite contains some testcase generators written in C,
> and some hand-written testcases.  I'm thinking about rewriting the
> generators at least in something better suited to text manipulation, i.e.
> bash or perl.  What would be the feeling having such kind of stuff in
> GCC's CVS?
That stuff should go in directories like `gcc/config/PLATFORM/'.  Even better,
make the testsuite platform-independant.  And write the generators in
perl ;-).  

> Basically I'm looking for some consensus how to make my above goal 
happen.
> So anyone any suggestions, ideas, flames?
What about a more generic mechanisim `--with-extratest=/path/to/test' 
that causes an extra testsuite in that path to be executed as part of `make
test'?  Maybe even the GCC testsuite could be based on an even more generic
harness mechanisim that expects test information in some agreed output
format (I'm thinking TAP) and tests everything and outputs it in a format
similar to the current format.  

Samuel Lauber

-- 
___
Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com

Powered by Outblaze

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

[Richard Henderson]

On Mon, Jun 13, 2005 at 11:16:04AM -0700, Mark Mitchell wrote:
> 1. For a bi-arch compiler for which 32-bit code is the default, we no
>longer need to override ASM_SPEC.

Well, this is the only way this patch applies, because...

> 2. We get earlier failure and better error messages from the assembler
>if the user tries to use a 64-bit compiler with a 32-bit assembler.

... this one isn't true.  You won't get "--64" emitted from just
"gcc z.c", only from "gcc -m64 z.c".  Unless I'm missing something?

That said, I guess I don't have a problem with this patch.


r~

Re: [PATCH] Change bb-reorder.c to use succ block frequency

[Richard Henderson]

On Mon, Jun 13, 2005 at 02:06:38PM -0500, Pat Haugen wrote:
> The following patch fixes the code to match the commentary of the algorithm
> such that block frequency is used instead of edge frequency.

Why?  It seems to me that edge frequency is what's going to matter
to the cpu when considering the branch.  Particularly for cpus that
don't have horrendously sophisticated branch predictors.


r~

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

[Daniel Jacobowitz]

On Mon, Jun 13, 2005 at 12:56:36PM -0700, Richard Henderson wrote:
> On Mon, Jun 13, 2005 at 11:16:04AM -0700, Mark Mitchell wrote:
> > 1. For a bi-arch compiler for which 32-bit code is the default, we no
> >longer need to override ASM_SPEC.
> 
> Well, this is the only way this patch applies, because...
> 
> > 2. We get earlier failure and better error messages from the assembler
> >if the user tries to use a 64-bit compiler with a 32-bit assembler.
> 
> ... this one isn't true.  You won't get "--64" emitted from just
> "gcc z.c", only from "gcc -m64 z.c".  Unless I'm missing something?

Right, I assume Mark meant "if you try to use foo-gcc -m64 with a
32-bit assembler".

> That said, I guess I don't have a problem with this patch.

How would you feel about a patch that made us always pass --64
as appropriate, at least if the assembler in question is gas?  I
periodically bootstrap on a 64-bit kernel with a 32-bit root FS.  But
the assembler and linker are biarch, and the 64-bit libs are installed,
so it's just the defaults that are wrong.  If we were explicit, an
x86_64-linux compiler would Just Work.

Which would be nice since that's what config.guess says to build :-)

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

[Richard Henderson]

On Mon, Jun 13, 2005 at 04:03:15PM -0400, Daniel Jacobowitz wrote:
> How would you feel about a patch that made us always pass --64
> as appropriate, at least if the assembler in question is gas?

I have no problem with that.


r~

Re: Problem with recompute_tree_invarant_for_addr_expr

[Zdenek Dvorak]

Hello,

> On Mon, Jun 13, 2005 at 07:39:33PM +0200, Zdenek Dvorak wrote:
> > This has a small flaw -- in case NODE has variable size, it gets
> > allocated on stack dynamically, it may be allocated and deallocated
> > several times, and its address is no longer an invariant.
> > 
> > So I tried to fix the code as follows:
> > 
> > if (decl_function_context (node) == current_function_decl
> > && TREE_CONSTANT (DECL_SIZE (node))
> >   ... /* set TREE_INVARIANT  */
> 
> Such nodes should never be seen having their address taken.  They
> should be completely removed during gimplification.  So I think we
> should stop here and figure out why you care about such nodes.

OK, I remembered.  I put

if (is_gimple_min_invariant (t))

or

if (is_gimple_val (t))
  {
shortcut;
  }

type constructs on some places in gimplification.  Which causes
problems, since is_gimple_min_invariant only checks the TREE_INVARIANT
flag for ADDR_EXPRs, and ADDR_EXPRs of variable sized decls then leak through.
The change to recompute_tree_invarant_for_addr_expr was intended to
prevent this.

Zdenek

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

[Florian Weimer]

* Daniel Jacobowitz:

> How would you feel about a patch that made us always pass --64
> as appropriate, at least if the assembler in question is gas?  I
> periodically bootstrap on a 64-bit kernel with a 32-bit root FS.  But
> the assembler and linker are biarch, and the 64-bit libs are installed,
> so it's just the defaults that are wrong.  If we were explicit, an
> x86_64-linux compiler would Just Work.

You still need some script hackery for objcopy and friends, I think,
that's why I didn't pursue the matter further.

Apart from that, the following entry from the specs file seems to
work (GAS does the right think with multiple --32/--64 options):

*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} %{!m64:--32} 
%{m64:--64} %{m32:--32}

Re: Use of check_vect() in vectorizer testsuite

[Devang Patel]

On Jun 10, 2005, at 2:01 PM, Dorit Naishlos wrote:

Devang, is vect-dv-2.c a duplicate of vect-ifcvt-1.c or are they  
both there

on purpose?


It is duplicate. I'll remove vect-dv-2.c tomorrow, unless I hear  
otherwise.


-
Devang

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

[Mark Mitchell]

Daniel Jacobowitz wrote:

On Mon, Jun 13, 2005 at 12:56:36PM -0700, Richard Henderson wrote:


On Mon, Jun 13, 2005 at 11:16:04AM -0700, Mark Mitchell wrote:


1. For a bi-arch compiler for which 32-bit code is the default, we no
  longer need to override ASM_SPEC.


Well, this is the only way this patch applies, because...



2. We get earlier failure and better error messages from the assembler
  if the user tries to use a 64-bit compiler with a 32-bit assembler.


... this one isn't true.  You won't get "--64" emitted from just
"gcc z.c", only from "gcc -m64 z.c".  Unless I'm missing something?



Right, I assume Mark meant "if you try to use foo-gcc -m64 with a
32-bit assembler".


Right.

That said, I guess I don't have a problem with this patch. 


How would you feel about a patch that made us always pass --64
as appropriate, at least if the assembler in question is gas?  I
periodically bootstrap on a 64-bit kernel with a 32-bit root FS.  But
the assembler and linker are biarch, and the 64-bit libs are installed,
so it's just the defaults that are wrong.  If we were explicit, an
x86_64-linux compiler would Just Work.

Which would be nice since that's what config.guess says to build :-) 


I checked in the version RTH originally approved, after testing on 
x86_64-unknown-linux-gnu.


I would be in favor of making the mode always explicit, as you suggest 
-- but I would prefer that we not embed the assumption that the default 
mode is 64-bit mode in x86-64.h so that we can continue to use that file 
for 32-bit default compilers.  (Perhaps it could go in biarch64.h, which 
assumes 64-bit mode to be the default already?)  Or, at least, make it 
easy for a 32-bit default to override x86-64.h.


--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

[gomp] New branch for OpenMP: gomp-20050608-branch

[Diego Novillo]

After two false starts, we now have enough bits to start adding
real OpenMP support to GCC.  Since CVS branches slow down as time
goes by, it is better to start with a brand new branch.

I cut gomp-20050608-branch last week and added Dmitry's parser,
Richard's libgomp and some initial IL bits to connect the parser
to the library.

I'll be sending the patches separately.


Diego.

Re: GCC 4.0.1 Status (2005-06-05)

[Geoffrey Keating]

Mark Mitchell <[EMAIL PROTECTED]> writes:

> Andrew Pinski wrote:
> > On Jun 5, 2005, at 1:41 PM, Devang Patel wrote:
> >
> >>
> >> On Jun 5, 2005, at 10:18 AM, Mark Mitchell wrote:
> >>
> >>> Here are three bugs I'd really like to see fixed.
> >>>
> >>> * 21528: SRA and/or aliasing problem.
> >>>
> >>> * 21847: DCE over-eagerness.
> >>>
> >>> * 20928: IA32 ICE.
> >>
> >>
> >> * 19523: [4.0/4.1 Regression] DBX_USE_BINCL support broken in the
> >> C++ compiler
> > * 21828: [4.0/4.1 Regression] debug info omitted for global variables
> > Is even worse since debugging GCC is very hard when debugging with
> > optimizations turned on (or -funit-at-a-time).
> 
> I agree that these are both serious, though neither seems to rise to
> the level of the KDE issues, in that these both affect "only"
> debugging.  PR 19523 affects only stabs, which I do not think is the
> default on any primary or secondary platform.

Darwin is a secondary platform, and stabs is the default there.  I
believe that a variant of stabs is also the default on AIX, which is a
primary platform.

Re: A Suggestion for Release Testing

[Mike Stump]

On Jun 12, 2005, at 10:51 AM, Gerald Pfeifer wrote:

Note, though, that this is only one part of the equation.  A most
significant amount of work also goes into analysing and potentially
fixing packages which do not compile any longer and submit fixes
upstream.


:-(  Sometimes we wish that gcc had a 5 year warn cycle, followed by  
a 5 year, -fpretty-please cycle, just so that we don't loose the  
testing that building tons of software brings to the table.

Re: strange double comparison results with -O[12] on x86(-32)

[Robert Dewar]

Florian Weimer wrote:

* Andrew Pinski:


This is known as GCC PR 323 which is not a bug: 
.



It is a bug in GCC, the C standard, or the x86 FP hardware.  I'm
leaning towards the C standard or the hardware. 8-)


Well it is only a bug in that you Florian have decided that
you don't like the C standard. Of course that's your choice,
but the decision for the C standard was made with some
awareness of this issue, and (I know you have a smiley but)
the hardware does not have a bug, since the IEEE standard
does not require anything particular of the hardware per se.
You could say it is an inefficiency in the hardware, just
as Alpha is inefficient for precise IEEE operations.

Re: strange double comparison results with -O[12] on x86(-32)

[Robert Dewar]

Dave Korn wrote:


  ... or it's a bug in the libc/crt-startup, which is where the hardware
rounding mode is (or should be) set up ...


Well if you think that the operations should reflect IEEE 64-bit semantics
(which is the only rationale for mucking with the rounding mode in the
startup), then this is only an approximate fix, since the intermediate
values still have excessive range, so you don't get infinities when
expected.

Re: Problem with recompute_tree_invarant_for_addr_expr

[Richard Henderson]

On Mon, Jun 13, 2005 at 10:54:23PM +0200, Zdenek Dvorak wrote:
> OK, I remembered.  I put
> 
> if (is_gimple_min_invariant (t))
> 
> or
> 
> if (is_gimple_val (t))
>   {
> shortcut;
>   }
> 
> type constructs on some places in gimplification.

With an aim toward speeding up gimplification, I guess.  Any idea how
much benefit you get from that?

As for the original question, you could try modifying tree-nested.c to
use a local routine for creating the ADDR_EXPRs of the frame object,
and force TREE_INVARIANT on there.


r~

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

[Zack Weinberg]

Mark Mitchell <[EMAIL PROTECTED]> writes:

> I would be in favor of making the mode always explicit, as you suggest
> -- but I would prefer that we not embed the assumption that the
> default mode is 64-bit mode in x86-64.h so that we can continue to use
> that file for 32-bit default compilers.  (Perhaps it could go in
> biarch64.h, which assumes 64-bit mode to be the default already?)  Or,
> at least, make it easy for a 32-bit default to override x86-64.h.

Or, if GAS can be told which mode it should be in via directives in
its input (.code32/.code64?), then we could add something like

 fputs (TARGET_64BIT ? "\t.code64\n" : "\t.code32", 
asm_out_file);

to x86_file_start, and kill the spec hackery altogether.

zw

Re: A Suggestion for Release Testing

[Matthew Sachs]

I've been doing regular builds of Fink against Apple's branch,  
building our last release alongside our latest engineering build and  
comparing the two.  See:

http://cvs.sourceforge.net/viewcvs.py/fink/scripts/buildfink/
http://fink.opendarwin.org/build/2005-05-08/out/report.html

Re: A Suggestion for Release Testing

[Andrew Pinski]

On Jun 13, 2005, at 10:36 PM, Matthew Sachs wrote:

I've been doing regular builds of Fink against Apple's branch, 
building our last release alongside our latest engineering build and 
comparing the two.  See:

http://cvs.sourceforge.net/viewcvs.py/fink/scripts/buildfink/
http://fink.opendarwin.org/build/2005-05-08/out/report.html


Yes Matt but the FSF mainline moves much faster than Apple's branch.

-- Pinski

Re: a "hello world" frontend

[Rafael Ávila de Espíndola]

Em Sun 12 Jun 2005 23:58, James A. Morrison escreveu:
>  Was there anything in particular that you found hard to understand in the
> treelang frontend.  It is supposed to be the example/tutorial front-end.
One thing is that the parser is very big and mixed with C code. I find it 
easier to read a parser without side effects that just builds a abstract 
syntax tree ("Modern compiler implementation in ML" influence...). Just 
moving some of the C code to auxiliary functions in parse-aux.c would be very 
helpfull (are you interested in this patch(s)?).

>  I suppose I should update this howto for gcc4.
That would be wonderfull!!!

>  Mapped locations are a better(tm) way of tracking source locations
> throughout the compilation.
Thanks.

>  Perhaps, but the implementation may be the same because of how the
> callbacks used to be implemented.  With the langhooks it should be easy for
> any frontend to use the default implementation of a calback.
Convert is called directly and not through langhooks. Why?
Some call backs don't have a default: LANG_HOOKS_BUILTIN_FUNCTION for example.

>  Where?  I build NOP_EXPRs around the use of variables, in the treelang
> frontend so I can get accurate source locations for where variables are
> used.
at build_string_literal in hello1.c (copied from builtins.c). This looks like 
a lot of work to build a string. I tried to use something similar to 
gfc_build_string_const (fortran/trans-const.c) but failed.

>  function_end_locus is part of the function struct, which in treelang there
> is only cfun at any given time.
>

>  The answer is in tree.h:833,
>In a FUNCTION_DECL, nonzero if function has been defined.
but in tree.h:2092
/* In a VAR_DECL or FUNCTION_DECL,
   nonzero means external reference:
   do not allocate storage, and refer to a definition elsewhere.  */

So a function can be defined and have a "definition elsewhere" at the same 
time? Isn't it true that
DECL_EXTERNAL(n) != TREE_STATIC(n) for all n?

>  That's good.  Perhaps with some help we can clean up the interfaces some
> more.
I will try to help as I try to undertend the current one :)

Thank you very much for yours comments.

Rafael Ávila de Espíndola


pgp2166Wpxs3e.pgp
Description: PGP signature

Re: a "hello world" frontend

[James A. Morrison]

Rafael Ávila de Espíndola <[EMAIL PROTECTED]> writes:

> Em Sun 12 Jun 2005 23:58, James A. Morrison escreveu:
> >  Was there anything in particular that you found hard to understand in the
> > treelang frontend.  It is supposed to be the example/tutorial front-end.
> One thing is that the parser is very big and mixed with C code. I find it 
> easier to read a parser without side effects that just builds a abstract 
> syntax tree ("Modern compiler implementation in ML" influence...). Just 
> moving some of the C code to auxiliary functions in parse-aux.c would be very 
> helpfull (are you interested in this patch(s)?).

 Yup, I'd be willing to take the patches.  If you are going to do this stuff
and other cleanup (which I do hope you do ;) then you should get a copyright
assignment on file with the FSF.
 
> >  I suppose I should update this howto for gcc4.
> That would be wonderfull!!!

> >  Perhaps, but the implementation may be the same because of how the
> > callbacks used to be implemented.  With the langhooks it should be easy for
> > any frontend to use the default implementation of a calback.
> Convert is called directly and not through langhooks. Why?
> Some call backs don't have a default: LANG_HOOKS_BUILTIN_FUNCTION for example.

 Right, convert probably should be turned into a langhook so we can find uses
of convert in the middle end that should call fold_convert instead.  Also,
a patch to make a default for LANG_HOOKS_BUILTIN_FUNCTION would probably be
a good cleanup patch.

> >  Where?  I build NOP_EXPRs around the use of variables, in the treelang
> > frontend so I can get accurate source locations for where variables are
> > used.
> at build_string_literal in hello1.c (copied from builtins.c). This looks like 
> a lot of work to build a string. I tried to use something similar to 
> gfc_build_string_const (fortran/trans-const.c) but failed.

 Ahh, treelang does have strings.  I may take a look at your strings to see
how I can add them to treelang.  Treelang probably should have strings.

> >  function_end_locus is part of the function struct, which in treelang there
> > is only cfun at any given time.
> >
> 
> >  The answer is in tree.h:833,
> >In a FUNCTION_DECL, nonzero if function has been defined.
> but in tree.h:2092

tree.h:2115 in the cvs copy I have.

> /* In a VAR_DECL or FUNCTION_DECL,
>nonzero means external reference:
>do not allocate storage, and refer to a definition elsewhere.  */
> 
> So a function can be defined and have a "definition elsewhere" at the same 
> time? Isn't it true that
> DECL_EXTERNAL(n) != TREE_STATIC(n) for all n?

 No, TREE_STATIC for FUNCTION_DECLs only says if a function has been defined
or not.


-- 
Thanks,
Jim

http://www.csclub.uwaterloo.ca/~ja2morri/
http://phython.blogspot.com
http://open.nit.ca/wiki/?page=jim

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

[Richard Henderson]

On Mon, Jun 13, 2005 at 07:17:24PM -0700, Zack Weinberg wrote:
> Or, if GAS can be told which mode it should be in via directives in
> its input (.code32/.code64?), then we could add something like
> 
>  fputs (TARGET_64BIT ? "\t.code64\n" : "\t.code32", 
> asm_out_file);
> 
> to x86_file_start, and kill the spec hackery altogether.

I'm a fan of such directives.  I suspect that we'll have to keep
the spec hackery for a while yet.  We don't usually force binutils
upgrades with compiler upgrades...


r~

Re: Use of check_vect() in vectorizer testsuite

[Dorit Naishlos]

Devang Patel <[EMAIL PROTECTED]> wrote on 14/06/2005 00:24:27:
>
> On Jun 10, 2005, at 2:01 PM, Dorit Naishlos wrote:
>
> > Devang, is vect-dv-2.c a duplicate of vect-ifcvt-1.c or are they
> > both there
> > on purpose?
>
> It is duplicate. I'll remove vect-dv-2.c tomorrow, unless I hear
> otherwise.
>

it looks like there's nothing related to if-conversion in that testcase,
but rather distance-vector tests, so maybe remove vect-ifcvt-1.c instead

dorit

> -
> Devang
>

Re: A Suggestion for Release Testing

[Mark Mitchell]

Scott Robert Ladd wrote:

Given the recent problems with the 4.0.0 release and major packages like
KDE and the kernel, has anyone considered testing releases by completely
compiling a Linux system?


I'm all for more testing -- but I have a standard rant about it being 
easier to run tests than to fix problems.  We actually have a wealth of 
known regressions -- some pretty serious -- in Bugzilla, and plenty more 
known bugs.  Most come from real problems reported by real users on real 
code.  So, it's not like we're running out of bugs to fix.


Setting up automated regression testing is good, and hugely useful -- 
but what makes it *really* valuable is having someone who comes in every 
morning, looks at the output, and figures out who to blame, and, if 
necessary, fixes the problem herself.


--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

[Zack Weinberg]

Richard Henderson <[EMAIL PROTECTED]> writes:

> On Mon, Jun 13, 2005 at 07:17:24PM -0700, Zack Weinberg wrote:
>> Or, if GAS can be told which mode it should be in via directives in
>> its input (.code32/.code64?), then we could add something like
>> 
>>  fputs (TARGET_64BIT ? "\t.code64\n" : "\t.code32", 
>> asm_out_file);
>> 
>> to x86_file_start, and kill the spec hackery altogether.
>
> I'm a fan of such directives.  I suspect that we'll have to keep
> the spec hackery for a while yet.  We don't usually force binutils
> upgrades with compiler upgrades...

So I take it that such directives do not already exist?  Darn.

zw