Am 21.03.25 um 15:21 schrieb Richard Biener:
On Fri, Mar 21, 2025 at 2:38 PM Georg-Johann Lay wrote:
Am 21.03.25 um 08:58 schrieb Richard Biener:
On Thu, Mar 20, 2025 at 8:05 PM Georg-Johann Lay via Gcc
wrote:
For avr, there is no support for shared objects, yet
when building libgcc
For avr, there is no support for shared objects, yet
when building libgcc, for each module.o there is also module_s.o
that's build with -DSHARED.
How can this be turned off?
What doesn't word is to configure with --disable-shared, and even
without turning it off by hand, there is
Am 21.03.25 um 08:58 schrieb Richard Biener:
On Thu, Mar 20, 2025 at 8:05 PM Georg-Johann Lay via Gcc
wrote:
For avr, there is no support for shared objects, yet
when building libgcc, for each module.o there is also module_s.o
that's build with -DSHARED.
How can this be turned off?
On Fri, Mar 21, 2025 at 2:38 PM Georg-Johann Lay wrote:
>
> Am 21.03.25 um 08:58 schrieb Richard Biener:
> > On Thu, Mar 20, 2025 at 8:05 PM Georg-Johann Lay via Gcc
> > wrote:
> >>
> >> For avr, there is no support for shared objects, yet
> >> whe
On Thu, Mar 20, 2025 at 8:05 PM Georg-Johann Lay via Gcc
wrote:
>
> For avr, there is no support for shared objects, yet
> when building libgcc, for each module.o there is also module_s.o
> that's build with -DSHARED.
>
> How can this be turned off?
>
> What does
Hi!
Seems libgcc mostly uses triplets after GCC_ in symbol version names in the
last few years (looking at GCC 5+):
find -name \*.ver -o -name \*.ver.in | xargs grep
'GCC_[156789][0-9]*\.[0-9]*\.[0-9]* '
./config/i386/libgcc-glibc.ver:%inherit GCC_12.0.0 GCC_7.0.0
./config/i
On 12/6/23 15:03, DJ Delorie wrote:
Alexandre Oliva writes:
This looks like a latent bug in the port.
I'm not surprised, that port was weird.
This was just a plain asm insn in strub.c:
/* Make sure the stack overwrites are not optimized away. */
asm ("" : : "m" (end[0]));
whose
Alexandre Oliva writes:
> This looks like a latent bug in the port.
I'm not surprised, that port was weird.
> This was just a plain asm insn in strub.c:
>
> /* Make sure the stack overwrites are not optimized away. */
> asm ("" : : "m" (end[0]));
>
> whose constraint passes during reload, r
[adding gcc@]
Hi, Jeff,
On Dec 6, 2023, Jeff Law wrote:
> libgcc is currently failing to build on rl78, looks like it might be
> strub related.
Thanks for letting me know.
>> /home/jlaw/test/gcc/libgcc/strub.c:149:1: error: unrecognizable insn:
>> 149 | }
>>
Hello,
under which license is libgcc/config/sparc/lb1spc.S? The header says:
/* This is an assembly language implementation of mulsi3, divsi3, and modsi3
for the sparc processor.
These routines are derived from the SPARC Architecture Manual,
version 8,
slightly edited to match the
ould detect and introduce the builtin where appropriate.
>
> Would this be acceptable, or am I wasting my time planning something
> that would get rejected?
So why not make it possible for the target to specify there's a libcall
for a specific optab so the vectorizer would simply us
On 22/03/2023 13:56, Richard Biener wrote:
Basically, the -ffast-math instructions will always be the fastest way,
but the goal is that the default optimization shouldn't just disable
vectorization entirely for any loop that has a divide in it.
We try to express division as multiplication, but
and integer),
> >> but amdgcn only has hardware instructions suitable for -ffast-math.
> >>
> >> We have recently implemented vector versions of all the libm functions,
> >> but the libgcc functions aren't builtins and therefore don't use those
> >>
all the libm functions,
but the libgcc functions aren't builtins and therefore don't use those
hooks.
What's the best way to achieve this? Add a new __builtin_div (and
__builtin_mod) that tree-vectorize can find, perhaps? Or something else?
What do you want to do? Vectorize the out
functions,
> but the libgcc functions aren't builtins and therefore don't use those
> hooks.
>
> What's the best way to achieve this? Add a new __builtin_div (and
> __builtin_mod) that tree-vectorize can find, perhaps? Or something else?
What do you want to do? Vec
Hi all,
I want to be able to vectorize divide operators (softfp and integer),
but amdgcn only has hardware instructions suitable for -ffast-math.
We have recently implemented vector versions of all the libm functions,
but the libgcc functions aren't builtins and therefore don't
On 21/06/2022 15:24, Jakub Jelinek wrote:
On Tue, Jun 21, 2022 at 03:13:19PM +0200, Sebastian Huber wrote:
Hello,
I noticed that several division related routines provided by libgcc such as
__divdi3, __moddi3 and __umoddi3 have references to _Unwind_Resume for the
sparc-rtems target. For
On Tue, Jun 21, 2022 at 03:13:19PM +0200, Sebastian Huber wrote:
> Hello,
>
> I noticed that several division related routines provided by libgcc such as
> __divdi3, __moddi3 and __umoddi3 have references to _Unwind_Resume for the
> sparc-rtems target. For example:
That is
Hello,
I noticed that several division related routines provided by libgcc such
as __divdi3, __moddi3 and __umoddi3 have references to _Unwind_Resume
for the sparc-rtems target. For example:
.file "libgcc2.c"
! GNU C17 (GCC) version 13.0.0 20220621 (experimental) [master
Hi all,
I'm backporting RISC-V support to GCC 4.6.4 in order to obtain a bootstrappable
GCC for RISC-V and I'm finding some issues I can't solve myself. Maybe you can
help.
I managed to backport the core of gcc, so now I can compile to assembly.
The problems came with the back
Hi!
On Fri, May 06, 2022 at 02:09:21PM +, Matthias Gehre via Gcc wrote:
> We would like to add support for division/modulo on large arbitrary precision
> integers to libgcc/compiler-rt
> as required by C23's _BitInt type [0].
>
> >From what I know, gcc doesn't
On Friday, May 6 2022, "Matthias Gehre" wrote to "lennox" saying:
> Jakub Jelinek wrote:
> > Rather than uint32_t, wouldn't using the word size (64-bit for lp64, 32-bit
> for ilp32) be better?
> Is there a portable way to specify this in C? (size_t, uintptr_t?) And is the
> word size
> clearly de
On Fri, 6 May 2022, Matthias Gehre via Gcc wrote:
> > This proposed interface doesn't say anything about what aliasing is or
> > isn't permitted among the four arrays pointed to.
> Good catch. I would lean into saying that none of the four arrays must alias
> because allowing them to alias would r
> Note that each architecture also needs to specify its _BitInt ABI
> (including such things as whether the values of padding bits inside the
> size of the _BitInt type, or outside that size but within a register used
> for argument passing or return, have specified values or are arbitrary).
> HJ h
On Fri, May 06, 2022 at 02:09:21PM +, Matthias Gehre via Gcc wrote:
> /// \param quo The quotient represented by n words. Must be non-null.
> /// \param rem The remainder represented by n words. Must be non-null.
> /// \param a The dividend represented by n + 1 words. Must be non-null.
> /// \p
uted the value itself), even in the absence of
needing to allocate extra memory or allowing the libgcc function to write
to those arrays, or you need to pass in a width in bits (rather than a
number of words) to the libgcc function so that it can tell which bits are
padding.
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, May 06, 2022 at 02:09:21PM +, Matthias Gehre via Gcc wrote:
> /// \param quo The quotient represented by n words. Must be non-null.
> /// \param rem The remainder represented by n words. Must be non-null.
> /// \param a The dividend represented by n + 1 words. Must be non-null.
> /// \p
On Fri, 6 May 2022, Matthias Gehre via Gcc wrote:
> We would like to add support for division/modulo on large arbitrary
> precision integers to libgcc/compiler-rt as required by C23's _BitInt
> type [0].
Note that each architecture also needs to specify its _BitInt ABI
(includi
Hello!
We would like to add support for division/modulo on large arbitrary precision
integers to libgcc/compiler-rt
as required by C23's _BitInt type [0].
>From what I know, gcc doesn't yet support C23 _BitInt, but we would still
like to ensure that libgcc and compiler-rt can stay
Hi,
Are there some history or reason for this design ?
I think it’s clear & simple to keep coherent logic,
namely that there should be libgcc_eh.a for exceptions :)
Add Makefile.in segment of libgcc as following:
# Build LIB2ADDEH, LIB2ADDEHSTATIC,
Hi
The unwind code initializes an object_mutex, but it is never destroyed.
On VxWorks 5 at least, that's a problem, because it means that module
load+unload leaks a resource. I don't know about other VxWorks versions.
I'm wondering what the best fix is (insofar as upstream gcc wants to fix
it, we
t; > >> Hi,
> > >>
> > >> It was pointed out to me off-list that config/aarch64/value-unwind.h
> > >> is missing the runtime exception. It looks like a few other files
> > >> are too; a fuller list is:
> > >>
> > >> l
ue-unwind.h
> >> is missing the runtime exception. It looks like a few other files
> >> are too; a fuller list is:
> >>
> >> libgcc/config/aarch64/value-unwind.h
> >> libgcc/config/frv/frv-abi.h
> >> libgcc/config/i386/value-unwind.h
> >>
David Edelsohn writes:
> On Fri, Jul 9, 2021 at 12:53 PM Richard Sandiford via Gcc
> wrote:
>>
>> Hi,
>>
>> It was pointed out to me off-list that config/aarch64/value-unwind.h
>> is missing the runtime exception. It looks like a few other files
>> are
On Fri, Jul 9, 2021 at 12:53 PM Richard Sandiford via Gcc
wrote:
>
> Hi,
>
> It was pointed out to me off-list that config/aarch64/value-unwind.h
> is missing the runtime exception. It looks like a few other files
> are too; a fuller list is:
>
> libgcc/config/aarch64
Hi,
It was pointed out to me off-list that config/aarch64/value-unwind.h
is missing the runtime exception. It looks like a few other files
are too; a fuller list is:
libgcc/config/aarch64/value-unwind.h
libgcc/config/frv/frv-abi.h
libgcc/config/i386/value-unwind.h
libgcc/config/pa/pa64-hpux
On Thu Aug 13, 2020 at 2:50 PM CEST, Jakub Jelinek wrote:
> And unfortunately the functions that add the .globl directives for the
> calls
> are done at expansion time rather than only based on what calls survive
> through the RTL optimizations.
Thanks a lot Jakub for the explanation!
> Or why we
On Thu, Aug 13, 2020 at 02:33:50PM +0200, Tobias Wölfel via Gcc wrote:
> I observed that in some ELF files there is code present which is not used.
> It originates from integer arithmetics.
> The following snipped should help to demonstrate the problem.
It is there because the division in this ca
Hi,
I observed that in some ELF files there is code present which is not used.
It originates from integer arithmetics.
The following snipped should help to demonstrate the problem.
I have the function in the file foo.c:
```
unsigned long long foo(unsigned long a, unsigned long b)
{
retur
gthr-vxworks-thread.c fails to compile for vxworks 5.x:
libgcc/config/gthr-vxworks-thread.c:268:14: error: 'VX_USR_TASK_OPTIONS'
undeclared (first use in this function)
268 | options &= VX_USR_TASK_OPTIONS;
| ^~~~~~~
libgcc/config/gthr-vxworks-
(we simply use the definitions which are provided in
contrib/gthr_supp_vxw_5x.c), so we can fix this by nop'ing out
VX_ENTER_TLS_DTOR/VX_LEAVE_TLS_DTOR for vxworks 5.x.
---
libgcc/config/gthr-vxworks-tls.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libgcc/config/gthr-vxworks-tl
The vxworks-cond.c file fails to compile for vxworks 5.x:
libgcc/config/gthr-vxworks-cond.c:29:
./gthr-default.h:274:3: error: unknown type name 'TASK_ID'
274 | TASK_ID task_id;
| ^~~
There is a TASK_ID typedef in our system headers, but (1) is is
commented out, (2) liv
On Thu, Dec 19, 2019 at 04:08:39PM -0800, Ian Lance Taylor wrote:
> On Wed, Dec 18, 2019 at 7:58 AM Segher Boessenkool
> wrote:
> >
> > On Sun, Dec 15, 2019 at 09:43:20AM -0800, Ian Lance Taylor wrote:
> > > On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool
> > > wrote:
> > > >
> > > > On Sat,
ce Taylor via gcc wrote:
> > > > I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu,
> > > > cross-compiling from x86_64-pc-linux-gnu. I'm at SVN revision 279830.
> > > > I'm seeing the following. Is anybody else seeing this c
On Sun, Dec 15, 2019 at 09:43:20AM -0800, Ian Lance Taylor wrote:
> On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool
> wrote:
> >
> > On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote:
> > > I'm seeing compiler crashes building
On Sun, Dec 15, 2019 at 09:43:20AM -0800, Ian Lance Taylor wrote:
> On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool
> wrote:
> >
> > On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote:
> > > I'm seeing compiler crashes building
On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool
wrote:
>
> On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote:
> > I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu,
> > cross-compiling from x86_64-pc-linux-gnu. I'm at
On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote:
> I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu,
> cross-compiling from x86_64-pc-linux-gnu. I'm at SVN revision 279830.
> I'm seeing the following. Is anybody else seeing
On Sat, Dec 14, 2019 at 10:51 AM Ian Lance Taylor wrote:
>
> I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu,
> cross-compiling from x86_64-pc-linux-gnu. I'm at SVN revision 279830.
> I'm seeing the following. Is anybody else seeing this crash?
I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu,
cross-compiling from x86_64-pc-linux-gnu. I'm at SVN revision 279830.
I'm seeing the following. Is anybody else seeing this crash? Thanks.
Ian
/tmp/go-build-release/gccgo-objdir/ppc/./gcc/xgcc
-B/tmp/go-buil
atively quickly.
With my modified libgcc, when the two fields are missing, I use the
cache to provide a "load base hint". I then do the ordinary module
scan, but I exit early if dl_phdr_info::dlpi_addr doesn't match the
hint. Unless a module has been unloaded, this first pass should f
On 13/11/2018 21:20, Stafford Horne wrote:
On Tue, Nov 13, 2018 at 11:57:13AM -0600, Joel Sherrill wrote:
Sebastian confirmed he couldn't get a complete RTEMS build either.
I looked into this enough to spot that old or1k port's libgcc/config.host
has an extra_parts line for or1k-*-
s
>> 417e50dbcfd4b8dd699f48df5ac9b9a733fd80e2. It failed in the libgcc build:
>>
>> /scratch/git-rtems-source-builder/rtems/build/or1k-rtems5-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d-newlib-2ab57ad59bc35dafffa69cd4da5e228971de069f-x86_64-linux-gnu-1/build/./gcc/xgcc
>
Hello Stafford,
I tried to build the or1k-rtems5 target with GCC
4c0c3d1029e79b6709b43fed8c5a5944f245516d and Binutils
417e50dbcfd4b8dd699f48df5ac9b9a733fd80e2. It failed in the libgcc build:
/scratch/git-rtems-source-builder/rtems/build/or1k-rtems5-gcc
> On May 31, 2018, at 12:35 PM, Joseph Myers wrote:
>
> On Tue, 29 May 2018, Paul Koning wrote:
>
>> Question about proper target maintainer procedures...
>>
>> The pdp11 target needs udivhi3 in libgcc. There's udivsi3, and it's
>> really e
On Tue, 29 May 2018, Paul Koning wrote:
> Question about proper target maintainer procedures...
>
> The pdp11 target needs udivhi3 in libgcc. There's udivsi3, and it's
> really easy to tweak those files for HImode. And that works.
>
> Should I add the HI files
Question about proper target maintainer procedures...
The pdp11 target needs udivhi3 in libgcc. There's udivsi3, and it's really
easy to tweak those files for HImode. And that works.
Should I add the HI files to the libgcc directory, or under config/pdp11?
There's nothing
Today I get an ICE during configuration of libgcc in stage 2 on
x86_64-w64-mingw32. That's rev. 257390.
configure:3688:
/opt/devel/SCRATCH/tmp.Sbg1TmFqa7/gcc-8.0.0/gcc-8.0.0/./gcc/xgcc
-B/opt/devel/SCRATCH/tmp.Sbg1TmFqa7/gcc-8.0.0/gcc-8.0.0/./gcc/
-L/opt/devel/gnu/gcc/MINGW_NT/x86_6
Adds libgcc/config/i386/i386-asm.h to manage common cpp and gas macros. Adds
assembly stubs. stubs use the following naming convention:
(sav|res)ms64[f][x]
save|resSave or restore
ms64Avoid possible name collisions with future stubs
(specific to 64-bit
On Fri, Nov 4, 2016 at 8:12 AM, lei wang wrote:
>
> Thanks. One more question, my current entry point of the program is
> main, after which there is a call to __main to do the constructor
> stuffs and register destructors. Without INVOKE__main, which point
> should I define as the entry?
You shou
Thanks. One more question, my current entry point of the program is
main, after which there is a call to __main to do the constructor
stuffs and register destructors. Without INVOKE__main, which point
should I define as the entry?
Lei
2016-11-04 11:06 GMT-04:00 Ian Lance Taylor :
> On Fri, Nov 4
On Fri, Nov 4, 2016 at 7:55 AM, lei wang wrote:
>
> In fact, I just want to find a practical way to make the crt work.
> Currently, I did the following configure in my port:
>
> include "elfos.h" in tm.h
> define HAS_INIT_SECTION
> undefine OBJECT_FORMAT_ELF
> define INVOKE__main
> use default INI
brief structure of libgcc/crtstuff.c is as follows:
>>
>> #ifdef CRT_BEGIN
>> …
>> #elif defined(CRT_END)
>> ...
>> # ifdef OBJECT_FORMAT_ELF
>> …
>> # else
>>
>> static void
>> __do_global_ctors_aux (void)/* prologue goes in .text
On Thu, Nov 3, 2016 at 7:20 PM, Lei Wang wrote:
> The brief structure of libgcc/crtstuff.c is as follows:
>
> #ifdef CRT_BEGIN
> …
> #elif defined(CRT_END)
> ...
> # ifdef OBJECT_FORMAT_ELF
> …
> # else
>
> static void
> __do_global_ctors_aux (void)
The brief structure of libgcc/crtstuff.c is as follows:
#ifdef CRT_BEGIN
…
#elif defined(CRT_END)
...
# ifdef OBJECT_FORMAT_ELF
…
# else
static void
__do_global_ctors_aux (void)/* prologue goes in .text section */
{
asm (__LIBGCC_INIT_SECTION_ASM_OP__);
DO_GLOBAL_CTORS_BODY;
atexit
On 07/15/2015 02:58 PM, Jeff Law wrote:
On 07/15/2015 08:33 AM, Andrew MacLeod wrote:
Maybe if gthr-default already existed (as well as config.status), the
makefile would spawn the libgcov-interface.c object builds... meanwhile
a reconfigure is going which ends up overwriting gthr-default.h at
On 07/15/2015 08:33 AM, Andrew MacLeod wrote:
Oh, wait. this isnt on a scratch build this time, this is on an
incremental rebuild I just noticed (I was doing stuff on multiple
machines, turn out the other one was a scratch build)
make -j16 from the root build directory.
and it may have happened
failure in libgcc when doing a scratch
build (onx86_64-unknown-linux-gnu) , and if I simply do another make,
it works fine. I am always building with make -j16, so its never been
easy to spot.
This morning, it happened to fail in such a way that I can sort of see
whats going on for a change
I occasionally get a build failure in libgcc when doing a scratch build
(onx86_64-unknown-linux-gnu) , and if I simply do another make, it works
fine. I am always building with make -j16, so its never been easy to spot.
This morning, it happened to fail in such a way that I can sort of see
On Wed, 1 Jul 2015, Zinovy Nis wrote:
> Had anyone a chance to compare FP implementation in compiler_rt? I
> still wonder why the sizes differ so much, Incomplete implementation
> in compiler_rt?
> compiler_rt claims it is IEEE-compliant.
If you examine the implementation approaches, you will see
On 01/07/15 16:34, Zinovy Nis wrote:
> The only idea on size difference I have is:
>
> headers text in many of FP-emulation files from compiler_rt contains lines
> like:
>
> // This file implements quad-precision soft-float addition ***with the
> IEEE-754 default rounding*** (to nearest, ties to
ze with
>>>
>>> #ifdef __OPTIMIZE_SIZE__
>>> #else
>>> #endif
>>
>> I don't think there's any low-hanging fruit for size optimization. If you
>> wanted to save that 6 or 7 kB (total, across all the float and double code
>> in lib
t; #else
>> #endif
>
> I don't think there's any low-hanging fruit for size optimization. If you
> wanted to save that 6 or 7 kB (total, across all the float and double code
> in libgcc, as compared to fp-bit or ieeelib and mentioned in the Summit
> paper) you&#x
t; #ifdef __OPTIMIZE_SIZE__
> #else
> #endif
I don't think there's any low-hanging fruit for size optimization. If you
wanted to save that 6 or 7 kB (total, across all the float and double code
in libgcc, as compared to fp-bit or ieeelib and mentioned in the Summit
paper) you
hat __float128 support in libgcc uses the hardware exceptions and
rounding modes when available), not for size (and generality takes
precedence over speed where they conflict, hence being a bit slower than
ieeelib even after the 2006 optimization work).
soft-fp is expected to be used on 32-bit and
e) and for generality
> (it's used in the Linux kernel for floating-point emulation, where you
> want to follow the same choice of NaN etc. as a particular processor even
> where IEEE semantics don't specify a particular choice, and it has
> optional support for floating-point e
you
want to follow the same choice of NaN etc. as a particular processor even
where IEEE semantics don't specify a particular choice, and it has
optional support for floating-point exceptions and rounding modes - note
that __float128 support in libgcc uses the hardware exceptions and
round
On Tue, Jun 30, 2015 at 4:33 AM, Zinovy Nis wrote:
> Hi.
>
>
> I'm building libgcc for a "iamcu" target (Pentium-like but with
> soft-fp emulation, the only x86 with SoftFP I know) with
> --enable-target-optspace.
Support for i?86*-*-elfiamcu target has been
Hi.
I'm building libgcc for a "iamcu" target (Pentium-like but with
soft-fp emulation, the only x86 with SoftFP I know) with
--enable-target-optspace.
It works properly but I noticed that code the size for many arithmetic
functions is much more larger than for soft-fp emulat
Hi
I noticed the arm-rtems (and I assume arm-eabi) have these warnings
about calloc() and realloc(). Can this file include stdlib.h to resolve
this?
../../../gcc/libgcc/emutls.c: In function '__emutls_get_address':
../../../gcc/libgcc/emutls.c:159:13: warning: implicit declaration o
I noticed that there are three symbols in libgcc with no leading __:
isinfd32, isinfd64, isinfd128. Is there any reason for that? As far
as I can see GCC will never generate calls to those functions
(especially because PR 43374 means that the isinf macro doesn't
currently work for de
Hello,
Question:
Were any changes to the compile/link process...specifically ones
related to dlopen...for libgcc between versions 4.8.x and 4.9.x?
Background:
I was successfully able to bootstrap 4.8.0 from 4.7.0 on an Android
tablet. When I attempt to do the same...or when I attempt to upgrade
the weakref magic in libgcc/gthr-posix.h is not guaranteed to work
which can at least break libstdc++ with static linking and dlopen
there are several bugs here:
- fallback code (unknown posix systems) should assume multi-threaded
application instead of using a fragile threadedness test
On 11/5/2014 11:10 AM, DJ Delorie wrote:
> Last time you mentioned this, I asked what the contents of that
> config.log were...
I thought I posted it. Anyway, here is the m32c-rtems and h8300-rtems
libgcc config.logs.
It looks more obvious now. Both targets have an ICE compiling
the au
Last time you mentioned this, I asked what the contents of that
config.log were...
Hi
h8300-rtems and m32c-rtems both fail in libgcc during the configure
probes of make.
configure: WARNING: decimal float is not supported for this target, ignored
checking whether fixed-point is supported... no
checking whether to use setjmp/longjmp exceptions... unknown
configure: error: unable
Hi
It looks like the check for SJLJ use by a target starting at line
211 in libgcc/configure.ac does not take into account whether
the build included a language that needs this. For RTEMS,
we build m32c with only C and this check not being guarded
results in needing to provide --disable-sjlj
Joel Sherrill writes:
> On 9/3/2014 1:24 PM, Jeff Law wrote:
>> On 09/03/14 09:56, Bernhard Reutner-Fischer wrote:
>>> Perhaps m5206 is not TARGET_CAS and should not compile this linux-atomic
>>> in the first place?
>> No, I don't think so.
> Coldfire does not have the CAS instruction per
> http:
On 9/3/2014 1:24 PM, Jeff Law wrote:
> On 09/03/14 09:56, Bernhard Reutner-Fischer wrote:
>> Trying to bootstrap m68k i hit an assert in emit_library_call_value_1
>> that wants to assure that the stack is aligned properly.
>>
>> PUSH_ROUNDING(GET_MODE_SIZE(QImode)) for m5206 is currently 1 so
>> t
On 09/03/14 09:56, Bernhard Reutner-Fischer wrote:
Trying to bootstrap m68k i hit an assert in emit_library_call_value_1
that wants to assure that the stack is aligned properly.
PUSH_ROUNDING(GET_MODE_SIZE(QImode)) for m5206 is currently 1 so
the testcase below has stack_pointer_delta = 1 + 1 +
first place?
(is emit_library_call_value_1 missing a do_pending_stack_adjust() before
NO_DEFER_POP ? Does not seem relevant for this case though)
Slightly simplified reproducer:
$ cat x.i ; echo "EOF"; # see libgcc/config/m68k/linux-atomic.c
unsigned char
__attribute__ ((visibility ("hidden")))
_
*, so it may take
years to show up in mainline.
Thanks,
Joey
On Mon, Aug 4, 2014 at 2:40 PM, Mallikarjun Goudar
wrote:
> Hi All,
>
> sorry, sending previous mail with proper subject line.
>
> For cortex-m0 (armv6-m) target, i observed that ieee floating-point
> functions under libg
Hi All,
sorry, sending previous mail with proper subject line.
For cortex-m0 (armv6-m) target, i observed that ieee floating-point
functions under libgcc are implemented in C.
This takes lot of memory if one uses floating-point in their
applciations. I agree that usage of fp in cortex-m0 devices
Hi All,
For cortex-m0 (armv6-m) target, i observed that ieee floating-point
functions under libgcc are implemented in C.
This takes lot of memory if one uses floating-point in their
applcations. I agree that usage of fp in cortex-m0 devices might be
minimal.
I wanted to check if its good idea to
On 21 May 2014 14:13, Sheheryar Zahoor Qazi
wrote:
>>>Building libgcc is not optional. It is required for all targets.
>
> So, irrespective whether i provide floating point implementation by
> soft-fp, fpu-bit or ieeelib, an error free libgcc build is a MUST?
>
> What if
On Wed, May 21, 2014 at 6:13 AM, Sheheryar Zahoor Qazi
wrote:
>>>Building libgcc is not optional. It is required for all targets.
>
> So, irrespective whether i provide floating point implementation by
> soft-fp, fpu-bit or ieeelib, an error free libgcc build is a MUST?
Yes.
>>Building libgcc is not optional. It is required for all targets.
So, irrespective whether i provide floating point implementation by
soft-fp, fpu-bit or ieeelib, an error free libgcc build is a MUST?
What if I dont want to generate calls to libgcc.a but want want gcc to
generate inlin
On Tue, May 20, 2014 at 10:47 PM, Ian Lance Taylor wrote:
> On Tue, May 20, 2014 at 12:51 PM, Sheheryar Zahoor Qazi
> wrote:
>> Hi again!
>>
>>>>You need to look in target-arch/libgcc/config.log to see what the
>>>>problem is.
>> config.log states
On Tue, May 20, 2014 at 7:37 AM, Sheheryar Zahoor Qazi
wrote:
>>>If you have a working compiler that is missing some functions
>>>provided by libgcc, that should be sufficient to build libgcc.
> Meaning that even if i am unable build libgcc to my new architecture,
> I s
>>If you have a working compiler that is missing some functions
>>provided by libgcc, that should be sufficient to build libgcc.
Meaning that even if i am unable build libgcc to my new architecture,
I should be able to able to provide soft-fp support to the
architecture?
Btw i get t
1 - 100 of 376 matches
Mail list logo
