Hello,
On Thu, 12 Nov 2020, Stefan Kanthak wrote:
> Does GCC generate (unoptimised) code there, similar to the following i386
> assembly, using 4 loads, 4 shifts, 2 ands plus 3 ors?
Try for yourself. '-m32 -O2 -march=i386' is your friend.
Ciao,
Michael.
Spoiler: it's generating:
mov
libgcc2.c defines __bswapsi2() as follows:
typedef int SItype __attribute__ ((mode (SI)));
SItype
__bswapsi2 (SItype u)
{
return u) & 0xff00) >> 24)
| (((u) & 0x00ff) >> 8)
| (((u) & 0xff00) << 8)
| (((u) & 0x00ff) <<
libgcc2 provides "double-word" division as __udivmoddi4()
The following part of its source
| UWtype d0, d1, n0, n1, n2;
| UWtype b, bm;
...
| count_leading_zeros (bm, d1);
| if (bm == 0)
...
| else
| {
| UWtype m1, m0;
| /* Normalize. */
|
| b = W_TYPE
Hello,
the file libgcc/gthr.h defines the interface for the thread support used
by libgcc2 and C11. A couple of types are required, e.g.
__gthread_key_t
Is it allowed to copy objects of this type? For example is the
following a valid use case
__gthread_key_t k1
This error occurs if you configure GCC as cross compiler and
$ make
$ make clean-target-libgcc
$ make all-target-libgcc
./libgcc/libgcc2.c:32:23: fatal error: libgcc_tm.h: No such file or directory
Removing the $target directory altogether works:
$ make
$ rm -rf $target
$ make # rebuilds
On 21/06/11 19:01, Ian Lance Taylor wrote:
CFLAGS.
CFLAGS_FOR_BUILD is for code compiled for the build system. CFLAGS is
for code compiled for the host system. CFLAGS_FOR_TARGET is for code
compiled for the target system. The driver and the compiler as a whole
run on the host system. The bu
"Paulo J. Matos" writes:
> Which flag (like CFLAGS_FOR_BUILD) can I use that is passed in the
> command line to compile the driver?
CFLAGS.
CFLAGS_FOR_BUILD is for code compiled for the build system. CFLAGS is
for code compiled for the host system. CFLAGS_FOR_TARGET is for code
compiled for t
you could make it the default or you could add it to
DRIVER_SELF_SPECS. Or did you just mean that you always need it for
libgcc2 but not for user code?
My backend as two 'compilation modes' (the generated code differs slightly).
I added a define into the command line by doing
m
OPTS=-mas-mode in my t- makefile fragment?
Yes.
Alternatively, you implied that your backend always needs this option.
In that case you could make it the default or you could add it to
DRIVER_SELF_SPECS. Or did you just mean that you always need it for
libgcc2 but not for user code?
Ian
MULTILIBS. However, there's a flag
that I want all the LIBGCC2 built with. That's a special flag for my
backend -mas-mode. I added this to TARGET_LIBGCC2_FLAGS, however,
libgcc/configure is not passing this flag to the configure programs and
configure simply flags.
I noticed that i
"Paulo J. Matos" writes:
> There are some flags that are needed by the target to build libgcc2. I
> am keeping those in TARGET_LIBGCC2_FLAGS. However, compilation is
> failed even before the building begins because configure fails. While
> trying to compile test progr
Hi,
There are some flags that are needed by the target to build libgcc2. I
am keeping those in TARGET_LIBGCC2_FLAGS. However, compilation is failed
even before the building begins because configure fails. While trying to
compile test programs configure is using TARGET_LIBGCC2_FLAGS.
This
Eggenmüller Bernd writes:
> Andrew Pinski schrieb:
>> On Thu, May 13, 2010 at 8:46 AM, Eggenmüller Bernd wrote:
>>
>>> Is there any implementation with less registers like this.
>>>
>>
>> libgcc2 is written in C; so if it fails to compile you
Andrew Pinski schrieb:
On Thu, May 13, 2010 at 8:46 AM, Eggenmüller Bernd wrote:
Is there any implementation with less registers like this.
libgcc2 is written in C; so if it fails to compile you need to fix up
your backend. There might need some middle-end fixes too with this
small
Andrew Pinski schrieb:
On Thu, May 13, 2010 at 8:46 AM, Eggenmüller Bernd wrote:
Is there any implementation with less registers like this.
libgcc2 is written in C; so if it fails to compile you need to fix up
your backend. There might need some middle-end fixes too with this
small
On Thu, May 13, 2010 at 8:46 AM, Eggenmüller Bernd wrote:
> Is there any implementation with less registers like this.
libgcc2 is written in C; so if it fails to compile you need to fix up
your backend. There might need some middle-end fixes too with this
small number of registers used.
Ian Lance Taylor schrieb:
Eggenmüller Bernd writes:
Ian Lance Taylor schrieb:
Eggenmüller Bernd writes:
is it possible to translate the libgcc2 when i only have 4 registers
which are 32 bits long.
One of the four Registers is defined as Basepointer and another as
Eggenmüller Bernd writes:
> is it possible to translate the libgcc2 when i only have 4 registers
> which are 32 bits long.
> One of the four Registers is defined as Basepointer and another as
> Stackpointer.
> The other two can be used to calculate.
libgcc2 is intended to be mach
Hi all,
is it possible to translate the libgcc2 when i only have 4 registers
which are 32 bits long.
One of the four Registers is defined as Basepointer and another as
Stackpointer.
The other two can be used to calculate.
Reegards
Egge
On Thu, Mar 19, 2009 at 8:25 PM, Kai Tietz wrote:
> 2009/3/19 Ozkan Sezer :
>> On Thu, Mar 19, 2009 at 8:04 PM, Vincent R. wrote:
>>> On Thu, 19 Mar 2009 19:58:13 +0200, Ozkan Sezer wrote:
I'm a bit amazed that the prototype for VirtualProtect() is known to the
compiler but the definit
2009/3/19 Ozkan Sezer :
> On Thu, Mar 19, 2009 at 8:04 PM, Vincent R. wrote:
>> On Thu, 19 Mar 2009 19:58:13 +0200, Ozkan Sezer wrote:
>>> I'm a bit amazed that the prototype for VirtualProtect() is known to the
>>> compiler but the definition of DWORD is not.. In any case, it should be
>>> fixed
Ozkan Sezer wrote:
> On Thu, Mar 19, 2009 at 8:04 PM, Vincent R. wrote:
>> However you are wrong about DWORD definition it has always be defined
>> like this :
>>
>> typedef unsigned long DWORD, *PDWORD, *LPDWORD;
>>
>> at least windows.
>>
>
> A DWORD on windows is an unsigned 32 bit integer, t
On Thu, Mar 19, 2009 at 8:04 PM, Vincent R. wrote:
> On Thu, 19 Mar 2009 19:58:13 +0200, Ozkan Sezer wrote:
>> I'm a bit amazed that the prototype for VirtualProtect() is known to the
>> compiler but the definition of DWORD is not.. In any case, it should be
>> fixed easily by changing DWORD into
On Thu, 19 Mar 2009 19:58:13 +0200, Ozkan Sezer wrote:
> I'm a bit amazed that the prototype for VirtualProtect() is known to the
> compiler but the definition of DWORD is not.. In any case, it should be
> fixed easily by changing DWORD into unsigned int which is what a
> DWORD is always defined a
I'm a bit amazed that the prototype for VirtualProtect() is known to the
compiler but the definition of DWORD is not.. In any case, it should be
fixed easily by changing DWORD into unsigned int which is what a
DWORD is always defined as. And PR 39063 is still open anyway.
--
Ozkan
On Thu, Mar 19, 2009 at 7:49 AM, Vincent R. wrote:
> Hi,
>
> I tried to generate a cross-compiler from trunk a few hours ago and I have
> noticed that
> libgcc2.c doesn't compile anymore because of the following function :
It is caused by:
http://gcc.gnu.org/ml/gcc-patches/2
Hi,
I tried to generate a cross-compiler from trunk a few hours ago and I have
noticed that
libgcc2.c doesn't compile anymore because of the following function :
int
mprotect (char *addr, int len, int prot)
{
DWORD np, op;
if (prot == 7)
np = 0x40;
else if (prot == 5)
np =
Sandra Loosemore <[EMAIL PROTECTED]> writes:
> #6 0x0875dc03 in rest_of_handle_combine ()
> at /scratch/sandra/mips-mainline/src/gcc-mainline/gcc/combine.c:1264
The bug is that reg_stat in combine.c does not reallocate when a
splitter creates a new pseudo_reg. I'm working on a patch to con
Sandra Loosemore <[EMAIL PROTECTED]> writes:
> #6 0x0875dc03 in rest_of_handle_combine ()
> at /scratch/sandra/mips-mainline/src/gcc-mainline/gcc/combine.c:1264
>
> ...
>
> Looks like a job for valgrind? But I'm out of time for working on
> this, at least for now. Can anyone else take a stab
Ian Lance Taylor wrote:
Sandra Loosemore <[EMAIL PROTECTED]> writes:
I'm now at revision 126547, and am getting a different ICE when
building the same configuration:
/scratch/sandra/mips32-mainline/src/gcc-mainline/libstdc++-v3/src/locale.cc:
In member function 'std::string std::locale::name
Sandra Loosemore <[EMAIL PROTECTED]> writes:
> I'm now at revision 126547, and am getting a different ICE when
> building the same configuration:
> /scratch/sandra/mips32-mainline/src/gcc-mainline/libstdc++-v3/src/locale.cc:
> In member function 'std::string std::locale::name() const':
> /scratch
Ian Lance Taylor wrote:
Sandra Loosemore <[EMAIL PROTECTED]> writes:
The error reported here
http://gcc.gnu.org/ml/gcc/2007-07/msg00339.html
is also happening when building for target mipsisa32r2-elfoabi on
i686-pc-linux-gnu.
This should be fixed by revision 126536. Sorry for the problems
Sandra Loosemore <[EMAIL PROTECTED]> writes:
> The error reported here
>
> http://gcc.gnu.org/ml/gcc/2007-07/msg00339.html
>
> is also happening when building for target mipsisa32r2-elfoabi on
> i686-pc-linux-gnu.
This should be fixed by revision 126536. Sorry for the problems.
Ian
The error reported here
http://gcc.gnu.org/ml/gcc/2007-07/msg00339.html
is also happening when building for target mipsisa32r2-elfoabi on
i686-pc-linux-gnu.
-Sandra
On Sun, Feb 11, 2007 at 01:09:40PM -0800, H. J. Lu wrote:
> On Sun, Feb 11, 2007 at 05:11:15PM +0100, Hanno Meyer-Thurow wrote:
> > On 07 Feb 2007 15:36:14 -0800
> > Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> >
> > > Can anybody else out there recreate this on their x86_64 system?
> >
> > Not
On Sun, Feb 11, 2007 at 05:11:15PM +0100, Hanno Meyer-Thurow wrote:
> On 07 Feb 2007 15:36:14 -0800
> Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> > Can anybody else out there recreate this on their x86_64 system?
>
> Not that I could not recreate the segfault but I found a way to hide the
> s
On 07 Feb 2007 15:36:14 -0800
Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Can anybody else out there recreate this on their x86_64 system?
Not that I could not recreate the segfault but I found a way to hide the
segfault. Instead of optimizing with nocona
make \
LDFLAGS
On 07 Feb 2007 15:36:14 -0800
Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Hanno Meyer-Thurow <[EMAIL PROTECTED]> writes:
>
> > sorry to bother again. I reduced the code (attached) that segfaults here
> > on Core 2 Duo [1]. If I add -fno-split-wide-types the code does not
> > segfault.
> > That
Hanno Meyer-Thurow <[EMAIL PROTECTED]> writes:
> sorry to bother again. I reduced the code (attached) that segfaults here
> on Core 2 Duo [1]. If I add -fno-split-wide-types the code does not segfault.
> That flag comes from your patchset [2].
>
> execute:
> # ./cc1 -quiet -m64 -O1 test.c -o tes
On 07 Feb 2007 13:46:43 -0800
Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> * lower-subreg.c (resolve_clobber): Handle a subreg of a concatn.
Yes, that is there. I have revision 121690.
Hanno
Hanno Meyer-Thurow <[EMAIL PROTECTED]> writes:
> Hi Ian,
> sorry to bother again. I reduced the code (attached) that segfaults here
> on Core 2 Duo [1]. If I add -fno-split-wide-types the code does not segfault.
> That flag comes from your patchset [2].
>
> execute:
> # ./cc1 -quiet -m64 -O1 tes
Hi Ian,
sorry to bother again. I reduced the code (attached) that segfaults here
on Core 2 Duo [1]. If I add -fno-split-wide-types the code does not segfault.
That flag comes from your patchset [2].
execute:
# ./cc1 -quiet -m64 -O1 test.c -o test.o
Any ideas?
Regards,
Hanno
[1] http://gcc.gnu
/work/gcc/libgcc/../libdecnumber
-I../../libdecnumber -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep
-DL_muldi3 -c
/mnt/data/tmp/portage/dev-java/gcj-4.3.0_alpha20070202/work/gcc/libgcc/../gcc/libgcc2.c
\
-fvisibility=hidden -DHIDE_EXPORTS
/mnt/data/tmp/portage/dev-jav
-I.
> -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
> -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber
> -I../libdecnumber -DL_mulvdi3 -fvisibility=hidden -DHIDE_EXPORTS -c
> ../../gcc/gcc/libgcc2.c -o libgcc/./_mulvdi3.o
> ../../gc
/include -I../../gcc/gcc/../libdecnumber
-I../libdecnumber -DL_mulvdi3 -fvisibility=hidden -DHIDE_EXPORTS -c
../../gcc/gcc/libgcc2.c -o libgcc/./_mulvdi3.o
../../gcc/gcc/libgcc2.c:382: internal compiler error: in
prune_unused_types_update_strings, at dwarf2out.c:14009
Please submit a full bug report
d I am trying to do, when
libgcc2.c is compled with -DL_floatdidf, instead of defining a
routine called _floatdidf or __floatdidf, it creates a routine called
__floattidf which references __floatdidf.
...
This is on an RS/6000 AIX 5.3. I'm trying to compile gcc 4.0.2. I
have mucked with
Perry Smith <[EMAIL PROTECTED]> writes:
> The problem: In the particular build I am trying to do, when
> libgcc2.c is compled with -DL_floatdidf, instead of defining a
> routine called _floatdidf or __floatdidf, it creates a routine called
> __floattidf which references __float
I'm not sure how to present all this so bear with me:
The problem: In the particular build I am trying to do, when
libgcc2.c is compled with -DL_floatdidf, instead of defining a
routine called _floatdidf or __floatdidf, it creates a routine called
__floattidf which references __floa
Original Message
>From: Eric Fisher
>Sent: 01 September 2005 09:43
> Hello,
>
> Here is a question about porting gcc. After I modified machine.md and
> other backend files, I can make cc1 and xgcc now. But libgcc2.o still
> failed. I'd like to know does we mus
Hello,
Here is a question about porting gcc. After I modified machine.md and
other backend files, I can make cc1 and xgcc now. But libgcc2.o still
failed. I'd like to know does we must make libgcc2.o since the target
machine don't have float registers and 64bit registers.
Thanks a lot.
Eric
Sorry if this should be obvious, but:
- which integer target types are required to be supported by libgcc2's
trapping arithmetic implementation? (i.e. are all supported integer
types required to have arithmetic trapping operation counterparts?)
- under what circumstances are they utiliz
Am Donnerstag, 17. Februar 2005 03:11 schrieb James E Wilson:
> James E Wilson wrote:
> > Björn Haase wrote:
> >> #ifndef TARGET_SPECIFIC_SUBSTITUE_FOR_MODE_DF
>
> I see now that this is PR 19920. This message would have made more
> sense if you had included that important info.
>
> Anyways, I see
> James E Wilson wrote:
> These libgcc2 functions really are tied to modes, not to types. So if double
> is SFmode, gcc will never call one of the *df* functions for it. Meanwhile,
> some targets that make double be SFmode also make long double be DFmode, and
> hence we do sti
James E Wilson wrote:
Björn Haase wrote:
#ifndef TARGET_SPECIFIC_SUBSTITUE_FOR_MODE_DF
I see now that this is PR 19920. This message would have made more
sense if you had included that important info.
Anyways, I see that Richard Henderson has added a reasonable fix for it
now along the lines I
Björn Haase wrote:
#ifndef TARGET_SPECIFIC_SUBSTITUE_FOR_MODE_DF
typedef float DFtype __attribute__ ((mode (DF)));
#else
typedef float DFtype
__attribute__ ((mode (TARGET_SPECIFIC_SUBSTITUE_FOR_MODE_DF)));
#endif
These libgcc2
Hi,
I'd like to discuss with you a topic related to a recent bootstrap failure of
a couple of smaller embedded targets. The origin of the failure could be
removed easily. In my opinion the question is simply, what is the best way to
implement it?
Root of the problem is that libgcc2 pres
56 matches
Mail list logo
