Re: C++0x Memory model and gcc

[Richard Guenther]

On Thu, May 6, 2010 at 6:22 PM, Andrew MacLeod  wrote:
> Richard Guenther wrote:
>>
>> On Thu, May 6, 2010 at 5:50 PM, Richard Guenther
>>  wrote:
>>
>>>
>>> First let me say that the C++ memory model is crap when it
>>> forces data-races to be avoided for unannotated data like
>>> the examples for packed data.
>>>
>
> And it isn't consistent across the board, since neighbouring bits normally
> don't qualify and can introduce data races. I don't like it when a solution
> has exceptions like that. It is what it is however, and last I heard the
> plan was for C to adopt the changes as well.

I would have hoped that only data races between independent
objects are covered, thus

 tmp = a.i;
 b.j = tmp;

would qualify as a load of a and a store to b as far as dependencies
are concerned.  That would have been consistent with the
exceptions for bitfields and much more friendly to architectures
with weak support for unaligned accesses.

>>>
>>> Well, I hope that instead of just disabling optimizations you
>>> will help to improve their implementation to be able to optimize
>>> in a conformant manner.
>>>
>
> I don't want to disable any more than required. SSA names aren't affected
> since they are local variables only,  its only operations on shared memory,
> and I am hopeful that I can minimize the restrictions placed on them.  Some
> will be more interesting than others... like CSE... you can still perform
> CSE on a global as long as you don't introduce a NEW load on some execution
> path that didn't have before. What fun.

