Re: Help-The possible places where insn is splitted in greg pass
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. > > There is no machine instruction(r3=3Dr1*4+r2) match the pattern of > > insn#479. Though there is pattern r3=3Dmem(r1*4+r2). > > I don=92t quite understand the generation of reload information. There's two issues here. The first issue is that reload makes the fundamental assumption that everything that is a valid address, can be loaded into a register as well, if necessary. On many platforms this is true, either because there is some sort of "load address" instruction, or because the form of valid addresses matches standard arithmetic instruction patterns. Reload will simply emit a naked "set" of some register to the address -- if the back-end doesn't support that, you'll get the failure you saw. If this doesn't work on your particular platform, you could either try to set things up so that reload never thinks it needs to reload an address (but this may be difficult to achieve). The safe option would be to tell reload how to achieve computing an address by providing a "secondary reload" pattern. See e.g. s390_secondary_reload (in config/s390/s390.c) and the associated "reload_plus" pattern. The second issue is as you notice here: > Actually the second reload is not needed if there is already the first relo= > ad. > If (plus:SI (reg/f:SI 16 SP) (const_int 96 [0x60]) is replaced by > (reg:SI 12 a12), then (plus:SI (mult:SI (reg:SI 9 a9 [204]) > (const_int 4 [0x4])) (reg:SI 12 a12) ) is a valid memory address. > But in function find_reloads, I can=92t find the related code that > deciding whether the second reload should be generated by regarding > the previous reload. The function is too complex. :-( The first reload, loading sp + 96 into a register, is generated from within find_reloads_address. After this is done, it is assumed that the address is now valid. However, something else later in find_reloads apparently assumes there is still some problem with the operand, and decides to reload the whole address. It is hard to say exactly what the problem is, without seeing the insn constraints, but the most likely cause seems to be that this instruction pattern does not have a general "m" constraint, but a more restricted memory constraint. If this is the case, the back-end procedure called to verify the constraint probably rejects it. This runs into another fundamental assumption reload makes: it assumes such procedures take other actions done by reload into account implicitly. This means the constraint checker ought to *accept* addresses of the form reg*const + (sp + const) because it ought to know that reload will already load the (sp + const) into a register anyway. If this is *not* the case, please send me the instruction pattern and constraints for the insn pattern that matched insn 320 before reload so I can investigate in more detail. (Please note that I'm currently travelling with restricted access to email, so it might be a couple of days before I'm able to reply; sorry ...) Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
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: link: /usr/local/src/trunk/objdir/./gcc/xgcc > -B/usr/local/src/trunk/objdir/./gcc/ > -B/usr/local/gnu/i686-pc-cygwin/bin/ > -B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem > /usr/local/gnu/i686-pc-cygwin/include -isystem > /usr/local/gnu/i686-pc-cygwin/sys-include -shared .libs/alloc.o > .libs/barrier.o .libs/critical.o .libs/env.o .libs/error.o > .libs/iter.o .libs/iter_ull.o .libs/loop.o .libs/loop_ull.o > .libs/ordered.o .libs/parallel.o .libs/sections.o .libs/single.o > .libs/task.o .libs/team.o .libs/work.o .libs/lock.o .libs/mutex.o > .libs/proc.o .libs/sem.o .libs/bar.o .libs/ptrlock.o .libs/time.o > .libs/fortran.o .libs/affinity.o -pthread -Wl,-O1 -o > .libs/libgomp-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib > -Xlinker .libs/libgomp-1.dll > xgcc: unrecognized option '-pthread' > Creating library file: .libs/libgomp-1.dll > libtool: link: (cd ".libs" && rm -f "libgomp.lib" && ln -s > "libgomp-1.dll" "libgomp.lib") > libtool: link: ar rc .libs/libgomp.lib alloc.o barrier.o critical.o > env.o error.o iter.o iter_ull.o loop.o loop_ull.o ordered.o parallel.o > sections.o single.o task.o team.o work.o lock.o mutex.o proc.o sem.o > bar.o ptrlock.o time.o fortran.o affinity.o > ar: .libs/libgomp.lib: File format not recognized > make[5]: *** [libgomp.la] Error 1 > make[5]: Leaving directory > `/usr/local/src/trunk/objdir/i686-pc-cygwin/libgomp' > make[4]: *** [all-recursive] Error 1 > make[4]: Leaving directory > `/usr/local/src/trunk/objdir/i686-pc-cygwin/libgomp' > make[3]: *** [all] Error 2 > make[3]: Leaving directory > `/usr/local/src/trunk/objdir/i686-pc-cygwin/libgomp' > make[2]: *** [all-stage1-target-libgomp] Error 2 > make[2]: Leaving directory `/usr/local/src/trunk/objdir' > make[1]: *** [stage1-bubble] Error 2 > make[1]: Leaving directory `/usr/local/src/trunk/objdir' > make: *** [all] Error 2 > > I can't say for sure when this started happening, for me, 156188 seems > to work, and 156189 does not. -- Cheers, /ChJ
strict aliasing violation
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, 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) {
return hash(*reinterpret_cast(reinterpret_cast(&v)));
}
but I expected char* to be allowed to alias anything.
Best regards
Piotr Wyderski
porting GCC to a micro with a very limited addressing mode --- what to write in LEGITIMATE_ADDRESS, LEGITIMIZE_ADDRESS and micro.md ?!
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) ; store R1 to memory at address (R2)
As far as I can understand, this is more limited than the current
architectures supported by GCC that I found in the current gcc/config/*.
Since for my port I started modifying a MIPS target (from the tutorials
by IIT Bombay http://www.cse.iitb.ac.in/grc/ - great work guys!), the
GCC still generates code like:
sw R15, 0(R13)
sw R13, -2(R13)
sw R14, -4(R13)
...
lw R14, -4(R13)
lw R15, 0(R13)
Now, in order to restrict the addressing mode, I want to force GCC to
compute the address and store it in a register, then generate the
instructions above to LOAD/STORE in memory. Thus I tried to fiddle with
LEGITIMATE_ADDRESS() and LEGITIMIZE_ADDRESS(), but the compilation of a
simple C program like:
void foobar(int par1, int par2, int parN)
{
int a, b, c;
a = -1;
b = -65535;
c = 0xabcd;
}
fails with
foobar7.c:11: internal compiler error: in change_address_1, at
emit-rtl.c:1800
Please submit a full bug report,
The same program gets compiled with the lw/sw above if I replace 0 with
1 in legitimate_address() below, at the comment /* reject/accept*/.
What should I do? How the addressing mode(s) are managed in the md files
and the LEGITxxx_ADDRESS() macros ? The GCC manual is not very clear on
this... Is there any other architecture/documentation I should look at ?
Thanks,
Sergio
===
Here follows a fragment of my micro.c with the C implementations of the
LEGITIMATE_ADDRESS() and LEGITIMIZE_ADDRESS() macros:
-
int
legitimate_address2(enum machine_mode MODE,rtx X)
{
rtx op1,op2;
if(CONSTANT_ADDRESS_P(X))
{
return 1;
}
if(GET_CODE(X)==REG && non_strict_base_reg(REGNO(X)))
{
return 1;
}
if(GET_CODE(X)==PLUS) /* is it offset+(Rx) ?! */
{
puts ("GET_CODE(X)==PLUS ");
op1=XEXP(X,0);
op2=XEXP(X,1);
if(GET_CODE(op1)==REG && CONSTANT_ADDRESS_P(op2) &&
non_strict_base_reg(REGNO(op1)))
{
return 0; /* reject / accept */
}
if(GET_CODE(op2)==REG && CONSTANT_ADDRESS_P(op1) &&
non_strict_base_reg(REGNO(op2)))
{
return 0; /* reject / accept */
}
}
/* reject all other cases, too */
puts ("legitimate_address2() - end - ret 0/NO");
return 0;
}
rtx
legitimize_address(rtx X,rtx OLDX, enum machine_mode MODE)
{
rtx op1,op2,op;
op=NULL;
if(memory_address_p(MODE,X))
return X;
if(GET_CODE(X)==MEM && !no_new_pseudos)
op = force_reg(MODE,X);
else if ( GET_CODE(X)==PLUS && !no_new_pseudos)
{
puts("GET_CODE(X)==PLUS && !no_new_pseudos !");
op1=XEXP(X,0);
op2=XEXP(X,1);
if(GET_CODE(op1)==REG && !CONSTANT_ADDRESS_P(op2))
{
op=force_reg(MODE,X);
}
else if(GET_CODE(op2)==REG && !CONSTANT_ADDRESS_P(op1))
{
op=force_reg(MODE,X);
}
else /* HACK */
{
op=force_reg(MODE,X);
}
-
/* Here is another HACK attempt, now disabled (commented), inspired by
http://gcc.gnu.org/ml/gcc/2001-07/msg01513.html, but this is not
working, either */
else if ( (GET_CODE (op1)== REG) && (GET_CODE (op2) ==
CONST_INT) )
{
op1 = force_reg (MODE, op1);
op = force_reg (MODE, gen_rtx_PLUS (MODE, op1, op2));
}
-
}
if(op!=NULL && memory_address_p(MODE,op))
{
return op; /* if we rewrote the expression */
}
return X; /* otherwise original */
}
-
Here is a fragment of "micro.md" with the definitions of the "movXX",
load and store patterns:
(define_expand "movhi"
[(set (match_operand:HI 0 "nonimmediate_operand" "")
(match_operand:HI 1 "general_operand" "")
)]
""
{
if(GET_CODE(operands[0])==MEM && GET_CODE(operands[1])!=REG)
{
if(!no_new_pseudos) {
operands[1]=force_reg(HImode,operands[1]);
}
Re: strict aliasing violation
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) {
>
> return hash(*reinterpret_cast std::uint32_t*>(reinterpret_cast(&v)));
> }
>
> but I expected char* to be allowed to alias anything.
Only when used as the type to access the object, but you access it as
uint32_t. The intermediate cast is irrelevant for aliasing
consideration.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: strict aliasing violation
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 and use
> the result as a parameter for an integral hash().
>
> 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) {
>
> return hash(*reinterpret_cast std::uint32_t*>(reinterpret_cast(&v)));
> }
>
> but I expected char* to be allowed to alias anything.
But your access is via std::uint32_t *, not char. Use a
union like
union { float f; uint32 i; } u = {.f = v};
return u.i;
Richard.
> Best regards
> Piotr Wyderski
>
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
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 libstdc++/36101, PR libstdc++/42813
* configure.ac (bootstrap_target_libs): Make inclusion of
target-libgomp conditional on libgomb being in target_configdirs.
* configure: Regenerate.
Index: configure.ac
===
--- configure.ac(revision 156191)
+++ configure.ac(working copy)
@@ -1744,7 +1744,7 @@ fi
stage1_languages=,c,
# Target libraries that we bootstrap.
-bootstrap_target_libs=,target-libgcc,target-libgomp,
+bootstrap_target_libs=,target-libgcc,
# Figure out what language subdirectories are present.
# Look if the user specified --enable-languages="..."; if not, use
@@ -2540,6 +2540,11 @@ fi
target_configdirs=`echo "${target_configdirs}" | sed -e 's/target-//g'`
build_configdirs=`echo "${build_configdirs}" | sed -e 's/build-//g'`
+# If we are building libgomp, bootstrap it.
+if echo " ${target_configdirs} " | grep " libgomp " > /dev/null 2>&1 ; then
+ bootstrap_target_libs=${bootstrap_target_libs}target-libgomp,
+fi
+
# Determine whether gdb needs tk/tcl or not.
# Use 'maybe' since enable_gdbtk might be true even if tk isn't available
# and in that case we want gdb to be built without tk. Ugh!
Index: configure
===
--- configure (revision 156191)
+++ configure (working copy)
@@ -6545,7 +6545,7 @@ fi
stage1_languages=,c,
# Target libraries that we bootstrap.
-bootstrap_target_libs=,target-libgcc,target-libgomp,
+bootstrap_target_libs=,target-libgcc,
# Figure out what language subdirectories are present.
# Look if the user specified --enable-languages="..."; if not, use
@@ -7394,6 +7394,11 @@ fi
target_configdirs=`echo "${target_configdirs}" | sed -e 's/target-//g'`
build_configdirs=`echo "${build_configdirs}" | sed -e 's/build-//g'`
+# If we are building libgomp, bootstrap it.
+if echo " ${target_configdirs} " | grep " libgomp " > /dev/null 2>&1 ; then
+ bootstrap_target_libs=${bootstrap_target_libs}target-libgomp,
+fi
+
# Determine whether gdb needs tk/tcl or not.
# Use 'maybe' since enable_gdbtk might be true even if tk isn't available
# and in that case we want gdb to be built without tk. Ugh!
Re: strict aliasing violation
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 floating-point value, treat its binary
> > representation as uint32_t/uint64_t and use
> > the result as a parameter for an integral hash().
> >
> > 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) {
> >
> > return hash(*reinterpret_cast > std::uint32_t*>(reinterpret_cast(&v)));
> > }
> >
> > but I expected char* to be allowed to alias anything.
>
> But your access is via std::uint32_t *, not char. Use a
> union like
>
> union { float f; uint32 i; } u = {.f = v};
> return u.i;
Nope, that is not allowed either.
What probably would work is to use memcpy() to copy the contents
of an object of type float into another object of type uint32_t and
then use the value of that object. As long as uint32_t does not have
any trap representations that should be safe.
--
Erik Trulsson
ertr1...@student.uu.se
Re: Mangled Typedef names in GNU 4.1.2 DWARF data?
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
bug or just an unsupported feature?
Thanks.
--- On Fri, 1/22/10, Michael Eager wrote:
> From: Michael Eager
> Subject: Re: Mangled Typedef names in GNU 4.1.2 DWARF data?
> To: "Ron Louzon"
> Cc: gcc@gcc.gnu.org
> Date: Friday, January 22, 2010, 4:39 PM
> Ron Louzon wrote:
> > The GNU 4.1.2 C++ compiler is mangling typedef names
> to the point that they are not retrievable from the DWARF
> data.
> >
> > For example, the type BASE_UNION is defined as
> >
> > typedef union
> > {
> > char ch;
> > int iVal;
> > long IVal;
> > } BASE_UNION;
>
> This is an anonymous union which is typedef'ed to
> BASE_UNION.
>
> >
> > The GNU 4.1.2 compiler generates the following DWARF
> data for this type
> >
> > <1><1279>: Abbrev Number: 35
> (DW_TAG_union_type)
> > <127a>
> DW_AT_sibling :
> <12a8>
> > <127e>
> DW_AT_name :
> $_4
> > <1282>
> DW_AT_byte_size :
> 4
> > <1283>
> DW_AT_decl_file :
> 35
> > <1284>
> DW_AT_decl_line :
> 29
>
> This doesn't look correct. The union has no name, so
> DW_AT_name should
> not be present or should be null. From the DWARF v.3
> spec:
>
> 2.15 Identifier Names
>
> Any debugging information entry representing a
> program entity that has been
> given a name may have a DW_AT_name attribute, whose
> value is a string
> representing the name as it appears in the source
> program. A debugging
> information entry containing no name attribute, or
> containing a name attribute
> whose value consists of a name containing a single
> null byte, represents a
> program entity for which no name was given in the
> source.
>
> > <2><1285>: Abbrev Number: 36
> (DW_TAG_member)
> > <1286>
> DW_AT_name :
> ch
> > <1289>
> DW_AT_decl_file :
> 35
> > <128a>
> DW_AT_decl_line :
> 30
> > <128b>
> DW_AT_type :
>
> > <2><128f>: Abbrev Number: 36
> (DW_TAG_member)
> > <1290>
> DW_AT_name :
> iVal
> > <1295>
> DW_AT_decl_file :
> 35
> > <1296>
> DW_AT_decl_line :
> 31
> > <1297>
> DW_AT_type :
>
> > <2><129b>: Abbrev Number: 36
> (DW_TAG_member)
> > <129c>
> DW_AT_name :
> IVal
> > <12a1>
> DW_AT_decl_file :
> 35
> > <12a2>
> DW_AT_decl_line :
> 32
> > <12a3>
> DW_AT_type :
>
> >
> > Notice that the union name has been changed to "$_4"
> in DIE <1279>.
> >
> > The GNU 3.4.4 compiler generates the following DWARF
> data from the same source code:
> >
> > <1><11d0>: Abbrev Number: 27
> (DW_TAG_union_type)
> > DW_AT_sibling
> : <123f>
> > DW_AT_name
> : (indirect string, offset: 0x6e):
> BASE_UNION
> > DW_AT_byte_size :
> 4
> > DW_AT_decl_file :
> 3
> > DW_AT_decl_line :
> 29
>
> This is similarly incorrect. The union has no name.
>
>
> > Why is GNU 4.1.2 generating the mangled type name and
> how do I correct this to generate the real type name?
>
> A better question might by why there is no DW_TAG_typedef
> DIE which looks like
>
> DW_TAG_typedef
>
> DW_AT_name: BASE_UNION
>
> DW_AT_type: <1279>
>
> BTW gcc-4.3.2 generates
>
> DW_AT_name:
>
> which is also incorrect.
>
>
>
> -- Michael eager ea...@eagercon.com
> 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
>
Re: strict aliasing violation
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 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, 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) {
>>>
>>>return hash(*reinterpret_cast>> std::uint32_t*>(reinterpret_cast(&v)));
>>>}
>>>
>>> but I expected char* to be allowed to alias anything.
>>
>> But your access is via std::uint32_t *, not char. Use a
>> union like
>>
>> 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.
Andrew.
Re: porting GCC to a micro with a very limited addressing mode --- what to write in LEGITIMATE_ADDRESS, LEGITIMIZE_ADDRESS and micro.md ?!
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 (R2) R1; load R1 from memory at address (R2) > STORE R1 (R2) ; store R1 to memory at address (R2) > > As far as I can understand, this is more limited than the current > architectures supported by GCC that I found in the current gcc/config/*. The Itanium (ia64) has the same limited choice of addressing modes. Gabriel
Re: strict aliasing violation
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
>> > 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, 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) {
>> >
>> > return hash(*reinterpret_cast> > std::uint32_t*>(reinterpret_cast(&v)));
>> > }
>> >
>> > but I expected char* to be allowed to alias anything.
>>
>> But your access is via std::uint32_t *, not char. Use a
>> union like
>>
>> union { float f; uint32 i; } u = {.f = v};
>> return u.i;
>
> Nope, that is not allowed either.
It's a GCC extension sanctioned by the latest revision of the C99
standard.
> What probably would work is to use memcpy() to copy the contents
> of an object of type float into another object of type uint32_t and
> then use the value of that object. As long as uint32_t does not have
> any trap representations that should be safe.
At least 6.5/6 does not explicitly suggest this. But it happens
to work with GCC as well.
Richard.
Re: strict aliasing violation
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++ mode (-std=gnu++0x) the compiler does not
understand the "u = {.f = v}" statement. Is it a feature
or a bug? ;-)
Best regards
Piotr Wyderski
Re: Mangled Typedef names in GNU 4.1.2 DWARF data?
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 output? Is this a GNU bug or just an unsupported feature? It looks like a GCC bug to me. GCC does generate DW_TAG_typedef for other typedefs. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
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
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
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 attached patch? Was this question and/or patch inspired by the "unrecognized option -pthread" warning above? Only we've always gotten that on cygwin and it's always been harmless up til now. (I'm not up-to-date with head, right now I'm still on r.156105 where the problem apparently arose at r.156189; I'll update to head and get a build going.) cheers, DaveK
Re: Support for export keyword to use with C++ templates ?
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 >>> tree ? >> >> I recommend reading "Why We Can't Afford Export." > > I have seen that paper in the link, N1426, and I find it to be biased > against export ... It may be biased, but I think it does a nice job of explaining why it is so hard to store template definitions and the set of symbols visible to them. g++ is free software. A clean implementation of export would certainly be accepted. All it takes is for somebody to write one. I know that seems like a non-answer, but as far as I can tell there is currently no constituency for adding export to g++. It's not something which people routinely complain about. There are C++ frontend issues which people do routinely complain about, such as bad error messages and compilation speed, and gcc developers do work on those areas. Ian
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
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 the attached patch? Was this question and/or patch inspired by the "unrecognized option -pthread" warning above? Well, I though the reason why you ended up with an unrecognized type libgomp-1.dll was that this diagnostic indicatde a serious problem. Only we've always gotten that on cygwin and it's always been harmless up til now. So how is a build with r156189 different from a build with provious revision? > (I'm not up-to-date with head, right now I'm still on r.156105 where the problem apparently arose at r.156189; I'll update to head and get a build going.) I've now committed the patch as r156218, but we'd still like to know if that fixes cygwin builds.
Re: porting GCC to a micro with a very limited addressing mode --- what to write in LEGITIMATE_ADDRESS, LEGITIMIZE_ADDRESS and micro.md ?!
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 any offset: >> >> LOAD (R2) R1; load R1 from memory at address (R2) >> STORE R1 (R2) ; store R1 to memory at address (R2) >> >> As far as I can understand, this is more limited than the current >> architectures supported by GCC that I found in the current gcc/config/*. > > The Itanium (ia64) has the same limited choice of addressing modes. > > Gabriel Thanks Gabriel. I dived into the ia64 md, but it is still unclear to me how the various parts (macros, define_expand and define_insn in MD etc.) work together to force the computation of a source/dest address plus offset into a register... can anyone help me with this ? Thanks, Sergio
Re: Long paths with ../../../../ throughout
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 notice lots of duplicate parameters: >>> >>> Is this directory really needed twice? >>> -L/usr/lib/gcc/i486-linux-gnu/4.3.3 -L/usr/lib/gcc/i486-linux-gnu/4.3.3 >> >> No. I would encourage you to investigate why it is happening. > > i tried: gcc -o t -Wl,-debug test.c, I see collect2 gets the > duplicates passed to it, and then it passes it on to ld. I would have > thought that if collect2 was compiled with define > LINK_ELIMINATE_DUPLICATE_LDIRECTORIES it would strip out the duplicate > parameters before calling ld. It does not appear to be switched on in > this Ubuntu package I am using though. Is it on by default? No. It was introduced only to avoid an error in the linker in some version of SGI Irix. Generally the duplicate -L option does no harm. I was actually thinking along of the lines of eliminating it earlier in the process. Why does the directory get in there twice in the first place? >> To see what collect2 is doing, use -Wl,-debug > > If I add this to my existing command line I see there not any output: > $ gcc -### -o t -Wl,-debug test.c > > If I change to not have -### I see it does work, not sure why. -### controls the gcc driver, not the collect2 program. > So I understand that this passes -debug to collect2. As collect2 only > has -v mode to display version. Would a patch to add --help to it be > supported? Also could describe something about collect2's purpose at > the top of that --help output. I think that ordinary uses of -Wl,--help will expect to see the --help option for the linker, not for collect2. That said, I think it would be OK to add a --help option for collect2 which issued some output and then went on to invoke the linker. > 1) collect.c:scan_libraries may not find ldd, in which case it > displays message on output, and returns as normal. Should it not be > fatal if ldd is required? It seems to me that it gives an error message, which should cause collect2 to exit with a non-zero status. Does that not happen for you? Note that ldd is only required on HP/UX. > 2) in collect2.c:main "-debug" is checked, and variable debug set to 1 > (perhaps that should be "true" to match the style of other flags) Yes, and debug should be changed from int to bool. Ian
Re: what 68k platform config switch put float return values in fpu register ?
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 fjgt L6 You see the func always return the values in Integer Register d0 and d1 put it to stack and then move it from stack to FPU regsiter. m68k-elf use the FPU Register and produce shorter and faster code You cannot change the way doubles are returned for you target! Doing this would render all existing object files useless since the return value is suddenly at a different place. Furthermore you would loose the ability to mix soft-float and hard-float compiled code. Gunther
Re: porting GCC to a micro with a very limited addressing mode --- what to write in LEGITIMATE_ADDRESS, LEGITIMIZE_ADDRESS and micro.md ?!
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 purpose) register as the address, without any offset: LOAD (R2) R1; load R1 from memory at address (R2) STORE R1 (R2) ; store R1 to memory at address (R2) As far as I can understand, this is more limited than the current architectures supported by GCC that I found in the current gcc/config/*. The Itanium (ia64) has the same limited choice of addressing modes. Gabriel Thanks Gabriel. I dived into the ia64 md, but it is still unclear to me how the various parts (macros, define_expand and define_insn in MD etc.) work together to force the computation of a source/dest address plus offset into a register... can anyone help me with this ? GO_IF_LEGITIMATE_ADDRESS is what you need to be looking at. jeff
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
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 >>> it's >>> not in target_configdirs. >>> >>> Does the cygwin build work with the attached patch? >> >> Was this question and/or patch inspired by the "unrecognized option >> -pthread" warning above? > > Well, I though the reason why you ended up with an unrecognized type > libgomp-1.dll was that this diagnostic indicatde a serious problem. > >> Only we've always gotten that on cygwin and it's >> always been harmless up til now. > > So how is a build with r156189 different from a build with provious > revision? > (I'm not up-to-date with head, >> >> right now I'm >> still on r.156105 where the problem apparently arose at r.156189; I'll >> update >> to head and get a build going.) > > I've now committed the patch as r156218, but we'd still like to know if that > fixes cygwin builds. FWIW, I still get a problem, this: /bin/sh ./libtool --tag CC --mode=link /usr/local/src/trunk/objdir/./gcc/xgcc -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/gnu/i686-pc-cygwin/bin/ -B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem /usr/local/gnu/i686-pc-cygwin/include -isystem /usr/local/gnu/i686-pc-cygwin/sys-include-Wall -Werror -Wc,-pthread -g -O2 -Wl,-O1 -o libgomp.la -version-info 1:0:0 -no-undefined -bindir "/usr/local/gnu/bin" -rpath /usr/local/gnu/lib/gcc/i686-pc-cygwin/4.5.0 alloc.lo barrier.lo critical.lo env.lo error.lo iter.lo iter_ull.lo loop.lo loop_ull.lo ordered.lo parallel.lo sections.lo single.lo task.lo team.lo work.lo lock.lo mutex.lo proc.lo sem.lo bar.lo ptrlock.lo time.lo fortran.lo affinity.lo libtool: link: /usr/local/src/trunk/objdir/./gcc/xgcc -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/gnu/i686-pc-cygwin/bin/ -B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem /usr/local/gnu/i686-pc-cygwin/include -isystem /usr/local/gnu/i686-pc-cygwin/sys-include-shared .libs/alloc.o .libs/barrier.o .libs/critical.o .libs/env.o .libs/error.o .libs/iter.o .libs/iter_ull.o .libs/loop.o .libs/loop_ull.o .libs/ordered.o .libs/parallel.o .libs/sections.o .libs/single.o .libs/task.o .libs/team.o .libs/work.o .libs/lock.o .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o .libs/ptrlock.o .libs/time.o .libs/fortran.o .libs/affinity.o-pthread -Wl,-O1 -o .libs/libgomp-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgomp-1.dll xgcc: unrecognized option '-pthread' Creating library file: .libs/libgomp-1.dll libtool: link: (cd ".libs" && rm -f "libgomp.lib" && ln -s "libgomp-1.dll" "libgomp.lib") libtool: link: ar rc .libs/libgomp.lib alloc.o barrier.o critical.o env.o error.o iter.o iter_ull.o loop.o loop_ull.o ordered.o parallel.o sections.o single.o task.o team.o work.o lock.o mutex.o proc.o sem.o bar.o ptrlock.o time.o fortran.o affinity.o ar: .libs/libgomp.lib: File format not recognized make[5]: *** [libgomp.la] Error 1 make[5]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libgomp' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libgomp' make[3]: *** [all] Error 2 make[3]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libgomp' make[2]: *** [all-stage1-target-libgomp] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir' make: *** [all] Error 2 (and, yes, I've been building with libgomp for quite a while on cygwin, and, yes, I do remember the pthread warning showing up before, mentioned it to Dave, and it hadn't caused me problems before to my understanding) -- Cheers, /ChJ
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
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?
Re: porting GCC to a micro with a very limited addressing mode --- what to write in LEGITIMATE_ADDRESS, LEGITIMIZE_ADDRESS and micro.md ?!
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 like this:
/* Return 1 if the address is OK, otherwise 0.
Used by GO_IF_LEGITIMATE_ADDRESS. */
bool
tomi_legitimate_address (enum machine_mode mode ATTRIBUTE_UNUSED,
rtx x,
bool strict_checking)
{
/* (mem reg) */
if (REG_P (x)
&& tomi_reg_ok (x, strict_checking)
)
{
return 1;
}
if (GET_CODE(x) == PRE_DEC)
{
...
}
if (GET_CODE(x) == POST_INC)
{
...
}
return 0;
}
tomi_reg_ok returns true if x is any register when strict checking is
clear and true if x is one of my addressing registers when strict
checking is set.
GCC will feed any memory accesses through this function to see if they
are directly supported, and if not it will break them up into
something smaller and try again.
Hope that helps,
-- Michael
2010/1/26 Sergio Ruocco :
> 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 any offset:
>>>
>>> LOAD (R2) R1 ; load R1 from memory at address (R2)
>>> STORE R1 (R2) ; store R1 to memory at address (R2)
>>>
>>> As far as I can understand, this is more limited than the current
>>> architectures supported by GCC that I found in the current gcc/config/*.
>>
>> The Itanium (ia64) has the same limited choice of addressing modes.
>>
>> Gabriel
>
> Thanks Gabriel.
>
> I dived into the ia64 md, but it is still unclear to me how the various
> parts (macros, define_expand and define_insn in MD etc.) work together
> to force the computation of a source/dest address plus offset into a
> register... can anyone help me with this ?
>
> Thanks,
>
> Sergio
>
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
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/obj-lto/./gcc/xgcc -B/gnu/gcc/obj-lto/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-include-shared .libs/alloc.o .libs/barrier.o .libs/critical.o .libs/env.o .libs/error.o .libs/iter.o .libs/iter_ull.o .libs/loop.o .libs/loop_ull.o .libs/ordered.o .libs/parallel.o .libs/sections.o .libs/single.o .libs/task.o .libs/team.o .libs/work.o .libs/lock.o .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o .libs/ptrlock.o .libs/time.o .libs/fortran.o .libs/affinity.o-pthread -Wl,-O1 -o .libs/cyggomp-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgomp.dll.a xgcc: unrecognized option '-pthread' Creating library file: .libs/libgomp.dll.a libtool: link: ar rc .libs/libgomp.a alloc.o barrier.o critical.o env.o error.o iter.o iter_ull.o loop.o loop_ull.o ordered.o parallel.o sections.o single.o task.o team.o work.o lock.o mutex.o proc.o sem.o bar.o ptrlock.o time.o fortran.o affinity.o libtool: link: ranlib .libs/libgomp.a libtool: link: ( cd ".libs" && rm -f "libgomp.la" && ln -s "../libgomp.la" "libgomp.la" ) Libtool is definitely confused since it's not got the right 'cyg' prefix for the dll in CJ's version, and it's forgotten the .a suffix for the import library, meaning it'll overwrite (or be overwritten by) the DLL. I think we had something like this a while back when gomp was enabled but fortran not configured in. Hang on PR41418. Same symptoms. Haven't verified if there's a similar cause yet, am bootstrapping r156219 ATM. cheers, DaveK
Re: strict aliasing violation
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's a C extension, according to the documentation.
> In C++ mode (-std=gnu++0x) the compiler does not
> understand the "u = {.f = v}" statement. Is it a feature
> or a bug? ;-)
A feature; the C++ committee decided not to support designated initializers.
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
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 Checking multilib configuration for libgomp... Configuring stage 1 in i686-pc-cygwin/libgomp configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... yes checking for --enable-generated-files-in-srcdir... no checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking target system type... i686-pc-cygwin checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for i686-pc-cygwin-gcc... /gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-include checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-includeaccepts -g... yes checking for /gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-includeoption to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of /gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-include ... gcc3 checking for i686-pc-cygwin-ar... ar checking for i686-pc-cygwin-ranlib... ranlib checking for perl... /usr/bin/perl checking whether make sets $(MAKE)... (cached) yes checking for makeinfo... makeinfo --split-size=500 --split-size=500 checking for modern makeinfo... yes checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by /gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-include ... /gnu/gcc/obj2/./gcc/collect-ld checking if the linker (/gnu/gcc/obj2/./gcc/collect-ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /gnu/gcc/obj2/./gcc/nm checking the name lister (/gnu/gcc/obj2/./gcc/nm) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 8192 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking for /gnu/gcc/obj2/./gcc/collect-ld option to reload object files... -r checking for i686-pc-cygwin-objdump... objdump checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL checking for i686-pc-cygwin-ar... (cached) ar checking for i686-pc-cygwin-strip... strip checking for i686-pc-cygwin-ranlib... (cached) ranlib checking command to parse /gnu/gcc/obj2/./gcc/nm output from /gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-includeobject... ok checking how to run the C preprocessor... /gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-include-E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if /gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
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 === --- configure.ac(revision 155240) +++ configure.ac(working copy) @@ -146,7 +146,11 @@ case `echo $GFORTRAN` in -* | no* ) FC=no ;; *) -FC="$GFORTRAN" ;; +if test -x "$GFORTRAN"; then + FC="$GFORTRAN" +else + FC=no +fi ;; esac AC_PROG_FC(gfortran) FCFLAGS="$FCFLAGS -Wall" (untested) Paolo
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
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 for "rm -rf i686-pc-cygwin/libgomp; make configure-target-libgomp all-target-libgomp". I'll leave a full bootstrap running overnight but it looks sound to me. cheers, DaveK
Re: fixincludes
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 fixincludes when we flipped the meaning of "extern inline" from the GNU89 meaning to the C99 meaning when running in C99 mode.) Ian
Re: Successful make profiledbootstrap of GCC 4.4.3 and GCC 4.5.0 (SVN revision 156177) on Snow Leopard 10.6.2 x86_64-apple-darwin10.2.0
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 Intel Core 2 Duo), no Macs boot the 64-bit kernel by > default and only 4 (These being Mac Pros, Xserves, Macbook Pros and > iMacs) are allowed to boot i...@all, leaving that the system kernel > runs 32-bit, but almost every application is 64-bit. Also, the command > uname returns i386 despite the Core 2 Duo being more of a i686 or > x86_64, a 64-bit processor. It seems therefore that config.guess > confuses itself in bitness, picking the 32-bit version called i386 > rather than the correct choice, x86_64. So the recommendation is to > add an entry under Build Stats saying that 4.4.3 under > x86_64-apple-darwin10.2.0 is successful, and to add to the > system-specific installation notes to add these options to the > configure: > > --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 > --host=x86_64-apple-darwin10 > This issue doesn't exist in either gcc 4.4.3 or gcc trunk as both contain the updated config.guess which properly detects the code generation of the default system compiler rather than using uname for obtaining the architecture. Thus on a EMT64 compatible processor config.guess will return... x86_64-apple-darwin10.2.0 for the default compiler but if you set CC to gcc-4.0, it will return... i386-apple-darwin10.2.0 Jack
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
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 completed fine. cheers, DaveK
Re: can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
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 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 but it looks sound to me. Committed, I think we can revert Joern's second patch, I'll check in the next 1-2 days. Paolo
