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 Boleynpbo...@gmail.com 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 stdio.h
#include stdlib.h
/* 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 bonz...@gnu.org wrote:
On 03/27/2011 06:27 AM, Ian Lance Taylor wrote:
Nathan Boleynpbo...@gmail.com 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 stdio.h
#include stdlib.h
/* 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:
mem_ref 0x77ff9118
type record_type 0x75b295e8 GENOME_LOC_TYPE_2 packed type_0 BLK
size integer_cst 0x75b256b8 constant 48
unit size integer_cst 0x75b25708 constant 6
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 i...@google.com: roy rosen roy.1ro...@gmail.com 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:
mem_ref 0x77ff9118
typerecord_type 0x75b295e8 GENOME_LOC_TYPE_2 packed type_0 BLK
sizeinteger_cst 0x75b256b8 constant 48
unit sizeinteger_cst 0x75b25708 constant 6
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 bonz...@gnu.org 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:
mem_ref 0x77ff9118
typerecord_type 0x75b295e8 GENOME_LOC_TYPE_2 packed type_0 BLK
sizeinteger_cst 0x75b256b8 constant 48
unit sizeinteger_cst 0x75b25708 constant 6
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 jayant.so...@kpitcummins.com 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: mem_ref 0x77ff9118 typerecord_type 0x75b295e8 GENOME_LOC_TYPE_2 packed type_0 BLK sizeinteger_cst 0x75b256b8 constant 48 unit sizeinteger_cst 0x75b25708 constant 6 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: mem_ref 0x77ff9118 typerecord_type 0x75b295e8 GENOME_LOC_TYPE_2 packed type_0 BLK sizeinteger_cst 0x75b256b8 constant 48 unit sizeinteger_cst 0x75b25708 constant 6 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 stdio.h
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#65533;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 ja...@redhat.com
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 bonz...@gnu.org wrote: On 03/28/2011 02:27 PM, Michael Matz wrote: mem_ref 0x77ff9118 typerecord_type 0x75b295e8 GENOME_LOC_TYPE_2 packed type_0 BLK sizeinteger_cst 0x75b256b8 constant 48 unit sizeinteger_cst 0x75b25708 constant 6 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 mekl...@cisco.com 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 Merrillja...@redhat.com 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 jos...@codesourcery.com * 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 ja...@redhat.com: 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 piotr.wyder...@gmail.com: Jakub Jelinek ja...@redhat.com: 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 roy.1ro...@gmail.com writes: 2011/3/24 Ian Lance Taylor i...@google.com: roy rosen roy.1ro...@gmail.com 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 bary...@smp.if.uj.edu.pl 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: templatechar... 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
[Bug rtl-optimization/48064] Optimizer produces suboptimal code for e.g. x = x ^ (x 1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48064 Jasper Neumann jasper.neumann at web dot de changed: What|Removed |Added Severity|minor |normal
[Bug c/48305] [4.7 Regression] ice at -O0: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48305
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.03.28 07:44:54
CC||jakub at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org
|gnu.org |
Target Milestone|--- |4.7.0
Summary|ice at -O0: verify_gimple |[4.7 Regression] ice at
|failed |-O0: verify_gimple failed
Ever Confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-28
07:44:54 UTC ---
Shorter testcase:
int
foo (int x, char y)
{
return (x ^ 7U y = 0) == (1U ^ x);
}
[Bug target/48308] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2011-03-28 07:47:41 UTC --- Works for me on armv5tel-linux-gnueabi with gcc-4.6-20110325 (r171529) and binutils-2.20.1 (heavily updated). Please attach the intermediate assembly file.
[Bug fortran/48298] F2003 Implement User Defined Derived Type IO (DTIO)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-28 07:48:51 UTC --- (In reply to comment #1) Created attachment 23785 [details] A starting front end only patch + if (gfc_notify_std (GFC_STD_F2003, Fortran 2003: DT format + specifier not allowed at %C) == FAILURE) I somehow have parse problems; it sounds to me as if in Fortran 2003 the DT specifier is not allowed. I would use: + if (gfc_notify_std (GFC_STD_F2003, Fortran 2003: DT format + specifier at %C) == FAILURE)
[Bug lto/48309] gcc -flto -fuse-linker-plugin generates crashing executables on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48309 --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-03-28 08:12:57 UTC --- It can be a duplicate of bug 47891.
[Bug fortran/48279] [4.6/4.7 Regression] segfault in gfc_check_vardef_context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48279 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code CC||burnus at gcc dot gnu.org Target Milestone|--- |4.6.1 Summary|segfault in |[4.6/4.7 Regression] |gfc_check_vardef_context|segfault in ||gfc_check_vardef_context --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-28 08:13:02 UTC --- (In reply to comment #4) call set(get_d_string(h), 0, 'Three') With NAG and with GCC 4.5 (and 4.3/4.4) I get the error that no specific function could be found. Thus, I mark this PR now as regression and ICE-on-invalid-code. I have not checked whether the other examples are valid or not.
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-28 08:49:47 UTC --- Could you please check if this test worked before my patch? It may have been that the failure simply went unnoticed. Thanks. Rainer
[Bug c/48190] [regression?] Huge memory use while compiling qemu-0.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48190 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.03.28 08:59:13 CC||rsandifo at gcc dot gnu.org AssignedTo|unassigned at gcc dot |rsandifo at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug debug/48041] dwarf2out emits unnecessary null byte in empty .debug_abbrev section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48041 Mark Wielaard mark at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |mark at gcc dot gnu.org |gnu.org | --- Comment #2 from Mark Wielaard mark at gcc dot gnu.org 2011-03-28 09:10:09 UTC --- Patch committed.
[Bug debug/48229] DW_TAG_type_unit has no DW_AT_producer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48229 --- Comment #5 from Jan Kratochvil jan.kratochvil at redhat dot com 2011-03-28 09:12:20 UTC --- Created attachment 23788 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23788 GDB patch attempt with ptype regressions. (In reply to comment #4) Still I believe DW_TAG_type_unit should have DW_AT_producer as it is a standalone entity - but currently it is not. I guess I have to implement your described althorithm into GDB instead. It cannot work as GDB often looks up the type without any referrer from DW_TAG_compile_unit, such as during the `ptype' GDB command. A draft patch thus has many regressions such as: -PASS: gdb.base/nofield.exp: ptype struct not_empty +FAIL: gdb.base/nofield.exp: ptype struct not_empty (GDB internal error) This means GDB will have to start full read (like -readnow) of CUs till it finds some CU referencing the specific type to find its DW_AT_producer. During scan of .debug_info for GDB partial symbols GDB currently skips over subtrees of DIEs which reference the type signature for performance reasons, it no longer can. With .gdb_index there is no GDB partial symbols scan but .gdb_index also indexes types by their name and there is no referrer ever seen during the `ptype' GDB command. So it means performance regression for non-.gdb_index case and a possible new extension/version of .gdb_index to handle it.
[Bug debug/48229] DW_TAG_type_unit has no DW_AT_producer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48229 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-28 09:22:57 UTC --- .debug_types only appears with -gdwarf-4, I don't think any gcc defaulted to that yet, so if you are talking about DW_AT_accessibility default, IMHO just assume the DWARF3+ semantics in .debug_types.
[Bug tree-optimization/48295] Incorrect code generated with dynamic floating point rounding mode switches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48295 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.28 09:31:53 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 09:31:53 UTC --- Code motion optimizations (or even CSE) have no idea about dynamic rounding mode changes, -frounding-math does not change this (this switch is only guarding expression simplifications that usually assume round-to-nearest behavior). The only mode for which I'd accept such band-aid patches is -O0. Anyway, confirmed, but long-time known with no idea when or even how this is going to be fixed. Btw, your testcase would be kindof invalid as you are not using the documented standard way of accessing fenv but using inline-asm (and we don't have a special clobber that tells GCC you touched the FP control word). As for CSE, try /* Round to upward. */ tem1 = a + b; /* Round to nearest. */ tem2 = a + b; diff = tem1 - tem2; and see it optimized to zero at compile-time. I suppose there is a duplicate bug somewhere about the general issue.
[Bug target/48297] Suboptimal optimization of boolean expression addition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48297 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.28 09:34:02 Component|c |target Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 09:34:02 UTC --- Confirmed.
[Bug target/48301] Xcode 4.0's llvm-gcc can't bootstrap gcc 4.6.0 or trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48301 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 09:35:37 UTC --- So llvm miscompiles cc1. Not a GCC bug.
[Bug driver/48306] presence of gcc subdir with . in PATH causes breakdown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48306 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.03.28 09:40:43 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 09:40:43 UTC --- Works for me. How did you configure/install GCC? What does -v output say for the compile command?
[Bug bootstrap/48307] [4.7 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48307 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 09:41:22 UTC --- Fixed.
[Bug fortran/48311] New: [Quadmath] Documentation - typo, order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48311 Summary: [Quadmath] Documentation - typo, order Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: documentation Severity: trivial Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org http://gcc.gnu.org/onlinedocs/libquadmath/strtoflt128.html The function dmath_strtopQ converts a string into a __float128 number. Should be dmath_strtopQ - strtoflt128 http://gcc.gnu.org/onlinedocs/libquadmath/quadmath_005fsnprintf.html I would move the comment from the very bottom to before the example - it is currently a bit lost there.
[Bug lto/48309] gcc -flto -fuse-linker-plugin generates crashing executables on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48309 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.03.28 09:45:36 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 09:45:36 UTC --- Please also specify the exact linker version you are using.
[Bug middle-end/48310] ask a question about expand_used_vars in cfgexpand.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48310 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 09:47:01 UTC --- Please ask questions on the GCC mailinglists, not via bugzilla.
[Bug ada/44431] [boot with C++] Conflicting exit declaration in ada/b_gnatb.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44431 --- Comment #6 from gingold at gcc dot gnu.org gingold at gcc dot gnu.org 2011-03-28 09:49:14 UTC --- Author: gingold Date: Mon Mar 28 09:49:10 2011 New Revision: 171593 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171593 Log: 2011-03-28 Tristan Gingold ging...@adacore.com PR ada/44431 * gcc-interface/Make-lang.in (ada/b_gnat1.adb): Replaces ada/b_gnat1.c. Use ada output of gnatbind. (ada/b_gnatb.adb): Ditto. (ada/b_gnat1.o, ada/b_gnatb.o): New rules. (ada.mostlyclean, ada.stage1) (ada.stage2, ada.stage3, ada.stage4, ada.stageprofile) (ada.stagefeedback): Adjust. * gcc-interface/Makefile.in (b_gnatl.adb): Replaces b_gnatl.c Use ada output of gnatbind. (b_gnatm.adb): Ditto. (b_gnatl.o, b_gnatm.o): New rules. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Make-lang.in trunk/gcc/ada/gcc-interface/Makefile.in
[Bug ada/44431] [boot with C++] Conflicting exit declaration in ada/b_gnatb.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44431 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-03-28 09:53:27 UTC --- Presumably. Reopen if not.
[Bug tree-optimization/48295] Incorrect code generated with dynamic floating point rounding mode switches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48295 --- Comment #3 from Frederic Riss frederic.riss at gmail dot com 2011-03-28 09:58:50 UTC --- In bug #34678 I thought you were agreeing with Joseph that -frounding-math had a more general meaning than the one you are expressing here, but I get your point that a more general solution should be implemented. Regarding the validity of the testcase, I took glibc's implementation of fesetround that I inlined. I did that because I saw that /usr/include/fenv.h has provisions for including inline versions of the fenv routines, although it's not the case yet for x86. So I guess it's possible that someday you get exactly that situation even though people are using the standard routines to switch rounding mode. In fact my private port does exactly this. Can you think of other places than CSE that would exhibit these issues? Unfortunately, I have to put some band-aids into place for our numerical analysts to be able to do their jobs.
[Bug tree-optimization/48134] [4.6 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1085 with custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48134 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 10:14:41 UTC --- Author: rguenth Date: Mon Mar 28 10:14:34 2011 New Revision: 171595 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171595 Log: 2011-03-28 Richard Guenther rguent...@suse.de Backport from mainline 2011-03-24 Richard Guenther rguent...@suse.de PR middle-end/48269 * tree-object-size.c (addr_object_size): Do not double-account for MEM_REF offsets. * gcc.dg/builtin-object-size-10.c: New testcase. 2011-03-22 Richard Guenther rguent...@suse.de PR tree-optimization/48228 * tree-vrp.c (vrp_visit_phi_node): Do not stop propagating for single-arg PHIs. * gcc.dg/Wstrict-overflow-23.c: New testcase. 2011-03-17 Richard Guenther rguent...@suse.de PR middle-end/48134 * tree-ssa.c (insert_debug_temp_for_var_def): If we propagated a value make sure to fold the statement. * gcc.dg/pr48134.c: New testcase. 2011-03-15 Richard Guenther rguent...@suse.de PR middle-end/48031 * fold-const.c (fold_indirect_ref_1): Do not create new variable-sized or variable-indexed array accesses when in gimple form. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/Wstrict-overflow-23.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/builtin-object-size-10.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48134.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/fold-const.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-object-size.c branches/gcc-4_6-branch/gcc/tree-ssa.c branches/gcc-4_6-branch/gcc/tree-vrp.c
[Bug c/48228] incorrect signed overflow warning when only 0 and 1 are used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48228 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 10:14:40 UTC --- Author: rguenth Date: Mon Mar 28 10:14:34 2011 New Revision: 171595 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171595 Log: 2011-03-28 Richard Guenther rguent...@suse.de Backport from mainline 2011-03-24 Richard Guenther rguent...@suse.de PR middle-end/48269 * tree-object-size.c (addr_object_size): Do not double-account for MEM_REF offsets. * gcc.dg/builtin-object-size-10.c: New testcase. 2011-03-22 Richard Guenther rguent...@suse.de PR tree-optimization/48228 * tree-vrp.c (vrp_visit_phi_node): Do not stop propagating for single-arg PHIs. * gcc.dg/Wstrict-overflow-23.c: New testcase. 2011-03-17 Richard Guenther rguent...@suse.de PR middle-end/48134 * tree-ssa.c (insert_debug_temp_for_var_def): If we propagated a value make sure to fold the statement. * gcc.dg/pr48134.c: New testcase. 2011-03-15 Richard Guenther rguent...@suse.de PR middle-end/48031 * fold-const.c (fold_indirect_ref_1): Do not create new variable-sized or variable-indexed array accesses when in gimple form. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/Wstrict-overflow-23.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/builtin-object-size-10.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48134.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/fold-const.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-object-size.c branches/gcc-4_6-branch/gcc/tree-ssa.c branches/gcc-4_6-branch/gcc/tree-vrp.c
[Bug middle-end/48269] [4.6 Regression] Incorrect fortify warning for a packed struct member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48269 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 10:14:40 UTC --- Author: rguenth Date: Mon Mar 28 10:14:34 2011 New Revision: 171595 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171595 Log: 2011-03-28 Richard Guenther rguent...@suse.de Backport from mainline 2011-03-24 Richard Guenther rguent...@suse.de PR middle-end/48269 * tree-object-size.c (addr_object_size): Do not double-account for MEM_REF offsets. * gcc.dg/builtin-object-size-10.c: New testcase. 2011-03-22 Richard Guenther rguent...@suse.de PR tree-optimization/48228 * tree-vrp.c (vrp_visit_phi_node): Do not stop propagating for single-arg PHIs. * gcc.dg/Wstrict-overflow-23.c: New testcase. 2011-03-17 Richard Guenther rguent...@suse.de PR middle-end/48134 * tree-ssa.c (insert_debug_temp_for_var_def): If we propagated a value make sure to fold the statement. * gcc.dg/pr48134.c: New testcase. 2011-03-15 Richard Guenther rguent...@suse.de PR middle-end/48031 * fold-const.c (fold_indirect_ref_1): Do not create new variable-sized or variable-indexed array accesses when in gimple form. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/Wstrict-overflow-23.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/builtin-object-size-10.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48134.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/fold-const.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-object-size.c branches/gcc-4_6-branch/gcc/tree-ssa.c branches/gcc-4_6-branch/gcc/tree-vrp.c
[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031 --- Comment #18 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 10:14:39 UTC --- Author: rguenth Date: Mon Mar 28 10:14:34 2011 New Revision: 171595 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171595 Log: 2011-03-28 Richard Guenther rguent...@suse.de Backport from mainline 2011-03-24 Richard Guenther rguent...@suse.de PR middle-end/48269 * tree-object-size.c (addr_object_size): Do not double-account for MEM_REF offsets. * gcc.dg/builtin-object-size-10.c: New testcase. 2011-03-22 Richard Guenther rguent...@suse.de PR tree-optimization/48228 * tree-vrp.c (vrp_visit_phi_node): Do not stop propagating for single-arg PHIs. * gcc.dg/Wstrict-overflow-23.c: New testcase. 2011-03-17 Richard Guenther rguent...@suse.de PR middle-end/48134 * tree-ssa.c (insert_debug_temp_for_var_def): If we propagated a value make sure to fold the statement. * gcc.dg/pr48134.c: New testcase. 2011-03-15 Richard Guenther rguent...@suse.de PR middle-end/48031 * fold-const.c (fold_indirect_ref_1): Do not create new variable-sized or variable-indexed array accesses when in gimple form. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/Wstrict-overflow-23.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/builtin-object-size-10.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48134.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/fold-const.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-object-size.c branches/gcc-4_6-branch/gcc/tree-ssa.c branches/gcc-4_6-branch/gcc/tree-vrp.c
[Bug middle-end/48269] [4.6 Regression] Incorrect fortify warning for a packed struct member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48269 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.6.1 Resolution||FIXED Known to fail||4.6.0 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 10:20:54 UTC --- Fixed.
[Bug tree-optimization/48228] incorrect signed overflow warning when only 0 and 1 are used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48228 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|c |tree-optimization Known to work||4.6.1, 4.7.0 Target Milestone|4.7.0 |4.6.1 Known to fail||4.6.0 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 10:21:54 UTC --- And 4.6.1. I'm not planning to backport further as it's also an optimization change.
[Bug tree-optimization/48134] [4.6 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1085 with custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48134 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 10:22:30 UTC --- Fixed.
[Bug target/47553] ARM neon vld1q_lane_u8 co. don't accept lanes = 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47553 --- Comment #3 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-03-28 10:23:03 UTC --- Author: rsandifo Date: Mon Mar 28 10:22:57 2011 New Revision: 171596 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171596 Log: gcc/ PR target/47553 * config/arm/predicates.md (neon_lane_number): Accept 0..15. gcc/testsuite/ PR target/47553 * gcc.target/arm/neon-vld-1.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.target/arm/neon-vld-1.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/arm/predicates.md branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/48290] FAIL: gcc.dg/vect/pr38529.c, ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1072
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48290
--- Comment #3 from Ira Rosen irar at il dot ibm.com 2011-03-28 10:30:55 UTC
---
I am going to test this patch. It checks that if we have a phi in outer loop in
the basic block after the inner loop, then this phi is really inner loop's exit
phi, i.e., its operand is defined in the inner loop.
Index: tree-vect-loop.c
===
--- tree-vect-loop.c(revision 171466)
+++ tree-vect-loop.c(working copy)
@@ -1184,11 +1184,11 @@ vect_analyze_loop_operations (loop_vec_i
print_gimple_stmt (vect_dump, phi, 0, TDF_SLIM);
}
+ /* Inner-loop loop-closed exit phi in outer-loop vectorization
+ (i.e. a phi in the tail of the outer-loop). */
if (! is_loop_header_bb_p (bb))
{
- /* inner-loop loop-closed exit phi in outer-loop vectorization
- (i.e. a phi in the tail of the outer-loop).
- FORNOW: we currently don't support the case that these phis
+ /* FORNOW: we currently don't support the case that these phis
are not used in the outerloop (unless it is double reduction,
i.e., this phi is vect_reduction_def), cause this case
requires to actually do something here. */
@@ -1202,6 +1202,32 @@ vect_analyze_loop_operations (loop_vec_i
Unsupported loop-closed phi in outer-loop.);
return false;
}
+
+ /* If PHI is used in the outer loop, we check that its operand
+ is defined in the inner loop. */
+ if (STMT_VINFO_RELEVANT_P (stmt_info))
+{
+ tree phi_op;
+ gimple op_def_stmt;
+
+ if (gimple_phi_num_args (phi) != 1)
+return false;
+
+ phi_op = PHI_ARG_DEF (phi, 0);
+ if (TREE_CODE (phi_op) != SSA_NAME)
+return false;
+
+ op_def_stmt = SSA_NAME_DEF_STMT (phi_op);
+ if (!op_def_stmt || !vinfo_for_stmt (op_def_stmt))
+return false;
+
+ if (STMT_VINFO_RELEVANT (vinfo_for_stmt (op_def_stmt))
+!= vect_used_in_outer
+ STMT_VINFO_RELEVANT (vinfo_for_stmt (op_def_stmt))
+ != vect_used_in_outer_by_reduction)
+return false;
+}
+
continue;
}
[Bug target/47553] ARM neon vld1q_lane_u8 co. don't accept lanes = 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47553 --- Comment #4 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-03-28 10:32:12 UTC --- Author: rsandifo Date: Mon Mar 28 10:32:09 2011 New Revision: 171597 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171597 Log: gcc/ PR target/47553 * config/arm/predicates.md (neon_lane_number): Accept 0..15. gcc/testsuite/ PR target/47553 * gcc.target/arm/neon-vld-1.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.target/arm/neon-vld-1.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/arm/predicates.md branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug go/48312] New: [4.7 regression] http, rpc, websocket tests hang on Solaris 2/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48312 Summary: [4.7 regression] http, rpc, websocket tests hang on Solaris 2/x86 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: r...@gcc.gnu.org Host: i386-pc-solaris2.1[01] Target: i386-pc-solaris2.1[01] Build: i386-pc-solaris2.1[01] Created attachment 23789 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23789 Minimal patch to get fd_rtems.go to compile. After the latest libgo import, the network-related libgo tests hang on Solaris 10 and 11/x86. To even get libgo to compile, I needed the attached patch to fd_rtems.go (which should better be called fd_select.go since this is what it really is). Even after that, the http, rpc, and websocket tests just hang in select, as can be seen in the pstack output from the http test: 8131:./a.out - lwp# 1 / thread# 1 fe35b3ab lwp_park (0, 0, 0) fe354e03 cond_wait_queue (de221678, de221660, 0, fe355329) + 63 fe3553a1 __cond_wait (de221678, de221660, 8045158, fe3553e9) + 89 fe3553f7 cond_wait (de221678, de221660, 80451a8, fe35542d) + 27 fe355442 pthread_cond_wait (de221678, de221660, 80451c8, fe3f7500, 18, 8045100) + 24 fe64467c __go_receive_acquire (de221660, 0, 8045218, fe641cb9, 80451f8, 80451f8) + 7c fe6447f1 __go_receive_small_closed (de221660, 0, 0, fe87d6c0, 16) + 41 fe64489d __go_receive_small (de221660, de22c500, 0, 809eaea, 14, 1) + 2d fe7fd1cd libgo_testing.testing.RunTests (8088b38, de40, 30, 30, fefa0810, fee70018) + 21d fe7fd481 libgo_testing.testing.Main (8088b38, de40, 30, 30, de20ebf0, 0) + 81 08088cb4 main.main (4d9060de, 8045720, 80453f0, feffb93c, 8045400, de20) + 48 080958ef main (1, 8045434, 804543c, 8045428, 80640c2, 80956f0) + 1df 08064123 _start (1, 8045788, 0, 8045790, 804579e, 80457aa) + 83 - lwp# 24 / thread# 24 fe35b3ab lwp_park (0, 0, 0) fe354e03 cond_wait_queue (de217f68, de217f50, 0, fe355329) + 63 fe3553a1 __cond_wait (de217f68, de217f50, cdefea68, fe3553e9) + 89 fe3553f7 cond_wait (de217f68, de217f50, de217f50, fe35542d) + 27 fe355442 pthread_cond_wait (de217f68, de217f50, 5a5b497, 321, 8056414, 100) + 24 fe64467c __go_receive_acquire (de217f50, 0, 0, 807e3b8, cdefeb00, fefc0744) + 7c fe643d4e __go_receive_big (de217f50, cdefeb50, de229300, fe6494b7, fedf3f40, de234f20) + 3e 080809b2 libgo_http.http.roundTrip.pN27_libgo_http.http.persistConn (cdefec08, de23f840, de229300, 4, 809c52c, 4) + 112 0807e6b9 libgo_http.http.RoundTrip.pN25_libgo_http.http.Transport (cdefeccc, de20eb60, de229300, fe6494b7, de230005, 11) + 301 0806b2c3 http.send (cdefedb8, de229300, 80a4268, de20eb60, 0, fe3f3000) + 249 0806b5d6 libgo_http.http.Get.pN22_libgo_http.http.Client (cdefee38, de200568, de234f60, 16, cdf00a3c, 0) + 1de 0806b38d libgo_http.http.Get (cdefeee8, de23, 16, fe350f13, 0, fe3f3000) + 4e 08088f87 go.http_test.TestClient (de22c5d0, 0, fee60200, fe353c8c, fe87d6c0, fe8cb584) + 89 fe7fc595 testing.tRunner (de22c5d0, de222348, fe87d6c0, 80bc468, fe8cb584, fe87d6c0) + 25 fe7fc25a testing.$thunk0 (de22c5e0, fe3f3000, cdefefd8, fe35a535, fe3f9e00, fee62000) + 1a fe641b41 start_go_thread (de21b380, fe3f3000, cdefefe8, fe35b079) + 81 fe35b0cc _thrp_setup (cdf00a40) + 9d fe35b370 _lwp_start (cdf00a40, 0, 0, 0, 0, 0) - lwp# 25 / thread# 25 fe35f4a7 pollsys (ce00ed00, 1, 0, 0) fe30afeb pselect (5, de22a000, 0, 0, 0, 0) + 193 fe30b2f1 select (5, de22a000, 0, 0, 0, fefc0744) + 79 fe7fb3f1 libgo_syscalls.syscall.Select (ce00ee40, 5, de22a000, de22a080, 0, 0) + 41 fe6b9301 libgo_net.net.WaitFD.pN22_libgo_net.net.pollster (ce00ef14, de2300a0, de201570, 0, 0, fe3f3000) + 221 fe6c1515 libgo_net.net.Run.pN24_libgo_net.net.pollServer (de201570, 0, fe87d6c0, 80bc440, fe8cb584, fe87d6c0) + e5 fe6b5843 net.$thunk0 (de232288, fe3f3000, ce00efd8, fe35a535, fe3f9e00, fee62000) + 13 fe641b41 start_go_thread (de23f140, fe3f3000, ce00efe8, fe35b079) + 81 fe35b0cc _thrp_setup (cdf00240) + 9d fe35b370 _lwp_start (cdf00240, 0, 0, 0, 0, 0) - lwp# 26 / thread# 26 fe35b3ab lwp_park (0, 0, 0) fe354e03 cond_wait_queue (de221b58, de221b40, 0, fe355329) + 63 fe3553a1 __cond_wait (de221b58, de221b40, cddffc58, fe3553e9) + 89 fe3553f7 cond_wait (de221b58, de221b40, cddffc98, fe35542d) + 27 fe355442 pthread_cond_wait (de221b58, de221b40, 1, fe87d6c0, 72, fe87d6c0) + 24 fe64467c __go_receive_acquire (de221b40, 0, fe50f9e3, fef70018, 3, 0) + 7c fe6447f1 __go_receive_small_closed (de221b40, 0, 0, fe87d6c0, de229280) + 41 fe64489d __go_receive_small (de221b40, de229200, 72, de201570, fe87d6c0, de229280) + 2d fe6ba741 libgo_net.net.WaitRead.pN24_libgo_net.net.pollServer
[Bug tree-optimization/48290] FAIL: gcc.dg/vect/pr38529.c, ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1072
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48290 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 10:38:27 UTC --- Thanks Ira.
[Bug target/47553] ARM neon vld1q_lane_u8 co. don't accept lanes = 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47553 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-03-28 10:49:10 UTC --- Fixed in 4.5, 4.6 and trunk.
[Bug tree-optimization/48295] Incorrect code generated with dynamic floating point rounding mode switches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48295 --- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-03-28 10:50:44 UTC --- On Mon, 28 Mar 2011, rguenth at gcc dot gnu.org wrote: Btw, your testcase would be kindof invalid as you are not using the documented standard way of accessing fenv but using inline-asm (and we don't have a special clobber that tells GCC you touched the FP control word). You mark the asm as reading and clobbering fpcr - that register name already exists in GCC, and it's a bug that glibc's fpu_control.h doesn't use it, though I suppose you'd need to add the mxcsr name as well. When -frounding-math is actually properly implemented it ought to be taught about target-specific registers representing rounding modes (and likewise exception status) so it knows how asms interact with the floating-point state. (Non-const, non-pure function calls will also need to be presumed to interact with the state in unknown ways since they may end up calling fenv.h functions.)
[Bug c/48305] [4.7 Regression] ice at -O0: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48305 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-28 10:55:56 UTC --- Created attachment 23790 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23790 gcc47-pr48305.patch Untested fix.
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245 --- Comment #21 from Rainer Orth ro at gcc dot gnu.org 2011-03-28 11:07:02 UTC --- Author: ro Date: Mon Mar 28 11:06:58 2011 New Revision: 171598 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171598 Log: PR target/48245 * config/darwin.h (LINK_COMMAND_SPEC_A): Use LINK_PLUGIN_SPEC. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-03/msg01890.htm ||l CC||ro at gcc dot gnu.org Resolution||FIXED AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 --- Comment #22 from Rainer Orth ro at gcc dot gnu.org 2011-03-28 11:08:39 UTC --- Fixed for 4.7.0.
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245 --- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-28 11:11:09 UTC --- --- Comment #20 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-24 18:46:41 UTC --- AFAICT, comment #12 is OK on *-darwin9 including cross-cris-elf. given that Mike has approved, if someone could chip in with a test on x86-64-darwin10, I would think you could apply it. I have bootstrapped gcc on x86-64-darwin10 with the patch in comment #12 on top of revision 171401 without failures for the tests ran by lto.exp (full test by tomorrow). Thanks. Based on Iain's and your testing and Mike's approval, I've applied the patch (slightly adapted to match the gcc.c form). Now I wonder what are the tests gcc/testsuite/gcc.dg/lto/20100722-1_0.c gcc/testsuite/gcc.dg/lto/20110201-1_0.c gcc/testsuite/gcc.dg/lto/pr46940_0.c gcc/testsuite/gcc.dg/lto/pr47188_0.c gcc/testsuite/gcc.dg/pr43157.c supposed to test? pr46940_0.c fails because only weak aliases are supported on darwin and the other tests pass even without plugin support. No idea. You'll have to ask the patch authors. This whole LTO and lto-plugin business remains a mystery to me. Rainer
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245 --- Comment #24 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 11:18:44 UTC --- (In reply to comment #20) AFAICT, comment #12 is OK on *-darwin9 including cross-cris-elf. given that Mike has approved, if someone could chip in with a test on x86-64-darwin10, I would think you could apply it. I have bootstrapped gcc on x86-64-darwin10 with the patch in comment #12 on top of revision 171401 without failures for the tests ran by lto.exp (full test by tomorrow). Now I wonder what are the tests gcc/testsuite/gcc.dg/lto/20100722-1_0.c gcc/testsuite/gcc.dg/lto/20110201-1_0.c gcc/testsuite/gcc.dg/lto/pr46940_0.c gcc/testsuite/gcc.dg/lto/pr47188_0.c gcc/testsuite/gcc.dg/pr43157.c supposed to test? pr46940_0.c fails because only weak aliases are supported on darwin and the other tests pass even without plugin support. They are various tests for previously existing bugs (mostly ICEs). Of course they now work.
[Bug middle-end/48310] ask a question about expand_used_vars in cfgexpand.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48310 --- Comment #2 from shushengyu zgss278 at 163 dot com 2011-03-28 11:20:03 UTC --- Oh,sorry!I am not know the rule well. Can you introduce someone who would like to give me some help to me? At 2011-03-28 17:47:06，rguenth at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48310 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 09:47:01 UTC --- Please ask questions on the GCC mailinglists, not via bugzilla. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245 --- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-28 11:21:20 UTC --- supposed to test? pr46940_0.c fails because only weak aliases are supported on darwin and the other tests pass even without plugin support. They are various tests for previously existing bugs (mostly ICEs). Of course they now work. But Dominique's point that all those tests have dg-require-linker-plugin, but passed on Darwin even without the lto-plugin. Rainer
[Bug debug/48229] 4.5.x should produce unambiguous DW_AT_accessibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48229 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added Summary|DW_TAG_type_unit has no |4.5.x should produce |DW_AT_producer |unambiguous ||DW_AT_accessibility --- Comment #7 from Jan Kratochvil jan.kratochvil at redhat dot com 2011-03-28 11:21:41 UTC --- In such case only the gcc-4.5.x branch should start to produce DW_AT_accessibility unambiguously (explicitly) at least in the -gdwarf-4 mode. This way it will not remain a long term regression testsuite problem.
[Bug libstdc++/48313] New: std::bind with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48313
Summary: std::bind with template function
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
$ cat t.cc EOF
#include functional
templateclass T void func( T )
{}
int main( int, char** )
{
std::bind( funcint, 0 );
}
EOF
$ g++ t.cc -std=gnu++0x
t.cc: In function 'int main(int, char**)':
t.cc:8:27: error: cannot bind 'void(int)' lvalue to 'void ()(int)'
...
This is with GCC 4.6.0. This works with GCC 4.5.2.
[Bug lto/48309] gcc -flto -fuse-linker-plugin generates crashing executables on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48309 --- Comment #3 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-03-28 11:35:37 UTC --- (In reply to comment #2) Gordon Magnusson wrote: C:\bugreportld -v GNU ld (GNU Binutils) 2.21.51.20110326
[Bug libobjc/48314] New: Make the new symbols weak symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48314 Summary: Make the new symbols weak symbols Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libobjc AssignedTo: unassig...@gcc.gnu.org ReportedBy: js-...@webkeks.org Hello, gcc 4.6 introduces a lot of new symbols like objc_setProperty, objc_sync_enter etc. Those are often already provided since they were always missing, but support for e.g. @synchronized was always there. This creates conflicts now when using gcc 4.6, thus I would suggest to make those weak symbols in 4.6.1.
[Bug middle-end/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target|x86_64-unknown-linux-gnu|x86_64-unknown-linux-gnu,
||i?86-*-*
Component|target |middle-end
Known to fail||2.95.2
--- Comment #16 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28
11:57:36 UTC ---
Also broken at least since GCC 2.95 on i?86 with
struct colour
{
unsigned char red;
unsigned char green;
unsigned char blue;
};
void print_colour(struct colour col) __attribute__((regparm(3)));
void
foo(struct colour *c)
{
print_colour(*c);
}
[Bug middle-end/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Blocks||37954 --- Comment #17 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 11:58:50 UTC --- PR37954 looks like a dup for arm.
[Bug c/42098] gcc does not honor alignment specification for qualified typedefs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42098 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 12:02:40 UTC --- dup. *** This bug has been marked as a duplicate of bug 12742 ***
[Bug c/12742] Type alignment is lost if const is added to typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||jepler at unpythonic dot ||net --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-28 12:02:40 UTC --- *** Bug 42098 has been marked as a duplicate of this bug. ***
[Bug libstdc++/48313] std::bind with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48313 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.28 12:17:25 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-28 12:17:25 UTC --- The example should work. I'm travelling today but will check the functional code later to see why the F constructor is being chosen instead of the const F one.
[Bug fortran/48279] [4.6/4.7 Regression] segfault in gfc_check_vardef_context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48279 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug libstdc++/48313] std::bind with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48313 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-28 12:24:23 UTC --- The example can be modified to work by passing a pointer, so the template argument isn't deduced as a function type: std::bind( funcint, 0 );
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-03-28 12:31:35 UTC --- (In reply to comment #1) Could you please check if this test worked before my patch? It may have been that the failure simply went unnoticed. I don't think thread_leak_test.c was tested before.
[Bug target/48308] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 --- Comment #2 from Gerhard Heift dev-gcc-20110327-b588 at gheift dot de 2011-03-28 12:34:31 UTC --- Created attachment 23791 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23791 generated assembler On line 114, the generates assembler code refers to .LPIC4, which does not exists.
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-28 12:40:06 UTC --- I don't think thread_leak_test.c was tested before. In that case, please try to compile it with the same flags used for one of the other tests (e.g, leak_test.c) to check if the problem is with my dg conversion or elsewhere. In any case, if this wasn't tested before, it's not a regression. Thanks. Rainer
[Bug libstdc++/48313] std::bind with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48313
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-28
12:43:12 UTC ---
It's not the _Bind constructor, it's the bind() call itself, this demonstrates
the problem:
templatetypename _Functor, typename... _ArgTypes
inline
void
bind(_Functor __f, _ArgTypes... __args) { }
templateclass T void func( T )
{}
int main( int, char** )
{
bind( funcint, 0 );
}
we might just need to overload std::bind for function types
std::bind() in 4.5 was defined differently as it didn't support rvalues
properly, so didn't show the problem
[Bug testsuite/48276] FAIL: gcc.target/i386/pr47502-2.c on x86_64-apple-darwin10.7.0 with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48276
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot com
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-03-28 12:44:50
UTC ---
Please try
diff --git a/gcc/testsuite/gcc.target/i386/pr47502-2.c
b/gcc/testsuite/gcc.target/i386/pr47502-2.c
index 1f57ea0..a8dc1ca 100644
--- a/gcc/testsuite/gcc.target/i386/pr47502-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr47502-2.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O2 } */
+/* { dg-options -O2 -fno-pic } */
int
foo (int how, const void *set, void *oset)
[Bug testsuite/48276] FAIL: gcc.target/i386/pr47502-2.c on x86_64-apple-darwin10.7.0 with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48276
--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-28
12:52:43 UTC ---
Please try
...
-/* { dg-options -O2 } */
+/* { dg-options -O2 -fno-pic } */
...
It does fix the failure, thanks.
[Bug target/48308] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2011-03-28 13:09:15 UTC --- (In reply to comment #2) Created attachment 23791 [details] generated assembler On line 114, the generates assembler code refers to .LPIC4, which does not exists. Indeed. If I compile with -mcpu=arm9tdmi as your assembly file indicates then I lose several lines of code, including the .LPIC4 label and a strcmp() call, but the reference to .LPIC4 remained. Normally I have -march=armv5te -mtune=xscale, and in that case the .LPIC4 label and surrounding code is not lost. Works(*) with gcc-4.4.5 and 4.5.2, so it's a regression. (*) Had to eliminate some apparent C1X-isms from the test case though.
[Bug testsuite/48276] FAIL: gcc.target/i386/pr47502-2.c on x86_64-apple-darwin10.7.0 with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48276 --- Comment #3 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-03-28 13:14:56 UTC --- Author: hjl Date: Mon Mar 28 13:14:47 2011 New Revision: 171604 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171604 Log: Add -fno-pic to gcc.target/i386/pr47502-2.c. 2011-03-28 H.J. Lu hongjiu...@intel.com PR testsuite/48276 * gcc.target/i386/pr47502-2.c: Add -fno-pic. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr47502-2.c
[Bug testsuite/48276] FAIL: gcc.target/i386/pr47502-2.c on x86_64-apple-darwin10.7.0 with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48276 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2011-03-28 13:19:01 UTC --- Fixed.
[Bug fortran/48279] [4.6/4.7 Regression] segfault in gfc_check_vardef_context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48279 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-28 13:21:30 UTC --- ==1823== Invalid read of size 1 ==1823==at 0x4C32E7: gfc_check_vardef_context (expr.c:4377) ==1823==by 0x4CBC25: compare_actual_formal (interface.c:2291) ==1823==by 0x4CD48B: gfc_arglist_matches_symbol (interface.c:2813) ==1823==by 0x4CD6F4: gfc_search_interface (interface.c:2842) ==1823==by 0x50D2A2: resolve_call (resolve.c:3204) The issue - or at least cause - for the segfault is the following code in gfc_check_vardef_context: if (!pointer e-expr_type == EXPR_FUNCTION e-symtree-n.sym-result-attr.pointer) The problem is that e-symtree-n.sym-result == NULL. The symbol itself is get_d_string. If one uses gdb's set e-symtree-n.sym-result = e-symtree-n.sym and continues, one gets the expected error: Error: There is no specific subroutine for the generic 'set' at (1) One problem seems to be that get_d_string is a generic interface - and not a specific one: (gdb) p e-symtree-n.sym-attr.generic $1 = 1 The specific interface has properly the result variables set: (gdb) p e-symtree-n.sym-generic-sym-name $3 = 0x2e876280 get_d_string_p (gdb) p e-symtree-n.sym-generic-sym-result $4 = (struct gfc_symbol *) 0x1281280 Calling gfc_check_vardef_context for an generic interface seems to be questionable.
[Bug debug/48315] New: ICE in mem_loc_descriptor, at dwarf2out.c:13899
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48315 Summary: ICE in mem_loc_descriptor, at dwarf2out.c:13899 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: armv5tejl-unknown-linux-gnueabi Target: armv5tejl-unknown-linux-gnueabi Build: armv5tejl-unknown-linux-gnueabi Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdi r/gcc/ /home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/vla2.f90 -B/hom e/dave/gnu/gcc/objdir/armv5tejl-unknown-linux-gnueabi/./libgomp/ -B/home/dave/gn u/gcc/objdir/armv5tejl-unknown-linux-gnueabi/./libgomp/.libs -I/home/dave/gnu/gc c/objdir/armv5tejl-unknown-linux-gnueabi/./libgomp -I/home/dave/gnu/gcc/gcc/libg omp/testsuite/.. -fmessage-length=0 -fopenmp -O3 -g -B/home/dave/gnu/gcc/objd ir/armv5tejl-unknown-linux-gnueabi/./libgomp/../libgfortran/.libs -L/home/dave /gnu/gcc/objdir/armv5tejl-unknown-linux-gnueabi/./libgomp/.libs -lgomp -L/home/d ave/gnu/gcc/objdir/armv5tejl-unknown-linux-gnueabi/./libgomp/../libgfortran/.lib s -lgfortran -lm -o ./vla2.exe(timeout = 300) /home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/vla2.f90: In function ' foo': /home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/vla2.f90:127:0: interna l compiler error: in mem_loc_descriptor, at dwarf2out.c:13899 FAIL: libgomp.fortran/vla2.f90 -O3 -g (internal compiler error) FAIL: libgomp.fortran/vla2.f90 -O3 -g (test for excess errors) -bash-3.2$ gcc/xgcc -Bgcc/ -v Reading specs from gcc/specs COLLECT_GCC=gcc/xgcc COLLECT_LTO_WRAPPER=gcc/lto-wrapper Target: armv5tejl-unknown-linux-gnueabi Configured with: ../gcc/configure --host=armv5tejl-unknown-linux-gnueabi --target=armv5tejl-unknown-linux-gnueabi --build=armv5tejl-unknown-linux-gnueabi --enable-languages=c,c++,fortran,objc,obj-c++ --enable-checking=release --enable-shared --enable-threads --disable-multilib --disable-libmudflap --disable-libssp --enable-symvers=gnu --enable-__cxa_atexit --disable-libstdcxx-pch --prefix=/home/dave/opt/gnu/gcc/gcc-4.6.0 --with-gmp=/home/dave/opt/gnu --with-as=/home/dave/opt/gnu/bin/as --with-ld=/home/dave/opt/gnu/bin/ld Thread model: posix gcc version 4.7.0 20110325 (experimental) [trunk revision 171528] (GCC) Similar fails: FAIL: libgomp.fortran/vla6.f90 -O3 -g (internal compiler error) FAIL: libgomp.fortran/vla6.f90 -O3 -g (test for excess errors) FAIL: libgomp.fortran/vla8.f90 -O3 -g (internal compiler error) FAIL: libgomp.fortran/vla8.f90 -O3 -g (test for excess errors)
[Bug preprocessor/48248] [4.5/4.6/4.7 Regression] Wrong error message location when compiling preprocessed code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48248 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-28 13:47:05 UTC --- Can't reproduce this, neither with g++ 4.5, nor trunk.
[Bug preprocessor/48248] [4.5/4.6/4.7 Regression] Wrong error message location when compiling preprocessed code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48248 --- Comment #3 from joerg.rich...@pdv-fs.de 2011-03-28 13:51:55 UTC --- (In reply to comment #2) Can't reproduce this, neither with g++ 4.5, nor trunk. Did you delete the empty lines?
[Bug tree-optimization/48316] New: missed CSE / reassoc with array offsets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48316
Summary: missed CSE / reassoc with array offsets
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
int
foo (int *p, int i)
{
int i1 = i + 1;
int i2 = i + 2;
return p[i1] + p[i2];
}
int
bar (int *p, unsigned long i)
{
unsigned long i1 = i + 1;
unsigned long i2 = i + 2;
return p[i1] + p[i2];
}
For both testcases (the latter being the more optimal input due to
pointer-plus-expr constraints) we miss to CSE the multiplication
of i by 4 which makes the memory references not trivially independent
(based on the same pointer, offsetted by different constants). Such
a case causes vectorization for alias checks being inserted for
gfortran.dg/reassoc_4.f with --param max-completely-peeled-insns=4000
IL on x86_64 is
bb 2:
i1_2 = i_1(D) + 1;
i2_3 = i_1(D) + 2;
D.2702_4 = (long unsigned int) i1_2;
D.2703_5 = D.2702_4 * 4;
D.2704_7 = p_6(D) + D.2703_5;
D.2705_8 = MEM[(int *)D.2704_7];
D.2706_9 = (long unsigned int) i2_3;
D.2707_10 = D.2706_9 * 4;
D.2708_11 = p_6(D) + D.2707_10;
D.2709_12 = MEM[(int *)D.2708_11];
D.2701_13 = D.2705_8 + D.2709_12;
return D.2701_13;
vs.
bb 2:
i1_2 = i_1(D) + 1;
i2_3 = i_1(D) + 2;
D.2694_4 = i1_2 * 4;
D.2695_6 = p_5(D) + D.2694_4;
D.2696_7 = MEM[(int *)D.2695_6];
D.2697_8 = i2_3 * 4;
D.2698_9 = p_5(D) + D.2697_8;
D.2699_10 = MEM[(int *)D.2698_9];
D.2693_11 = D.2696_7 + D.2699_10;
return D.2693_11;
For the reassoc_4.f testcase the question is whether either SCEV or
data-dependence can be enhanced to handle the cases (the multiplications
are in BB2, outside of any loop).
[Bug c/44384] builtin_object_size_ treatment of multidimensional arrays is unexpected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44384 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-28 14:05:34 UTC --- __builtin_object_size is a builtin for -D_FORTIFY_SOURCE checking, it is not a generic object size computation function, and for strcpy IMHO we don't want to treat each dimension as a field separator.
[Bug libstdc++/48313] std::bind with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48313
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-28
14:26:35 UTC ---
slightly further reduced:
templatetypename Functor, typename ArgTypes
inline void
bind(Functor f, ArgTypes a) { }
templatetypename T
void func( T )
{}
int main( int, char** )
{
bind( funcint, 0 );
}
this is certainly not a libstdc++ bug (std::bind matches the signature require
by the C++0x draft)
I think the parameter is a non-deduced context, because the argument is an
overload set containing one or more function templates ([temp.deduct.call p6)
So I think this is actually invalid and G++ is right to reject it.
[Bug tree-optimization/48317] New: SCCVN does not handle vector constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48317
Summary: SCCVN does not handle vector constructors
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
SCCVN does not handle CONSTRUCTORs well (they simply get put into a
reference-kind
single operand). This sucks for things like
vect_cst_.239_4355 = {pretmp.88_1931, pretmp.88_1931};
which the vectorizer generates (or which can happen via intrinsics or
generic vector support even earlier).
Not sure how to handle this variable-size code though.
[Bug c++/48289] [4.5/4.6/4.7 regression] -pedantic breaks std::move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48289 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-03-28 15:06:32 UTC --- Author: jason Date: Mon Mar 28 15:06:28 2011 New Revision: 171607 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171607 Log: Revert: PR c++/48289 * pt.c (build_non_dependent_expr): Keep dereferences outside the NON_DEPENDENT_EXPR. Removed: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/move1.C Modified: branches/gcc-4_5-branch/gcc/cp/ChangeLog branches/gcc-4_5-branch/gcc/cp/pt.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/48195] ICE: vector VEC(ipa_node_params_t,base) index domain error, in ipa_analyze_node at ipa-prop.c:1525 with -flto --param partial-inlining-entry-probability=101
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48195 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org 2011-03-28 15:15:15 UTC --- Mine.
[Bug go/48312] [4.7 regression] http, rpc, websocket tests hang on Solaris 2/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48312 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.03.28 15:51:34 Ever Confirmed|0 |1 --- Comment #1 from Ian Lance Taylor ian at airs dot com 2011-03-28 15:51:34 UTC --- Sorry, I forgot about this issue when I updated the library.
[Bug other/48318] New: Memory access error by build/genhooks?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48318 Summary: Memory access error by build/genhooks? Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: markus.elfr...@web.de Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Build: x86_64-unknown-linux-gnu I try to generate the current GCC software for my openSUSE 11.4 system. Unfortunately, I stumble on the following German message. ... /bin/sh /home/elfring/Projekte/GNU/GCC/Quellen/4.6.0/gcc/../move-if-change tmp-optionlist optionlist echo timestamp s-options build/genhooks \ /home/elfring/Projekte/GNU/GCC/Quellen/4.6.0/gcc/doc/tm.texi.in tmp-tm.texi gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genconstants \ build/genconstants.o build/read-md.o build/errors.o ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a /bin/sh: Zeile 1: 29541 Speicherzugriffsfehler build/genhooks /home/elfring/Projekte/GNU/GCC/Quellen/4.6.0/gcc/doc/tm.texi.in tmp-tm.texi make[3]: *** [s-tm-texi] Fehler 139 make[3]: *** Warte auf noch nicht beendete Prozesse... rm gcc.pod make[3]: Leaving directory `/home/elfring/Projekte/GNU/GCC/erzeugt/4.6.0/Auswahl/gcc' make[2]: *** [all-stage1-gcc] Fehler 2 make[2]: Leaving directory `/home/elfring/Projekte/GNU/GCC/erzeugt/4.6.0/Auswahl' make[1]: *** [stage1-bubble] Fehler 2 make[1]: Leaving directory `/home/elfring/Projekte/GNU/GCC/erzeugt/4.6.0/Auswahl' make: *** [all] Fehler 2 How can this memory access error/segmentation fault be resolved? I would like to use the configuration parameters --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr/local.
[Bug c++/48296] [C++0x] constexpr member function cannot use the class type it belongs as parameter type or return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48296 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org Summary|constexpr member function |[C++0x] constexpr member |cannot use the class type |function cannot use the |it belongs as parameter |class type it belongs as |type or return type |parameter type or return ||type --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-28 16:11:00 UTC --- Adding Jason in CC.
