Marek Vasut | 27 Jan 21:43 2016

[Gc] libatomic-ops nios2


I am trying to add support for nios2 CPU into libatomic-ops and gc .
The Linux kernel exports kuser helper for cmpxchg [1], so I believe
this might be the way to go? Or shall I somehow use the gcc atomic
builtin ops [2] ? Note that nios2 does not have dedicated atomic
instructions which could be used in userland, that's why the kuser

Thank you for any input!


Best regards,
Marek Vasut
Hanno Böck | 24 Jan 14:40 2016

[Gc] Address Sanitizer reports stack underflow


When trying to compile boehm-gc with address sanitizer it reports a
stack underflow in the function GC_push_all_eager().

I am not sure if this is a bug or if boehm-gc is in principle unable to
work with address sanitizer (as asan is basically intercepting memory
management and boehm-gc is supposed to be a replacement for existing
memory managements). But I haven't found it reported elsewhere and am

The bug appears as soon as one calls GC_INIT() (tested with gc-7.4.2).
It can also be triggered by running the test suite:
./configure CFLAGS="-fsanitize=address -g" LDFLAGS="-fsanitize=address"
make check

The asan errors will be in test-suite.log.

This is an example for such an error:
==2112==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7ffc1e6284a0 at pc
0x7fa4a24bcd14 bp 0x7ffc1e6283d0 sp 0x7ffc1e6283c0
READ of size 8 at 0x7ffc1e6284a0 thread T0
    #0 0x7fa4a24bcd13 in GC_push_all_eager /mnt/ram/asan/gc-7.4.2/mark.c:1509
    #1 0x7fa4a24bf26d in GC_push_current_stack /mnt/ram/asan/gc-7.4.2/mark_rts.c:664
    #2 0x7fa4a24b2357 in GC_with_callee_saves_pushed /mnt/ram/asan/gc-7.4.2/mach_dep.c:296
    #3 0x7fa4a24bf2d9 in GC_push_regs_and_stack /mnt/ram/asan/gc-7.4.2/mark_rts.c:741
    #4 0x7fa4a24bf509 in GC_push_roots /mnt/ram/asan/gc-7.4.2/mark_rts.c:813
    #5 0x7fa4a24b835d in GC_mark_some /mnt/ram/asan/gc-7.4.2/mark.c:352
    #6 0x7fa4a24a21ad in GC_stopped_mark /mnt/ram/asan/gc-7.4.2/alloc.c:637
(Continue reading)

Ivan Maidanski | 9 Jan 17:21 2016

