GCC 4.6.0 Released
The GNU Compiler Collection version 4.6.0 has been released. GCC 4.6.0 is a major release, containing substantial new functionality not available in GCC 4.5.x or previous GCC releases. The "link-time optimization" framework introduced in GCC 4.5.0 has been significantly improved in this release, it is now possible to compile very large applications like Mozilla or GCC itself with LTO. GCC can now partially inline functions, inlining just hot short path to exit and keeping the rest of the function out of line. Support for the upcoming C++0x standard has been notably improved, Fortran 2003 and 2008 has been greatly extended and many other frontends undergone substantial changes as well. Many other improvements have been added and more than thousand of bugs have been fixed in various parts of the compiler collection. See: http://gcc.gnu.org/gcc-4.6/changes.html for more information about changes in GCC 4.6.0. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in gcc/gcc-4.6.0/ subdirectory. If you encounter difficulties using GCC 4.6, please do not contact me directly. Instead, please visit http://gcc.gnu.org for information about getting help. As always, a vast number of people contributed to this GCC releases -- far too many to thank individually!
Re: Possible Bug
On 03/27/2011 06:27 AM, Ian Lance Taylor wrote:
Nathan Boley writes:
In a much larger application, I was getting a weird segfault that an
assignment to a temporary variable fixed. I distilled the example into
the attached "test_case.c". When I run test_case.c under valgrind I
get a memory read error, and it segfaults with electric fence, but I'm
not actually able to get a true segfault. However, I am pretty sure
that the same issue was causing the segfault in my application.
There is nothing wrong if gcc is reading an 8-byte value at an 8-byte
aligned address.
Note the struct is packed, so alignof = 1.
That said, I could not recreate the problem with your test case. I only
see 4-byte loads.
I see it with this modified testcase:
#include
#include
/* GCC uses 4-byte + 2-byte loads and stack passing */
typedef struct __attribute__((__packed__))
{
unsigned short chr;
unsigned int loc;
} GENOME_LOC_TYPE_1;
/* GCC uses 8-byte loads and register passing even though sizeof = 6 */
typedef struct __attribute__((__packed__))
{
unsigned chr:16;
unsigned loc:32;
} GENOME_LOC_TYPE_2;
//#define GENOME_LOC_TYPE GENOME_LOC_TYPE_1
#define GENOME_LOC_TYPE GENOME_LOC_TYPE_2
static __attribute__((__noclone__,__noinline__))
int f(GENOME_LOC_TYPE x)
{
return x.loc;
}
GENOME_LOC_TYPE h;
GENOME_LOC_TYPE *g = &h;
int
main()
{
printf ("%d %d\n", sizeof (GENOME_LOC_TYPE),
__alignof__(GENOME_LOC_TYPE));
return f(*g);
}
Both definitions have a (sizeof = 6, alignof = 1) but GCC loads the
second with an 8-byte load. It's really an ugly bug if I understood it
correctly, because I would have expected the second struct to have
sizeof = 8. The two final bytes are not padding, they are what's left
of the unsigned int from which the bitfields are carved. If that were
the correct fix for the bug, it would be a change to the ABI.
Paolo
Re: Possible Bug
On Mon, Mar 28, 2011 at 12:42 PM, Paolo Bonzini wrote:
> On 03/27/2011 06:27 AM, Ian Lance Taylor wrote:
>>
>> Nathan Boley writes:
>>
>>> In a much larger application, I was getting a weird segfault that an
>>> assignment to a temporary variable fixed. I distilled the example into
>>> the attached "test_case.c". When I run test_case.c under valgrind I
>>> get a memory read error, and it segfaults with electric fence, but I'm
>>> not actually able to get a true segfault. However, I am pretty sure
>>> that the same issue was causing the segfault in my application.
>>
>> There is nothing wrong if gcc is reading an 8-byte value at an 8-byte
>> aligned address.
>
> Note the struct is packed, so alignof = 1.
>
>> That said, I could not recreate the problem with your test case. I only
>> see 4-byte loads.
>
> I see it with this modified testcase:
>
> #include
> #include
>
> /* GCC uses 4-byte + 2-byte loads and stack passing */
> typedef struct __attribute__((__packed__))
> {
> unsigned short chr;
> unsigned int loc;
> } GENOME_LOC_TYPE_1;
>
> /* GCC uses 8-byte loads and register passing even though sizeof = 6 */
> typedef struct __attribute__((__packed__))
> {
> unsigned chr :16;
> unsigned loc :32;
> } GENOME_LOC_TYPE_2;
>
> //#define GENOME_LOC_TYPE GENOME_LOC_TYPE_1
> #define GENOME_LOC_TYPE GENOME_LOC_TYPE_2
>
> static __attribute__((__noclone__,__noinline__))
> int f(GENOME_LOC_TYPE x)
> {
> return x.loc;
> }
>
> GENOME_LOC_TYPE h;
> GENOME_LOC_TYPE *g = &h;
>
> int
> main()
> {
> printf ("%d %d\n", sizeof (GENOME_LOC_TYPE),
> __alignof__(GENOME_LOC_TYPE));
> return f(*g);
> }
>
>
> Both definitions have a (sizeof = 6, alignof = 1) but GCC loads the second
> with an 8-byte load. It's really an ugly bug if I understood it correctly,
> because I would have expected the second struct to have sizeof = 8. The two
> final bytes are not padding, they are what's left of the unsigned int from
> which the bitfields are carved. If that were the correct fix for the bug,
> it would be a change to the ABI.
At expansion time we have the following for the call argument:
unit size
align 8 symtab 0 alias set -1 canonical type 0x75b29540
which looks ok to me. expand generates a MEM of BLKmode:
(mem/s:BLK (reg/f:DI 62) [0 MEM[(struct GENOME_LOC_TYPE_2 *)g.0_1]+0 S6 A8])
which is also ok. But then calls.c calls move_block_to_reg and messes
up via operand_subword_force (mem, 0, BLKmode) which simply makes
a DImode mem out of it.
Richard.
Re: inline assembly vs. intrinsic functions
2011/3/24 Ian Lance Taylor : > roy rosen writes: > >>> You build a RECORD_TYPE holding the fields you want to return. You >>> define the appropriate builtin functions to return that record type. >> >> How is that done? using define_insn? How do I tell it to return a struct? >> Is there an example I can look at? > > A RECORD_TYPE is what gcc generates when you define a struct in your > source code. For an example of a backend building a struct, see, e.g., > ix86_build_builtin_va_list_abi. > > When you define your builtin functions in TARGET_INIT_BUILTINS you > specify the argument types and the return type, typically by building a > FUNCTION_TYPE and passing it to add_builtin_function. To define a > builtin which returns a struct, just arrange for the return type of the > FUNCTION_TYPE that you pass to add_builtin_function be the RECORD_TYPE > that you built. I understood this part. What I don't understand is: In addition to adding the builtin function, in the md file I have a define_insn for each built in, for example: (define_insn "A_ssodssxx2w" [(set (match_operand:SI 0 "register_operand" "=d ") (unspec:SI [(match_operand:SI 1 "register_operand" "d ") (match_operand:SI 2 "register_operand" "d ")] UNSPEC_A_SSODSSXX2W))] "" "ssodssxx.2w %2,%1,%0 %!" ) How do I create something equivalent which would have an rtl set expression to the structure. Thanks, Roy. > > Ian >
Re: Possible Bug
On 03/28/2011 01:06 PM, Richard Guenther wrote:
/* GCC uses 8-byte loads and register passing even though sizeof = 6 */
typedef struct __attribute__((__packed__))
{
unsigned chr:16;
unsigned loc:32;
} GENOME_LOC_TYPE_2;
//#define GENOME_LOC_TYPE GENOME_LOC_TYPE_1
#define GENOME_LOC_TYPE GENOME_LOC_TYPE_2
static __attribute__((__noclone__,__noinline__))
int f(GENOME_LOC_TYPE x)
{
return x.loc;
}
GENOME_LOC_TYPE h;
GENOME_LOC_TYPE *g =&h;
int
main()
{
printf ("%d %d\n", sizeof (GENOME_LOC_TYPE),
__alignof__(GENOME_LOC_TYPE));
return f(*g);
}
Both definitions have a (sizeof = 6, alignof = 1) but GCC loads the second
with an 8-byte load. It's really an ugly bug if I understood it correctly,
because I would have expected the second struct to have sizeof = 8. The two
final bytes are not padding, they are what's left of the unsigned int from
which the bitfields are carved. If that were the correct fix for the bug,
it would be a change to the ABI.
At expansion time we have the following for the call argument:
unit size
align 8 symtab 0 alias set -1 canonical type 0x75b29540
which looks ok to me.
It already isn't, why is the alignment 8 if __alignof__
(GENOME_LOC_TYPE_2) is 1?
The other question is a layout question, should the packed attribute
affect the removal of padding from the last bitfield element? That's a
very different kind of padding, and it affects whether the size of the
struct should be 6 or 8? Note this is slightly different from the
problem in -Wpacked-bitfield-compat.
In fact, should the poster's desired layout (the same as
GENOME_LOC_TYPE_1, I guess) be achievable at all with bitfields, even in
combination with the packed attribute?
Paolo
Re: Possible Bug
On Mon, Mar 28, 2011 at 1:36 PM, Paolo Bonzini wrote:
> On 03/28/2011 01:06 PM, Richard Guenther wrote:
>>>
>>> /* GCC uses 8-byte loads and register passing even though sizeof = 6 */
>>> typedef struct __attribute__((__packed__))
>>> {
>>> unsigned chr :16;
>>> unsigned loc :32;
>>> } GENOME_LOC_TYPE_2;
>>>
>>> //#define GENOME_LOC_TYPE GENOME_LOC_TYPE_1
>>> #define GENOME_LOC_TYPE GENOME_LOC_TYPE_2
>>>
>>> static __attribute__((__noclone__,__noinline__))
>>> int f(GENOME_LOC_TYPE x)
>>> {
>>> return x.loc;
>>> }
>>>
>>> GENOME_LOC_TYPE h;
>>> GENOME_LOC_TYPE *g =&h;
>>>
>>> int
>>> main()
>>> {
>>> printf ("%d %d\n", sizeof (GENOME_LOC_TYPE),
>>> __alignof__(GENOME_LOC_TYPE));
>>> return f(*g);
>>> }
>>>
>>>
>>> Both definitions have a (sizeof = 6, alignof = 1) but GCC loads the
>>> second
>>> with an 8-byte load. It's really an ugly bug if I understood it
>>> correctly,
>>> because I would have expected the second struct to have sizeof = 8. The
>>> two
>>> final bytes are not padding, they are what's left of the unsigned int
>>> from
>>> which the bitfields are carved. If that were the correct fix for the
>>> bug,
>>> it would be a change to the ABI.
>>
>> At expansion time we have the following for the call argument:
>>
>> > type> size
>> unit size
>> align 8 symtab 0 alias set -1 canonical type 0x75b29540
>>
>> which looks ok to me.
>
> It already isn't, why is the alignment 8 if __alignof__ (GENOME_LOC_TYPE_2)
> is 1?
>
> The other question is a layout question, should the packed attribute affect
> the removal of padding from the last bitfield element? That's a very
> different kind of padding, and it affects whether the size of the struct
> should be 6 or 8? Note this is slightly different from the problem in
> -Wpacked-bitfield-compat.
>
> In fact, should the poster's desired layout (the same as GENOME_LOC_TYPE_1,
> I guess) be achievable at all with bitfields, even in combination with the
> packed attribute?
Btw, this looks like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
Richard.
> Paolo
>
RE: Supporting multiple pointer sizes in GCC
>? MIPS has two pointer sizes, but a given compilation (gcc > invocation) uses only one of them, it comes from the chosen ABI. Yes, it looks like MIPS have got 2 ABIs - 32bit and 64bit. The choice of the ABI is controlled through a command line option '-march=arch'. Therefore in MIPS it doesn't look possible to have 2 pointers of different sizes existing simultaneously inside a single executable. Whereas, what I am looking forward to do is adding some target specific data attributes, say data16 and data32. In a simple test case I should be able to declare two different pointer variables using these attributes as following: char * ptrABC __attribute__ (data16); char * ptrXYZ __attribute__ (data32); The size of ptrABC should be 16bits and that of ptrXYZ should be 32bits. Will it be possible to do something like this in GCC? Regards, Jayant -Original Message- From: Paul Koning [mailto:paul_kon...@dell.com] Sent: Friday, March 25, 2011 11:20 PM To: DJ Delorie Cc: Jayant R. Sonar; gcc@gcc.gnu.org Subject: Re: Supporting multiple pointer sizes in GCC On Mar 25, 2011, at 1:37 PM, DJ Delorie wrote: > > "Jayant R. Sonar" writes: >> Is it possible to support multiple pointer sizes (e.g. 16bit, 32bit) >> which can co-exist in single compilation unit? >> Whether it is supported in GCC now? >> Is there any other architecture which has this feature already >> implemented? > > Yes, there are three that I know of - mips64, s390 (tpf), and m32c. ? MIPS has two pointer sizes, but a given compilation (gcc invocation) uses only one of them, it comes from the chosen ABI. paul
Re: Possible Bug
Hi, On Mon, 28 Mar 2011, Paolo Bonzini wrote: > > At expansion time we have the following for the call argument: > > > >> type > size > > unit size > > align 8 symtab 0 alias set -1 canonical type 0x75b29540 > > > > which looks ok to me. > > It already isn't, why is the alignment 8 if __alignof__ > (GENOME_LOC_TYPE_2) is 1? The aligns are printed in bits. It really is okay, as is the MEM. > The other question is a layout question, should the packed attribute > affect the removal of padding from the last bitfield element? A hypothetical question because we can't change this behaviour after about 15 years. Even if we could I'd argue that the current behaviour is correct (because we lack another attribute that would say 'and please also pack arrays of this type tightly', which then would finally imply that final padding is also removed, and hence we'd then hit this very same bug with testcases using _that_ attribute instead of packed). As some digging shows, already GCC 1.35 had effectively the same code. As soon as parameters are passed in registers GCC loads the parts fitting into registers as full words. We could simply sorry() for these cases, as they never worked correctly. Though I suppose that's quite unforgiving, as most of the time (struct in question not passing page border) it works fine. Ciao, Michael.
Re: Possible Bug
On 03/28/2011 02:27 PM, Michael Matz wrote: unit size align 8 symtab 0 alias set -1 canonical type 0x75b29540 which looks ok to me. It already isn't, why is the alignment 8 if __alignof__ (GENOME_LOC_TYPE_2) is 1? The aligns are printed in bits. It really is okay, as is the MEM. Uff, I'm always confused by align being printed after the unit size. As some digging shows, already GCC 1.35 had effectively the same code. As soon as parameters are passed in registers GCC loads the parts fitting into registers as full words. We could simply sorry() for these cases, as they never worked correctly. Though I suppose that's quite unforgiving, as most of the time (struct in question not passing page border) it works fine. We should warn, I think. Paolo
Proposed solution for bug 44384, "builtin_object_size_ treatment of multidimensional arrays is unexpected"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am trying to get a solution for bug 44384, "builtin_object_size_
treatment of multidimensional arrays is unexpected", and would like
to know if my approach is right.
First, a quick recap of the issue.
The issue at hand is that __builtin_object_size(ptr, type) always treats
multidimensional arrays as whole objects instead of treating each
dimension as a sub-object which results in unexpected results from
__builtin_object_size(ptr, type) when type & 1 does not equal zero.
As this is of significant interest, I have started to work on a possible
solution to this issue. Basically, the function, addr_objec_size(),
appears to be the heart of the __builtin_object_size() function.
However, after tracing the gcc source to see how the sizeof operator
works as well as checking to see how gcc handles cases such as:
void foo(char *)
{
//stuff
}
int main()
{
char c[10][20][30];
foo(c);
foo(c[2]);
}
I am of the opinion that addr_object_size() lacks the necessary
information to correctly determine which dimension of c is really being
looked at. Therefore, I am looking at ways to somehow append some of
the original type data to the arguments passed in to addr_object_size()
and then use that information where appropriate. One approach I am
considering is to append the data to the end of the tree before
fold_unary_loc() returns with the hopes that the appended data will be
available to addr_object_size().
However, I would like some feedback as to whether this is the proper
approach to take, and if so, what the best function to attempt this in
would be. I have already tried convert_for_assignment() (which seems to
be too early). This leads me to believe that the function I am looking
for might be one of the functions that handle the conversion of the
generic tree to the gimple tree.
Again any feedback that would help point me in the right direction would
be appreciated.
Thanks,
=mark
- --
Mark Eklund
Software Engineer
Product Development
mekl...@cisco.com
Cisco Systems, Inc.
170 West Tasman Dr
San Jose, CA 95134 USA
United States
Cisco.com - http://www.cisco.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk2QkvwACgkQQ0N2P/sOd5he+QCgltwvrRjSvOwSUgaDxLzLqasD
husAoLZQ+FUNx5smq4VyCo9heJl+VT2a
=myNY
-END PGP SIGNATURE-
[Fwd: GCC 4.6.0 Released]
Seems to be working well on Solaris 8 Sparc thus far. No surprises. I'll
post a result set once the tests are complete but for now I see the output
from hello.c is exactly as expected :
# pwd
/tmp/test
# cat -n hello.c
1 #include
2
3 int
4 main(int argc, char *argv[])
5 {
6 printf ( "Hello World!\n" );
7 return (0);
8 }
# gcc --version
gcc (Blastwave.org Inc. Mon Mar 28 06:28:14 GMT 2011) 4.6.0
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# gcc -mcpu=v8 -mno-app-regs -mno-vis -m32 -S -o hello.s hello.c
# cat hello.s
.file "hello.c"
.section".rodata"
.align 8
.LLC0:
.asciz "Hello World!"
.section".text"
.align 4
.global main
.type main, #function
.proc 04
main:
save%sp, -96, %sp
st %i0, [%fp+68]
st %i1, [%fp+72]
sethi %hi(.LLC0), %g1
or %g1, %lo(.LLC0), %o0
callputs, 0
nop
mov 0, %g1
mov %g1, %i0
restore
jmp %o7+8
nop
.size main, .-main
.ident "GCC: (Blastwave.org Inc. Mon Mar 28 06:28:14 GMT 2011)
4.6.0"
#
This is precisely the same as the output from 4.5.2 :
# diff /export/medusa/dclarke/build/test/hello_gcc_sparcv7.s hello.s
25c25
< .ident "GCC: (Blastwave.org Inc. Thu Dec 16 18:30:45 GMT 2010)
4.5.2"
---
> .ident "GCC: (Blastwave.org Inc. Mon Mar 28 06:28:14 GMT 2011)
4.6.0"
#
Thus all is well.
GCC is the ultimate open source project in my opinion in that it gives
birth to everything else. Well, that makes binutils the pen-ultimate I
guess. :-)
Thank you to the massive collection of Red Hat guys and volunteers and
to a massive colleection of truely gifted programmers and the FSF for
making GCC possible.
--
Dennis Clarke
dcla...@opensolaris.ca <- related to the open source Solaris
dcla...@blastwave.org <- related to open source for Solaris
pub 1024D/FA35B44B 2008-08-17
fingerprint = B766 3250 1511 40C8 088A 12B9 1D93 6C72 FA35 B44B
--
/~\ The ASCII Ribbon Campaign
\ /No HTML/RTF in email
X No Word docs in email
/ \ Respect for open standards
Thought du jour
---
In fact, my main conclusion after spending ten
years of my life working on the TeX project is
that software is hard. It.s harder than anything
else I.ve ever had to do. Donald E. Knuth, 5 Oct 2001,
Professor Emeritus of The Art of Computer Programming
at the Technische Universitat M�chen in a lecture
entitled "All Questions Answered".
123456789+123456789+123456789+123456789+123456789+123456789+1234
MESSAGE ENDS --
Original Message
Subject: GCC 4.6.0 Released
From:"Jakub Jelinek"
Date:Mon, March 28, 2011 03:25
To: gcc-annou...@gcc.gnu.org
Cc: gcc@gcc.gnu.org
--
The GNU Compiler Collection version 4.6.0 has been released.
GCC 4.6.0 is a major release, containing substantial new functionality
not available in GCC 4.5.x or previous GCC releases.
The "link-time optimization" framework introduced in GCC 4.5.0 has been
significantly improved in this release, it is now possible to compile
very large applications like Mozilla or GCC itself with LTO.
GCC can now partially inline functions, inlining just hot short path
to exit and keeping the rest of the function out of line.
Support for the upcoming C++0x standard has been notably improved,
Fortran 2003 and 2008 has been greatly extended and many other frontends
undergone substantial changes as well.
Many other improvements have been added and more than thousand of bugs
have been fixed in various parts of the compiler collection.
See:
http://gcc.gnu.org/gcc-4.6/changes.html
for more information about changes in GCC 4.6.0.
This release is available from the FTP servers listed here:
http://www.gnu.org/order/ftp.html
The release is in gcc/gcc-4.6.0/ subdirectory.
If you encounter difficulties using GCC 4.6, please do not contact me
directly. Instead, please visit http://gcc.gnu.org for information
about getting help.
As always, a vast number of people contributed to this GCC releases --
far too many to thank individually!
Re: Possible Bug
On Mon, Mar 28, 2011 at 3:36 PM, Paolo Bonzini wrote: > On 03/28/2011 02:27 PM, Michael Matz wrote: >>> type>>> size unit size align 8 symtab 0 alias set -1 canonical type 0x75b29540 which looks ok to me. >>> >>> It already isn't, why is the alignment 8 if __alignof__ >>> (GENOME_LOC_TYPE_2) is 1? >> >> The aligns are printed in bits. It really is okay, as is the MEM. > > Uff, I'm always confused by align being printed after the unit size. > >> As some digging shows, already GCC 1.35 had effectively the same code. >> As soon as parameters are passed in registers GCC loads the parts fitting >> into registers as full words. We could simply sorry() for these cases, as >> they never worked correctly. Though I suppose that's quite unforgiving, >> as most of the time (struct in question not passing page border) it works >> fine. > > We should warn, I think. We should fix the bug ;) Richard. > Paolo >
Re: Proposed solution for bug 44384, "builtin_object_size_ treatment of multidimensional arrays is unexpected"
On Mon, Mar 28, 2011 at 3:54 PM, Mark Eklund wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I am trying to get a solution for bug 44384, "builtin_object_size_
> treatment of multidimensional arrays is unexpected", and would like
> to know if my approach is right.
>
> First, a quick recap of the issue.
>
> The issue at hand is that __builtin_object_size(ptr, type) always treats
> multidimensional arrays as whole objects instead of treating each
> dimension as a sub-object which results in unexpected results from
> __builtin_object_size(ptr, type) when type & 1 does not equal zero.
>
> As this is of significant interest, I have started to work on a possible
> solution to this issue. Basically, the function, addr_objec_size(),
> appears to be the heart of the __builtin_object_size() function.
> However, after tracing the gcc source to see how the sizeof operator
> works as well as checking to see how gcc handles cases such as:
>
> void foo(char *)
> {
> //stuff
> }
>
> int main()
> {
> char c[10][20][30];
>
> foo(c);
> foo(c[2]);
> }
>
> I am of the opinion that addr_object_size() lacks the necessary
> information to correctly determine which dimension of c is really being
> looked at. Therefore, I am looking at ways to somehow append some of
> the original type data to the arguments passed in to addr_object_size()
> and then use that information where appropriate. One approach I am
> considering is to append the data to the end of the tree before
> fold_unary_loc() returns with the hopes that the appended data will be
> available to addr_object_size().
>
> However, I would like some feedback as to whether this is the proper
> approach to take, and if so, what the best function to attempt this in
> would be. I have already tried convert_for_assignment() (which seems to
> be too early). This leads me to believe that the function I am looking
> for might be one of the functions that handle the conversion of the
> generic tree to the gimple tree.
>
> Again any feedback that would help point me in the right direction would
> be appreciated.
What do you want to do with the information from __builtin_object_size?
Note that it was invented for a single special reason, it is probably not
suitable for anything else (and its somewhat fragile implementation shouldn't
be complicated by other usages).
Richard.
> Thanks,
>
> =mark
>
> - --
> Mark Eklund
> Software Engineer
> Product Development
> mekl...@cisco.com
> Cisco Systems, Inc.
> 170 West Tasman Dr
> San Jose, CA 95134 USA
> United States
> Cisco.com - http://www.cisco.com
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk2QkvwACgkQQ0N2P/sOd5he+QCgltwvrRjSvOwSUgaDxLzLqasD
> husAoLZQ+FUNx5smq4VyCo9heJl+VT2a
> =myNY
> -END PGP SIGNATURE-
>
Re: [C++0x] Range-based for statements and ADL
On 03/25/2011 06:13 AM, Rodrigo Rivas wrote: On Wed, Mar 23, 2011 at 5:46 PM, Jason Merrill wrote: Yep. Here is the wording that we approved today: [snip] Nice. Thank you. Could you update your patch to match the final wording? Thanks, Jason
Bootstrap failure on sparc-sun-solaris2.10
Hi. This morning's build on sparc-sun-solaris2.10 failed for me; the error message in 'stage_2' is below: options.c:753:3: error: enum conversion in initialization is invalid in C++ [-Werror=c++-compat] options.c:753:3: error: (near initialization for 'global_options_init.x_sparc_cpu_and_features') [-Werror=c++-compat] options.c:755:3: error: enum conversion in initialization is invalid in C++ [-Werror=c++-compat] options.c:755:3: error: (near initialization for 'global_options_init.x_sparc_cpu') [-Werror=c++-compat] cc1: all warnings being treated as errors My build on Friday worked, so the likely culprit is this change from today: 2011-03-28 Joseph Myers * config/sparc/sparc-opts.h: New. * config/sparc/sparc.c (sparc_handle_option, sparc_select, sparc_cpu, fpu_option_set, TARGET_HANDLE_OPTION): Remove. (sparc_option_override): Store processor_type enumeration rather than string in cpu_default. Remove name and enumeration from cpu_table. Directly default -mcpu then default -mtune from -mcpu without using sparc_select. Use target_flags_explicit instead of fpu_option_set. * config/sparc/sparc.h (enum processor_type): Move to sparc-opts.h. (sparc_cpu, struct sparc_cpu_select, sparc_select): Remove. * config/sparc/sparc.opt (config/sparc/sparc-opts.h): New HeaderInclude entry. (mcpu=, mtune=): Use Var and Enum. (sparc_processor_type): New Enum and EnumValue entries. The relevant lines of the auto-generated 'options.c' file look like this: 752: 0, /* sparc_cmodel_string */ 753: 0, /* sparc_cpu_and_features */ 754: 0, /* sparc_std_struct_return */ 755: 0, /* sparc_cpu */ 756: 0, /* asm_file_name */ Thanks, as always, to everyone working on GCC. Art Haas
Re: GCC 4.6.0 Released
Jakub Jelinek : > The GNU Compiler Collection version 4.6.0 has been released. Compilation failure on Cygwin: ../../../libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error: fenv.h: No such file or directory compilation terminated. make[3]: *** [bid_decimal_globals.o] Error 1 Configured as: ../configure --prefix=/opt/gcc-4.6.0 -v --enable-bootstrap --enable-version-specific-runtime-libs --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=c,c++ --disable-symvers --enable-libgomp --enable-libssp --enable-threads=posix --with-arch=core2 --with-tune=generic --enable-libgcj-sublibs Best regards Piotr Wyderski
Re: GCC 4.6.0 Released
2011/3/28 Piotr Wyderski : > Jakub Jelinek : > >> The GNU Compiler Collection version 4.6.0 has been released. > > Compilation failure on Cygwin: > > ../../../libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error: > fenv.h: > No such file or directory > compilation terminated. > make[3]: *** [bid_decimal_globals.o] Error 1 > > Configured as: > > ../configure --prefix=/opt/gcc-4.6.0 -v --enable-bootstrap > --enable-version-specific-runtime-libs --enable-static > --enable-shared --enable-shared-libgcc --disable-__cxa_atexit > --with-gnu-ld --with-gnu-as --with-dwarf2 > --disable-sjlj-exceptions --enable-languages=c,c++ --disable-symvers > --enable-libgomp --enable-libssp > --enable-threads=posix --with-arch=core2 --with-tune=generic > --enable-libgcj-sublibs > > Best regards > Piotr Wyderski Piotr, this is a known issue and strictly cygwin related. Please update your cygwin environment to newest version, or disable decimal-floating point by option. Regards, Kai
Re: inline assembly vs. intrinsic functions
roy rosen writes: > 2011/3/24 Ian Lance Taylor : >> roy rosen writes: >> You build a RECORD_TYPE holding the fields you want to return. You define the appropriate builtin functions to return that record type. >>> >>> How is that done? using define_insn? How do I tell it to return a struct? >>> Is there an example I can look at? >> >> A RECORD_TYPE is what gcc generates when you define a struct in your >> source code. For an example of a backend building a struct, see, e.g., >> ix86_build_builtin_va_list_abi. >> >> When you define your builtin functions in TARGET_INIT_BUILTINS you >> specify the argument types and the return type, typically by building a >> FUNCTION_TYPE and passing it to add_builtin_function. To define a >> builtin which returns a struct, just arrange for the return type of the >> FUNCTION_TYPE that you pass to add_builtin_function be the RECORD_TYPE >> that you built. > > I understood this part. > What I don't understand is: > In addition to adding the builtin function, in the md file I have a > define_insn for each built in, for example: > > (define_insn "A_ssodssxx2w" > [(set (match_operand:SI 0 "register_operand" "=d ") > (unspec:SI [(match_operand:SI 1 "register_operand" "d ") > (match_operand:SI 2 "register_operand" "d ")] > UNSPEC_A_SSODSSXX2W))] > "" > "ssodssxx.2w %2,%1,%0 %!" > ) > > How do I create something equivalent which would have an rtl set > expression to the structure. At the RTL level the structure doesn't matter. Your instruction presumably sets some registers. A register is just a register, it doesn't have a type. In TARGET_EXPAND_BUILTIN you need to pick up the two registers and assemble them into a PARALLEL. You're going to build REGs to pass to the insn pattern. Then do something along the lines of: ret0 = gen_rtx_EXPR_LIST (VOIDmode, reg0, const0_rtx); ret1 = gen_rtx_EXPR_LIST (VOIDmode, reg1, const1_rtx); ret = gen_rtx_PARALLEL (??mode, gen_rtvec (2, reg0, reg1)); tree nt = build_qualified_type (struct_type, TYPE_QUAL_CONST); target = assign_temp (nt, 0, 0, 1); emit_group_store (target, ret, struct_type, ??); Ian
Re: Bootstrap comparison failure! (gcc 4.6.x with -O3)
On 03-27 09:42, Andi Kleen wrote: > Witold Baryluk writes: > > > > make BOOT_CFLAGS="$CFLAGS -flto" CFLAGS_FOR_BUILD="$CFLAGS" > > CXXFLAGS_FOR_BUILD="$CXXFLAGS" bootstrap > > Easier is to configure with --with-build-config=bootstrap-lto > then you don't need all the magic CFLAGS lines. As you see I actually use --with-build-config=bootstrap-lto. :) Will try without manually setting CFLAGS. The problem with documentation is that not all aspects of build are explained on build instruction webpage. So I'm just experimenting, and looking what will happen. > > > And then waited > > > > I actually waited 5 days... (each file compiled about 45minutes on average, > > eating 100% of CPU). Normally whole gcc compiles in 25 minutes on this > > machine. > > It sounds like you don't have enough memory? Did you swap? LTO (or > rather the first phase of it) needs quite a bit more memory than a > normal build. I suspect you don't want to do this with less than 4GB, > better 8G. No. cc1 uses about 65MB of ram. Plenty of free RAM, and no swaping. Machine have 2GB of RAM. > > If you have /tmp in shmfs it is also much worse because there will > be large temporary files in memory too (workaround is to use > TMPDIR=/some/dir/on/disk) Yes, actually TMP/TEMP/TMPDIR variables are set just beforce ./configure... and points to fast and big file system. > > > > > After wait I got this: > > You have to use -frandom-seed=1 to avoid LTO bootstrap failures. > If you use the build config line above that is done by default. Ok. I will try random-seed. Thanks! -- Witold Baryluk JID: witold.baryluk // jabster.pl signature.asc Description: Digital signature
Re: GCC 4.6.0 Released
> this is a known issue and strictly cygwin related. Please update your > cygwin environment to newest version, or disable decimal-floating > point by option. Well, maybe this is known, but it is not noted on the GCC 4.6.0 release notes, nor on the target-specific installation information page at http://gcc.gnu.org/install/specific.html#x-x-cygwin Possibly one of the target maintainers might want to update that? FX
Re: GCC 4.6.0 Released
On Mon, Mar 28, 2011 at 11:52:56AM -0700, FX wrote: > > this is a known issue and strictly cygwin related. Please update your > > cygwin environment to newest version, or disable decimal-floating > > point by option. > > Well, maybe this is known, but it is not noted on the GCC 4.6.0 release > notes, nor on the target-specific installation information page at > http://gcc.gnu.org/install/specific.html#x-x-cygwin > Possibly one of the target maintainers might want to update that? I think that the right place for the note is at http://gcc.gnu.org/install/specific.html#x-x-cygwin It should say something like: Versions of Cygwin older than x.y.z fail to build the decimal floating point library, libbid. You will either need to upgrade Cygwin to a newer version or disable decimal floating point by specifying --disable-decimal-float at configure time.
[C++-0X] User-defined literals
Greetings, I am taking a new shot at user-defined literals. Compared to the previous attempt: * I have altered libcpp so that it tokenizes user defined literals in one chunk properly. * I have started work on new tree nodes and accessors. * I have (or am trying to) refine the checks for argument and template parameter. I would like to check that template literal operators have the specific non-type parameter pack: template Foo operator"" sluggo(); I looked through the internals documentation and didn't see much on this. Could anyone give me some pointers? Also, is there any preference for using VEC vs. TREE_CHAIN for making trees and accessing them? Is one sort of "modern"? Finally I am using compparms to verify that a literal operator argument list conforms to strings like: (const char*) (const char*, std::size_t) (const wchar_t*, std::size_t) ... I cant get them to work. I built a set of global trees for the argument types that I want to check. The char and number tests work. I use things like this to build the argument lists (I neglect the return type). userdef_lit_char16_str_type = build_function_type_list (void_type_node, char16_array_type_node, size_type_node, NULL_TREE); I'm hoping that this matches (const char16_t*, std::size_t) but it doesn't. Ideas? Thanks, Ed Smith-Rowland
GCC_NO_EXECUTABLES vs. libtool
We have several bug reports for 4.6.0 about failures of the form
checking dynamic linker characteristics... configure: error: Link tests are not
allowed after GCC_NO_EXECUTABLES.
http://gcc.gnu.org/PR47836
http://gcc.gnu.org/PR46586
http://gcc.gnu.org/PR45174
http://gcc.gnu.org/PR39107
The problem arising when building a cross-compiler for a GNU/Linux
target. Configure scripts like libiberty/configure.ac,
libquadmath/configure.ac, etc., use GCC_NO_EXECUTABLES. The
GCC_NO_EXECUTABLES macro checks whether a link succeeds. If it does
not, it sets gcc_no_link. If a later attempt to run a link test, the
above error is reported.
Unfortunately, on a GNU/Linux host (recall that for a target library,
the target is the host), libtool itself does a link test. From the top
level libtool.m4 file, in _LT_SYS_DYNAMIC_LINKER, in the "linux* |
k*bsd*-gnu | kopensolaris*-gnu" case:
AC_LINK_IFELSE([AC_LANG_PROGRAM([],[])],
[AS_IF([ ($OBJDUMP -p conftest$ac_exeext) 2>/dev/null | grep
"RUNPATH.*$libdir" >/dev/null],
[lt_cv_shlibpath_overrides_runpath=yes])])
That test fails when a link fails. That test must not be run when
linking fails.
Shortly after that code in libtool.m4, I see this:
if test -f /etc/ld.so.conf; then
lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s
2>/dev/null", \[$]2)); skip = 1; } { if (!skip) print \[$]0; skip = 0; }' <
/etc/ld.so.conf | $SED -e 's/#.*//;/^[ ]*hwcap[]/d;s/[:, ]/
/g;s/=[^=]*$//;s/=[^= ]* / /g;s/"//g;/^$/d' | tr '\n' ' '`
sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
fi
Testing /etc/ld.so.conf is absolutely meaningless when building a target
library for a non-native compilation. That test must not be run when
cross-compiling.
We should definitely fix this for gcc 4.6.1. However, I don't know what
the best way to fix this is. Our gcc-specific target libraries check
$with_cross_host to see if they are being built as a cross-compiled
target library. Presumably libtool doesn't want to check that.
GCC_NO_EXECUTABLES sets a gcc-specific shell variable and overrides
AC_LINK_IFELSE to test variable. libtool doesn't know anything about
that. So what should we do here?
Ian
Re: GCC_NO_EXECUTABLES vs. libtool
Hello Ian,
* Ian Lance Taylor wrote on Tue, Mar 29, 2011 at 07:39:25AM CEST:
> We have several bug reports for 4.6.0 about failures of the form
>
> checking dynamic linker characteristics... configure: error: Link tests are
> not allowed after GCC_NO_EXECUTABLES.
> Unfortunately, on a GNU/Linux host (recall that for a target library,
> the target is the host), libtool itself does a link test.
The general strategy I've been following with these is wrapping the link
test result with a cache variable, and trying to let the cache variable
be pre-set by configure.ac in the no-executables case (and adjusting
libtool/tests/no-executables.at). Then, even if the cache variable is
not set, the user can work around it.
> From the top
> level libtool.m4 file, in _LT_SYS_DYNAMIC_LINKER, in the "linux* |
> k*bsd*-gnu | kopensolaris*-gnu" case:
>
> AC_LINK_IFELSE([AC_LANG_PROGRAM([],[])],
> [AS_IF([ ($OBJDUMP -p conftest$ac_exeext) 2>/dev/null | grep
> "RUNPATH.*$libdir" >/dev/null],
>[lt_cv_shlibpath_overrides_runpath=yes])])
>
> That test fails when a link fails. That test must not be run when
> linking fails.
There's a simple workaround for the time being: pass
target_configargs='lt_cv_shlibpath_overrides_runpath=yes'
(or =no, depending on which is correct) to toplevel configure.
> Shortly after that code in libtool.m4, I see this:
>
> if test -f /etc/ld.so.conf; then
> lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s
> 2>/dev/null", \[$]2)); skip = 1; } { if (!skip) print \[$]0; skip = 0; }' <
> /etc/ld.so.conf | $SED -e 's/#.*//;/^[ ]*hwcap[]/d;s/[:,
> ]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;s/"//g;/^$/d' | tr '\n' ' '`
> sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
> fi
>
> Testing /etc/ld.so.conf is absolutely meaningless when building a target
> library for a non-native compilation. That test must not be run when
> cross-compiling.
Right. There are probably more such cases. I'm not sure how to change
the code for best results here, apart from just using /lib /usr/lib.
> We should definitely fix this for gcc 4.6.1. However, I don't know what
> the best way to fix this is. Our gcc-specific target libraries check
> $with_cross_host to see if they are being built as a cross-compiled
> target library. Presumably libtool doesn't want to check that.
> GCC_NO_EXECUTABLES sets a gcc-specific shell variable and overrides
> AC_LINK_IFELSE to test variable. libtool doesn't know anything about
> that. So what should we do here?
Well, we can introduce another variable that tells Libtool macros that
/ is not something to look at for system details. I'm not sure if
$with_sysroot can be (ab)used for that.
Cheers,
Ralf
Re: GCC_NO_EXECUTABLES vs. libtool
* Ralf Wildenhues wrote on Tue, Mar 29, 2011 at 07:55:27AM CEST:
> * Ian Lance Taylor wrote on Tue, Mar 29, 2011 at 07:39:25AM CEST:
> > Shortly after that code in libtool.m4, I see this:
> >
> > if test -f /etc/ld.so.conf; then
> > lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s
> > 2>/dev/null", \[$]2)); skip = 1; } { if (!skip) print \[$]0; skip = 0; }' <
> > /etc/ld.so.conf | $SED -e 's/#.*//;/^[ ]*hwcap[]/d;s/[:,
> > ]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;s/"//g;/^$/d' | tr '\n' ' '`
> > sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
> > fi
This code, too, is guarded by cache variables, but that's not easy to
see; lt_cv_sys_lib_search_path_spec and lt_cv_sys_lib_dlsearch_path_spec
are checked only several lines later, near the end of the macro.
So GCC (or the user) could override them too, if need be.
Cheers,
Ralf
