On 01/25/2010 11:38 PM, Dave Korn wrote:
On 25/01/2010 20:58, Paolo Bonzini wrote:
This probably is a new version of PR41418 then. We have the
problem that
fortran is turned on in --enable-languages, so libgomp configure
expects the
fortran compiler to be available.
Does this fix it for
On 25/01/2010 22:38, Dave Korn wrote:
> > On 25/01/2010 20:58, Paolo Bonzini wrote:
>> >> Does this fix it for you?
> >
> > That succeeded for "rm -rf i686-pc-cygwin/libgomp; make
> > configure-target-libgomp all-target-libgomp". I'll leave a full bootstrap
> > running overnight
That complet
On Sun, Jan 24, 2010 at 08:26:04PM -0500, Olexa Bilaniuk wrote:
>
> I am on Mac OS X Snow Leopard. There has been some noise around the
> forums that GCC fails for various reasons. It turns out that despite
> having all the requirements to run 64-bit systems, including a 64-bit
> processor (an Int
Basile STARYNKEVITCH writes:
> Why is it still useful on recent GNU/Linux systems?
In general, it's not. But future versions of gcc may want changes to
current versions of glibc. We've seen that happen in the past, and it
is likely to happen again in the future. (E.g., we needed to use
fixinc
On 25/01/2010 20:58, Paolo Bonzini wrote:
>
>>This probably is a new version of PR41418 then. We have the
>> problem that
>> fortran is turned on in --enable-languages, so libgomp configure
>> expects the
>> fortran compiler to be available.
>
> Does this fix it for you?
That succeeded fo
This probably is a new version of PR41418 then. We have the problem that
fortran is turned on in --enable-languages, so libgomp configure expects the
fortran compiler to be available.
Does this fix it for you?
Index: configure.ac
===
On 25/01/2010 20:19, Dave Korn wrote:
> am bootstrapping r156219 ATM.
Not finished yet, but I may have seen a problem already:
make[4]: Leaving directory `/gnu/gcc/obj2/i686-pc-cygwin/libgcc'
make[3]: Leaving directory `/gnu/gcc/obj2/i686-pc-cygwin/libgcc'
mkdir -p -- i686-pc-cygwin/libgomp
On 25 January 2010 15:51, Piotr Wyderski:
> Andrew Haley wrote:
>
union { float f; uint32 i; } u = {.f = v};
return u.i;
>>>
>>> Nope, that is not allowed either.
>>
>> Of course it is allowed. It's a legitimate gcc extension, and it's
>> supported by many other compilers too.
>
> It
On 25/01/2010 19:31, Joern Rennecke wrote:
> Quoting Christian Joensson :
>
>> FWIW, I still get a problem, this:
>
> Could you show the log file from a successful libgomp build with a previous
> version?
> Did it usea different ar?
It should look something like this:
libtool: link: /gnu/gcc/
Hi Sergio. My port has similar addressing modes - all memory must be
accessed by one of two registers and can only be accessed indirectly,
indirect with pre increment, and indirect with post increment. The
key is GO_IF_LEGITIMATE_ADDRESS and the legitimate address helper
function. Mine looks lik
Quoting Christian Joensson :
FWIW, I still get a problem, this:
Could you show the log file from a successful libgomp build with a previous
version?
Did it usea different ar?
2010/1/25 Joern Rennecke:
> Quoting Dave Korn :
>
>> On 25/01/2010 14:04, Joern Rennecke wrote:
>>>
>>> Quoting Christian Joensson :
>
> -Xlinker .libs/libgomp-1.dll
> xgcc: unrecognized option '-pthread'
>>>
>>> Oops, we can't actually always bootstrap libgomp - we shouldn't try if
>>>
On 01/25/10 11:21, Sergio Ruocco wrote:
Gabriel Paubert wrote:
On Mon, Jan 25, 2010 at 01:34:09PM +0100, Sergio Ruocco wrote:
Hi everyone,
I am porting GCC to a custom 16-bit microcontroller with very limited
addressing modes. Basically, it can only load/store using a (general
purpos
Bernd Roesch wrote:
a call of a function and return value with double float is on all
m68k-amigaos compiler (that use only other 68k config files but
same main source) as this.
jsr testfunc
move.l d1,-(sp)
move.l d0,-(sp)
fdmove.d (sp)+,fp1
fsmove.x fp1,fp0
lea (16,sp),sp
Jon Grant writes:
> I see that some of the files are located in the -L library directory
> specified, crtbegin.o, crtend.o in which case, perhaps they both do
> not need their full long path specified.
Most linkers do not use the -L path to search for file names on the
command line.
>>> Also I
Gabriel Paubert wrote:
> On Mon, Jan 25, 2010 at 01:34:09PM +0100, Sergio Ruocco wrote:
>> Hi everyone,
>>
>> I am porting GCC to a custom 16-bit microcontroller with very limited
>> addressing modes. Basically, it can only load/store using a (general
>> purpose) register as the address, without an
Quoting Dave Korn :
On 25/01/2010 14:04, Joern Rennecke wrote:
Quoting Christian Joensson :
-Xlinker .libs/libgomp-1.dll
xgcc: unrecognized option '-pthread'
Oops, we can't actually always bootstrap libgomp - we shouldn't try if it's
not in target_configdirs.
Does the cygwin build work with
Timothy Madden writes:
> On Fri, Jan 22, 2010 at 2:24 AM, Ian Lance Taylor wrote:
>> Timothy Madden writes:
>>
>>> Why is it so hard to store template definitions (and the set of
>>> symbols visible to them) in an
>>> object file, probably as a representation of the parsed template source
>>>
On 25/01/2010 14:04, Joern Rennecke wrote:
> Quoting Christian Joensson :
>>> -Xlinker .libs/libgomp-1.dll
>>> xgcc: unrecognized option '-pthread'
>
> Oops, we can't actually always bootstrap libgomp - we shouldn't try if it's
> not in target_configdirs.
>
> Does the cygwin build work with the a
On 01/25/2010 03:04 PM, Joern Rennecke wrote:
Quoting Christian Joensson :
-Xlinker .libs/libgomp-1.dll
xgcc: unrecognized option '-pthread'
Oops, we can't actually always bootstrap libgomp - we shouldn't try if it's
not in target_configdirs.
Ok.
Paolo
Ron Louzon wrote:
The use of anonymous structure does seem to be the problem. I also missed the
fact that the TYPE_DEF DIE is missing from the DWARF data. If the TYPE
_DEF DIE was in the DWARF data, I could still parse the anonymous type.
Do you think the TYPE_DEF DIE should be part of the ou
Andrew Haley wrote:
>>> union { float f; uint32 i; } u = {.f = v};
>>> return u.i;
>>
>> Nope, that is not allowed either.
>
> Of course it is allowed. It's a legitimate gcc extension, and it's
> supported by many other compilers too.
It's a C extension, according to the documentation.
In C+
On Mon, Jan 25, 2010 at 3:42 PM, Erik Trulsson wrote:
> On Mon, Jan 25, 2010 at 02:19:04PM +0100, Richard Guenther wrote:
>> On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
>> wrote:
>> > I have a hash function hash(T v) overloaded for
>> > all integral types. I want to provide a variant for
>> >
On Mon, Jan 25, 2010 at 01:34:09PM +0100, Sergio Ruocco wrote:
>
> Hi everyone,
>
> I am porting GCC to a custom 16-bit microcontroller with very limited
> addressing modes. Basically, it can only load/store using a (general
> purpose) register as the address, without any offset:
>
> LOAD
On 01/25/2010 02:42 PM, Erik Trulsson wrote:
> On Mon, Jan 25, 2010 at 02:19:04PM +0100, Richard Guenther wrote:
>> On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
>> wrote:
>>> I have a hash function hash(T v) overloaded for all integral
>>> types. I want to provide a variant for float and doubl
The use of anonymous structure does seem to be the problem. I also missed the
fact that the TYPE_DEF DIE is missing from the DWARF data. If the TYPE
_DEF DIE was in the DWARF data, I could still parse the anonymous type.
Do you think the TYPE_DEF DIE should be part of the output? Is this a GNU
On Mon, Jan 25, 2010 at 02:19:04PM +0100, Richard Guenther wrote:
> On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
> wrote:
> > I have a hash function hash(T v) overloaded for
> > all integral types. I want to provide a variant for
> > float and double, which should work as follows:
> > take the
Quoting Christian Joensson :
-Xlinker .libs/libgomp-1.dll
xgcc: unrecognized option '-pthread'
Oops, we can't actually always bootstrap libgomp - we shouldn't try if it's
not in target_configdirs.
Does the cygwin build work with the attached patch?
2010-01-23 Joern Rennecke
PR libs
On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
wrote:
> I have a hash function hash(T v) overloaded for
> all integral types. I want to provide a variant for
> float and double, which should work as follows:
> take the floating-point value, treat its binary
> representation as uint32_t/uint64_t a
Piotr Wyderski writes:
> However, GCC warns me about strict aliasing
> rules violation, which is technically correct, but
> in this case is intended. How do I perform this
> conversion ina GCC-friendly way? Even that
> produces a warning:
>
> inline hash_type hash(float v) {
>
> retur
Hi everyone,
I am porting GCC to a custom 16-bit microcontroller with very limited
addressing modes. Basically, it can only load/store using a (general
purpose) register as the address, without any offset:
LOAD (R2) R1; load R1 from memory at address (R2)
STORE R1 (R2) ; st
I have a hash function hash(T v) overloaded for
all integral types. I want to provide a variant for
float and double, which should work as follows:
take the floating-point value, treat its binary
representation as uint32_t/uint64_t and use
the result as a parameter for an integral hash().
However,
Should have gone here I suppose...
2010/1/25 Christian Joensson:
> Hi Dave.
>
> I see you're busy with your cygwin improvement branch... however, I
> just want to give you a heads up, as for a some time, I can't build
> gcc trunk, there's something with libgomp that's quite wrong.
>
> libtool: lin
Qifei Fan wrote:
> > But insn#479 is not recognized by recog() in insn-recog.c and the
> > compilation failed. (recog only recognizes RTL defined in md, right?)
> > Here the backtrace is
> > reload--->cleanup_subreg_operands--->extract_insn_cached--->extract_insn-=
> -->recog_memoized--->recog.
>
34 matches
Mail list logo
