Re: Option to make unsigned-signed conversion always well-defined?
On Thu, Oct 6, 2011 at 12:55 AM, Pedro Pedruzzi
pedro.pedru...@gmail.com wrote:
Em 05-10-2011 17:11, Ulf Magnusson escreveu:
Hi,
I've been experimenting with different methods for emulating the
signed overflow of an 8-bit CPU.
You would like to check whether a 8-bit signed addition will overflow or
not, given the two operands. Is that correct?
As you used the word `emulating', I am assuming that your function will
not run by the mentioned CPU.
No, it'll most likely only run on systems with a wider bitness.
Does this 8-bit CPU use two's complement representation?
Yes, and the criterion for signed overflow is both numbers have the
same sign, but the sign of the sum is different. Should have made
that more clear.
The method I've found that seems to
generate the most efficient code on both ARM and x86 is
bool overflow(unsigned int a, unsigned int b) {
const unsigned int sum = (int8_t)a + (int8_t)b;
return (int8_t)sum != sum;
}
(The real function would probably be 'inline', of course. Regs are
stored in overlong variables, hence 'unsigned int'.)
Looking at the spec, it unfortunately seems the behavior of this
function is undefined, as it relies on signed int addition wrapping,
and that (int8_t)sum truncates bits. Is there some way to make this
guaranteed safe with GCC without resorting to inline asm? Locally
enabling -fwrap takes care of the addition, but that still leaves the
conversion.
I believe the cast from unsigned int to int8_t is implementation-defined
for values that can't be represented in int8_t (e.g. 0xff). A kind of
`undefined behavior' as well.
I tried:
bool overflow(unsigned int a, unsigned int b) {
const unsigned int sum = a + b;
return ((a 0x80) == (b 0x80)) ((a 0x80) != (sum 0x80));
}
But it is not as efficient as yours.
--
Pedro Pedruzzi
Yeah, I tried similar bit-trickery along the lines of
bool overflow(unsigned int a, unsigned int b) {
const uint8_t ab = (uint8_t)a;
const uint8_t bb = (uint8_t)b;
const uint8_t sum = ab + bb;
return (ab ^ bb) ~(ab ^ sum) 0x80;
}
, but it doesn't seem to generate very efficient code.
/Ulf
Re: Option to make unsigned-signed conversion always well-defined?
On Thu, Oct 6, 2011 at 10:25 AM, Ulf Magnusson ulfali...@gmail.com wrote:
On Thu, Oct 6, 2011 at 12:55 AM, Pedro Pedruzzi
pedro.pedru...@gmail.com wrote:
Em 05-10-2011 17:11, Ulf Magnusson escreveu:
Hi,
I've been experimenting with different methods for emulating the
signed overflow of an 8-bit CPU.
You would like to check whether a 8-bit signed addition will overflow or
not, given the two operands. Is that correct?
As you used the word `emulating', I am assuming that your function will
not run by the mentioned CPU.
No, it'll most likely only run on systems with a wider bitness.
Does this 8-bit CPU use two's complement representation?
Yes, and the criterion for signed overflow is both numbers have the
same sign, but the sign of the sum is different. Should have made
that more clear.
The method I've found that seems to
generate the most efficient code on both ARM and x86 is
bool overflow(unsigned int a, unsigned int b) {
const unsigned int sum = (int8_t)a + (int8_t)b;
return (int8_t)sum != sum;
}
(The real function would probably be 'inline', of course. Regs are
stored in overlong variables, hence 'unsigned int'.)
Looking at the spec, it unfortunately seems the behavior of this
function is undefined, as it relies on signed int addition wrapping,
and that (int8_t)sum truncates bits. Is there some way to make this
guaranteed safe with GCC without resorting to inline asm? Locally
enabling -fwrap takes care of the addition, but that still leaves the
conversion.
I believe the cast from unsigned int to int8_t is implementation-defined
for values that can't be represented in int8_t (e.g. 0xff). A kind of
`undefined behavior' as well.
I tried:
bool overflow(unsigned int a, unsigned int b) {
const unsigned int sum = a + b;
return ((a 0x80) == (b 0x80)) ((a 0x80) != (sum 0x80));
}
But it is not as efficient as yours.
--
Pedro Pedruzzi
Yeah, I tried similar bit-trickery along the lines of
bool overflow(unsigned int a, unsigned int b) {
const uint8_t ab = (uint8_t)a;
const uint8_t bb = (uint8_t)b;
const uint8_t sum = ab + bb;
return (ab ^ bb) ~(ab ^ sum) 0x80;
}
, but it doesn't seem to generate very efficient code.
/Ulf
Might as well do
bool overflowbit(unsigned int a, unsigned int b) {
const unsigned int sum = a + b;
return (a ^ b) ~(a ^ sum) 0x80;
}
But still not very good output compared to other approaches as expected.
/Ulf
Re: Option to make unsigned-signed conversion always well-defined?
Ulf Magnusson ulfali...@gmail.com writes:
Might as well do
bool overflowbit(unsigned int a, unsigned int b) {
const unsigned int sum = a + b;
return (a ^ b) ~(a ^ sum) 0x80;
}
But still not very good output compared to other approaches as expected.
How about:
bool overflowbit2(unsigned int a, unsigned int b)
{
const unsigned int sum = a + b;
return ~(a ^ b) sum 0x80;
}
?
I thik it has the same results as your function...
[I just made a table of all 8 possibilities, and checked!]
-miles
--
Circus, n. A place where horses, ponies and elephants are permitted to see
men, women and children acting the fool.
Re: Option to make unsigned-signed conversion always well-defined?
On Thu, Oct 6, 2011 at 11:04 AM, Miles Bader mi...@gnu.org wrote:
Ulf Magnusson ulfali...@gmail.com writes:
Might as well do
bool overflowbit(unsigned int a, unsigned int b) {
const unsigned int sum = a + b;
return (a ^ b) ~(a ^ sum) 0x80;
}
But still not very good output compared to other approaches as expected.
How about:
bool overflowbit2(unsigned int a, unsigned int b)
{
const unsigned int sum = a + b;
return ~(a ^ b) sum 0x80;
}
?
I thik it has the same results as your function...
[I just made a table of all 8 possibilities, and checked!]
-miles
--
Circus, n. A place where horses, ponies and elephants are permitted to see
men, women and children acting the fool.
Ops, should have been
return ~(a ^ b) (a ^ sum) 0x80
~(a ^ b) gives 1 in the sign bit position if the signs are the same,
and (a ^ sum) gives 1 if it's different in the sum.
A clearer way of writing it (that also generates suboptimal code) is
bool overflow(unsigned int a, unsigned int b) {
const unsigned asign = a0x80;
const unsigned bsign = b0x80;
const unsigned sumsign = (a + b) 0x80;
return (asign == bsign) (asign != sumsign);
}
Seems bit-fiddling isn't the way to go.
Maybe I should take this to gnu-help as it isn't really development-related.
/Ulf
Bugzilla down
Suddenly bugzilla went down. Am I the only one seeing this? -- PMatos
Re: Merging gdc (GNU D Compiler) into gcc
On 4 October 2011 09:41, Andrew Haley a...@redhat.com wrote: On 10/04/2011 08:08 AM, Iain Buclaw wrote: I've have received news from Walter Bright that the license of the D frontend has been assigned to the FSF. As the current maintainer of GDC, I would like to get this moved forward, starting with getting the ball rolling. What would need to be done? And what are the processes required? (ie: passing the project through to technical review.) In general we welcome contributions like this. The biggest problem in the past has always been continued maintainership: some front- ends have been abandoned because of a lack of TLC. As the current GDC maintainer, I'm sure you know that keeping up with gcc development requires constant attention. Do you have anyone who could be a co-maintainer? Andrew. (Apparently the first message from my phone didn't get sent through earlier.) I have spoken to Daniel, I can confirm he is willing to help co-maintain GDC with me. I have no intention of letting this project go abandoned, nor do I see any end in sight of my continued maintaining and development of gdc. I understand your concerns that GDC might not receive the care it requires to keep up with the rest of GCC, and you can have my word that I will do my utmost to ensure this will never be the case. Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Bugzilla down
On 10/06/2011 04:41 PM, Paulo J. Matos wrote: Suddenly bugzilla went down. Am I the only one seeing this? Actually, the whole gcc.gnu.org since yesterday seems rather flaky. At the moment it works fine for me, though. Paolo.
Re: Bugzilla down
On 06/10/11 15:41, Paulo J. Matos wrote: Suddenly bugzilla went down. Am I the only one seeing this? Opps, now sorted. -- PMatos
Re: Bugzilla down
Paolo Carlini paolo.carlini at oracle.com writes: On 10/06/2011 04:41 PM, Paulo J. Matos wrote: Suddenly bugzilla went down. Am I the only one seeing this? Actually, the whole gcc.gnu.org since yesterday seems rather flaky. At the moment it works fine for me, though. Same symptoms as those on kernel.org before the intrusion was detected. Perhaps someone should run chkrootkit on the gnu servers?
Re: Option to make unsigned-signed conversion always well-defined?
Hi.
Instead of all the clever bit twiddling I have used code similar to
sum UINT8_MAX
which just generates
cmp ax,255
seta al
which seems to be far more efficient (even the signed version gets optimized
down to the above single check).
Please could someone tell me if I have missed something here
Signed check:
bool overflow(int16_t a, int16_t b)
{
const int16_t sum = a + b;
return sum INT8_MAX || sum INT8_MIN;
}
Unsigned check
bool overflow(uint16_t a, uint16_t b)
{
const uint16_t sum = a + b;
return sum UINT8_MAX;
}
Jeremy
Re: float op-and-halve
On 10/05/2011 07:16 PM, David Miller wrote: From: David Bremner dbrem...@gmail.com Date: Wed, 5 Oct 2011 19:08:41 -0700 What about treating these instructions as fused multiply-adds with constant arguments? Richard Henderson (CC:'d) chatted with me the other day about this and made the same initial suggestion, but after thinking about it some more he concluded that this would not work currently. The reciprocal of 2 is exactly represented, so there's no loss of precision. The x86 backend uses a similar method to model the x87 instructions that load various constants, see standard_80387_constant_p. Indeed, it sounds compelling. Richard, what was the exact reason doing this won't work? I don't quite remember the details. We were talking about a representation of (fma (plus a b) 0.5 -0.0) Problems with this arise when the compiler propagates constants into both A and B and tries to fold this. The PLUS will be simplified independently of the FMA. Which means that the compiler evaluation of the expression will see overflow when the insn won't. We'd have to invent a new fp-add-and-multiply rtx code taking two addition operands and a multiplication operand in order to get the compiler to fold this properly. Which doesn't seem that worthwhile given that Sparc is the only target I've seen with this feature. OTOH, we do have the target hook whereby we can simplify the builtin during gimple optimization. And unless our gimple optimizers are totally falling over should take care of all of the folding possibilities. You'd need to use the MPFR routines to properly evaluate this, Dave. r~
Re: Option to make unsigned-signed conversion always well-defined?
On Thu, Oct 6, 2011 at 11:04 AM, Miles Bader mi...@gnu.org wrote:
How about:
bool overflowbit2(unsigned int a, unsigned int b)
{
const unsigned int sum = a + b;
return ~(a ^ b) sum 0x80;
}
?
I thik it has the same results as your function...
[I just made a table of all 8 possibilities, and checked!]
Miles, it is not the same. Take for example (0xff, 0xff). In 8-bit 2's
complement, this is (-1, -1) and does not overflow. Your function says
it does.
Em 06-10-2011 12:23, Jeremy Hall escreveu:
bool overflow(int16_t a, int16_t b)
{
const int16_t sum = a + b;
return sum INT8_MAX || sum INT8_MIN;
}
Jeremy, here you are ignoring the problem of converting from the
unsigned int (in the range 0 to 0xff) to the signed integer that it
represents in 8-bit two's complement. Example: 0xff - -1.
In practice, casting the unsigned int to int8_t works in most cases, but
it is compiler-defined. We are trying to find a always well-defined
approach that is efficient as well.
Ops, should have been
return ~(a ^ b) (a ^ sum) 0x80
~(a ^ b) gives 1 in the sign bit position if the signs are the same,
and (a ^ sum) gives 1 if it's different in the sum.
This is good. Do you think this is suboptimal? How are you evaluating
efficiency? In x86 this generates pretty small code.
overflow2:
400524: 8d 04 3elea(%rsi,%rdi,1),%eax
400527: 31 f8 xor%edi,%eax
400529: 31 f7 xor%esi,%edi
40052b: f7 d7 not%edi
40052d: 21 f8 and%edi,%eax
40052f: 25 80 00 00 00 and$0x80,%eax
400534: c3 retq
--
Pedro Pedruzzi
Re: Option to make unsigned-signed conversion always well-defined?
(I'll cross-post this to gcc and keep it on gcc-help after that.)
On Thu, Oct 6, 2011 at 4:46 PM, Andrew Haley a...@redhat.com wrote:
inline int8_t as_signed_8 (unsigned int a) {
a = 0xff;
return a 0x80 ? (int)a - 0x100 : a;
}
int overflow(unsigned int a, unsigned int b) {
int sum = as_signed_8(a) + as_signed_8(b);
return as_signed_8(sum) != sum;
}
Andrew.
That's a really neat trick, and seems to generate identical code. Thanks!
I'd be interesting to know if this version produces equally efficient
code with MSVC.
To summarize what we have so far, here's four different methods along
with the code generated for X86 and ARM (GCC 4.5.2):
#include inttypes.h
inline int8_t as_signed_8(unsigned int a) {
a = 0xff;
return a 0x80 ? (int)a - 0x100 : a;
}
bool overflow_range(unsigned int a, unsigned int b) {
const int sum = as_signed_8(a) + as_signed_8(b);
return sum -128 || sum 127;
}
bool overflow_bit(unsigned int a, unsigned int b) {
const unsigned int sum = a + b;
return ~(a ^ b) (a ^ sum) 0x80;
}
bool overflow_unsafe(unsigned int a, unsigned int b) {
const unsigned int sum = (int8_t)a + (int8_t)b;
return (int8_t)sum != sum;
}
bool overflow_safe(unsigned int a, unsigned int b) {
const int sum = as_signed_8(a) + as_signed_8(b);
return as_signed_8(sum) != sum;
}
Output for X86 with -O3 -fomit-frame-pointer:
_Z14overflow_rangejj:
0: 0f be 54 24 04 movsbl 0x4(%esp),%edx
5: 0f be 44 24 08 movsbl 0x8(%esp),%eax
a: 8d 84 02 80 00 00 00lea0x80(%edx,%eax,1),%eax
11: 3d ff 00 00 00 cmp$0xff,%eax
16: 0f 97 c0seta %al
19: c3 ret
1a: 8d b6 00 00 00 00 lea0x0(%esi),%esi
0020 _Z12overflow_bitjj:
20: 8b 54 24 08 mov0x8(%esp),%edx
24: 8b 4c 24 04 mov0x4(%esp),%ecx
28: 89 d0 mov%edx,%eax
2a: 31 c8 xor%ecx,%eax
2c: 01 ca add%ecx,%edx
2e: 31 ca xor%ecx,%edx
30: f7 d0 not%eax
32: 21 d0 and%edx,%eax
34: a8 80 test $0x80,%al
36: 0f 95 c0setne %al
39: c3 ret
3a: 8d b6 00 00 00 00 lea0x0(%esi),%esi
0040 _Z15overflow_unsafejj:
40: 0f be 54 24 08 movsbl 0x8(%esp),%edx
45: 0f be 44 24 04 movsbl 0x4(%esp),%eax
4a: 8d 04 02lea(%edx,%eax,1),%eax
4d: 0f be d0movsbl %al,%edx
50: 39 c2 cmp%eax,%edx
52: 0f 95 c0setne %al
55: c3 ret
56: 8d 76 00lea0x0(%esi),%esi
59: 8d bc 27 00 00 00 00lea0x0(%edi,%eiz,1),%edi
0060 _Z13overflow_safejj:
60: 0f be 54 24 08 movsbl 0x8(%esp),%edx
65: 0f be 44 24 04 movsbl 0x4(%esp),%eax
6a: 8d 04 02lea(%edx,%eax,1),%eax
6d: 0f be d0movsbl %al,%edx
70: 39 c2 cmp%eax,%edx
72: 0f 95 c0setne %al
75: c3 ret
Output for ARM with -O3 -fomit-frame-pointer -mthumb -march=armv7:
_Z14overflow_rangejj:
0: b249sxtbr1, r1
2: b240sxtbr0, r0
4: 1808addsr0, r1, r0
6: 3080addsr0, #128; 0x80
8: 28ffcmp r0, #255; 0xff
a: bf94ite ls
c: 2000movls r0, #0
e: 2001movhi r0, #1
10: 4770bx lr
12: bf00nop
14: f3af 8000 nop.w
18: f3af 8000 nop.w
1c: f3af 8000 nop.w
0020 _Z12overflow_bitjj:
20: 180baddsr3, r1, r0
22: 4041eorsr1, r0
24: ea83 0200 eor.w r2, r3, r0
28: ea22 0001 bic.w r0, r2, r1
2c: f3c0 10c0 ubfxr0, r0, #7, #1
30: 4770bx lr
32: bf00nop
34: f3af 8000 nop.w
38: f3af 8000 nop.w
3c: f3af 8000 nop.w
0040 _Z15overflow_unsafejj:
40: b242sxtbr2, r0
42: b249sxtbr1, r1
44: 1888addsr0, r1, r2
46: b243sxtbr3, r0
48: 1a18subsr0, r3, r0
4a: bf18it ne
4c: 2001movne r0, #1
4e: 4770bx lr
0050 _Z13overflow_safejj:
50: b242sxtbr2, r0
52: b249sxtbr1, r1
54: 1888addsr0, r1, r2
56: b243sxtbr3, r0
58: 1a18subsr0, r3, r0
5a: bf18it ne
5c: 2001movne r0, #1
5e: 4770bx lr
Not sure which version would be fastest on ARM (no device
Re: Bugzilla down
octoploid cryptooctopl...@gmail.com writes: Actually, the whole gcc.gnu.org since yesterday seems rather flaky. At the moment it works fine for me, though. Same symptoms as those on kernel.org In gcc.gnu.org's case, apparently this was being caused by someone hammering on the bugzilla server. A case of excessive popularity perhaps rather than anything too suspicious. before the intrusion was detected. Perhaps someone should run chkrootkit on the gnu servers? This is being regularly done already. - FChE
Re: Option to make unsigned-signed conversion always well-defined?
* Ulf Magnusson:
I've been experimenting with different methods for emulating the
signed overflow of an 8-bit CPU. The method I've found that seems to
generate the most efficient code on both ARM and x86 is
bool overflow(unsigned int a, unsigned int b) {
const unsigned int sum = (int8_t)a + (int8_t)b;
return (int8_t)sum != sum;
}
There's a GCC extension which is relevant here:
| For conversion to a type of width N, the value is reduced modulo 2^N
| to be within range of the type; no signal is raised.
http://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html#Integers-implementation
Using that, you can replace the final 0x80 with a signed
comparison to zero, which should be give you the best possible code
(for the generic RISC). You only need to hunt down a copy of Hacker's
Delight or find the right bit twiddling by other means. 8-)
Re: onlinedocs formated text too small to read
Georg-Johann Lay wrote, On 01/08/11 09:40: Jon Grant wrote: [.] http://gcc.gnu.org/ml/gcc/2011-07/msg00106.html CCed Gerald, I think he cares for that kind of things. If he does not answer (it's vacation time) file a PR so that it won't be forgotten. Johann Thank you. I filled a PR now: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50642 Best regards, Jon
Re: cc1.exe: warnings being treated as errors
Jonathan Wakely wrote, On 26/09/11 09:57: [.] Feel free to request a new option in Bugzilla to suppress the note, that's the right place for this discussion. Good point. I've created a ticket: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50643 Regards, Jon
Re: The AST tree modification. Edited.
Hi,
as an addition to Balaji's answer. Please find attached an extract of a
sample front-end generating various types of tree nodes (e.g. arrays,
structs, ...). This used to work with an older version of GCC, but I'm
not sure if this still works with the most recent version. Anyway, it
should give you some pointers for further investigations ...
Best regards,
Andi
Hello,
For most of the things you are looking for, please look for a function
called build_decl. It is used in several places inside GCC. Let me give you a
small example,
If you do the following:
tree x = build_decl (UNKNOWN_LOCATION, VAR_DECL, get_identifer(ii),
integer_type_node)
you will declare a variable called ii of type integer.
Similarly, to create a new internal structure, if do something like this:
tree struct_frame = lang_hooks.make_type (RECORD_TYPE);
tree struct_field = build_decl (UNKNOWN_LOCATION, FIELD_DECL,
get_identifier(variable), integer_type_node)
TREE_CHAIN(struct_field) = struct_frame
You will create the following internal structure
struct {
int variable;
}
I hope this helps you get started.
Thanks,
Balaji V .Iyer.
-Original Message-
From: niXman [mailto:i.nix...@gmail.com]
Sent: Monday, October 03, 2011 6:51 PM
To: gcc@gcc.gnu.org
Subject: The AST tree modification. Edited.
Hi everybody!
It is necessary to implement a plug-in for GCC designed to collect the
information on types of translation unit, and generate static const array of
types rtti_ex _ on its base; //
enum class type_ {
char_, uchar_, short_, ushort_, int_, uint_, long_, ulong_,
int64_, uint64_, array_, pointer_, double_, long_double_, float_,
class_
};
struct rtti_ex_ { //
const char* name;
const type_ type;
const size_t size;
const size_t align;
const size_t offset;
};
// generated from plugin.
static const rtti_ex_ rtti_ex_array_[] = {
{...},
{...},
{...}
};
/
There aren't any problems with information collection from AST. There is a
complexity with AST modification:
1. How to declare a variable?
2. How to declare the typedef?
3. How to declare a structure?
4. How to declare an array of structures?
I suppose that there should be a function like: tree make_subtree (const char*
source); which result I could insert in the corresponding node. But I haven't
found it.
Please, give me some links on this subject. It is very desirable, if you could
give some links with examples.
Thanks.
#include config.h
#include system.h
#include coretypes.h
#include tm.h
#include tree.h
#include tree-dump.h
#include tree-iterator.h
#include gimple.h
#include function.h
#include flags.h
#include output.h
#include ggc.h
#include toplev.h
#include varray.h
#include langhooks-def.h
#include langhooks.h
#include target.h
#include cgraph.h
#include sfe1.h
#include opts.h
#include input.h
/* static unsigned int global_var = 0; */
tree create_decl__global_var ()
{
tree __glob_id = get_identifier(global_var);
tree __glob_decl = build_decl(VAR_DECL, __glob_id, unsigned_type_node);
/* allocate static storage for this variable */
TREE_STATIC(__glob_decl) = true;
/* static: internal linkage */
TREE_PUBLIC(__glob_decl) = false;
/* the context of this declaration: file scope */
DECL_CONTEXT(__glob_decl) = NULL_TREE;
/* this declaration is used in its scope */
TREE_USED(__glob_decl) = true;
/* initialization to 0 */
tree __glob_init_val = build_int_cstu(unsigned_type_node, 1);
DECL_INITIAL(__glob_decl) = __glob_init_val;
layout_decl(__glob_decl, false);
rest_of_decl_compilation(__glob_decl, 1, 0);
return __glob_decl;
}
tree create_decl__str ()
{
tree __str_id = get_identifier(str);
/* create a new type for const char */
tree __str_array_type = build_array_type(char_type_node, build_index_type(build_int_cst(NULL_TREE, 18)));
tree __str_type = build_pointer_type(char_type_node);
tree __str_array_ptr_type = build_pointer_type(__str_array_type);
tree __str_decl = build_decl(VAR_DECL, __str_id, __str_type);
TREE_STATIC(__str_decl) = true;
/* external linkage */
TREE_PUBLIC(__str_decl) = true;
DECL_CONTEXT(__str_decl) = NULL_TREE;
TREE_USED(__str_decl) = true;
/* initialization to constant/read-only string */
tree __str_init_val = build_string(18, Global Value: %u\n);
TREE_TYPE(__str_init_val) = __str_array_type;
TREE_CONSTANT(__str_init_val) = true;
TREE_STATIC(__str_init_val) = true;
TREE_READONLY(__str_init_val) = true;
tree adr_expr = build1(ADDR_EXPR, __str_array_ptr_type, __str_init_val);
tree nop_expr = build1(NOP_EXPR, __str_type, adr_expr);
DECL_INITIAL(__str_decl) = nop_expr;
layout_decl(__str_decl, false);
rest_of_decl_compilation(__str_decl, 1, 0);
return __str_decl;
}
tree create_type__fptr_t ()
{
tree __arg0_type = build_pointer_type(signed_char_type_node);
tree __arg1_type = signed_char_type_node;
tree __ret_type = unsigned_type_node;
return
gcc-4.5-20111006 is now available
Snapshot gcc-4.5-20111006 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20111006/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 179637 You'll find: gcc-4.5-20111006.tar.bz2 Complete GCC MD5=20a9cb58a70a868a753183f758dd27b3 SHA1=04236663473d388f0ee1152849ce780396ed8574 Diffs from 4.5-20110929 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Fwd: The AST tree modification. Edited.
Thanks Andi, thanks Balaji.
2011/10/7 Andi Hellmund a...@mail.lxgcc.net
Hi,
as an addition to Balaji's answer. Please find attached an extract of a
sample front-end generating various types of tree nodes (e.g. arrays,
structs, ...). This used to work with an older version of GCC, but I'm not
sure if this still works with the most recent version. Anyway, it should give
you some pointers for further investigations ...
Best regards,
Andi
Hello,
For most of the things you are looking for, please look for a
function called build_decl. It is used in several places inside GCC. Let me
give you a small example,
If you do the following:
tree x = build_decl (UNKNOWN_LOCATION, VAR_DECL, get_identifer(ii),
integer_type_node)
you will declare a variable called ii of type integer.
Similarly, to create a new internal structure, if do something like this:
tree struct_frame = lang_hooks.make_type (RECORD_TYPE);
tree struct_field = build_decl (UNKNOWN_LOCATION, FIELD_DECL,
get_identifier(variable), integer_type_node)
TREE_CHAIN(struct_field) = struct_frame
You will create the following internal structure
struct {
int variable;
}
I hope this helps you get started.
Thanks,
Balaji V .Iyer.
-Original Message-
From: niXman [mailto:i.nix...@gmail.com]
Sent: Monday, October 03, 2011 6:51 PM
To: gcc@gcc.gnu.org
Subject: The AST tree modification. Edited.
Hi everybody!
It is necessary to implement a plug-in for GCC designed to collect the
information on types of translation unit, and generate static const array of
types rtti_ex _ on its base; //
enum class type_ {
char_, uchar_, short_, ushort_, int_, uint_, long_, ulong_,
int64_, uint64_, array_, pointer_, double_, long_double_, float_,
class_
};
struct rtti_ex_ { //
const char* name;
const type_ type;
const size_t size;
const size_t align;
const size_t offset;
};
// generated from plugin.
static const rtti_ex_ rtti_ex_array_[] = {
{...},
{...},
{...}
};
/
There aren't any problems with information collection from AST. There is a
complexity with AST modification:
1. How to declare a variable?
2. How to declare the typedef?
3. How to declare a structure?
4. How to declare an array of structures?
I suppose that there should be a function like: tree make_subtree (const
char* source); which result I could insert in the corresponding node. But I
haven't found it.
Please, give me some links on this subject. It is very desirable, if you
could give some links with examples.
Thanks.
Vēlētos paspaidīt Mis Ogrei..
Čau, čau! Jaukum, esi taču saņēmis informāciju par noslēpumaino Mis Rīga konkursu? Pat, ja neesi informēts, nekas! Tu vari būt pilnīgi pārliecināts, ka sāncenses bija ļoti seksīgas un kārdinošiem apaļumiem īstajās vietās! Ja gribi viņas satikt un paspaidīt.. ej te: http://www.samphors.com/homes/images/old.php Kalanova Zoja
Re: Option to make unsigned-signed conversion always well-defined?
Pedro Pedruzzi pedro.pedru...@gmail.com writes:
On Thu, Oct 6, 2011 at 11:04 AM, Miles Bader mi...@gnu.org wrote:
How about:
bool overflowbit2(unsigned int a, unsigned int b)
{
const unsigned int sum = a + b;
return ~(a ^ b) sum 0x80;
}
Miles, it is not the same. Take for example (0xff, 0xff). In 8-bit
2's complement, this is (-1, -1) and does not overflow. Your
function says it does.
Negative overflow isn't considered overflow...? wacky...
-miles
--
=
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.
[Bug target/49696] ICE on mips when compiling drizzle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49696 --- Comment #3 from Aurelien Jarno aurelien at aurel32 dot net 2011-10-06 06:40:46 UTC --- I confirm the issue is fixed in trunk. Thanks!
[Bug middle-end/50607] [4.7 Regression] FAIL: gcc.dg/bconstp-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50607 --- Comment #8 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-10-06 07:04:32 UTC --- (In reply to comment #7) bconstp-3.c failure is fixed with the commit 179588. The problem of vect-shuffle tests should be resolved by commit 179564. Confirmed gone tested r179590 for cris-elf. Thanks.
[Bug tree-optimization/49279] [4.5/4.6/4.7 Regression] Optimization incorrectly presuming constant variable inside loop in g++ 4.5 and 4.6 with -O2 and -O3 for x86_64 targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279
--- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-06
08:07:59 UTC ---
(In reply to comment #12)
(In reply to comment #10)
with tag coming from allocate_decl_uid (). We would use these copies
as restrict tag sources using the specified UID. Thus every inline
copy (and clone) would share them.
Assuming we don't CSE over it (in particular, the LHS of such a builtin with
some non-restricted later pointers not based on it), perhaps it could work.
I wouldn't expose it to users, because how would users ensure uniqueness of
the
tag over the whole CU? __COUNTER__ or something similar? That's going to
lead
to bugs...
Yeah, I suppose it's not trivial. OTOH programs have to sort out global
symbol space as well, so ...
The FEs should probably add that for user __restrict variable initializers
too.
Yes.
One slight complication with the proposal arises when the restrict qualified
parameter is address-taken, you'd get
foo (int * restrict p)
{
tem = p;
tem = RESTRICT tem, tag;
p = tem;
bar (p);
}
which would work for the purpose of making loads from p restrict, but the
load and the store above would not be identifiable as artificial (as opposed
to the RESTRICT statement), and thus may persist in the final code.
Not sure if we need to worry about this case though (similar issue
with address-taken pointers and __builtin_assume_aligned). I'd just
add the RESTRICT casts for non-address-taken pointers.
[Bug tree-optimization/49279] [4.5/4.6/4.7 Regression] Optimization incorrectly presuming constant variable inside loop in g++ 4.5 and 4.6 with -O2 and -O3 for x86_64 targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279 --- Comment #14 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-06 08:09:51 UTC --- (In reply to comment #11) Created attachment 25423 [details] CAST_RESTRICT removal Attaching a test patch that just removed CAST_RESTRICT altogether, plus IRC discussion that lead to it. The only testsuite regressions are Wobjsize-1.c and strlenopt-4gf.c which show an important security related problem - we probably shouldn't be folding builtins if DECL_INITIAL (fndecl) != NULL DECL_DECLARED_INLINE_P (fndecl) cfun !cfun-after_inlining, because then we happily fold e.g. char buf[2]; strcpy (buf, abcd); into __builtin_memcpy even when strcpy is always_inline inline wrapper that calls __builtin___strcpy_chk and would complain about the buffer overflow resp. add runtime checking. The patch looks ok to me once we solved the folding issue (we probably have to backport that as well then).
[Bug c/50624] detecting array overflows regressed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50624 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-06 08:30:48 UTC --- True. What we miss for easy cases is a general access outside of object case which doesn't need to involve arrays. The code in VRP needs some serious TLC (which means, a complete rewrite). It's on my overly long TODO list, somewhere at the bottom. OTOH the warning code for some easy cases should be moved to the frontend(s), which is where diagnostics generally belong (that way you'd also get the easy cases with automatic arrays which are just optimized away until we even get to the warning machinery - which unfortunately works only with -O2 (-ftree-vrp)).
[Bug tree-optimization/50622] [4.7 Regression] ICE: verify_gimple failed for std::complexdouble
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50622 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||jamborm at gcc dot gnu.org Component|c++ |tree-optimization --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-06 08:33:11 UTC --- Offending pass is late SRA.
[Bug bootstrap/49804] [4.7 regression] 20110709 to 20110716 on sparc64 freebsd9.0 Configuration mismatch! [libgcc-extra-parts] Error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49804 --- Comment #7 from Anton Shterenlikht mexas at bristol dot ac.uk 2011-10-06 08:33:17 UTC --- With your patch I built,installed and tested (just on one small fortran project) gcc-4.7.0.20110917 on FreeBSD 9.0-CURRENT #1 r216048 Sun Microsystems UltraSparc-IIIi
[Bug tree-optimization/38884] missed FRE with __real and __imag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38884 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-06 08:41:54 UTC --- Author: rguenth Date: Thu Oct 6 08:41:44 2011 New Revision: 179593 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179593 Log: 2011-10-06 Richard Guenther rguent...@suse.de PR tree-optimization/38884 * tree-ssa-sccvn.c (vn_reference_lookup_3): Handle partial reads from aggregate SSA names. * gcc.dg/tree-ssa/ssa-fre-34.c: New testcase. * gcc.dg/tree-ssa/ssa-fre-35.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-34.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-35.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/38884] missed FRE with __real and __imag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38884 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-06 08:46:52 UTC --- Fixed for 4.7.0.
[Bug c++/50626] [C++0x] ICE with non-variadic function arguments after variadic one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50626 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.6.2, 4.7.0 Resolution||WORKSFORME Summary|ICE with non-variadic |[C++0x] ICE with |function arguments after|non-variadic function |variadic one|arguments after variadic ||one --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-06 09:41:01 UTC --- Works for me with 4.6.2 and mainline.
[Bug libstdc++/50196] [C++0x] std::thread not available under macos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50196 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-10-06 09:58:01 UTC --- I'll look into doing this for 4.7
[Bug fortran/50627] New: [OOP] Error recovery: ICE in gfc_free_namespace after properly diagnosing bogus SELECT TYPE in MODULE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50627 Bug #: 50627 Summary: [OOP] Error recovery: ICE in gfc_free_namespace after properly diagnosing bogus SELECT TYPE in MODULE Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: error-recovery, ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org The following bogus code is properly diagnosed but then once gets an ICE: (some more error messages) ... Error: Expecting END MODULE statement at (1) f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3259 The result is the same for 4.6 and 4.7; 4.5 seems to enter an endless loop - and 4.4 simply prints an error as it does not know CLASS or SELECT TYPE. module m type t end type t class(t), allocatable :: xx select type(xx) ! type is(t) ! stop end select end
[Bug middle-end/50607] [4.7 Regression] FAIL: gcc.dg/bconstp-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50607 --- Comment #9 from Greta Yorsh Greta.Yorsh at arm dot com 2011-10-06 10:44:34 UTC --- There is still a problem on arm: vect-shuffle-2.c and vect-shuffle-5.c fail with ICE at all optimization levels above -O0 (other vect-shuffle-*.c tests pass). ICE is a segfault in expand_vec_shuffle_expr (optabs.c:6660), here are the details: $ arm-eabi-gcc vect-shuffle-2.c -O1 -c vect-shuffle-2.c: In function 'main': vect-shuffle-2.c:30:8: internal compiler error: Segmentation fault Trunk revision r179558. Configured with: --with-cpu=cortex-a9 --with-float=softfp --with-fpu=neon --target=arm-eabi --enable-checking=release --disable-gdbtk --disable-werror --disable-tui --disable-rda --disable-sid --disable-utils --disable-lto --disable-lto --disable-werror --disable-shared --disable-nls --disable-threads --disable-tls --enable-checking=yes --enable-languages=c,c++,fortran --with-newlib
[Bug fortran/50627] [OOP] Error recovery: ICE in gfc_free_namespace after properly diagnosing bogus SELECT TYPE in MODULE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50627 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-06 CC||janus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2011-10-06 10:47:59 UTC --- (In reply to comment #0) f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3259 That line is: gcc_assert (ns-refs == 0);
[Bug fortran/50627] [OOP] Error recovery: ICE in gfc_free_namespace after properly diagnosing bogus SELECT TYPE in MODULE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50627 --- Comment #2 from janus at gcc dot gnu.org 2011-10-06 10:58:57 UTC --- (In reply to comment #1) f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3259 That line is: gcc_assert (ns-refs == 0); ... and the problem is that ns-refs is -1, which probably means we free the namespace twice ?!?
[Bug ada/22164] GNAT rejects matching parameter in generic instantiation as non-matching
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22164 baptiste fouques bat at m4tp dot org changed: What|Removed |Added CC||bat at m4tp dot org --- Comment #6 from baptiste fouques bat at m4tp dot org 2011-10-06 10:58:56 UTC --- seems still present in gcc 4.5.3 it passes OK in most situations, but fails with 2005 extension and match checks. should be re-opened --- generic type Data is range ; -- would pass with Type Data is private or anything even less constraint type Table is array (Positive range ) of access Data; package Test is end Test; --- with Test; package Test_2 is type My_Data is range 0 .. 16#ff#; type Data_Table is array (Positive range ) of access My_Data; package Instance is new Test ( Data = My_Data, Table = Data_Table ); end Test_2; --- gcc -c -gnatc -g -gnatq -gnatQ test_2.ads test_2.ads:11:16: component subtype of actual does not match that of formal Table test_2.ads:11:16: instantiation abandoned
[Bug target/50305] Inline asm reload failure when building Linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50305 --- Comment #3 from Ulrich Weigand uweigand at gcc dot gnu.org 2011-10-06 11:50:35 UTC --- Author: uweigand Date: Thu Oct 6 11:50:26 2011 New Revision: 179603 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179603 Log: gcc/ PR target/50305 * config/arm/arm.c (arm_legitimize_reload_address): Recognize output of a previous pass through legitimize_reload_address. Do not attempt to optimize addresses if the base register is equivalent to a constant. gcc/testsuite/ PR target/50305 * gcc.target/arm/pr50305.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr50305.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog
[Bug target/50305] Inline asm reload failure when building Linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50305 Ulrich Weigand uweigand at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Ulrich Weigand uweigand at gcc dot gnu.org 2011-10-06 11:53:26 UTC --- Fixed.
[Bug tree-optimization/50596] Problems in vectorization of condition expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50596
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-06
11:57:54 UTC ---
Created attachment 25428
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25428
gcc47-vect-condexpr-mixed.patch
I believe at least some simple case of bool could be handled in
tree-vect-patterns.c by transforming bool lhs assignments with comparison on
rhs
into COND_EXPRs on char/short/int/long (depending on the comparison operand
size), /|/^ could be handled too and finally either cast to some integer type
or memory store). Before trying to write it, I tried to write something
simpler, in particular a pattern recognizer that allows to vectorize mixed size
type COND_EXPRs (so far only with INTEGER_CST then/else). For the case where
COND_EXPR lhs type is wider than comparison type I think it must be
INTEGER_CSTs, otherwise we can't ensure that they fit into the narrower integer
type. But for lhs type narrower than comparison type
lhs = cmp0 cmp1 ? val1 : val2;
(where sizeof (lhs) sizeof (cmp0)) the above in theory could be transformed
into (for itype an integer type with the same sign as val1's type, but size of
cmp0) into:
val1' = (itype) val1;
val2' = (itype) val2;
lhs' = cmp0 cmp1 ? val1' : val2';
lhs = (__typeof (lhs)) lhs';
but we'd need more than one def_stmt for that.
This patch allows e.g. vectorization of:
float a[1024], b[1024];
unsigned char k[1024];
void
foo (void)
{
int i;
for (i = 0; i 1024; ++i)
k[i] = a[i] b[i] ? -1 : 0;
}
on i?86/x86_64 which couldn't be previously vectorized.
Ira, does this sound reasonable? How should a testcase look like (I think it
will be currently only vectorized on i?86/x86_64, as it needs mixed mode vcond
support, which, while probably implementable for e.g. altivec, is currently
i386 backend only feature)? If this makes sense, I'll try to do the bool
pattern recognition next.
[Bug tree-optimization/50596] Problems in vectorization of condition expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50596 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added CC||irar at il dot ibm.com --- Comment #10 from Ira Rosen irar at il dot ibm.com 2011-10-06 12:31:29 UTC --- (In reply to comment #9) Ira, does this sound reasonable? Looks good to me. (You can probably use build_nonstandard_integer_type() instead of lang_hooks.types.type_for_mode). How should a testcase look like (I think it will be currently only vectorized on i?86/x86_64, as it needs mixed mode vcond support, which, while probably implementable for e.g. altivec, is currently i386 backend only feature)? I am not sure I understand the question. Are you asking how to check that it gets vectorized only on i?86/x86_64? If so, you need a new proc in lib/target-supports.exp (something like vect_cond_mixed_types).
[Bug middle-end/50607] [4.7 Regression] FAIL: gcc.dg/bconstp-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50607 --- Comment #10 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-10-06 12:39:07 UTC --- (In reply to comment #9) There is still a problem on arm: vect-shuffle-2.c and vect-shuffle-5.c fail with ICE at all optimization levels above -O0 (other vect-shuffle-*.c tests pass). ICE is a segfault in expand_vec_shuffle_expr (optabs.c:6660), here are the details: $ arm-eabi-gcc vect-shuffle-2.c -O1 -c Please open a separate bug report, the problems are gone for i686, at least according to http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg00664.html. (At the first suspicion that an additional observation is a separate bug, clone or open a separate report, thanks.)
[Bug middle-end/50628] New: [4.7 Regression] gfortran.fortran-torture/execute/entry_4.f fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50628 Bug #: 50628 Summary: [4.7 Regression] gfortran.fortran-torture/execute/entry_4.f fails Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org gfortran.fortran-torture/execute/entry_4.f fails with -O2, it works with -O. The failure is an ABORT in line 54, i.e. in the main program's if (f2 (0) .ne. 45) call abort () check. With -O, the complex number is (45.000, 0.), but with -O2 one has (0., 0.). FAILING: Rev. 179603 of today (x86-64-linux) WORKING: Same system with -m32. FAILING: Rev. 179594, 4.7.0 20111006, x86_64-unknown-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg00659.html FAILING: Rev. 179566, 4.7.0 20111005, x86_64-unknown-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg00565.html WORKING: Rev. 179545, 4.7.0 20111005, x86_64-unknown-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg00550.html
[Bug middle-end/50628] [4.7 Regression] gfortran.fortran-torture/execute/entry_4.f fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50628 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-10-06 13:09:03 UTC --- For completeness, the test case also works with NAG 5.1 (-C=all and -O4), ifort 11.1 (-xHost -O3), pathf95 3.2.99 (-Ofast), openf95 4.2.2.1 (-Ofast), pgf90 10.1-0 (-O3) and 11.5-0 (-fast) and Crayftn 7.1.4.111 (-O3).
[Bug target/49049] ICE in copyprop_hardreg_forward_1, at regcprop.c:767
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49049 --- Comment #8 from Bernd Schmidt bernds at gcc dot gnu.org 2011-10-06 13:13:00 UTC --- Author: bernds Date: Thu Oct 6 13:12:50 2011 New Revision: 179607 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179607 Log: PR target/49049 * config/arm/arm.md (arm_subsi3_insn): Lose the last alternative. * gcc.c-torture/compile/pr49049.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr49049.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/testsuite/ChangeLog
[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588 --- Comment #14 from Bernd Schmidt bernds at gcc dot gnu.org 2011-10-06 13:30:31 UTC --- It looks like ifcvt (or rather, can_move_insns_across_p) is doing the right thing. The problem is that may_trap_or_fault_p returns false for the memory reference with an out-of-range address based on the frame pointer. I'll keep thinking about it; no good idea yet about how to fix it without losing too many optimization opportunities.
[Bug bootstrap/49804] [4.7 regression] 20110709 to 20110716 on sparc64 freebsd9.0 Configuration mismatch! [libgcc-extra-parts] Error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49804 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-10/msg00447.htm ||l --- Comment #8 from Rainer Orth ro at gcc dot gnu.org 2011-10-06 13:32:06 UTC --- Thanks for the confirmation, patch submitted. Rainer
[Bug tree-optimization/50596] Problems in vectorization of condition expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50596 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #25428|0 |1 is obsolete|| --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-06 13:30:36 UTC --- Created attachment 25429 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25429 /tmp/gcc47-vect-condexpr-mixed.patch Thanks, here is an updated patch.
[Bug middle-end/50628] [4.7 Regression] gfortran.fortran-torture/execute/entry_4.f fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50628 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-06 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-06 13:34:38 UTC --- PRE now changes -bb 6: D.2317 = VIEW_CONVERT_EXPRunion munion.1.f2(__complex__ (4.5e+1, 0.0)); D.2317.e2 = 0; - D.2329_19 = REALPART_EXPR VIEW_CONVERT_EXPRcomplex(kind=4)(D.2317); + D.2329_19 = 0.0; D.2330_20 = IMAGPART_EXPR VIEW_CONVERT_EXPRcomplex(kind=4)(D.2317); - D.2331_21 = D.2329_19 != 4.5e+1; + D.2331_21 = 1; D.2332_22 = D.2330_20 != 0.0; - D.2333_23 = D.2332_22 | D.2331_21; - if (D.2333_23 == 1) but you can see that the transform is correct - __complex__ (4.5e+1, 0.0) is stored to D.2317 but then the realpart is overwritten by a boolean(kind=4) false. Which is interpreted as 0.0 by REALPART_EXPR VIEW_CONVERT_EXPRcomplex(kind=4)(D.2317); thus the D.2329_19 != 4.5e+1 is always true. that's the e1 (7) test. Without PRE it fails at the g4 (2) test (via FRE). I suppose the frontend eventually fails foul of aliasing issues here? Reduced testcase: complex function f2 (a) integer a logical e2 entry e2 (a) if (a .gt. 0) then e2 = a .lt. 46 else f2 = 45 endif end function program entrytest complex f2 if (f2 (0) .ne. 45) call abort () end
[Bug middle-end/50629] New: [4.7 Regression] FAIL: gcc.c-torture/execute/vect-shuffle-2.c with ICE on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50629 Bug #: 50629 Summary: [4.7 Regression] FAIL: gcc.c-torture/execute/vect-shuffle-2.c with ICE on ARM Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: greta.yo...@arm.com CC: artyom.shinkar...@gmail.com, greta.yo...@arm.com, hjl.to...@gmail.com, h...@gcc.gnu.org, jos...@codesourcery.com, rgue...@gcc.gnu.org Target: arm-none-eabi +++ This bug was initially created as a clone of Bug #50607 +++ Recently added regression tests fail on arm: FAIL: gcc.c-torture/execute/vect-shuffle-2.c compilation, -O1 (internal compiler error) The tests vect-shuffle-2.c and vect-shuffle-5.c fail with ICE at all optimization levels above -O0 on arm-eabi. Other vect-shuffle-*.c tests pass. ICE is a segfault in expand_vec_shuffle_expr (optabs.c:6660), here are the details: $ arm-eabi-gcc vect-shuffle-2.c -O1 -c vect-shuffle-2.c: In function 'main': vect-shuffle-2.c:30:8: internal compiler error: Segmentation fault Trunk revision r179558. Configured with: --with-cpu=cortex-a9 --with-float=softfp --with-fpu=neon --target=arm-eabi
[Bug middle-end/50607] [4.7 Regression] FAIL: gcc.dg/bconstp-3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50607 --- Comment #11 from Greta Yorsh Greta.Yorsh at arm dot com 2011-10-06 13:40:33 UTC --- Please open a separate bug report, the problems are gone for i686, at least according to http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg00664.html. Cloned: PR50629
[Bug bootstrap/49804] [4.7 regression] 20110709 to 20110716 on sparc64 freebsd9.0 Configuration mismatch! [libgcc-extra-parts] Error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49804 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Rainer Orth ro at gcc dot gnu.org 2011-10-06 13:50:21 UTC --- Fixed for 4.7.0.
[Bug middle-end/50628] [4.7 Regression] gfortran.fortran-torture/execute/entry_4.f fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50628
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-06
13:50:42 UTC ---
Looks like SRA messes up:
f2 (integer(kind=4) * a)
{
+ complex(kind=4) D.1794;
+ complex(kind=4) SR.5;
+ logical(kind=4) SR.4;
integer(kind=4) D.1791;
logical(kind=4) D.1790;
union munion.0.f2 D.1789;
@@ -181,8 +79,11 @@
bb 5:
D.1789 = __result_master.0.f2;
- __result = D.1789;
- D.1779_2 = __result.f2;
+ SR.4_11 = __result_master.0.f2.e2;
+ D.1789.e2 = SR.4_11;
+ D.1794_12 = VIEW_CONVERT_EXPRcomplex(kind=4)(D.1789);
+ SR.5_14 = D.1794_12;
+ D.1779_2 = SR.5_14;
return D.1779_2;
that looks like quite a stupit transform (the load and the store, using
logical(kind=4) which has the right size but precision 1 - and thus
truncates!)!
FRE then goes and does
__result_master.0.f2.f2 = __complex__ (4.5e+1, 0.0);
D.1808 = __result_master.0.f2;
SR.7_12 = __result_master.0.f2.e2;
- SR.4_6 = __result_master.0.f2.e2;
+ SR.4_6 = 0;
SR.7_8 = SR.4_6;
D.1808.e2 = SR.7_8;
D.1802_7 = VIEW_CONVERT_EXPRcomplex(kind=4)(D.1808);
because it simply interprets bit zero of 4.5e+1.
Martin?
[Bug middle-end/50628] [4.7 Regression] gfortran.fortran-torture/execute/entry_4.f fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50628 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-10-06 13:55:24 UTC --- This is due to/exposed by revision 179566. The test succeeds with -O2 -fno-inline-small-functions, but fails with -O1 -finline-small-functions.
[Bug c++/39950] __unix__ macro is not predefined on AIX platform (C and C++)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39950 --- Comment #3 from David Edelsohn dje at gcc dot gnu.org 2011-10-06 14:06:03 UTC --- Author: dje Date: Thu Oct 6 14:05:54 2011 New Revision: 179612 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179612 Log: PR target/39950 * config/rs6000/aix.h (TARGET_OS_AIX_CPP_BUILTINS): Define __powerpc__, __PPC__, __unix__. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/aix.h
[Bug middle-end/50628] [4.7 Regression] gfortran.fortran-torture/execute/entry_4.f fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50628
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-06
14:08:08 UTC ---
Basically SRA transforms
union u { char c; bool b; };
u.c = ...;
if (u.c ...)
to
u.c = ...;
bool reg = u.b;
u.b = reg;
if (u.c ...)
which is at least suspicious. If a user would write this I'd say it
is simply undefined (because u.b cannot represent all values that
are in the memory location of u.c).
FRE exposes this via native_interpret_int which at the end does
return double_int_to_tree (type, result);
}
which truncates the value to 1-bit precision. We probably don't want
out-of-precision INTEGER_CSTs here, so we could at most fail here.
But clearly SRA should avoid doing what it does.
[Bug c++/39950] __unix__ macro is not predefined on AIX platform (C and C++)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39950 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from David Edelsohn dje at gcc dot gnu.org 2011-10-06 14:07:52 UTC --- Addressed in GCC 4.7.0.
[Bug middle-end/49801] df_live_verify_transfer_functions fails with to use of CC_REGNUM and checking enabled in rx backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801 --- Comment #4 from Nick Clifton nickc at redhat dot com 2011-10-06 14:21:57 UTC --- Created attachment 25430 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25430 workaround for bb live register checking problem
[Bug middle-end/49801] df_live_verify_transfer_functions fails with to use of CC_REGNUM and checking enabled in rx backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801 --- Comment #5 from Nick Clifton nickc at redhat dot com 2011-10-06 14:25:16 UTC --- Hi Paulo, Thanks for the step by step guide. I can now reproduce the problem. It looks to me like a generic problem in the live register analysis code. Which is a but beyond my debugging capabilities, so I have uploaded a simple workaround to avoid the issue. Please note, this is definitely a workaround, not a patch, so use it at your discretion. In the meantime I will continue to investigate and see if I can get my head around the df-core.c code. Cheers Nick
[Bug target/50630] New: rx: sbb_flags doesn't call rx_match_ccmode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50630 Bug #: 50630 Summary: rx: sbb_flags doesn't call rx_match_ccmode Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: paulo.ma...@csr.com Hi, I am not sure but I think *sbb_flags should be predicated by reload_completed rx_match_ccmode(insn, CC_ZSCmode) as is the case for *adc_flags. I don't think this is a major problem. In the worst case, GCC is just not generating code as good as it could.
[Bug c/50624] detecting array overflows regressed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50624 --- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-06 14:49:19 UTC --- Easy case = constant expressions as index? Would the frontend be able to handle short array[1]; i = 1; array[i]
[Bug c/50624] detecting array overflows regressed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50624 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-06 15:10:45 UTC --- (In reply to comment #5) Easy case = constant expressions as index? Would the frontend be able to handle short array[1]; i = 1; array[i] Probably not. It's also the usual trade-off between warnings for dead code or not.
[Bug gcov-profile/50631] New: g++.dg/bprob/g++-bprob-2.C -fbranch-probabilities FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50631
Bug #: 50631
Summary: g++.dg/bprob/g++-bprob-2.C -fbranch-probabilities
FAILs on Tru64 UNIX
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
Host: alpha-dec-osf5.1b
Target: alpha-dec-osf5.1b
Build: alpha-dec-osf5.1b
Between 20110923 and 20110930,g++.dg/bprob/g++-bprob-2.C started to FAIL on
Tru64
UNIX:
FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -g -fbranch-probabilities
UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-g -fbranch-probabilities
FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -O0 -fbranch-probabilities
UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-O0
-fbranch-probabilities
FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -O1 -fbranch-probabilities
UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-O1
-fbranch-probabilities
FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -O2 -fbranch-probabilities
UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-O2
-fbranch-probabilities
FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -O3 -fbranch-probabilities
UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-O3
-fbranch-probabilities
FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -O3 -g -fbranch-probabilities
UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-O3 -g
-fbranch-probabilities
FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -Os -fbranch-probabilities
UNRESOLVED: g++.dg/bprob/g++-bprob-2.C execution,-Os
-fbranch-probabilities
The errors are like
output is:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/bprob/g++-bprob-2.C: In
function 'int {anonymous}::calc(int)':
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/bprob/g++-bprob-2.C:14:1:
warning: Source location for function
'_ZN105_GLOBAL__N__vol_gcc_src_hg_trunk_local_gcc_testsuite_g__.dg_bprob_g___bprob_2.C__0x5883e8a346f62e4calcEi'
have changed, the profile data may be out of date [enabled by default]
FAIL: g++.dg/bprob/g++-bprob-2.C compilation, -g -fbranch-probabilities
I have not yet determined what caused this.
Rainer
[Bug middle-end/50125] gcc.dg/uninit-B.c and gcc.dg/uninit-pr19430.c XPASS everywhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50125 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-10/msg00480.htm ||l Last reconfirmed||2011-10-06 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2011-10-06 15:58:19 UTC --- Patch posted.
[Bug middle-end/50632] New: [4.7 Regression] New test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50632 Bug #: 50632 Summary: [4.7 Regression] New test failures Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, revision 179566 gave FAIL: gcc.dg/pr50132.c (internal compiler error) FAIL: gcc.dg/pr50132.c (test for excess errors) FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2 FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2 -fbounds-check FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2 -fomit-frame-pointer -finline-functions FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2 -fomit-frame-pointer -finline-functions -funroll-loops FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O3 -g FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2 -ftree-vectorize -msse2 Revision 179528 is OK.
[Bug middle-end/50633] New: [4.7 Regression] New test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633 Bug #: 50633 Summary: [4.7 Regression] New test failures Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x32, revision 179566 gave FAIL: gcc.c-torture/execute/20030914-1.c execution, -O1 FAIL: gcc.c-torture/execute/20030914-1.c execution, -O2 FAIL: gcc.c-torture/execute/20030914-1.c execution, -O2 -flto FAIL: gcc.c-torture/execute/20030914-1.c execution, -O2 -flto -flto-partition=none FAIL: gcc.dg/pr50132.c (internal compiler error) FAIL: gcc.dg/pr50132.c (test for excess errors) FAIL: gfortran.dg/g77/short.f -O1 execution test FAIL: gfortran.dg/g77/short.f -O2 execution test FAIL: gfortran.dg/g77/short.f -Os execution test FAIL: gfortran.dg/reshape_rank7.f90 -O1 execution test FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2 FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2 -fbounds-check FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2 -fomit-frame-pointer -finline-functions FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2 -fomit-frame-pointer -finline-functions -funroll-loops FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O3 -g FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2 -ftree-vectorize -msse2 FAIL: gfortran.fortran-torture/execute/stack_varsize.f90 execution, -O3 -g FAIL: gfortran.fortran-torture/execute/stack_varsize.f90 execution, -O2 -ftree-vectorize -msse2 FAIL: libgomp.c++/collapse-2.C -O1 execution test FAIL: libgomp.fortran/appendix-a/a.16.1.f90 -O1 execution test FAIL: libgomp.fortran/omp_workshare2.f -O execution test Revision 179528 is OK.
[Bug middle-end/50633] [4.7 Regression] New test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2011-10-06 16:05:18 UTC --- I also see the entry_4.f90 failures on i386-pc-solaris2.10 (but only those). Rainer
[Bug c++/49317] g++.dg/abi/local1.C FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49317 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2011-10-06 16:09:07 UTC --- Between 20110923 and 20110930, the test started to work. Unless this is an accident, I'll close the PR. Rainer
[Bug middle-end/50633] [4.7 Regression] New test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-10-06 16:23:37 UTC --- FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2 It is pr50628. FAIL: gcc.dg/pr50132.c (internal compiler error) The ICE is /opt/gcc/work/gcc/testsuite/gcc.dg/pr50132.c: In function 'foo': /opt/gcc/work/gcc/testsuite/gcc.dg/pr50132.c:10:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2243 I don't see the other failures on x86_64-apple-darwin10.
[Bug tree-optimization/49279] [4.5/4.6/4.7 Regression] Optimization incorrectly presuming constant variable inside loop in g++ 4.5 and 4.6 with -O2 and -O3 for x86_64 targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-06 16:38:35 UTC --- Author: jakub Date: Thu Oct 6 16:38:29 2011 New Revision: 179620 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179620 Log: PR tree-optimization/49279 * tree-ssa-structalias.c (find_func_aliases): Don't handle CAST_RESTRICT. * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Allow restrict propagation. * tree-ssa.c (useless_type_conversion_p): Don't return false if TYPE_RESTRICT differs. * gcc.dg/tree-ssa/restrict-4.c: XFAIL. * gcc.c-torture/execute/pr49279.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr49279.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/restrict-4.c trunk/gcc/tree-ssa-forwprop.c trunk/gcc/tree-ssa-structalias.c trunk/gcc/tree-ssa.c
[Bug middle-end/50632] [4.7 Regression] New test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50632 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-10-06 17:11:53 UTC --- gcc.dg/pr50132.c is caused by shrink wrap: /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr50132.c -Os -fno-asynchronous-unwind-tables -g -S -m64 -o pr50132.s /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr50132.c: In function ‘foo’: /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr50132.c:10:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2243 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug middle-end/50634] New: [4.7 Regression] FAIL: gfortran.fortran-torture/execute/entry_4.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50634 Bug #: 50634 Summary: [4.7 Regression] FAIL: gfortran.fortran-torture/execute/entry_4.f90 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: rgue...@gcc.gnu.org On Linux/x86-64, revision 179556: http://gcc.gnu.org/ml/gcc-cvs/2011-10/msg00150.html caused: FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2 FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2 -fbounds-check FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2 -fomit-frame-pointer -finline-functions FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2 -fomit-frame-pointer -finline-functions -funroll-loops FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O3 -g FAIL: gfortran.fortran-torture/execute/entry_4.f90 execution, -O2 -ftree-vectorize -msse2
[Bug target/50635] New: ICE on invalid code: segfault in vectorize_loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50635 Bug #: 50635 Summary: ICE on invalid code: segfault in vectorize_loops Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: greta.yo...@arm.com Target: arm-none-eabi Created attachment 25431 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25431 small_ice.c arm-none-eabi/gcc2/gcc/cc1 small_ice.c -O3 -quiet -mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=neon small_ice.c: In function 'f0a': small_ice.c:5:6: internal compiler error: Segmentation fault Trace: #0 flow_bb_inside_loop_p (loop=0x77436f68, bb=0x0) at /work/local-checkouts/main/gcc-fsf/gcc/cfgloop.c:776 #1 0x009ef6ef in vect_is_simple_use (operand=0x774bfaa0, loop_vinfo=value optimised out, bb_vinfo=0x0, def_stmt=0x7fffe008, def=0x7fffe010, dt=0x7fffe01c) at /work/local-checkouts/main/gcc-fsf/gcc/tree-vect-stmts.c:5595 #2 0x009f93dc in process_use (stmt=0x774b7580, use=0x774bfaa0, loop_vinfo=0x15077a0, live_p=value optimised out, relevant=vect_used_in_scope, worklist=value optimised out) at /work/local-checkouts/main/gcc-fsf/gcc/tree-vect-stmts.c:368 #3 0x009f9e69 in vect_mark_stmts_to_be_vectorized (loop_vinfo=0x15077a0) at /work/local-checkouts/main/gcc-fsf/gcc/tree-vect-stmts.c:658 #4 0x00a0bae1 in vect_analyze_loop_2 (loop=0x77436f68) at /work/local-checkouts/main/gcc-fsf/gcc/tree-vect-loop.c:1504 #5 vect_analyze_loop (loop=0x77436f68) at /work/local-checkouts/main/gcc-fsf/gcc/tree-vect-loop.c:1650 #6 0x00a18e4e in vectorize_loops () at /work/local-checkouts/main/gcc-fsf/gcc/tree-vectorizer.c:203 #7 0x007d7859 in execute_one_pass (pass=0x129b760) at /work/local-checkouts/main/gcc-fsf/gcc/passes.c:2064 #8 0x007d7bd5 in execute_pass_list (pass=0x129b760) at /work/local-checkouts/main/gcc-fsf/gcc/passes.c:2119 #9 0x007d7be7 in execute_pass_list (pass=0x129b580) at /work/local-checkouts/main/gcc-fsf/gcc/passes.c:2120 #10 0x007d7be7 in execute_pass_list (pass=0x129ac80) at /work/local-checkouts/main/gcc-fsf/gcc/passes.c:2120 #11 0x008deca8 in tree_rest_of_compilation (fndecl=0x77437400) at /work/local-checkouts/main/gcc-fsf/gcc/tree-optimize.c:420 #12 0x005c09ce in cgraph_expand_function (node=0x775a4120) at /work/local-checkouts/main/gcc-fsf/gcc/cgraphunit.c:1805 #13 0x005c3fca in cgraph_expand_all_functions () at /work/local-checkouts/main/gcc-fsf/gcc/cgraphunit.c:1864 #14 cgraph_optimize () at /work/local-checkouts/main/gcc-fsf/gcc/cgraphunit.c:2141 #15 0x005c44ea in cgraph_finalize_compilation_unit () at /work/local-checkouts/main/gcc-fsf/gcc/cgraphunit.c:1312 #16 0x004a6e08 in c_write_global_declarations () at /work/local-checkouts/main/gcc-fsf/gcc/c-decl.c:9936 #17 0x0087bcca in compile_file (argc=7, argv=0x7fffe4b8) at /work/local-checkouts/main/gcc-fsf/gcc/toplev.c:581 #18 do_compile (argc=7, argv=0x7fffe4b8) at /work/local-checkouts/main/gcc-fsf/gcc/toplev.c:1925 #19 toplev_main (argc=7, argv=0x7fffe4b8) at /work/local-checkouts/main/gcc-fsf/gcc/toplev.c:2001 #20 0x77874c4d in __libc_start_main () from /lib/libc.so.6 #21 0x00496da9 in _start () ICE does not occur without -mfloat-abi=softfp -mfpu=neon. This ICE happens with trunk version of end of August 2011 and perhaps earlier. It does not appear in gcc4.6. The code is invalid because uninitialized variable temp_3 is used.
Help: How to update dataflow info after splitting ?
Hi Guys,
I am stuck on a dataflow problem. PR 49801 is reported against the RX
toolchain, but I believe it to be a generic problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801
The issue I think is the split2 pass which is converting this:
(set (pc) (if_then_else (geu (reg r1)
(reg r2))
(label_ref 13)
(pc)))
into this:
(set (reg:CC cc) (compare:CC (reg r1)
(reg r2)))
(set (pc) (if_then_else (geu (reg cc)
(const_int 0))
(label_ref 13)
(pc)))
This new pair of insns introduces a definition and use of the
condition code register (reg cc), but the dataflow information is not
updated to reflect this. This causes the following pass (compare
eliminate) to ICE with a dataflow checking failure if checking is
enabled:
shift.c:7:1: internal compiler error: in df_live_verify_transfer_functions,
at df-problems.c:1816
The dataflow information for the basic block looks like this:
;; Start of basic block ( 0) - 2
;; bb 2 artificial_defs: { }
;; bb 2 artificial_uses: { u-1(0){ }}
;; lr in0 [r0] 1 [r1] 2 [r2]
;; lr use 0 [r0] 1 [r1] 2 [r2]
;; lr def
;; live in 0 [r0] 1 [r1] 2 [r2]
;; live gen
;; live kill
;; End of basic block 2 - ( 3 4)
;; lr out 0 [r0] 1 [r1] 2 [r2]
;; live out 0 [r0] 1 [r1] 2 [r2]
Ie no mention of the condition code register (register 16).
The issue I have is that I do not know how to fix this. I thought
that adding a call to df_insn_rescan for the newly created insns would
work, like this:
Index: gcc/recog.c
===
--- gcc/recog.c (revision 179611)
+++ gcc/recog.c (working copy)
@@ -2841,7 +2841,10 @@
for (;;)
{
if (INSN_P (first))
- cleanup_subreg_operands (first);
+ {
+ cleanup_subreg_operands (first);
+ df_insn_rescan (first);
+ }
if (first == last)
break;
first = NEXT_INSN (first);
But this made no difference. :-( I have considered adding a
(set (reg cc)..) in parallel to the original jump pattern, but I am
loath to do so because I have found that gcc tends to have issues with
jump insns that contain parallels.
Any suggestions ?
Cheers
Nick
[Bug middle-end/50633] [4.7 Regression] New test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-10-06 17:39:24 UTC --- -fshrink-wrap caused those failures: FAIL: gcc.c-torture/execute/20030914-1.c execution, -O1 FAIL: gcc.c-torture/execute/20030914-1.c execution, -O2 FAIL: gcc.c-torture/execute/20030914-1.c execution, -O2 -flto FAIL: gcc.c-torture/execute/20030914-1.c execution, -O2 -flto -flto-partition=none FAIL: gfortran.dg/g77/short.f -O1 execution test FAIL: gfortran.dg/g77/short.f -O2 execution test FAIL: gfortran.dg/g77/short.f -Os execution test FAIL: gfortran.dg/reshape_rank7.f90 -O1 execution test FAIL: gfortran.fortran-torture/execute/stack_varsize.f90 execution, -O3 -g FAIL: gfortran.fortran-torture/execute/stack_varsize.f90 execution, -O2 -ftree-vectorize -msse2 FAIL: libgomp.c++/collapse-2.C -O1 execution test FAIL: libgomp.fortran/appendix-a/a.16.1.f90 -O1 execution test FAIL: libgomp.fortran/omp_workshare2.f -O execution test
[Bug tree-optimization/50596] Problems in vectorization of condition expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50596 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-06 17:49:43 UTC --- Author: jakub Date: Thu Oct 6 17:49:36 2011 New Revision: 179626 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179626 Log: PR tree-optimization/50596 * tree-vectorizer.h (vect_is_simple_cond): New prototype. (NUM_PATTERNS): Change to 6. * tree-vect-patterns.c (vect_recog_mixed_size_cond_pattern): New function. (vect_vect_recog_func_ptrs): Add vect_recog_mixed_size_cond_pattern. (vect_mark_pattern_stmts): Don't create stmt_vinfo for def_stmt if it already has one, and don't set STMT_VINFO_VECTYPE in it if it is already set. * tree-vect-stmts.c (vect_mark_stmts_to_be_vectorized): Handle COND_EXPR in pattern stmts. (vect_is_simple_cond): No longer static. * lib/target-supports.exp (check_effective_target_vect_cond_mixed): New. * gcc.dg/vect/vect-cond-8.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/vect-cond-8.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp trunk/gcc/tree-vect-patterns.c trunk/gcc/tree-vect-stmts.c trunk/gcc/tree-vectorizer.h
[Bug middle-end/50633] [4.7 Regression] New test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2011-10-06 17:55:48
UTC ---
Here is a small testcase. shrink-wrap screwed up stack adjustment
for local variables:
[hjl@gnu-mic-2 pr50633]$ cat x.i
struct s { int val[16]; };
extern double f (struct s pb, double pc);
int main ()
{
struct s x;
int i;
for (i = 0; i 16; i++)
x.val[i] = i + 1;
if (f (x, 1.0L) != 10136.0L)
__builtin_abort ();
return 0;
}
[hjl@gnu-mic-2 pr50633]$ /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -mx32 -O -S x.i
-fno-shrink-wrap -o good.s
[hjl@gnu-mic-2 pr50633]$ /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -mx32 -O -S x.i -o bad.s
[hjl@gnu-mic-2 pr50633]$ cat good.s
.filex.i
.text
.globlmain
.typemain, @function
main:
.LFB0:
.cfi_startproc
subq$136, %rsp
.cfi_def_cfa_offset 144
movl$0, %eax
movl%esp, %ecx
addl$60, %ecx
.L2:
addl$1, %eax
leal(%rcx,%rax,4), %edx
movl%eax, (%edx)
cmpl$16, %eax
jne.L2
movq64(%rsp), %rax
movq%rax, (%rsp)
movq72(%rsp), %rax
movq%rax, 8(%rsp)
movq80(%rsp), %rax
movq%rax, 16(%rsp)
movq88(%rsp), %rax
movq%rax, 24(%rsp)
movq96(%rsp), %rax
movq%rax, 32(%rsp)
movq104(%rsp), %rax
movq%rax, 40(%rsp)
movq112(%rsp), %rax
movq%rax, 48(%rsp)
movq120(%rsp), %rax
movq%rax, 56(%rsp)
movsd.LC0(%rip), %xmm0
callf
ucomisd.LC1(%rip), %xmm0
jp.L5
je.L7
.L5:
callabort
.L7:
movl$0, %eax
addq$136, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.sizemain, .-main
.section.rodata.cst8,aM,@progbits,8
.align 8
.LC0:
.long0
.long1086556160
.align 8
.LC1:
.long0
.long1086573568
.identGCC: (GNU) 4.7.0 20111005 (experimental)
.section.note.GNU-stack,,@progbits
[hjl@gnu-mic-2 pr50633]$ cat bad.s
.filex.i
.text
.globlmain
.typemain, @function
main:
.LFB0:
.cfi_startproc
movl$0, %eax
movl%esp, %ecx
addl$60, %ecx
.L2:
addl$1, %eax
leal(%rcx,%rax,4), %edx
movl%eax, (%edx)
cmpl$16, %eax
jne.L2
subq$136, %rsp
.cfi_def_cfa_offset 144
movq64(%rsp), %rax
movq%rax, (%rsp)
movq72(%rsp), %rax
movq%rax, 8(%rsp)
movq80(%rsp), %rax
movq%rax, 16(%rsp)
movq88(%rsp), %rax
movq%rax, 24(%rsp)
movq96(%rsp), %rax
movq%rax, 32(%rsp)
movq104(%rsp), %rax
movq%rax, 40(%rsp)
movq112(%rsp), %rax
movq%rax, 48(%rsp)
movq120(%rsp), %rax
movq%rax, 56(%rsp)
movsd.LC0(%rip), %xmm0
callf
ucomisd.LC1(%rip), %xmm0
jp.L5
je.L7
.L5:
callabort
.L7:
movl$0, %eax
addq$136, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.sizemain, .-main
.section.rodata.cst8,aM,@progbits,8
.align 8
.LC0:
.long0
.long1086556160
.align 8
.LC1:
.long0
.long1086573568
.identGCC: (GNU) 4.7.0 20111005 (experimental)
.section.note.GNU-stack,,@progbits
[hjl@gnu-mic-2 pr50633]$ diff -up good.s bad.s
--- good.s2011-10-06 10:52:45.410961190 -0700
+++ bad.s2011-10-06 10:52:48.938896097 -0700
@@ -5,8 +5,6 @@
main:
.LFB0:
.cfi_startproc
-subq$136, %rsp
-.cfi_def_cfa_offset 144
movl$0, %eax
movl%esp, %ecx
addl$60, %ecx
@@ -16,6 +14,8 @@ main:
movl%eax, (%edx)
cmpl$16, %eax
jne.L2
+subq$136, %rsp
+.cfi_def_cfa_offset 144
movq64(%rsp), %rax
movq%rax, (%rsp)
movq72(%rsp), %rax
[hjl@gnu-mic-2 pr50633]$
[Bug target/50635] ICE on invalid code: segfault in vectorize_loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50635 --- Comment #1 from Greta Yorsh Greta.Yorsh at arm dot com 2011-10-06 18:08:25 UTC --- In fact, it's ICE on valid - see the testcase small_ice_init.c. The command line and backtrace are the same.
[Bug target/50635] ICE on valid: segfault in vectorize_loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50635 --- Comment #2 from Greta Yorsh Greta.Yorsh at arm dot com 2011-10-06 18:09:51 UTC --- Created attachment 25432 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25432 small testcase for ice on valid code
[Bug middle-end/50634] [4.7 Regression] FAIL: gfortran.fortran-torture/execute/entry_4.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50634 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mikael at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Mikael Morin mikael at gcc dot gnu.org 2011-10-06 18:13:08 UTC --- Dup. *** This bug has been marked as a duplicate of bug 50628 ***
[Bug middle-end/50628] [4.7 Regression] gfortran.fortran-torture/execute/entry_4.f fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50628 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #6 from Mikael Morin mikael at gcc dot gnu.org 2011-10-06 18:13:08 UTC --- *** Bug 50634 has been marked as a duplicate of this bug. ***
[Bug middle-end/50628] [4.7 Regression] gfortran.fortran-torture/execute/entry_4.f90 fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50628 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org Summary|[4.7 Regression]|[4.7 Regression] |gfortran.fortran-torture/ex |gfortran.fortran-torture/ex |ecute/entry_4.f fails |ecute/entry_4.f90 fails --- Comment #7 from Mikael Morin mikael at gcc dot gnu.org 2011-10-06 18:16:53 UTC --- (In reply to comment #4) This is due to/exposed by revision 179566. According to H.J. in bug 50634: On Linux/x86-64, revision 179556: There is certainly a typo in one of the reported revisions.
[Bug other/50636] New: GC in large LTO builds cause excessive fragmentation in memory map
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636 Bug #: 50636 Summary: GC in large LTO builds cause excessive fragmentation in memory map Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org When doing a very large LTO build I fail with out of virtual memory Some investigation showed the problem was not actually running out of memory, but gcc excessively fragmenting its memory map. The Linux kernel has a default limit of 64k mappings per process and the fragmentation exceeded that. This lead to gc mmap allocations failing and other problems. A workaround is to increase /proc/sys/vm/max_map_count Looking at /proc/$(pidof lto1)/maps I see there are lots of 1-3 page holes between other anonymousmemory. I think that's caused by ggc-pages free_pages() function freeing too early and in too small chunks (and perhaps LTO garbage collecting too much?)
[Bug middle-end/50628] [4.7 Regression] gfortran.fortran-torture/execute/entry_4.f90 fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50628 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-10-06 18:28:00 UTC --- There is certainly a typo in one of the reported revisions. Yes, it is 179556.
[Bug testsuite/50637] New: gcc.dg/vect/vect-align-2.c is invalid (FAILs with -O2 -flto -fpeel-loops)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50637
Bug #: 50637
Summary: gcc.dg/vect/vect-align-2.c is invalid (FAILs with -O2
-flto -fpeel-loops)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: do...@gcc.gnu.org
The testcase accesses an array out of bounds, causing a testsuite failure with
nondefault flags:
$ gcc gcc.dg/vect/vect-align-2.c -O2 -flto -fpeel-loops
$ ./a.out
Aborted
The problem is:
...
#define N 17
...
int z[16] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
...
for (i=0; iN; i++)
for (j=0; jN; j++)
f2.y[i][j] = z[i];
for (i=0; iN; i++)
for (j=0; jN; j++)
if (f2.y[i][j] != z[i])
abort ();
...
z[16] is read out of bounds.
vect-align-1.c uses:
int x[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
what might be a better solution
[Bug middle-end/50633] [4.7 Regression] New test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633
--- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-10-06 18:38:21
UTC ---
static int
frame_required_for_rtx (rtx *loc, void *data ATTRIBUTE_UNUSED)
{
rtx x = *loc;
if (x == stack_pointer_rtx || x == hard_frame_pointer_rtx
|| x == arg_pointer_rtx || x == pic_offset_table_rtx)
return 1;
return 0;
}
failed to handle
(gdb) call debug_rtx (insn)
(insn 99 34 36 2 (set (reg:SI 2 cx [106])
(reg:SI 7 sp)) x.i:11 64 {*movsi_internal}
(nil))
(gdb)
X32 has (reg/f:DI 7 sp) as hardware stack pointer. It also
should check regno.
[Bug middle-end/50633] [4.7 Regression] New test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633 --- Comment #6 from Bernd Schmidt bernds at gcc dot gnu.org 2011-10-06 18:43:21 UTC --- How do you build this? What's the target triplet?
[Bug middle-end/50633] [4.7 Regression] New test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2011-10-06 18:50:14 UTC --- This patch seems to work: diff --git a/gcc/function.c b/gcc/function.c index 863f09d..0bc1dd9 100644 --- a/gcc/function.c +++ b/gcc/function.c @@ -5312,6 +5312,21 @@ frame_required_for_rtx (rtx *loc, void *data ATTRIBUTE_UNUSED) if (x == stack_pointer_rtx || x == hard_frame_pointer_rtx || x == arg_pointer_rtx || x == pic_offset_table_rtx) return 1; + if (x != NULL + REG_P (x) + ((stack_pointer_rtx != NULL + REG_P (stack_pointer_rtx) + REGNO (x) == REGNO (stack_pointer_rtx)) + || (hard_frame_pointer_rtx != NULL + REG_P (hard_frame_pointer_rtx) + REGNO (x) == REGNO (hard_frame_pointer_rtx)) + || (arg_pointer_rtx != NULL + REG_P (arg_pointer_rtx) + REGNO (x) == REGNO (arg_pointer_rtx)) + || (pic_offset_table_rtx != NULL + REG_P (pic_offset_table_rtx) + REGNO (x) == REGNO (pic_offset_table_rtx +return 1; return 0; }
[Bug middle-end/50633] [4.7 Regression] New test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2011-10-06 18:51:45 UTC --- (In reply to comment #6) How do you build this? What's the target triplet? If you build GCC for Linux/x86-64, you will get x32 code generation and you can see the problem from assembly output.
[Bug target/50603] [x32] Unnecessary lea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50603
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-10-06 19:00:54
UTC ---
[hjl@gnu-mic-2 pr50633]$ cat x.i
struct s { int val[16]; };
extern double f (struct s pb, double pc);
int main ()
{
struct s x;
int i;
for (i = 0; i 16; i++)
x.val[i] = i + 1;
if (f (x, 1.0L) != 10136.0L)
__builtin_abort ();
return 0;
}
[hjl@gnu-mic-2 pr50633]$ make x.s
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -mx32 -O -S x.i
[hjl@gnu-mic-2 pr50633]$ cat x.s
.filex.i
.text
.globlmain
.typemain, @function
main:
.LFB0:
.cfi_startproc
subq$136, %rsp
.cfi_def_cfa_offset 144
movl$0, %eax
movl%esp, %ecx
addl$60, %ecx
.L2:
addl$1, %eax
leal(%rcx,%rax,4), %edx
movl%eax, (%edx)
cmpl$16, %eax
jne.L2
movq64(%rsp), %rax
movq%rax, (%rsp)
movq72(%rsp), %rax
movq%rax, 8(%rsp)
movq80(%rsp), %rax
movq%rax, 16(%rsp)
movq88(%rsp), %rax
movq%rax, 24(%rsp)
movq96(%rsp), %rax
movq%rax, 32(%rsp)
movq104(%rsp), %rax
movq%rax, 40(%rsp)
movq112(%rsp), %rax
movq%rax, 48(%rsp)
movq120(%rsp), %rax
movq%rax, 56(%rsp)
movsd.LC0(%rip), %xmm0
callf
ucomisd.LC1(%rip), %xmm0
jp.L5
je.L7
.L5:
callabort
.L7:
movl$0, %eax
addq$136, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.sizemain, .-main
leal(%rcx,%rax,4), %edx
movl%eax, (%edx)
can be combined into
movl%eax, (%ecx,%eax,4)
[Bug middle-end/50632] [4.7 Regression] FAIL: gcc.dg/pr50132.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50632
Richard Henderson rth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011-10-06
AssignedTo|unassigned at gcc dot |rth at gcc dot gnu.org
|gnu.org |
Target Milestone|--- |4.7.0
Ever Confirmed|0 |1
--- Comment #2 from Richard Henderson rth at gcc dot gnu.org 2011-10-06
19:04:34 UTC ---
The problem is that the CSA pass is dropping a note when combining
(insn 13 12 16 3 (parallel [
(set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) z.c:9 254 {*adddi_1}
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil)))
(insn/f 31 30 35 4 (parallel [
(set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])))
(clobber (reg:CC 17 flags))
(clobber (mem:BLK (scratch) [0 A8]))
]) z.c:10 -1
(expr_list:REG_CFA_ADJUST_CFA (set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])))
(nil)))
to
(insn/f 31 30 35 3 (parallel [
(set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int 24 [0x18])))
(clobber (reg:CC 17 flags))
(clobber (mem:BLK (scratch) [0 A8]))
]) z.c:10 921 {pro_epilogue_adjust_stack_di_add}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_CFA_ADJUST_CFA (set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])))
(nil
We've lost the REG_ARGS_SIZE note, which also affects the CFA
given that we're not using a frame pointer.
[Bug tree-optimization/50635] ICE on valid: segfault in vectorize_loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50635 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-10-06 CC||irar at il dot ibm.com Component|target |tree-optimization AssignedTo|unassigned at gcc dot |irar at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Ira Rosen irar at il dot ibm.com 2011-10-06 19:14:58 UTC --- I'll test this fix next week. Index: tree-vect-patterns.c === --- tree-vect-patterns.c(revision 179447) +++ tree-vect-patterns.c(working copy) @@ -385,6 +385,7 @@ vect_handle_widen_mult_by_const (gimple stmt, tree || TREE_TYPE (gimple_assign_lhs (new_stmt)) != new_type) return false; + VEC_safe_push (gimple, heap, *stmts, def_stmt); *oprnd = gimple_assign_lhs (new_stmt); } else
[Bug middle-end/50632] [4.7 Regression] FAIL: gcc.dg/pr50132.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50632 --- Comment #3 from Richard Henderson rth at gcc dot gnu.org 2011-10-06 19:15:48 UTC --- Created attachment 25433 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25433 proposed patch Testing this patch now.
[Bug target/50603] [x32] Unnecessary lea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50603
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2011-10-06 19:19:23
UTC ---
Combine failed:
(set (mem:SI (and:DI (plus:DI (subreg:DI (mult:SI (reg/v:SI 84 [ i ])
(const_int 4 [0x4])) 0)
(subreg:DI (reg:SI 106) 0))
(const_int 4294967292 [0xfffc])) [3 MEM[symbol: x, index:
D.2741_12, step: 4, offset: 4294967292B]+0 S4 A32])
(reg/v:SI 84 [ i ]))
for
(insn 37 35 39 3 (set (reg:SI 90)
(plus:SI (mult:SI (reg/v:SI 84 [ i ])
(const_int 4 [0x4]))
(reg:SI 106))) x.i:11 247 {*leasi_2}
(nil))
(insn 39 37 41 3 (set (mem:SI (zero_extend:DI (reg:SI 90)) [3 MEM[symbol: x,
index: D.2741_12, step: 4, offset: 4294967292B]+0 S4 A32])
(reg/v:SI 84 [ i ])) x.i:11 64 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 90)
(nil)))
Since address is 32bit aligned, 0xfffc is the same as
0x. But we don't have this information.
Re: [Bug other/50636] New: GC in large LTO builds cause excessive fragmentation in memory map
When doing a very large LTO build I fail with out of virtual memory Some investigation showed the problem was not actually running out of memory, but gcc excessively fragmenting its memory map. The Linux kernel has a default limit of 64k mappings per process and the fragmentation exceeded that. This lead to gc mmap allocations failing and other problems. A workaround is to increase /proc/sys/vm/max_map_count Looking at /proc/$(pidof lto1)/maps I see there are lots of 1-3 page holes between other anonymousmemory. I think that's caused by ggc-pages free_pages() function freeing too early and in too small chunks (and perhaps LTO garbage collecting too much?) In gcc-2.95 times ggc-page was probably not written with 8GB of memory use in mind :) Perhaps ggc-page should simply increase the chunks as memory grows? (i.e. release to system only when 20% of memory is unused it exceeds some minimal value) Honza
[Bug other/50636] GC in large LTO builds cause excessive fragmentation in memory map
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636 --- Comment #1 from Jan Hubicka hubicka at ucw dot cz 2011-10-06 19:20:45 UTC --- When doing a very large LTO build I fail with out of virtual memory Some investigation showed the problem was not actually running out of memory, but gcc excessively fragmenting its memory map. The Linux kernel has a default limit of 64k mappings per process and the fragmentation exceeded that. This lead to gc mmap allocations failing and other problems. A workaround is to increase /proc/sys/vm/max_map_count Looking at /proc/$(pidof lto1)/maps I see there are lots of 1-3 page holes between other anonymousmemory. I think that's caused by ggc-pages free_pages() function freeing too early and in too small chunks (and perhaps LTO garbage collecting too much?) In gcc-2.95 times ggc-page was probably not written with 8GB of memory use in mind :) Perhaps ggc-page should simply increase the chunks as memory grows? (i.e. release to system only when 20% of memory is unused it exceeds some minimal value) Honza
[Bug target/50603] [x32] Unnecessary lea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50603
--- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-10-06 19:37:56
UTC ---
Taking from combine.c:
else if (GET_CODE (t) == ZERO_EXTEND
(GET_CODE (XEXP (t, 0)) == PLUS
|| GET_CODE (XEXP (t, 0)) == IOR
|| GET_CODE (XEXP (t, 0)) == XOR)
GET_CODE (XEXP (XEXP (t, 0), 1)) == SUBREG
HWI_COMPUTABLE_MODE_P (mode)
subreg_lowpart_p (XEXP (XEXP (t, 0), 1))
rtx_equal_p (SUBREG_REG (XEXP (XEXP (t, 0), 1)), f)
((nonzero_bits (f, GET_MODE (f))
~GET_MODE_MASK (GET_MODE (XEXP (XEXP (t, 0), 1
== 0))
{
c1 = XEXP (XEXP (t, 0), 0); z = f; op = GET_CODE (XEXP (t, 0));
extend_op = ZERO_EXTEND;
m = GET_MODE (XEXP (t, 0));
}
I think this patch:
diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index 89cc8a7..4386b82 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -600,8 +600,8 @@
;; Match exactly 0x0 in anddi as a zero-extension operation
(define_predicate const_32bit_mask
(and (match_code const_int)
- (match_test trunc_int_for_mode (INTVAL (op), DImode)
-== (HOST_WIDE_INT) 0x)))
+ (match_test (nonzero_bits (op, GET_MODE (op))
+ ~GET_MODE_MASK (DImode)) == 0)))
;; Match 2, 4, or 8. Used for leal multiplicands.
(define_predicate const248_operand
should work.
[Bug target/50603] [x32] Unnecessary lea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50603 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2011-10-06 19:44:06 UTC --- It doesn't work since we fail to decompose subreg.
[Bug tree-optimization/49279] [4.5/4.6/4.7 Regression] Optimization incorrectly presuming constant variable inside loop in g++ 4.5 and 4.6 with -O2 and -O3 for x86_64 targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-06 19:56:40 UTC --- Author: jakub Date: Thu Oct 6 19:56:32 2011 New Revision: 179633 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179633 Log: PR tree-optimization/49279 * tree-ssa-structalias.c (find_func_aliases): Don't handle CAST_RESTRICT. * gcc.c-torture/execute/pr49279.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/pr49279.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-ssa-structalias.c