[Gc] Fwd: [bdwgc] Race conditions between thread termination and garbage collection (#86)

-------- Forwarded message --------
From: Daniel Mendler <notifications <at>>
CC: ivmai/bdwgc <bdwgc <at>>
Date: Sat, 09 Jan 2016, 16:46 +03:00
Subj: [bdwgc] Race conditions between thread termination and garbage collection (#86)

This was discussed before, but I don't know if it was resolved:
I use github master.
(gdb) info threads
  Id   Target Id         Frame
  11   Thread 0x7f7dfd962700 (LWP 2022) 0x00007f7e04dcd482 in do_sigsuspend (set=0x7f7e059db240 <suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
  10   Thread 0x7f7dfe163700 (LWP 2021) 0x00007f7e04dcd482 in do_sigsuspend (set=0x7f7e059db240 <suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
  9    Thread 0x7f7dfe964700 (LWP 2020) 0x00007f7e04dcd482 in do_sigsuspend (set=0x7f7e059db240 <suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
  8    Thread 0x7f7dff165700 (LWP 2019) 0x00007f7e04dcd482 in do_sigsuspend (set=0x7f7e059db240 <suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
  7    Thread 0x7f7dff966700 (LWP 2018) 0x00007f7e04dcd482 in do_sigsuspend (set=0x7f7e059db240 <suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
  6    Thread 0x7f7e00167700 (LWP 2017) 0x00007f7e04dcd482 in do_sigsuspend (set=0x7f7e059db240 <suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
  5    Thread 0x7f7e00968700 (LWP 2016) 0x00007f7e04dcd482 in do_sigsuspend (set=0x7f7e059db240 <suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
  4    Thread 0x7f7e01169700 (LWP 2015) sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
  3    Thread 0x7f7e0216b700 (LWP 2013) __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
  2    Thread 0x7f7e04970700 (LWP 2008) pthread_cond_wait <at> <at> GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
* 1    Thread 0x7f7e05c05b40 (LWP 2007) 0x00007f7e04dcd482 in do_sigsuspend (set=0x7f7e059db240 <suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
It seems that threads 2, 3, 4 are dead locked.
(gdb) thread 4
[Switching to thread 4 (Thread 0x7f7e01169700 (LWP 2015))]
#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
85  ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S: No such file or directory.
(gdb) bt
#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
#1  0x00007f7e057bcf82 in GC_stop_world () at pthread_stop_world.c:662
#2  0x00007f7e057a913e in GC_stopped_mark (stop_func=stop_func <at> entry=0x7f7e057a8c40 <GC_never_stop_func>) at alloc.c:646
#3  0x00007f7e057a9c99 in GC_try_to_collect_inner (stop_func=0x7f7e057a8c40 <GC_never_stop_func>) at alloc.c:486
#4  0x00007f7e057a9f0a in GC_try_to_collect_general (stop_func=stop_func <at> entry=0x0, force_unmap=force_unmap <at> entry=0) at alloc.c:1065
#5  0x00007f7e057a9fdd in GC_gcollect () at alloc.c:1089
(gdb) thread 3
[Switching to thread 3 (Thread 0x7f7e0216b700 (LWP 2013))]
#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
135 in ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S
(gdb) bt
#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007f7e055864b9 in _L_lock_909 () from /lib/x86_64-linux-gnu/
#2  0x00007f7e055862e0 in __GI___pthread_mutex_lock (mutex=0x7f7e059daca0 <GC_allocate_ml>) at ../nptl/pthread_mutex_lock.c:79
#3  0x00007f7e057bbed5 in GC_thread_exit_proc (arg=arg <at> entry=0x2662c00) at pthread_support.c:1409
#4  0x00007f7e057bacad in GC_inner_start_routine (sb=<error reading variable: value has been optimized out>, arg=<error reading variable: value has been optimized out>) at pthread_start.c:63
#5  0x00007f7e057b5a42 in GC_call_with_stack_base (fn=<optimized out>, arg=<optimized out>) at misc.c:1925
#6  0x00007f7e055840a4 in start_thread (arg=0x7f7e0216b700) at pthread_create.c:309
#7  0x00007f7e04e7e04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) thread 2
[Switching to thread 2 (Thread 0x7f7e04970700 (LWP 2008))]
#0  pthread_cond_wait <at> <at> GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
185 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such file or directory.
(gdb) bt
#0  pthread_cond_wait <at> <at> GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f7e057bc8f7 in GC_wait_marker () at pthread_support.c:2121
#2  0x00007f7e057b2cea in GC_help_marker (my_mark_no=my_mark_no <at> entry=30) at mark.c:1186
#3  0x00007f7e057bc8cc in GC_mark_thread (id=<optimized out>) at pthread_support.c:380
#4  0x00007f7e055840a4 in start_thread (arg=0x7f7e04970700) at pthread_create.c:309
#5  0x00007f7e04e7e04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Reply to this email directly or  view it on GitHub .

bdwgc mailing list
Ivan Maidanski | 5 Jan 08:40 2016

Re: [Gc] [PATCH] Fix PR66848 by enforcing 16-bit alignment on darwin

Hello Mike,

About upgrade of libgc to v7+: I'm preparing a patch in GCC trunk to polish libgc API to match that of bdwgc master. Though it does not seem to be complete (I haven't checked even whether it is buildable), you could get it (a set of patches actually) from


Fri, 1 Jan 2016, 10:28 -08:00 from Hans Boehm <boehm <at>>:

[Adding Ivan, the current bdwgc maintainer.]

I don't fully understand the issue here.  Do we understand where the problem is coming from?  Are the compiler/linker generating misaligned pointers someplace?  That would strike me as a misfeature elsewhere.

Setting ALIGNMENT to 2, as in the patch, is a pretty big hammer.  It causes the gc to look for pointers at every 2 byte offset, quadrupling the number of potential pointers that are tested, and significantly increasing the risk of finding "false" pointers.  I would expect more problems caused by large block allocations.


On Mon, Dec 28, 2015 at 1:44 PM, Mike Stump <mikestump <at>> wrote:
On Dec 22, 2015, at 9:08 AM, Jack Howarth < <at>> wrote:
> This bug doesn't exist in the more recent boehm-gc 7.2 or
> later releases. Until the exact change from 6.6 to 7.2 that suppresses
> this bug is identified or FSF gcc's boehm-gc is rebased on the 7.2
> version or later, the simple fix to suppress this issue on darwin is
> to enforce 16-bit alignment in boehm-gc/include/private/gcconfig.h for
> that target.

It would be nice to just pull in 7.2 (or just the latest release)…  seems like that should be easier to maintain to me.

> Okay for gcc trunk and back ports to gcc-5-branch and gcc-4_9-branch?

I’d like to punt the approval to a libboehm person, though, not sure we have any.  Just checked we don’t have an official maintainer listed.  :-(  Do we have anybody that wants to review the patch or should I?  Though I would prefer a new import of a newer library to fix the issue, I’m tempted to just approve the patch.  Kinda don’t want to as any deviation makes importing a new library annoying.  What do others think?

bdwgc mailing list
Ivan Maidanski | 5 Dec 15:05 2015

[Gc] Re[5]: Arm64 iOS support

Hello Kirill,

GC scans registers of other thread. This is a very target specific part - e.g. in case of Windows and iOS it uses context structure which contains all registers of the suspended thread.


суббота, 05 декабря 2015г., 00:09 +03:00 от Kirill Prazdnikov pkirill <at>>:

I see, thanks
Unfortunatelly RoboVM have closed sources and we will not be able to see any further bugs fixed.

I have one more question about the GC,
What if one thread call gcalloc and have the result on a register for some time, how come the collecting thread (another one) can see this pointer ?


4 дек. 2015 г. 13:05 пользователь "Ivan Maidanski" <ivmai <at>> написал:


The mentioned patch has been recently cherry-picked to bdwgc master, see


четверг, 03 декабря 2015г., 02:47 +03:00 от Shiro Kawai <shiro.kawai <at>>:

Could be the case; my use was limited so it's very likely that I haven't stepped
on to those nasty issues.  Hopefully those fixes will get merged
into the upstream.   The arm64 support is pre-release anyways, so YMMV...

On Wed, Dec 2, 2015 at 1:06 PM, Kirill Prazdnikov <pkirill <at>> wrote:
Hi Shiro,

RoboVM is a Java compiler for iOS.
They have a repo (, a fork of official (

They have solved many issues using the collector on iOS (32, 64, and 32 on 64).

Does it mean that I will face all that issues on iOS using original bdwgc code ?


On Thu, Dec 3, 2015 at 1:51 AM, Shiro Kawai <shiro.kawai <at>> wrote:
I'm using bdwgc on iOS8 and later (including arm64).  ro,.

On Tue, Dec 1, 2015 at 12:05 AM, Kirill Prazdnikov <pkirill <at>> wrote:

 does the collector support arm64 iOS ?


bdwgc mailing list
bdwgc <at>

bdwgc mailing list
bdwgc <at>
bdwgc mailing list
Niklas Therning | 3 Dec 22:42 2015

[Gc] Safe to call GC_finalize() BEFORE world starts?


In RoboVM (Java on iOS) we use GC_REGISTER_FINALIZER_NO_ORDER() to implement SoftReferences (i.e. weak references). When an instance of a Java object (the referent) is wrapped in a SoftReference we use GC_REGISTER_FINALIZER_NO_ORDER() to get a callback when the referent is no longer strongly reachable and then we clear all SoftReferences referring to it.

We're now facing a bug which seems to be related to the way finalizable objects are marked in GC_finalize(). GC_finalize() happens after the world is started and the referent is still weakly reachable until the callback has been called to clear the SoftReferences. So there is a small window where other threads can mutate the referent in such a way that some other instance it refers to never gets marked. E.g. by nulling out a field in the referent before GC_finalize() runs and then putting back the same value after GC_finalize() has run. This can lead to crashes later on when that other instance is reclaimed by the collector and reused in another allocation.

I have now patched GC_stopped_mark() in alloc.c to call GC_finalize() just before START_WORLD() is called (not if the stop function stops the marking) and it seems to fix the bug we've been seeing. But the question is whether this is safe? The finalizer callbacks are still called after the world is started.


bdwgc mailing list
Kirill Prazdnikov | 1 Dec 11:05 2015

[Gc] Arm64 iOS support


 does the collector support arm64 iOS ?


bdwgc mailing list
David Kastrup | 8 Nov 12:28 2015

[Gc] Two-phase finalization?

The Scheme interpreter Guile has been using the Boehm GC since version
2.0 and that's part of the reason the music typesetter LilyPond has not
yet been ported to Guile 2.

Guile offers user-defined types and in particular allows registering a
deallocation procedure for them via

 -- C Function: void scm_set_smob_free (scm_t_bits tc, size_t (*free)
          (SCM obj))
     This function sets the smob freeing procedure (sometimes referred
     to as a "finalizer") for the smob type specified by the tag TC.  TC
     is the tag returned by ‘scm_make_smob_type’.

     The FREE procedure must deallocate all resources that are directly
     associated with the smob instance OBJ.  It must assume that all
     ‘SCM’ values that it references have already been freed and are
     thus invalid.

     It must also not call any libguile function or macro except
     ‘scm_gc_free’, ‘SCM_SMOB_FLAGS’, ‘SCM_SMOB_DATA’,
     ‘SCM_SMOB_DATA_2’, and ‘SCM_SMOB_DATA_3’.

Note in particular the second paragraph which clearly states that with
respect to finalization order, there are no guarantees.  Now LilyPond
uses STL containers with pointers to other C++ structures with a Scheme
presence a lot.  It keeps these structures from being collected by using
a mark procedure registered via

 -- C Function: void scm_set_smob_mark (scm_t_bits tc, SCM (*mark) (SCM
     This function sets the smob marking procedure for the smob type
     specified by the tag TC.  TC is the tag returned by

     Defining a marking procedure may sometimes be unnecessary because
     large parts of the process’ memory (with the exception of
     ‘scm_gc_malloc_pointerless’ regions, and ‘malloc’- or
     ‘scm_malloc’-allocated memory) are scanned for live pointers(1).

     The MARK procedure must cause ‘scm_gc_mark’ to be called for every
     ‘SCM’ value that is directly referenced by the smob instance OBJ.
     One of these ‘SCM’ values can be returned from the procedure and
     Guile will call ‘scm_gc_mark’ for it.  This can be used to avoid
     deep recursions for smob instances that form a list.

     It must not call any libguile function or macro except
     ‘scm_gc_mark’, ‘SCM_SMOB_FLAGS’, ‘SCM_SMOB_DATA’,
     ‘SCM_SMOB_DATA_2’, and ‘SCM_SMOB_DATA_3’.

Now the problem we encounter is that if some structure A points to B and
some structure B points to A and both A and B are placed into
finalization, then the finalization of A will delete the associated C++
structure.  If now a mark pass is allowed through B, it will try to
access the deleted C++ structure of A.

Topological ordering will not do the trick since cyclical references are
quite typical (a NoteHead has a reference to the corresponding Stem, a
Stem has references to all corresponding NoteHeads).

So what we need here is a setting/hook where queuing some group of
objects for finalization will _stop_ any marking on them (including
false positives of the conservative marking process) before the first
finalization through a type hook stored via scm_set_smob_free on any
member of that group of objects occurs.

Individual objects don't have hooks of their own but they have some
additional bits available where one could record "placed into
finalization queue, don't call its scm_set_smob_mark hook any more"

The problem is how to get this information, or how to get these
semantics from Boehm GC.  Any ideas?


David Kastrup
bdwgc mailing list
bdwgc <at>
Agnius Vasiliauskas | 1 Nov 11:41 2015

[Gc] Issue with Valgrind in threading


I'm trying to use boehm garbage collector. When I run Valgrind memory leak detector in my
program which uses GC - i've got such messages: (GC was compiled with POSIX thread support):

Leak_PossiblyLost|====|144 bytes in 1 blocks are possibly lost in loss record 1 of 1| ||Call stack:|
/usr/lib/valgrind/||0x402C109: calloc|
/build/buildd/eglibc-2.19/elf/dl-tls.c|296|0x401117E: allocate_dtv|
/build/buildd/eglibc-2.19/elf/dl-tls.c|460|0x40118EB: _dl_allocate_tls|
/build/buildd/eglibc-2.19/nptl/allocatestack.c|589|0x40587A2: pthread_create <at> <at> GLIBC_2.1|
/home/agnius/Downloads/gc-7.4.2/pthread_support.c|437|0x80529ED: GC_start_mark_threads|
/home/agnius/Downloads/gc-7.4.2/misc.c|1195|0x80498DE: GC_init.part.1|
/home/agnius/Downloads/bigint/main.c|225|0x804B284: main|

seems like some memory leak issue when creating posix threads ?

Thanks for help.
bdwgc mailing list
Bruce A Henderson | 29 Sep 19:52 2015

[Gc] Problems with Emscripten


I have created a C-language generator ( ) for 
the programming language BlitzMax ( ) in order 
to support more platforms.
It successfully uses the Boehm GC on all currently targeted platforms 
and architectures (OSX, iOS, Android, Windows, Linux, Pi), except that 
is for Emscripten, where everything falls apart.

It appears, given the nature of the errors, that all of my global 
variables are being collected. For example, one object pushes output to 
stdout, and is working early in the run. However on the next call, it 
simply doesn't exist any more.

The variable is declared extern in the header, and like this in the .c :

struct brl_stream_TStream_obj* brl_standardio_StandardIOStream;

This particular object is created with GC_MALLOC_ATOMIC(), and is 
assigned a finalizer with GC_REGISTER_FINALIZER().

The modular project consists of many linked archives/static libs, which 
produce the final binary.

I am not setting any roots, letting the GC take care of that, as this 
works on all the other platforms.

Is there anything specific I should be doing (compile flags, definitions 
) for emscripten in order to hang on to my global variable references?



[Gc] compile gc-7.4.2 on sparc

I'm trying to compile gc-7.4.2 on a SunOS odin 5.10 Generic_142900-10 
sun4u sparc SUNW,SPARC-Enterprise
using gcc 5.2 and binutils-2.25 and it fail on dependence for 
sparc_mach_dep.lo.  The end of the build output
libtool: compile:  gcc -DHAVE_CONFIG_H -I./include -I./include 
-I./libatomic_ops/src -I./libatomic_ops/src -fexceptions
-Wall -Wextra -g -O2 -fno-strict-aliasing -MT pthread_stop_world.lo -MD 
-MP -MF .deps/pthread_stop_world.Tpo -c pthread_
stop_world.c  -fPIC -DPIC -o .libs/pthread_stop_world.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I./include -I./include 
-I./libatomic_ops/src -I./libatomic_ops/src -fexceptions
-Wall -Wextra -g -O2 -fno-strict-aliasing -MT pthread_stop_world.lo -MD 
-MP -MF .deps/pthread_stop_world.Tpo -c pthread_
stop_world.c -o pthread_stop_world.o >/dev/null 2>&1
depbase=`echo fnlz_mlc.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/bash ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H 
-I./include -I./include -I./libatomic_ops/src -I./l
ibatomic_ops/src  -fexceptions -Wall -Wextra -g -O2 -fno-strict-aliasing 
-MT fnlz_mlc.lo -MD -MP -MF $depbase.Tpo -c -o
fnlz_mlc.lo fnlz_mlc.c &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  gcc -DHAVE_CONFIG_H -I./include -I./include 
-I./libatomic_ops/src -I./libatomic_ops/src -fexceptions
-Wall -Wextra -g -O2 -fno-strict-aliasing -MT fnlz_mlc.lo -MD -MP -MF 
.deps/fnlz_mlc.Tpo -c fnlz_mlc.c  -fPIC -DPIC -o .
libtool: compile:  gcc -DHAVE_CONFIG_H -I./include -I./include 
-I./libatomic_ops/src -I./libatomic_ops/src -fexceptions
-Wall -Wextra -g -O2 -fno-strict-aliasing -MT fnlz_mlc.lo -MD -MP -MF 
.deps/fnlz_mlc.Tpo -c fnlz_mlc.c -o fnlz_mlc.o >/d
ev/null 2>&1
depbase=`echo libatomic_ops/src/atomic_ops.lo | sed 
/bin/bash ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H 
-I./include -I./include -I./libatomic_ops/src -I./l
ibatomic_ops/src  -fexceptions -Wall -Wextra -g -O2 -fno-strict-aliasing 
-MT libatomic_ops/src/atomic_ops.lo -MD -MP -MF
  $depbase.Tpo -c -o libatomic_ops/src/atomic_ops.lo 
libatomic_ops/src/atomic_ops.c &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  gcc -DHAVE_CONFIG_H -I./include -I./include 
-I./libatomic_ops/src -I./libatomic_ops/src -fexceptions
-Wall -Wextra -g -O2 -fno-strict-aliasing -MT 
libatomic_ops/src/atomic_ops.lo -MD -MP -MF libatomic_ops/src/.deps/atomic
_ops.Tpo -c libatomic_ops/src/atomic_ops.c  -fPIC -DPIC -o 
libtool: compile:  gcc -DHAVE_CONFIG_H -I./include -I./include 
-I./libatomic_ops/src -I./libatomic_ops/src -fexceptions
-Wall -Wextra -g -O2 -fno-strict-aliasing -MT 
libatomic_ops/src/atomic_ops.lo -MD -MP -MF libatomic_ops/src/.deps/atomic
_ops.Tpo -c libatomic_ops/src/atomic_ops.c -o 
libatomic_ops/src/atomic_ops.o >/dev/null 2>&1
make[1]: *** No rule to make target 'sparc_mach_dep.lo', needed by 
''.  Stop.
make[1]: Leaving directory '/odin/AUTORAN02/usr_local_src/add-on/gc-7.4.2'
Makefile:1716: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

I'm using the gc-7.4.2 tar file and libatomic_ops-7.4.2 and the first 
occurrence of sparc_mach_dep is in the No rule line.

I've search the mailing list archives and found other problems with this 
file, but no answers that fit.

Any ideas on how to assemble sparc_mach_dep.S?


Jim Ballantine