I don't understand that restriction anyway - how can an extra
load cause a data-race if the result is only used when it was
used before?  (You'd need to disable PPRE and GCSE completely
if that's really a problem)

Thus,

if (p)
  tmp = load;
...
if (q)
  use tmp;

how can transforming that to

tmp = load;
...
if (q)
  use tmp;

ever cause a problem?

>> And btw, if you are thinking on how to represent the extra
>> data-dependencies required for the consistency models think
>> of how to extend whatever you need in infrastructure for that
>> to also allow FENV dependencies - it's a quite similar problem
>> (FENV query/set are the atomic operations, usual arithmetic
>> is what the dependency is to).  It's completely non-trivial
>> (because it's scalar code, not memory accesses).  For
>> atomics you should be able to just massage the alias-oracle
>> data-dependence routines (maybe).
>>
>
> That's what I'm hoping actually..

We'll see.

Richard.

> Andrew.
>

generating MELT documentation from MELT sources.

[Basile Starynkevitch]

Hello All

I am working on the MELT branch [& plugin]
http://gcc.gnu.org/wiki/MiddleEndLispTranslator

MELT provides a lispy domain specific language [& its runtime] to code
GCC extensions in. So a MELT source file *.melt (eg foo.melt) is
translated into a sequence of *.c files (eg foo.c & foo+01.c &
foo+02.c) which are themselves compiled into a MELT *.so module
(e.g. foo.so). So a MELT module is like a GCC plugin, except that it
goes thru the MELT runtime and has a different ABI.

I am understanding that the GCC runtime licence gives the same
permissions for MELT modules (which are dlopen-ed by the melt.so
plugin for GCC 4.5, or by the gcc-melt binaries when MELT is compiled
as a branch). This probably means that any *.melt file under GPLv3+ is
ok w.r.t GCC licences. My understanding is the the GPLv3+ licence is
principally on the human written *.melt files. Actually, the generated
C code also duplicates the licensing comment from the *.melt file. But
practically a MELT generated *.c file is useless -and not very human
understandable- if you don't have the *.melt source.

In practice, a MELT module can implement some GCC passes (coded in the
MELT language) and install them in the GCC pass tree. In addition, the
entire MELT language is implemented in MELT (and is bootstrapped, so
the subversion tree or any MELT source distribution contains not only
the *.melt files for the MELT translator, but also the generated
melt/generated/*.c files which are their translation to C).

The MELT branch has also a [very incomplete, but existing]
documentation. You could regenerate it (as usual, by make pdf) or you
can look at a previous version of it on
http://gcc.gnu.org/wiki/MELT%20tutorial?action=AttachFile&do=view&target=GCC-MELT--gcc-internals-snapshot.pdf
I am refering to that file when I speak of the "generated PDF file"
in this email.

The reference documentation is automatically generated (by a special
mode of MELT). You can look at the chapter 15 (pages 319 & following)
of the generated PDF file linked above. The documentation is generated
by parsing the MELT source files, in particular by using the :doc
annotations inside them (and by computing standard things, like
e.g. class hierarchy, some cross-referencing, etc..).

I find quite convenient the idea of generating reference documentation
by processing the *.melt source files. I would be very sad to have to
abandon this idea.

So my question is: is there any legal or licensing issues to generate
*.texi from *.melt files; the *.melt files are of course FSF
copyrighted GPLv3+ licensed, as code in every branch of GCC. The
*.texi files (at least those written by humans, including melt.texi
written by me) are of course FSF copyrighted & in my understanding
GFDLv1.2+ licenced, as every *.texi files inside GCC.

A typical example of MELT code containing documentation is available
in many places, but in particular in gcc/melt/warmelt-base.melt [and
many other *.melt files] of the MELT branch. For examples:





The primitive to ignore a value is coded as

   near start of file warmelt-base.melt, near line 35

  ;; primitive to ignore a value
  (defprimitive ignore (v) :void
:doc #{Ignore the value passed as argument. Useful to avoid translation 
warnings, or to force the type of a conditional. See $CTYPE_VOID.}#
#{/*ignore*/(void)($v)}#)  

   end of citation from warmelt-base.melt

The generated documentation appears in page 458 of the generated PDF
file [yes, the names are not alphabetically sorted, that is a bug in
the documentation generator]




The iterator on integers, whose occurrences are translated to simple
for($IX=$IMIN; $IX<=$IMAX; $IX++) loops

    from file warmelt-base.melt near line 342
   ;;; citerator on integers
   (defciterator foreach_long_upto
 (:long imin imax)  ;start formals
 eachlong   ;state
 (:long ix) ;local formals
 :doc #{The $FOREACH_LONG_UPTO c-iterator provides the usual
   ascending integer iterator. Start formals are $IMIN, the minimum start
   integer, and $IMAX, le maximal ending integer. Local formal is $IX,
   the current index. The body is executed for each integer value $IX
   from $IMIN to $IMAX included.}#
;before expansion
   #{/*start $eachlong */
   long $eachlong#_min =  $imin;
   long $eachlong#_max = $imax;
   long $eachlong#_cur = 0;
   for ($eachlong#_cur = $eachlong#_min;
$eachlong#_cur <= $eachlong#_max;
 $eachlong#_cur ++) {
$ix = $eachlong#_cur;   
   }#
;after expansion
  #{ } /*end eachlong */}#
   )
    end of citation from file warmelt-base.melt

The generated documentation appears page 494 of the PDF file.   







GCC passes are reified as MELT objects, instances of the following classes

   fr

Re: a peculiar fpload problem on an inferior processor

[Amker.Cheng]

>  It is possible.  Your expander can handle it before reload; to handle it
> during and after reload, you need to implement a TARGET_SECONDARY_RELOAD hook.
>
> http://gcc.gnu.org/onlinedocs/gccint/Register-Classes.html#index-TARGET_005fSECONDARY_005fRELOAD-3974
>
Thanks Dave, It works, but I found that reload is not the only pass
which might generate fpload/fpstore instructions.
I am working with GCC 4.4(mips), there is function(mips_emit_move),
which is called in many pass after register allocation
and might generate fpload/fpstore.
For example, in pass pro_and_epilogue, it generates load/store for fpu
register which saved by function prologue/epilogue.

Seems I have to track down all calling of this function and make sure
it works in my way.

Thanks.

-- 
Best Regards.

Re: C++0x Memory model and gcc

[Andrew MacLeod]

Richard Guenther wrote:

On Thu, May 6, 2010 at 6:22 PM, Andrew MacLeod  wrote:
  

Richard Guenther wrote:



I would have hoped that only data races between independent
objects are covered, thus

 tmp = a.i;
 b.j = tmp;

would qualify as a load of a and a store to b as far as dependencies
are concerned.  That would have been consistent with the
exceptions for bitfields and much more friendly to architectures
with weak support for unaligned accesses.
  

They are independent as far as dependencies within this compilation unit.
The problem is if thread number 2 is performing
 a.j = val
 b.i = val2

now there are data races on both A and B if we load/store full words and 
the struct was something like: 
struct {

 char i;
 char j;
} a, b;

The store to B is particularly unpleasant since you may lose one of the 
2 stores.  The load data race on A is only in the territory of hardware 
or software race detectors.





I don't want to disable any more than required. SSA names aren't affected
since they are local variables only,  its only operations on shared memory,
and I am hopeful that I can minimize the restrictions placed on them.  Some
will be more interesting than others... like CSE... you can still perform
CSE on a global as long as you don't introduce a NEW load on some execution
path that didn't have before. What fun.



I don't understand that restriction anyway - how can an extra
load cause a data-race if the result is only used when it was
used before?  (You'd need to disable PPRE and GCSE completely
if that's really a problem)

Thus,

if (p)
  tmp = load;
...
if (q)
  use tmp;

how can transforming that to

tmp = load;
...
if (q)
  use tmp;

ever cause a problem?
  


If the other thread is doing something like:

if (!p)
 load = something

then there was no data race before since your thread wasn't performing a 
load when this thread was storing.  ie, 'p' was being used as the 
synchronization guard that prevented a data race.  When you do the 
transformation,  there is now a potential race that wasn't there before.


Some hardware can detect that and trigger an exception, or a software 
data race detector could trigger, and neither would have before, which 
means the behaviour is detectably different.


Thats also why I've separated the loads and stores for handling 
separately.  under normal circumstances, we want to allow this 
transformation.  If there aren't any detection abilities in play, then 
the transformation is fine... you can't tell that there was a race.  
With stores you can actually get different results, so we do need to 
monitor those.


Andrew

Re: a peculiar fpload problem on an inferior processor

[Dave Korn]

On 07/05/2010 12:04, Amker.Cheng wrote:
>>  It is possible.  Your expander can handle it before reload; to handle it
>> during and after reload, you need to implement a TARGET_SECONDARY_RELOAD 
>> hook.
>>
>> http://gcc.gnu.org/onlinedocs/gccint/Register-Classes.html#index-TARGET_005fSECONDARY_005fRELOAD-3974
>>
> Thanks Dave, It works, but I found that reload is not the only pass
> which might generate fpload/fpstore instructions.
> I am working with GCC 4.4(mips), there is function(mips_emit_move),
> which is called in many pass after register allocation
> and might generate fpload/fpstore.
> For example, in pass pro_and_epilogue, it generates load/store for fpu
> register which saved by function prologue/epilogue.
> 
> Seems I have to track down all calling of this function and make sure
> it works in my way.

  Ah, I forgot pro/epilogue generation, but I think that's the only other
thing that happens after reload.  That is a special case: it has to generate
strict rtl that directly matches the insns it wants.  You'll probably have to
arrange for it to save at least one GPR early enough in the prologue sequence
to be able to use it as a temp for your FP moves, and similar in the epilogue
sequence.

cheers,
  DaveK

Re: C++0x Memory model and gcc

[Mark Mitchell]

Ian Lance Taylor wrote:

> -fmemory-model=single
> Assume single threaded execution, which also means no signal
> handlers.
> -fmemory-model=fast
> The user is responsible for all synchronization.  Accessing
> the same memory words from different threads may break
> unpredictably.
> -fmemory-model=safe
> The compiler will do its best to protect you.

That makes sense to me.  I think that's an appropriately user-oriented
view of the choices.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: [RFC] Introduce -Ofast

[Mark Mitchell]

Richard Guenther wrote:

> This is a proposal to introduce an optimization level -Ofast
> that can collect (target specific) optimization flags that
> can affect runtime behavior such as -funsafe-math-optimizations
> or -mrecip.

I think that makes sense.  Defining what's allowed in these cases is
always tricky (there was a long thread a couple of years back in which
we tried to get some scoping on just what -ffast-math might be allowed
to do), but I think the short answer is "this option will try to make
your program go faster, even if that means doing things the standards do
not allow the compiler to do".

> Currently none of the standard optimization levels have this
> kind of affect and we should not change that (people might
> argue that -funsafe-math-optimizations can go into -O3).

I agree that -O3 should not violate the standards.  However, I don't
agree that it shouldn't be target-specific.  (It's quite possible that
we agree; I'm interpreting your words.)  If there's a magic option that
makes MIPS go faster but makes Power go slower, then -O3 on MIPS should
most definitely turn it on, and -O3 on Power most definitely should not.
 As a user, I don't want to know about the option; I just want -O3 to
generate fast code.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

profile mode output analysis (call stacks to source code mapping)

[Karel Gardas]

Hello,

with recent fixes into profile mode I've succeed even using it for
MICO[1] on OpenSolaris platform. It seems only compilation to static
libraries is supported at the moment, but never mind my server run
generates something. As it provides some hints I'd like to more
closely analyze I would definitely like to find the place in the
source code to which the advices apply. Is there any tool which
translates call stacks to humans or is there any documentation/hint
how to use generated call stack information to find out appropriate
place in the source code?

Thanks!
Karel
[1]: www.mico.org

Re: C++0x Memory model and gcc

[Ian Lance Taylor]

Andrew MacLeod  writes:

> They are independent as far as dependencies within this compilation unit.
> The problem is if thread number 2 is performing
>  a.j = val
>  b.i = val2
>
> now there are data races on both A and B if we load/store full words
> and the struct was something like: struct {
>  char i;
>  char j;
> } a, b;
>
> The store to B is particularly unpleasant since you may lose one of
> the 2 stores.  The load data race on A is only in the territory of
> hardware or software race detectors.

In this exmaple, if we do a word access to a, then we are running past
the boundaries of the struct.  We can only assume that is OK if a is
aligned to a word boundary.  And if both a and b are aligned to word
boundaries, then there is no problem doing a word access to a.

So the only potential problem here is if we have two small variables
where one is aligned and the other is not.  This is an unusual
situation because small variables are not normally aligned.  We can
avoid trouble by forcing an alignment to a word boundary after every
aligned variable.

Or so it seems to me.

Ian

[Fwd: Re: C++0x Memory model and gcc]

[Andrew MacLeod]

Oops, didn't reply all...


 Original Message 
Subject:Re: C++0x Memory model and gcc
Date:   Fri, 07 May 2010 10:37:40 -0400
From:   Andrew MacLeod 
To: Ian Lance Taylor 
References: 	<4be2e39a.5060...@redhat.com> 
 
 
<4be2ecdb.2040...@redhat.com> 
 
<4be41552.4000...@redhat.com> 





Ian Lance Taylor wrote:

Andrew MacLeod  writes:

  

They are independent as far as dependencies within this compilation unit.
The problem is if thread number 2 is performing
 a.j = val
 b.i = val2

now there are data races on both A and B if we load/store full words
and the struct was something like: struct {
 char i;
 char j;
} a, b;

The store to B is particularly unpleasant since you may lose one of
the 2 stores.  The load data race on A is only in the territory of
hardware or software race detectors.



In this exmaple, if we do a word access to a, then we are running past
  


yes, well that's not what I was getting at.  Add a short to the struct 
to pad it out to a word or access the variables via a short load and 
store...  and do the appropriate masking.   I was just trying not to 
make the example any bigger than need be :-P



So the only potential problem here is if we have two small variables
where one is aligned and the other is not.  This is an unusual
situation because small variables are not normally aligned.  We can
avoid trouble by forcing an alignment to a word boundary after every
aligned variable.

Or so it seems to me.
  


The problem is when you load or store a larger unit than the actual 
object you are loading or storing.  Its not specifically an alignment 
thing.


I don't know how many architectures still do this, but we need to 
disable those that do.


Andrew

Re: where are caller-save addresses legitimized?

[Greg McGary]

On 05/05/10 21:27, Jeff Law wrote:

On 05/05/10 21:34, Greg McGary wrote:
   

On 05/05/10 20:21, Jeff Law wrote:
 

I'm not sure they are ever legitimized -- IIRC caller-save tries to only
generate addressing modes which are safe for precisely this reason.
   

Apparently not so: caller save is quite capable of producing invalid
offsets.
Perhaps my port needs some hook to help GCC produce good addresses?
I've been looking, but haven't found it yet...
 

Try != successful :(

You might want to look at his code in init_caller_save:
   


Unfortunately, that didn't yield any clues.  I'll proceed by building 
some well-established RISCy target and see what it does in similar 
circumstances.


G

Re: where are caller-save addresses legitimized?

[Jeff Law]

On 05/07/10 14:54, Greg McGary wrote:


Unfortunately, that didn't yield any clues.  I'll proceed by building 
some well-established RISCy target and see what it does in similar 
circumstances.
The canonical testcase for caller-save on risc targets was sparc FP code 
-- the older sparcs didn't have any call-saved FP regs.


Jeff

What is the best way to resolve ARM alignment issues for large modules?

[Shaun Pinney]

Hello all,

Essentially, we have code which works fine on x86/PowerPC but fails on ARM due
to differences in how misaligned accesses are handled.  The failures occur in
multiple large modules developed outside of our team and we need to find a
solution.  The best question to sum this up is, how can we use the compiler to
arrive at a complete solution to quickly identify all code locations which
generate misaligned accesses and/or prevent the compiler from generating
misaligned accesses?  Thanks for any advice.  I'll go into more detail below.

---
We're using an ARM9 core (ARMv5) and notice that GCC generates misaligned load
instructions for certain modules in our platform.  For these modules, which work
correctly on x86/PowerPC, the misaligned loads causes failures.  This is because
the ARM rounds down misaligned addresses to the correct alignment, performs the
memory load, and rotates the data before placing in a register.  As a result, a
misaligned multi-byte load instruction on ARM actually loads memory below the
requested address and does not load all upper bytes from "address" to "address +
size - 1" so it appears to these modules as incorrect data.  On x86/PowerPC,
loads do provide bytes from "address" to "address + size - 1" regardless of
alignment, so there are no problems.

Fixing the code manually for ARM alignment has difficulties.  Due to the large
code volume of these external modules, it is difficult to identify all locations
which may be affected by misaligned accesses so the code can be rewritten.
Currently, the only way to detect these issues is to use -Wcast-align and view
the output to get a list of potential alignment issues.  This appears to list a
large number of false positives so sorting through and doing code investigation
to locate true problems looks very time-consuming.  On the runtime side, we've
enabled alignment exceptions to catch some additional cases, but the problem is
that exceptions are only thrown for running code.  There is always the chance
there is some more unexecuted 'hidden' code waiting to fail when the right
circumstance occurs.  I'd like to provably remove the problem entirely and
quickly.

One idea, to guarantee no load/store alignment problems will affect our product,
was to force the compiler to generate single byte load/store instructions in
place of multi byte load/store instructions when the alignment cannot be
verified by the compiler.  Such as, for pointer typecasts where the alignment is
increased (e.g. char * to int *), accesses to misaligned fields of packed data
structures, accesses to structure fields not allocated on the stack, etc.  Is
this available?  Obviously, this will add performance overhead, but would
clearly resolve the issue for affected modules.

Does the ARM compiler provide any other techniques to help with these types of
problems?  It'd be very helpful to find a fast and complete way to do this work.
Thanks!

Thanks again for your advice.

Best regards,
Shaun

BTW - our ARM also allows us to change the behavior of multi-byte load/store
instructions so they read from 'address' to 'address + size - 1'.  However, our
OS, indicates that it intentionally uses misaligned loads/stores, so changing
the ARM's load/store behavior to fix the module alignment problems would break
the OS in unknown places.  Also, because of this we cannot permanently enable
alignment exceptions either.  I plan to discuss this more with our OS vendor.

ANNOUNCEMENT : Workshop on Essential Abstractions in GCC, 2010.

[Prashant Rawat]

-
  Workshop on Essential Abstractions in GCC, 2010
 (http://www.cse.iitb.ac.in/grc/gcc-workshop-10)
    ---

Organized by : GCC Resource Center (http://www.cse.iitb.ac.in/grc)
Venue :   Department of Computer Science and Engineering,
  IIT Bombay (http://www.cse.iitb.ac.in)
Dates :    5-8 July (Monday to Thursday) 2010

The workshop has been designed such that people with experience in
GCC can join the workshop on the second day (Tuesday, 6 July 2010).
Please visit the workshop web page for the details.
---

--
With regards,
Prashant Singh Rawat
http://www.cse.iitb.ac.in/~prashantr

builtin ffs vs. renamed ffs (vms-crtl.h)

[Jay K]

In gcc for VMS there is some mechanism to rename functions.
See the files:

/src/gcc-4.5.0/gcc/config/vms/vms-crtl-64.h
/src/gcc-4.5.0/gcc/config/vms/vms-crtl.h


which are mostly just lists of function from/to.


As well in gcc there is a mechanism for optimizing various "builtin" functions, 
like ffs.


These two mechanisms seem to conflict or be applied in the wrong order.
I didn't look at it deeply.


The symptom is that if you add ffs (to decc$ffs) to vms-crtl.h, the translation
is not done, and you end up with unresolved external ffs.


If you #if out the support for "builtin ffs", it works.


My local hack is below but obviously that's not the way.


I'll enter a bug.


Thanks,
 - Jay


diff -u /src/orig/gcc-4.5.0/gcc/builtins.c ./builtins.c
--- /src/orig/gcc-4.5.0/gcc/builtins.c    2010-04-13 06:47:11.0 -0700
+++ ./builtins.c    2010-05-07 23:11:30.0 -0700
@@ -51,6 +51,8 @@
 #include "value-prof.h"
 #include "diagnostic.h"
 
+#define DISABLE_FFS
+
 #ifndef SLOW_UNALIGNED_ACCESS
 #define SLOW_UNALIGNED_ACCESS(MODE, ALIGN) STRICT_ALIGNMENT
 #endif
@@ -5899,6 +5901,7 @@
 return target;
   break;
 
+#ifndef DISABLE_FFS
 CASE_INT_FN (BUILT_IN_FFS):
 case BUILT_IN_FFSIMAX:
   target = expand_builtin_unop (target_mode, exp, target,
@@ -5906,6 +5909,7 @@
   if (target)
 return target;
   break;
+#endif
 
 CASE_INT_FN (BUILT_IN_CLZ):
 case BUILT_IN_CLZIMAX:
@@ -13612,6 +13616,7 @@
 case BUILT_IN_ABORT:
   abort_libfunc = set_user_assembler_libfunc ("abort", asmspec);
   break;
+#ifndef DISABLE_FFS
 case BUILT_IN_FFS:
   if (INT_TYPE_SIZE < BITS_PER_WORD)
 {
@@ -13620,6 +13625,7 @@
                        MODE_INT, 0), "ffs");
 }
   break;
+#endif
 default:
   break;
 }
diff -u /src/orig/gcc-4.5.0/gcc/optabs.c ./optabs.c
--- /src/orig/gcc-4.5.0/gcc/optabs.c    2010-03-19 12:45:01.0 -0700
+++ ./optabs.c    2010-05-07 23:11:36.0 -0700
@@ -45,6 +45,8 @@
 #include "basic-block.h"
 #include "target.h"
 
+#define DISABLE_FFS
+
 /* Each optab contains info on how this target machine
    can perform a particular operation
    for all sizes and kinds of operands.
@@ -3240,6 +3242,7 @@
 return temp;
 }
 
+#ifndef DISABLE_FFS
   /* Try implementing ffs (x) in terms of clz (x).  */
   if (unoptab == ffs_optab)
 {
@@ -3247,6 +3250,7 @@
   if (temp)
 return temp;
 }
+#endif
 
   /* Try implementing ctz (x) in terms of clz (x).  */
   if (unoptab == ctz_optab)
@@ -3268,7 +3272,11 @@
 
   /* All of these functions return small values.  Thus we choose to
  have them return something that isn't a double-word.  */
-  if (unoptab == ffs_optab || unoptab == clz_optab || unoptab == ctz_optab
+  if (
+#ifndef DISABLE_FFS
+  unoptab == ffs_optab ||
+#endif
+    unoptab == clz_optab || unoptab == ctz_optab
   || unoptab == popcount_optab || unoptab == parity_optab)
 outmode
   = GET_MODE (hard_libcall_value (TYPE_MODE (integer_type_node),
@@ -6301,7 +6309,9 @@
   init_optab (addcc_optab, UNKNOWN);
   init_optab (one_cmpl_optab, NOT);
   init_optab (bswap_optab, BSWAP);
+#ifndef DISABLE_FFS
   init_optab (ffs_optab, FFS);
+#endif
   init_optab (clz_optab, CLZ);
   init_optab (ctz_optab, CTZ);
   init_optab (popcount_optab, POPCOUNT);
@@ -6558,9 +6568,11 @@
   one_cmpl_optab->libcall_basename = "one_cmpl";
   one_cmpl_optab->libcall_suffix = '2';
   one_cmpl_optab->libcall_gen = gen_int_libfunc;
+#ifndef DISABLE_FFS
   ffs_optab->libcall_basename = "ffs";
   ffs_optab->libcall_suffix = '2';
   ffs_optab->libcall_gen = gen_int_libfunc;
+#endif
   clz_optab->libcall_basename = "clz";
   clz_optab->libcall_suffix = '2';
   clz_optab->libcall_gen = gen_int_libfunc;
@@ -6643,11 +6655,13 @@
   satfractuns_optab->libcall_basename = "satfractuns";
   satfractuns_optab->libcall_gen = gen_satfractuns_conv_libfunc;
 
+#ifndef DISABLE_FFS
   /* The ffs function operates on `int'.  Fall back on it if we do not
  have a libgcc2 function for that width.  */
   if (INT_TYPE_SIZE < BITS_PER_WORD)
 set_optab_libfunc (ffs_optab, mode_for_size (INT_TYPE_SIZE, MODE_INT, 0),
        "ffs");
+#endif
 
   /* Explicitly initialize the bswap libfuncs since we need them to be
  valid for things other than word_mode.  */


Thanks,
 - Jay
  

vmsdbgout.c int-to-enum cast and #define globalref

[Jay K]

vmsdbgout.c has an int-to-enum warning and needs some form of "globalref" when 
host=alpha-dec-vms since that #includes the VMS system headers.
Perhaps gcc should recognize globalref when target=*vms* and at least interpret 
it as extern.

Thanks,
 - Jay

diff -u /src/orig/gcc-4.5.0/gcc/vmsdbgout.c ./vmsdbgout.c
--- /src/orig/gcc-4.5.0/gcc/vmsdbgout.c    2009-11-25 02:55:54.0 -0800
+++ ./vmsdbgout.c    2010-05-06 01:40:20.0 -0700
@@ -21,6 +21,8 @@
 along with GCC; see the file COPYING3.  If not see
 .  */
 
+#define globalref extern
+
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
@@ -743,7 +745,7 @@
   modbeg.dst_b_modbeg_flags.dst_v_modbeg_version = 1;
   modbeg.dst_b_modbeg_flags.dst_v_modbeg_unused = 0;
   modbeg.dst_b_modbeg_unused = 0;
-  modbeg.dst_l_modbeg_language = module_language;
+  modbeg.dst_l_modbeg_language = (DST_LANGUAGE)module_language;
   modbeg.dst_w_version_major = DST_K_VERSION_MAJOR;
   modbeg.dst_w_version_minor = DST_K_VERSION_MINOR;
   modbeg.dst_b_modbeg_name = strlen (module_name);
@@ -822,7 +824,7 @@
  + string count byte + string length */
   header.dst__header_length.dst_w_length
 = DST_K_DST_HEADER_SIZE - 1 + 1 + 4 + 1 + strlen (go);
-  header.dst__header_type.dst_w_type = 0x17;
+  header.dst__header_type.dst_w_type = (DST_DTYPE)0x17;
 
   totsize += write_debug_header (&header, "transfer", dosizeonly);
 


  

Re: a peculiar fpload problem on an inferior processor

[Amker.Cheng]

>  Ah, I forgot pro/epilogue generation, but I think that's the only other
> thing that happens after reload.  That is a special case: it has to generate
> strict rtl that directly matches the insns it wants.  You'll probably have to
> arrange for it to save at least one GPR early enough in the prologue sequence
> to be able to use it as a temp for your FP moves, and similar in the epilogue
> sequence.

Yes, Thanks for your help , Dave



-- 
Best Regards.