[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 __vic changed: What|Removed |Added CC||d.v.a at ngs dot ru --- Comment #80 from __vic 2011-07-21 07:01:12 UTC --- Gentlemans! It has been 10 years but there is no progress. Why the standard-compliant value is still not defined in platforms other that @#$%#^% Solaris? How do we write universal code for C++98 and C++11 without the proper defined macro?
[Bug target/49799] New: gcc arm generates illegal sbfx instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49799
Summary: gcc arm generates illegal sbfx instruction
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
Host: linux
Target: armeabi
Compile the following code with options -march=armv7-a -O2
extern __inline int bar(int a)
{
int tmp;
if (a <= 0) a ^= 0x;
return tmp - 1;
}
void foo(short *K)
{
short tmp;
short *pptr, P[14];
pptr = P;
tmp = bar(*K);
*pptr = (*K << tmp) >> 16;
if (*P < tmp)
*K++ = 0;
}
gcc 4.7 generates
foo:
ldrshr3, [r0, #0]
sbfxr3, r3, #17, #16// A
sxthr3, r3
cmnr3, #1
movltr3, #0
strlthr3, [r0, #0]@ movhi
bxlr
The sbfx instruction is illegal since the bit position + width > 32.
Although the source code is ill formed (function bar returns undefined value),
compiler should never generate illegal instructions.
gcc4.6 has the same problem.
[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997 --- Comment #20 from Iain Sandoe 2011-07-21 07:54:51 UTC --- hm .. I think this might be a new (objc). bug, rather than a back-end problem; since it doesn't show with normal c-strings (even when compiled -x objective-c). Will try to take a look.
[Bug rtl-optimization/49800] New: segfault with -fsched-pressure -fdump-rtl-sched1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49800
Summary: segfault with -fsched-pressure -fdump-rtl-sched1
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kreb...@gcc.gnu.org
t.c:
void foo (int a)
{
}
/home/andreas/clean/gcc-head-build/gcc/cc1 -O2 -fdump-rtl-sched1
-fsched-pressure -quiet t.c
Program received signal SIGSEGV, Segmentation fault.
print_pseudo_costs (f=0x80cc9340) at
/home/andreas/clean/gcc-head/gcc/ira-costs.c:1404
1404 if (REG_N_REFS (regno) <= 0)
#0 print_pseudo_costs (f=0x80cc9340) at
/home/andreas/clean/gcc-head/gcc/ira-costs.c:1404
#1 find_costs_and_classes (dump_file=0x80cc9340) at
/home/andreas/clean/gcc-head/gcc/ira-costs.c:1770
#2 0x803edf9e in ira_set_pseudo_classes (dump_file=0x80cc9340)
at /home/andreas/clean/gcc-head/gcc/ira-costs.c:2031
#3 0x8085cda8 in sched_init () at
/home/andreas/clean/gcc-head/gcc/haifa-sched.c:4250
#4 0x808654f4 in haifa_sched_init () at
/home/andreas/clean/gcc-head/gcc/haifa-sched.c:4273
#5 0x804dcbca in schedule_insns () at
/home/andreas/clean/gcc-head/gcc/sched-rgn.c:3299
#6 schedule_insns () at /home/andreas/clean/gcc-head/gcc/sched-rgn.c:3287
#7 0x804dd4ce in rest_of_handle_sched () at
/home/andreas/clean/gcc-head/gcc/sched-rgn.c:3501
(gdb) p regstat_n_sets_and_refs
$1 = (regstat_n_sets_and_refs_t *) 0x0
regstat_n_sets_and_refs is not initialized when sched-pressure perhaps invoking
regstat_init_n_sets_and_refs in sched_init is needed?
This worked with 4.6. The check in print_pseudo_costs was:
for (regno = max_reg_num () - 1; regno >= FIRST_PSEUDO_REGISTER; regno--)
{
if (regno_reg_rtx[regno] == NULL_RTX)
continue;
and has been changed to:
for (regno = max_reg_num () - 1; regno >= FIRST_PSEUDO_REGISTER; regno--)
{
if (REG_N_REFS (regno) <= 0)
continue;
[Bug target/49049] ICE in copyprop_hardreg_forward_1, at regcprop.c:767
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49049
Matthias Klose changed:
What|Removed |Added
CC||doko at ubuntu dot com
--- Comment #4 from Matthias Klose 2011-07-21 08:28:41
UTC ---
[ http://bugs.debian.org/630746 ]
looks like a regression in current 4.6 branch and the trunk, works with current
4.4 and 4.5 branches. The volume.i builds with -O2 instead of -O1 (the Debian
compiler targets armv4 by default).
$ gcc -g -O -c volume.i../vol/volume.c: In function 'VShutdown_r':
../vol/volume.c:1320:1: error: insn does not satisfy its constraints:
(insn 1117 1116 669 56 (set (reg:SI 8 r8 [561])
(minus:SI (const_int 12 [0xc])
(const_int 5784 [0x1698]))) ../vol/volume.c:1409 29
{*arm_subsi3_insn}
(nil))
../vol/volume.c:1320:1: internal compiler error: in copyprop_hardreg_forward_1,
at regcprop.c:767
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug target/49049] ICE in copyprop_hardreg_forward_1, at regcprop.c:767
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49049 --- Comment #5 from Matthias Klose 2011-07-21 08:31:56 UTC --- Created attachment 24801 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24801 preprocessed volume.i source
[Bug c/49801] New: 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
Summary: df_live_verify_transfer_functions fails with to use of
CC_REGNUM and checking enabled in rx backend
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paulo.ma...@csr.com
Created attachment 24802
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24802
files resulting from -da -fdump-tree-all-all
Compiled the rx backend enough to get a cc1:
$ ../gcc-4.6.1/configure --enable-languages=c --target=rx-linux-elf
--disable-libssp --disable-shared --disable-libquadmath --enable-checking=all
--prefix=$HOME/local/rx-gcc-461 && make -j5
...
$ cat shift.c
unsigned long foo(unsigned int a, unsigned int b)
{
if(a < b)
return a << b;
else
return a >> b;
}
$ ~/tmp/rx-gcc461-build/gcc/cc1 -Os -da -fdump-tree-all-all shift.c
{GC 953k -> 896k} foo {GC 900k -> 899k}
Analyzing compilation unit
{GC 1092k -> 959k} {GC 959k -> 959k}Performing interprocedural optimizations
<*free_lang_data> {GC 959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k} {GC
959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k} {GC 959k ->
959k} {GC 959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k}
{GC 959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k}
{GC 959k -> 959k} {GC 959k -> 959k} {GC 959k -> 959k} {GC 963k -> 963k} {GC
963k -> 963k} {GC 963k -> 963k} {GC 964k -> 963k} {GC 963k -> 963k} {GC 965k ->
963k} {GC 964k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k
-> 963k} {GC 964k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k}
{GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC
963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k ->
963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k ->
963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k}
{GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k ->
963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC
963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k ->
963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC 963k -> 963k} {GC
963k -> 963k} {GC 963k -> 963k}Assembling functions:
foo {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k}
{GC 965k -> 965k} {GC 966k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC
968k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k ->
965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k}
{GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC
967k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 965k -> 965k} {GC 966k ->
966k} {GC 966k -> 966k} {GC 966k -> 966k} {GC 966k -> 966k} {GC 966k -> 965k}
{GC 972k -> 969k} {GC 969k -> 969k} {GC 970k -> 969k} {GC 969k -> 969k} {GC
969k -> 969k} {GC 969k -> 969k} {GC 974k -> 973k} {GC 973k -> 973k} {GC 973k ->
973k} {GC 973k -> 971k} {GC 971k -> 971k} {GC 972k -> 972k} {GC 972k -> 972k}
{GC 973k -> 972k} {GC 972k -> 972k} {GC 972k -> 972k} {GC 972k -> 972k} {GC
972k -> 972k} {GC 972k -> 972k} {GC 972k -> 972k} {GC 973k -> 972k} {GC 972k ->
972k} {GC 972k -> 972k} {GC 972k -> 972k} {GC 974k -> 972k} {GC 972k -> 972k}
shift.c: In function ‘foo’:
shift.c:7:1: internal compiler error: in df_live_verify_transfer_functions, at
df-problems.c:1816
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug target/38479] Incorrect dwarf generated for function with parameters greater 4 words in length
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38479 --- Comment #6 from Ionut Anghelcovici 2011-07-21 08:55:46 UTC --- The problem only occurs when the argument to a function is a 64 bit type and gcc tries to store it in r3/stack. This creates a different function prolog than the usual. The reason for this is basically that half of the value is passed in r3 (the last available register for arguments), and half of it is passed on the stack. So in this special case, the function prolog starts with: sub sp, sp, #4 The reason is that gcc wants to allocate space to store the second half of the 64 bit value on the stack as well. So it reserves these additional 4 bytes first and later writes the other part of the value passed in r3 to this location. However, the debug info generation doesn't take this special case properly into account so the debugger displays wrong info (also verified this with Trace32).
[Bug c/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 #1 from Paulo J. Matos 2011-07-21 09:03:06 UTC --- I pinpointed this issue to the bitmaps computed in df_live_verify_transfer_functions (df-problems.c). bitmap saved_gen has no bit set while bb_info->gen has bit 16 set (corresponding to the CC reg). Something seems to be confusing function computing these values but I haven't been able yet to pinpoint the problem.
[Bug fortran/49802] New: [F2008] Handle VALUE with arrays (DIMENSION)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49802 Summary: [F2008] Handle VALUE with arrays (DIMENSION) Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Depends on: 35203 Blocks: 39627 Fortran 2008 relaxed the constrains with regards to VALUE. While Fortran 2003 only allowed it for objects which can be transferred by pass-by-value (in sprite of BIND(C) dummys/C nonpointer parameters), Fortran 2003 now allows for everything which may be copied in, which is nearly everything. Fortran 2008 has: C557 An entity with the VALUE attribute shall be a dummy data object that is not an assumed-size array or a coarray, and does not have a coarray ultimate component. C558 An entity with the VALUE attribute shall not have the ALLOCATABLE, INTENT (INOUT), INTENT(OUT), POINTER, or VOLATILE attributes. Fortran 2003 has: C527 (R501) If the VALUE attribute is specified, the PARAMETER, EXTERNAL, POINTER, ALLOCATABLE, DIMENSION, VOLATILE, INTENT(INOUT), or INTENT(OUT) attribute shall not be specified. Thus: DIMENSION has been removed and just attr.codimension/attr.coarray_comp are prohibited - as a dummy with assumed size as there copy-in/copy-out will fail.
[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997
--- Comment #21 from Iain Sandoe 2011-07-21 09:05:10
UTC ---
This is indeed a new bug - if there is to be any lengthly deliberation, please
move it to its own PR (against objective-c).
calling fix_string_type () on a tree that is already a STRING_CST appears to
break things..
(the size and unit_size fields get screwed up).
... this might be intended [i.e. we should not call the function when we
already have a STRING_CST]
(or indicate a bug elsewhere).
I am assuming the former for now ergo, try this:
Index: gcc/objc/objc-act.c
===
--- gcc/objc/objc-act.c (revision 176554)
+++ gcc/objc/objc-act.c (working copy)
@@ -3132,10 +3132,13 @@ objc_build_string_object (tree string)
struct string_descriptor *desc, key;
void **loc;
- /* Prep the string argument. */
- string = fix_string_type (string);
- TREE_SET_CODE (string, STRING_CST);
- length = TREE_STRING_LENGTH (string) - 1;
+ if (TREE_CODE (string) != STRING_CST)
+{
+ /* Prep the string argument. */
+ string = fix_string_type (string);
+ TREE_SET_CODE (string, STRING_CST);
+ length = TREE_STRING_LENGTH (string) - 1;
+}
/* The target may have different ideas on how to construct an ObjC string
literal. On Darwin (Mac OS X), for example, we may wish to obtain a
[Bug c++/49803] New: [C++0x] erroneous variant-member initialization in a union containing an anonymous struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49803
Summary: [C++0x] erroneous variant-member initialization in a
union containing an anonymous struct
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fuchsia.gr...@virgin.net
/* The output of this code should be 'Y'. But define SHOW_BUG and it becomes
X: */
#define SHOW_BUG
#include
struct X
{
X() : m_value {'X'} {}
char m_value;
};
union Y
{
// N3291=11-0061 12.6.2/8 says no initialization of
// of other variant members (i.e. m_x) should
// be performed.
Y( char c )
: m_char1{ c }
{ }
#ifdef SHOW_BUG
struct
{
#endif
char m_char1;
#ifdef SHOW_BUG
};
#endif
Xm_x;
};
int main()
{
Y y ( 'Y' );
printf( "%c\n", y.m_char1 ); // expected 'Y', get 'X'...
return 0;
}
[Bug fortran/49802] [F2008] Handle VALUE with arrays (DIMENSION)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49802 --- Comment #1 from Tobias Burnus 2011-07-21 09:20:22 UTC --- Additionally, the follow constraint of Fortran 2003 is gone: C528 (R501) If the VALUE attribute is specified, the length type parameter values shall be omitted or specified by initialization expressions.
[Bug middle-end/48973] [4.4/4.5 Regression] Inliner bug with one-bit (1-bit) bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48973 --- Comment #17 from Jakub Jelinek 2011-07-21 09:39:19 UTC --- Author: jakub Date: Thu Jul 21 09:39:16 2011 New Revision: 176555 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176555 Log: PR middle-end/48973 * expr.c (expand_expr_real_1) : If the comparison has a single bit signed type, use constm1_rtx instead of const1_rtx for true value. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/expr.c
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #81 from Paolo Carlini 2011-07-21 09:52:11 UTC --- Marc and Rainer, if you have proposals for Solaris, I think this is the right time for 4.7...
[Bug fortran/49802] [F2008] Handle VALUE with arrays (DIMENSION)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49802 --- Comment #2 from Tobias Burnus 2011-07-21 09:55:16 UTC --- Created attachment 24803 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24803 Patch for the resolver/parse part - not for the actual implementation Implementation strategy: * For scalar types, continue to pass by value (for optimization purpose) * For strings, arrays, and complicated DT: Copy the data and pass by reference. * For VALUE + OPTIONAL - also for scalars: copy and pass by reference Note: For generating a copy one needs - as already currently - do a deep copy to capture also the allocatable components. Example for alloc components with VALUE. The example fails (wrong result) with NAG, ifort, gfortran and g95; pgi gets an ICE and crayftn states "The array syntax statement is not conformable", which also looks bogus. I believe that the test case is valid Fortran 2003. implicit none type t integer, allocatable :: A(:) end type t integer :: i type(t) :: x allocate(x%A(8)) x%A = [(i, i = 1, 8)] call by_value(x) print *, x%A if (any (x%A /= [(i, i = 1, 8)])) call abort() contains subroutine by_value(y) type(t), value :: y y%A = [(-10*i, i=1,9)] print *, y%A end subroutine end
[Bug fortran/49802] [F2003, F2008] Wrong code with VALUE, F2008: VALUE with arrays/DIMENSION
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49802 Tobias Burnus changed: What|Removed |Added Blocks||20585 Summary|[F2008] Handle VALUE with |[F2003, F2008] Wrong code |arrays (DIMENSION) |with VALUE, F2008: VALUE ||with arrays/DIMENSION --- Comment #3 from Tobias Burnus 2011-07-21 10:13:33 UTC --- As postscript: Using strings works - but only as long as the length is known at compile time (as F2003 mandates). If not, the dump looks OK at a glance but it does not work: CALLER: by_value (str, 10); CALLEE: by_value (character(kind=1)[1:_y] y, integer(kind=4) _y) D.1554 = _y; _gfortran_transfer_integer_write (&dt_parm.0, &D.1554, 4); but the latter does not print the expected "10" but some seemingly random number. Obviously, passing strings by value fails if the length is not known - one should thus go back to pass them by reference after copying. Test case: Change "(*)" to "(10)" for a working program: implicit none character(len=10) :: str str = "123456789" call by_value(str) print *, str if (str /= "123456789") call abort() contains subroutine by_value(y) character(len=*), value :: y print *, len(y) if (len(y) /= 10) call abort() print *, y y = "abcdefghij" print *, y if (str /= "abcdefghij") call abort() end subroutine end
[Bug fortran/49802] [F2003, F2008] Wrong code with VALUE, F2008: VALUE with arrays/DIMENSION
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49802 --- Comment #4 from Tobias Burnus 2011-07-21 10:21:22 UTC --- (In reply to comment #3) >by_value (character(kind=1)[1:_y] y, integer(kind=4) _y) Technically, it makes sense that it does not work: The caller passes + bytes: sizeof(str) and sizeof(strlen); in this example: 10 bytes for str and 4 bytes for the length (value: 10). How should the poor callee know which bytes belong to the string length? That's different to printf(char *format, ...): There one first knows what to expect before the unknown data comes.
[Bug target/49798] .quad instead of .long is used for address for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798 --- Comment #3 from Uros Bizjak 2011-07-21 10:25:28 UTC --- (In reply to comment #1) > To get Pmode value out of symbol in ptr_mode, we have to do zero-extension > ourself. Linker should put correct address (so, zero extended 32bit address) here.
[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997
--- Comment #22 from Iain Sandoe 2011-07-21 10:36:02
UTC ---
hmm, comment #21 is not the right solution ... (even if it works)
... the right solution is either
(a) to handle arrays of arbitrary-sized ints in fix_string_type () (without
assuming that they are whar when not explicitly set to
char{,16,32}_array_type_node)
or
(b) to force the type of CPP_OBJC_STRING to be char{,16,32}_array_type_node
as appropriate.
a. might look something like:
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 176554)
+++ gcc/c-family/c-common.c (working copy)
@@ -911,6 +911,32 @@ fix_string_type (tree value)
nchars = length / (TYPE_PRECISION (char32_type_node) / BITS_PER_UNIT);
e_type = char32_type_node;
}
+ else if (TREE_TYPE (value) && TREE_CODE (TREE_TYPE (value)) == ARRAY_TYPE)
+{
+ int prec;
+
+ if (TREE_TYPE (TREE_TYPE ((value
+prec = TYPE_PRECISION (TREE_TYPE (TREE_TYPE ((value;
+ else
+prec = TYPE_PRECISION (wchar_type_node);
+
+ nchars = length / (prec / BITS_PER_UNIT);
+ switch (prec)
+{
+ case BITS_PER_UNIT:
+ e_type = char_type_node;
+ break;
+ case 16:
+ e_type = char16_type_node;
+ break;
+ case 32:
+ e_type = char32_type_node;
+ break;
+ default:
+ e_type = wchar_type_node;
+ break;
+ }
+}
else
{
nchars = length / (TYPE_PRECISION (wchar_type_node) / BITS_PER_UNIT);
b. needs some more investigation.
thoughts?
[Bug target/49799] gcc arm generates illegal sbfx instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49799 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson 2011-07-21 11:10:45 UTC --- gcc-4.5.3 and gcc-4.4.6 also generate the invalid sbfx, gcc-4.3.6 appears to work and generates foo: ldrsh r3, [r0, #0] mvn r2, #0 mov r3, r3, asl r2 cmp r2, r3, asr #16 movgt r3, #0 @ movhi strgth r3, [r0, #0]@ movhi bx lr
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #82 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-07-21 11:32:42 UTC --- > --- Comment #81 from Paolo Carlini > 2011-07-21 09:52:11 UTC --- > Marc and Rainer, if you have proposals for Solaris, I think this is the right > time for 4.7... I thought the conclusion were that this would be fixable inside libstdc++ without (much) touching the Solaris headers. Given that I'm not a C++ person at all, I'm relying on the libstdc++ maintainers to handle that. I can help of course if there's still some need for fixincludes. As a prerequisite, PR c++/30112 needs to be fixed which also recently bit me when trying gold on Solaris 11. Rainer
[Bug tree-optimization/49749] Reassociation rank algorithm does not include all non-NULL operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49749
--- Comment #12 from Richard Guenther 2011-07-21
12:04:01 UTC ---
+ tree arg = gimple_phi_arg (stmt, i)->def;
+ if (TREE_CODE (arg) == SSA_NAME)
+{
+ gimple def_stmt = SSA_NAME_DEF_STMT (arg);
+ if (def_stmt
+ && gimple_bb (def_stmt)
arg = gimple_phi_arg_def (stmt, i);
if (TREE_CODE (arg) == SSA_NAME
&& !SSA_NAME_IS_DEFAULT_DEF (arg))
{
gimple def_stmt = SSA_NAME_DEF_STMT (arg);
...
without the def_stmt != NULL and gimple_bb != NULL check.
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #83 from Paolo Carlini 2011-07-21 12:08:32 UTC --- Ok, thus I marked 30112 as blocking this, I'll try to raise its priority. Otherwise Rainer, ok, in terms of producing an actual patch I was addressing mostly Marc, but, unless I'm badly misremembering, something *should* be special about Solaris, eg I'm pretty sure I can fix the macro for systems using glibc without major problems. Thus it would be great if you could coordinate with Marc in terms of extensive testing on Solaris...
[Bug c++/30112] pragma redefine_extname fails when namespaces are involved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30112 Paolo Carlini changed: What|Removed |Added CC||jason at redhat dot com --- Comment #4 from Paolo Carlini 2011-07-21 12:11:37 UTC --- Jason, I gather this is blocking libstdc++/1773, which we would really like to finally fix, can you have a look? Thanks in advance.
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #84 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-07-21 12:14:17 UTC --- > --- Comment #83 from Paolo Carlini > 2011-07-21 12:08:32 UTC --- > Ok, thus I marked 30112 as blocking this, I'll try to raise its priority. Fine, thanks. > Otherwise Rainer, ok, in terms of producing an actual patch I was addressing > mostly Marc, but, unless I'm badly misremembering, something *should* be > special about Solaris, eg I'm pretty sure I can fix the macro for systems > using > glibc without major problems. Thus it would be great if you could coordinate IIUC the major problem is that the Solaris headers (at least since Solaris 10) are (fully?) C++ aware, while glibc is not, so we were running into conflicts. I brought the issue and my findings with fixing Solaris headers to avoid the conflicts up with the Solaris C++ and libc engineers, and there was major opposition to `fixing' them for the benefit of libstdc++ if the problem is mostly on the libstdc++ side. > with Marc in terms of extensive testing on Solaris... Sure, no problem: I've got an extensive test farm over here, from Solaris 8 to 11, both x86 and SPARC. As soon as something is ready for testing, I'm prepared :-) Rainer
[Bug lto/49796] [4.7 Regression] 483.xalancbmk/447.dealII in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49796 Martin Jambor changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from Martin Jambor 2011-07-21 12:22:33 UTC --- verify_edge_corresponds_to_fndecl fails. The reason is that e->callee->former_clone_of is NULL. Since e->callee is _ZN10xalanc_1_814XalanDOMStringC2EPKtj.constprop.15198, that is clearly incorrect. Moreover, the node corresponding to decl, which is "__comp_ctor," does not have an alias flag set. I think that the name implies it should be set too. gimple_has_body returns false for it and, perhaps most importantly, it's analyzed flag and analyzed flag of e->callee->analyzed are cleared too. This is all in ltrans stage of LTO. I assume the flags are weird here because the cloned function, its original and its alias end up in a different partition. I have tried building with -flto-partition=none and it succeeded which supports this theory. Perhaps we just should not do this check for !analyzed nodes? Or should we try to stream this info into different partitions too? Honza?
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #85 from Paolo Carlini 2011-07-21 12:34:21 UTC --- Fair enough, and I should really find the time to go again through the entire trail. Just wanted to add that for a C header to be 'C++ ready' is a rather vaguely defined notion, thus, whereas I can definitely trust my new colleagues that something consistent and sane is in place in the Solaris headers, I still fear too much special casing in v3. Well, we could also imagine properly defining the macros *only* on linux and Solaris at some point, and gradually ask the port maintainers to work out the missing bits on their ports. At this point I'd really ask Marc if, maybe post 30112, he is willing to outline again a possible patch which you could test. As I said already, ideally, if the patch would be large, I would really recommend sending for review a mini version first, fixing only a couple of headers.
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #86 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-07-21 12:44:59 UTC --- > --- Comment #85 from Paolo Carlini > 2011-07-21 12:34:21 UTC --- > Fair enough, and I should really find the time to go again through the entire > trail. Just wanted to add that for a C header to be 'C++ ready' is a rather > vaguely defined notion, thus, whereas I can definitely trust my new colleagues > that something consistent and sane is in place in the Solaris headers, I still > fear too much special casing in v3. Well, we could also imagine properly > defining the macros *only* on linux and Solaris at some point, and gradually > ask the port maintainers to work out the missing bits on their ports. You should find a description of the problems I found in this thread: Allow __cplusplus=199711L to work with Solaris 2 headers http://gcc.gnu.org/ml/libstdc++/2011-03/msg00032.html Thanks. Rainer
[Bug target/49799] gcc arm generates illegal sbfx instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49799 Mikael Pettersson changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #2 from Mikael Pettersson 2011-07-21 12:53:19 UTC --- It's triggered by: Author: rearnsha Date: Tue Jan 13 14:09:50 2009 New Revision: 143338 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143338 Log: * arm.c (struct processors): Pass for speed down into cost helper functions. (const_ok_for_op): Handle COMPARE and inequality nodes. (arm_rtx_costs_1): Rewrite. (arm_size_rtx_costs): Update prototype. (arm_rtx_costs): Pass speed down to helper functions. (arm_slowmul_rtx_costs): Rework cost calculations. (arm_fastmul_rtx_costs, arm_xscale_rtx_costs): Likewise. (arm_9e_rtx_costs): Likewise. It looks like the cost tweaks exposed a pre-existing bug.
[Bug bootstrap/49786] [4.7 Regression] bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49786 --- Comment #13 from Martin Jambor 2011-07-21 13:00:31 UTC --- The problem in the summary is a call graph verification error, which is most likely a duplicate of PR 49796 (an infrastructure/verifier problem really) while the problem reported in comment #10 is "caller edge count is negative" which is most certainly a different error. I ran a profiled LTO bootstrap overnight but unfortunately could not reproduce neither. Nevertheless, I will try to follow Ian's suggestion. Ian, was there anything specific that you did in order to reproduce the issue? Thanks.
[Bug target/49798] .quad instead of .long is used for address for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798 H.J. Lu changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-07/msg01711.htm ||l --- Comment #4 from H.J. Lu 2011-07-21 13:09:21 UTC --- (In reply to comment #3) > (In reply to comment #1) > > > To get Pmode value out of symbol in ptr_mode, we have to do zero-extension > > ourself. > > Linker should put correct address (so, zero extended 32bit address) here. Did you mean assembler? In many cases, .quad is still simply wrong (PR 47446). GCC shouldn't generate .quad in this case. A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01711.html
[Bug bootstrap/49786] [4.7 Regression] bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49786 --- Comment #14 from Markus Trippelsdorf 2011-07-21 13:10:36 UTC --- H.J. also reported: lto1: error: caller edge count is negative in the description. So it's likely the same issue as in comment #10. BTW the following already fixes the problem for me: - cs->count = cs->count * new_sum / orig_node_count; + cs->count = cs->count * (new_sum / orig_node_count);
[Bug libobjc/49804] New: regression gcc4.7 from 20110709 to 20110716 on ia64, sparc64 freebsd9.0 Configuration mismatch! [libgcc-extra-parts] Error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49804
Summary: regression gcc4.7 from 20110709 to 20110716 on ia64,
sparc64 freebsd9.0 Configuration mismatch!
[libgcc-extra-parts] Error
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libobjc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: me...@bristol.ac.uk
On ia64, sparc64 freebsd9.0 I've installed gcc-4.7.0.20110709
Both arches fail to build 4.7.0.20110716.
On ia64:
Checking multilib configuration for libgcc...
gmake[3]: Entering directory
`/usr/ports/lang/gcc47/work/build/ia64-portbld-freebsd9.0/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
rm -f libgcc.a
objects="__divxf3.o __divdf3.o __divsf3.o __divdi3.o __moddi3.o __udivdi3.o
__umoddi3.o
+__divsi3.o
__modsi3.o __udivsi3.o __umodsi3.o __save_stack_nonlocal.o __nonlocal_goto.o
+__restore_stack_nonloc
al.o __trampoline.o _fixtfdi.o _fixunstfdi.o _floatditf.o _muldi3.o _negdi2.o
_lshrdi3.o
+_ashldi3.o
_ashrdi3.o _cmpdi2.o _ucmpdi2.o _clear_cache.o _trampoline.o __main.o
_absvsi2.o _absvdi2.o
+_addvs
i3.o _addvdi3.o _subvsi3.o _subvdi3.o _mulvsi3.o _mulvdi3.o _negvsi2.o
_negvdi2.o _ctors.o
+_ffssi2.
o _ffsdi2.o _clz.o _clzsi2.o _clzdi2.o _ctzsi2.o _ctzdi2.o _popcount_tab.o
_popcountsi2.o
+_popcount
di2.o _paritysi2.o _paritydi2.o _powisf2.o _powidf2.o _powixf2.o _powitf2.o
_mulsc3.o _muldc3.o
+_mu
lxc3.o _multc3.o _divsc3.o _divdc3.o _divxc3.o _divtc3.o _bswapsi2.o
_bswapdi2.o _clrsbsi2.o
+_clrsb
di2.o _fixunssfsi.o _fixunsdfsi.o _fixunsxfsi.o _fixsfdi.o _fixdfdi.o
_fixxfdi.o _fixunssfdi.o
+_fix
unsdfdi.o _fixunsxfdi.o _floatdisf.o _floatdidf.o _floatdixf.o _floatundisf.o
_floatundidf.o
+_float
undixf.o _floatunditf.o _eprintf.o __gcc_bcmp.o _divdi3.o _moddi3.o _udivdi3.o
_umoddi3.o
+_udiv_w_s
div.o _udivmoddi4.o enable-execute-stack.o";
\
if test -z "$objects"; then \
echo 'int __libgcc_eh_dummy;' > eh_dummy.c; \
/usr/ports/lang/gcc47/work/build/./gcc/xgcc
-B/usr/ports/lang/gcc47/work/build/./gcc/
+-B/usr/loca
l/ia64-portbld-freebsd9.0/bin/ -B/usr/local/ia64-portbld-freebsd9.0/lib/
-isystem
+/usr/local/ia64-p
ortbld-freebsd9.0/include -isystem
/usr/local/ia64-portbld-freebsd9.0/sys-include-g -O2 -pipe
+-
I/usr/local/include -fno-strict-aliasing -O2 -g -O2 -pipe -I/usr/local/include
+-fno-strict-aliasin
g -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes
+-Wold-st
yle-definition -isystem ./include -fPIC -pthread -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2
+-fbuilding-
libgcc -fno-stack-protector -I. -I. -I../.././gcc
-I../.././../gcc-4.7-20110716/libgcc
+-I../.././
../gcc-4.7-20110716/libgcc/. -I../.././../gcc-4.7-20110716/libgcc/../gcc
+-I../.././../gcc-4.7-20110
716/libgcc/../include -DHAVE_CC_TLS -fvisibility=hidden -DHIDE_EXPORTS -c
eh_dummy.c \
-o eh_dummy.o; \
objects=eh_dummy.o; \
fi; \
/usr/local/ia64-portbld-freebsd9.0/bin/ar rc libgcc.a $objects
/usr/local/ia64-portbld-freebsd9.0/bin/ranlib libgcc.a
# If the gcc directory specifies which extra parts to
# build for this target, and the libgcc configuration also
# specifies, make sure they match. This can be removed
# when the gcc directory no longer holds libgcc configuration;
# it is useful when migrating a target.
Configuration mismatch!
Extra parts from gcc directory: crtbegin.o crtbeginS.o crtend.o crtendS.o
Extra parts from libgcc: crtbegin.o crtend.o crtbeginS.o crtendS.o
crtfastmath.o
exit 1
gmake[3]: *** [libgcc-extra-parts] Error 1
On sparc64:
Checking multilib configuration for libgcc...
gmake[3]: Entering directory
`/usr/ports/lang/gcc47/work/build/sparc64-portbld-freebsd9.0/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
gmake[4]: Entering directory
`/usr/ports/lang/gcc47/work/build/sparc64-portbld-freebsd9.0/libgcc'
if [ -z "" ]; then \
true; \
else \
rootpre=`${PWDCMD-pwd}`/; export rootpre; \
srcrootpre=`cd ../.././../gcc-4.7-20110716/libgcc; ${PWDCMD-pwd}`/; export
srcrootpre; \
lib=`echo "${rootpre}" | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \
compiler="/usr/ports/lang/gcc47/work/build/./gcc/xgcc
-B/usr/ports/lang/gcc47/work/build/./gcc/
+-B/usr/local/sparc64-portbld-freebsd
9.0/bin/ -B/usr/local/sparc64-portbld-freebsd9.0/lib/ -isystem
+/usr/local/sparc64-portbld-freebsd9.0/include -isystem /usr/local/sparc
64-portbld-freebsd9.0/sys-include "; \
for i in `${compiler} --print-multi-lib 2>/dev/null`; do \
dir=`echo $i | sed -e 's/;.*$//'`; \
if [ "${dir}" = "." ]; then \
true; \
else \
if [ -d ../${dir}/${lib} ]; then \
flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \
if (cd ../${dir}/${lib}; gma
[Bug tree-optimization/49770] [4.7 Regression] wrong code with -fno-tree-forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49770 --- Comment #5 from Richard Guenther 2011-07-21 13:19:27 UTC --- Author: rguenth Date: Thu Jul 21 13:19:18 2011 New Revision: 176567 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176567 Log: 2011-07-21 Richard Guenther PR tree-optimization/49770 * tree-ssa-sccvn.c (valueize_refs_1): Return whether we valueized any operand. Renamed from ... (valueize_refs): ... this. New wrapper around valueize_refs_1. (valueize_shared_reference_ops_from_ref): Return whether we valueized any operand. (vn_reference_lookup): Only when we valueized any operand use the valueized reference for alias analysis. Do not preserve the original reference tree in this case. * g++.dg/torture/pr49770.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr49770.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/49770] [4.7 Regression] wrong code with -fno-tree-forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49770 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Richard Guenther 2011-07-21 13:25:12 UTC --- Flixed.
[Bug libobjc/49804] regression gcc4.7 from 20110709 to 20110716 on ia64, sparc64 freebsd9.0 Configuration mismatch! [libgcc-extra-parts] Error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49804 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Richard Guenther 2011-07-21 13:26:42 UTC --- This has been fixed already.
[Bug target/49798] .quad instead of .long is used for address for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798 --- Comment #5 from Uros Bizjak 2011-07-21 13:30:22 UTC --- (In reply to comment #4) > > Linker should put correct address (so, zero extended 32bit address) here. > > Did you mean assembler? In many cases, .quad is still simply wrong (PR 47446). No, the linker. But looking at mentioned PR, linker is not able to generate BFD_RELOC_64. > GCC shouldn't generate .quad in this case. A patch is posted at > > http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01711.html IMO, this patch is wrong. Generated code should look like the one for i686, so it looks to me that check for Pmode != ptr_mode is missing somewhere in the middle end.
[Bug target/49798] .quad instead of .long is used for address for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798 --- Comment #6 from H.J. Lu 2011-07-21 14:02:54 UTC --- (In reply to comment #5) > (In reply to comment #4) > > > > Linker should put correct address (so, zero extended 32bit address) here. > > > > Did you mean assembler? In many cases, .quad is still simply wrong (PR > > 47446). > > No, the linker. But looking at mentioned PR, linker is not able to generate > BFD_RELOC_64. That is correct. We shouldn't have BFD_RELOC_64 in 32bit. > > GCC shouldn't generate .quad in this case. A patch is posted at > > > > http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01711.html > > IMO, this patch is wrong. Generated code should look like the one for i686, so > it looks to me that check for Pmode != ptr_mode is missing somewhere in the > middle end. That is not necessarily true if Pmode is used here. In this regard, x32 is the same as x86-64. Basically a 64bit value is generated from an address. If address is 32bit, we just need to zero-extend it.
[Bug c/49779] Wrong code generated for while loop with guard containing continue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49779 --- Comment #6 from joseph at codesourcery dot com 2011-07-21 14:26:05 UTC --- See PR 44715 for previous discussion of issues with loop control statements in statement expressions.
[Bug middle-end/49805] New: [4.7 Regression] FAIL: FAIL: gcc.target/i386/andor-2.c scan-assembler-not sete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49805 Summary: [4.7 Regression] FAIL: FAIL: gcc.target/i386/andor-2.c scan-assembler-not sete 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/ia32, revision 176563 gave FAIL: gcc.target/i386/andor-2.c scan-assembler-not sete Revision 176559 is OK.
[Bug target/49799] gcc arm generates illegal sbfx instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49799 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.21 14:27:59 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Ramana Radhakrishnan 2011-07-21 14:27:59 UTC --- Confirmed - and it appears as though combine is doing this transformation . Based on a quick debug I couldn't spot any pattern in the backend that encourages this other than the extv matcher. One could guard this by making sure that the backend doesn't recognize such forms but combine really shouldn't be generating such a extv instruction reading more bits than that are already available. Ramana
[Bug middle-end/49806] New: [4.7 Regression] FAIL: gcc.dg/tree-ssa/vrp47.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49806 Summary: [4.7 Regression] FAIL: gcc.dg/tree-ssa/vrp47.c 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/ia32, revision 176564 gave FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp1 "x[^ ]* \^ 1" 1 Revision 176539 is OK.
[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997 --- Comment #23 from Iain Sandoe 2011-07-21 14:52:26 UTC --- OK, done some more debugging so one can't call fix_string_type () twice on the same string and get a sensible result... ... the determination of the string type by equating to one of the global_tree nodes is broken on the second call since the first call overwrites the tree type: code fragment from fix_string_type (): i_type = build_index_type (size_int (nchars - 1)); a_type = build_array_type (e_type, i_type); if (c_dialect_cxx() || warn_write_strings) a_type = c_build_qualified_type (a_type, TYPE_QUAL_CONST); TREE_TYPE (value) = a_type; === So either this is wrong - or we need some way to know that fix_string_type has already been called (by lex_string()). in the meantime - this just avoids making the second call, because I can't see that there's any case in which objc_build_string_object () is called without a string from lex_string ()? (grep suggests not). thus; assuming that fix_string_type () is behaving as expected, the following is a fix : Index: gcc/objc/objc-act.c === --- gcc/objc/objc-act.c (revision 176554) +++ gcc/objc/objc-act.c (working copy) @@ -3132,9 +3132,8 @@ objc_build_string_object (tree string) struct string_descriptor *desc, key; void **loc; - /* Prep the string argument. */ - string = fix_string_type (string); - TREE_SET_CODE (string, STRING_CST); + gcc_checking_assert (TREE_CODE (string) == STRING_CST); + length = TREE_STRING_LENGTH (string) - 1; /* The target may have different ideas on how to construct an ObjC string
[Bug c++/30112] pragma redefine_extname fails when namespaces are involved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30112 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.07.21 15:06:46 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug middle-end/49805] [4.7 Regression] FAIL: FAIL: gcc.target/i386/andor-2.c scan-assembler-not sete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49805 H.J. Lu changed: What|Removed |Added CC||ktietz at gcc dot gnu.org Target Milestone|--- |4.7.0 --- Comment #1 from H.J. Lu 2011-07-21 15:39:09 UTC --- It is caused by revision 176563: http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00830.html
[Bug c++/30112] pragma redefine_extname fails when namespaces are involved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30112 Jason Merrill changed: What|Removed |Added CC|jason at redhat dot com | --- Comment #5 from Jason Merrill 2011-07-21 15:41:52 UTC --- Incidentally, when adding me to the CC list of a PR, please use ja...@gcc.gnu.org rather than ja...@redhat.com.
[Bug middle-end/49806] [4.7 Regression] FAIL: gcc.dg/tree-ssa/vrp47.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49806 H.J. Lu changed: What|Removed |Added CC||ktietz at gcc dot gnu.org Target Milestone|--- |4.7.0 --- Comment #1 from H.J. Lu 2011-07-21 15:41:49 UTC --- It is caused by revision 176563: http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00830.html
[Bug c++/30112] pragma redefine_extname fails when namespaces are involved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30112 --- Comment #6 from Paolo Carlini 2011-07-21 15:49:16 UTC --- Agreed (indeed, I saw both in Bugzilla but never figured out which one you preferred ;)
[Bug middle-end/49805] [4.7 Regression] FAIL: FAIL: gcc.target/i386/andor-2.c scan-assembler-not sete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49805 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Richard Guenther 2011-07-21 15:50:38 UTC --- It's a dup of PR49806 (same testcase). *** This bug has been marked as a duplicate of bug 49806 ***
[Bug middle-end/49806] [4.7 Regression] FAIL: gcc.dg/tree-ssa/vrp47.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49806 --- Comment #2 from Richard Guenther 2011-07-21 15:50:38 UTC --- *** Bug 49805 has been marked as a duplicate of this bug. ***
[Bug middle-end/49806] [4.7 Regression] FAIL: gcc.dg/tree-ssa/vrp47.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49806 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.21 15:50:55 Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther 2011-07-21 15:50:55 UTC --- Related (same testcase): FAIL: gcc.target/i386/andor-2.c scan-assembler-not sete
[Bug target/49798] .quad instead of .long is used for address for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798
--- Comment #7 from H.J. Lu 2011-07-21 15:53:56
UTC ---
IRA generates
(insn 13 3 18 2 (set (reg/v:DI 21 xmm0 [orig:63 v ] [63])
(mem/u/c/i:DI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S8 A64]))
x.i:12 62 {*movdi_internal_rex64}
(expr_list:REG_EQUIV (symbol_ref:DI ("") [flags 0x40] )
(nil)))
This requires zero-extending 32bit address to 64bit.
[Bug target/49798] .quad instead of .long is used for address for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798
--- Comment #8 from H.J. Lu 2011-07-21 16:03:20
UTC ---
(In reply to comment #7)
> IRA generates
>
> (insn 13 3 18 2 (set (reg/v:DI 21 xmm0 [orig:63 v ] [63])
> (mem/u/c/i:DI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S8 A64]))
> x.i:12 62 {*movdi_internal_rex64}
> (expr_list:REG_EQUIV (symbol_ref:DI ("") [flags 0x40] 0x7f4068bbc140 >)
> (nil)))
>
> This requires zero-extending 32bit address to 64bit.
I am not sure how we can express it in constant pool beyond what
we have today. I can add a new assembler directive, xquad, so that we do
something similar to
/* Target hook for assembling integer objects. The sparc version has
special handling for aligned DI-mode objects. */
static bool
sparc_assemble_integer (rtx x, unsigned int size, int aligned_p)
{
/* ??? We only output .xword's for symbols and only then in environments
where the assembler can handle them. */
if (aligned_p && size == 8
&& (GET_CODE (x) != CONST_INT && GET_CODE (x) != CONST_DOUBLE))
{
if (TARGET_V9)
{
assemble_integer_with_op ("\t.xword\t", x);
return true;
}
else
{
assemble_aligned_integer (4, const0_rtx);
assemble_aligned_integer (4, x);
return true;
}
}
return default_assemble_integer (x, size, aligned_p);
}
[Bug target/49798] .quad instead of .long is used for address for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798
--- Comment #9 from Uros Bizjak 2011-07-21 16:25:49
UTC ---
Please compare optimized tree dumps from i686 (a) compilation vs x32 (b):
(a)
foo (union U u)
{
union U v;
_Bool D.2000;
double D.1999;
double D.1998;
int D.1997;
:
v = {};
v.m = &;
D.1998_1 = u.d;
D.1999_2 = v.d;
D.2000_3 = D.1998_1 == D.1999_2;
D.1997_4 = (int) D.2000_3;
return D.1997_4;
}
(b)
foo (union U u)
{
double D.2709;
_Bool D.2704;
double D.2702;
int D.2701;
:
D.2709_8 = VIEW_CONVERT_EXPR(&);
D.2702_1 = u.d;
D.2704_3 = D.2702_1 == D.2709_8;
D.2701_4 = (int) D.2704_3;
return D.2701_4;
}
We can't directly move & (32bit value) to double (64bit value).
However, we expand to:
(insn 6 5 11 (set (reg/f:DI 66)
(symbol_ref:DI ("") [flags 0x40] ))
pr49798.c:12 -1
(nil))
...
(insn 13 12 14 (set (reg:CCFPU 17 flags)
(compare:CCFPU (reg:DF 73)
(subreg:DF (reg/f:DI 66) 0))) pr49798.c:13 -1
(nil))
Does this looks OK?
[Bug target/49798] .quad instead of .long is used for address for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798
--- Comment #10 from H.J. Lu 2011-07-21 16:32:01
UTC ---
(In reply to comment #9)
> Please compare optimized tree dumps from i686 (a) compilation vs x32 (b):
>
> (a)
>
> foo (union U u)
> {
> union U v;
> _Bool D.2000;
> double D.1999;
> double D.1998;
> int D.1997;
>
> :
> v = {};
> v.m = &;
> D.1998_1 = u.d;
> D.1999_2 = v.d;
> D.2000_3 = D.1998_1 == D.1999_2;
> D.1997_4 = (int) D.2000_3;
> return D.1997_4;
>
> }
>
> (b)
>
> foo (union U u)
> {
> double D.2709;
> _Bool D.2704;
> double D.2702;
> int D.2701;
>
> :
> D.2709_8 = VIEW_CONVERT_EXPR(&);
> D.2702_1 = u.d;
> D.2704_3 = D.2702_1 == D.2709_8;
> D.2701_4 = (int) D.2704_3;
> return D.2701_4;
>
> }
>
> We can't directly move & (32bit value) to double (64bit value).
>
> However, we expand to:
>
> (insn 6 5 11 (set (reg/f:DI 66)
> (symbol_ref:DI ("") [flags 0x40] ))
> pr49798.c:12 -1
> (nil))
>
> ...
>
> (insn 13 12 14 (set (reg:CCFPU 17 flags)
> (compare:CCFPU (reg:DF 73)
> (subreg:DF (reg/f:DI 66) 0))) pr49798.c:13 -1
> (nil))
>
> Does this looks OK?
We can't compare x32 directly with ia32 since ia32 doesn't support
movdi_internal_rex64. We want to use 64bit instructions for x32.
[Bug target/49798] .quad instead of .long is used for address for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798
--- Comment #11 from Uros Bizjak 2011-07-21 16:36:56
UTC ---
(In reply to comment #10)
> > Does this looks OK?
>
> We can't compare x32 directly with ia32 since ia32 doesn't support
> movdi_internal_rex64. We want to use 64bit instructions for x32.
The problem is not in compare, but in
(insn 6 5 11 (set (reg/f:DI 66)
(symbol_ref:DI ("") [flags 0x40] ))
pr49798.c:12 -1
(nil))
Expander should choose SImode register here and SImode symbol reference.
[Bug target/49798] .quad instead of .long is used for address for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798
Uros Bizjak changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #12 from Uros Bizjak 2011-07-21 16:46:36
UTC ---
(In reply to comment #9)
> Please compare optimized tree dumps from i686 (a) compilation vs x32 (b):
>
> (a)
>
> foo (union U u)
> {
> union U v;
> _Bool D.2000;
> double D.1999;
> double D.1998;
> int D.1997;
>
> :
> v = {};
> v.m = &;
> D.1998_1 = u.d;
> D.1999_2 = v.d;
> D.2000_3 = D.1998_1 == D.1999_2;
> D.1997_4 = (int) D.2000_3;
> return D.1997_4;
>
> }
>
> (b)
>
> foo (union U u)
> {
> double D.2709;
> _Bool D.2704;
> double D.2702;
> int D.2701;
>
> :
> D.2709_8 = VIEW_CONVERT_EXPR(&);
> D.2702_1 = u.d;
> D.2704_3 = D.2702_1 == D.2709_8;
> D.2701_4 = (int) D.2704_3;
> return D.2701_4;
>
> }
>
> We can't directly move & (32bit value) to double (64bit value).
>
> However, we expand to:
>
> (insn 6 5 11 (set (reg/f:DI 66)
> (symbol_ref:DI ("") [flags 0x40] ))
> pr49798.c:12 -1
> (nil))
>
> ...
>
> (insn 13 12 14 (set (reg:CCFPU 17 flags)
> (compare:CCFPU (reg:DF 73)
> (subreg:DF (reg/f:DI 66) 0))) pr49798.c:13 -1
> (nil))
>
> Does this looks OK?
IMO, VIEW_CONVERT_EXPR is already wrong, let's CC richi for opinion.
[Bug target/49798] .quad instead of .long is used for address for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798
--- Comment #13 from H.J. Lu 2011-07-21 17:16:35
UTC ---
With -mx32 -O, I got
foo (union U u)
{
union U v;
_Bool D.2704;
double D.2703;
double D.2702;
int D.2701;
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
v = {};
v.m = &;
D.2702_1 = u.d;
D.2703_2 = v.d;
D.2704_3 = D.2702_1 == D.2703_2;
D.2701_4 = (int) D.2704_3;
return D.2701_4;
# SUCC: EXIT [100.0%]
}
In x.i.153r.dfinit,
(insn 8 6 9 2 (set (reg:SI 68)
(symbol_ref:SI ("") [flags 0x40] ))
x.i:12 64 {*movsi_internal}
(nil))
(insn 9 8 10 2 (set (reg:DI 67)
(zero_extend:DI (reg:SI 68))) x.i:12 112 {*zero_extendsidi2_rex64}
(nil))
x.i.154r.cse1 has
(insn 8 6 9 2 (set (reg/f:SI 68)
(symbol_ref:SI ("") [flags 0x40] ))
x.i:12 64 {*movsi_internal}
(nil))
(insn 9 8 10 2 (set (reg/f:DI 67)
(symbol_ref:DI ("") [flags 0x40] ))
x.i:12 62 {*movdi_internal_rex64}
(nil))
[Bug target/49798] .quad instead of .long is used for address for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798
--- Comment #14 from H.J. Lu 2011-07-21 17:19:06
UTC ---
It looks like (symbol_ref:DI ("")) is treated as zero_extend
for symbol address. My patch just does that, similar to Sparc.
[Bug target/49798] .quad instead of .long is used for address for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798
--- Comment #15 from H.J. Lu 2011-07-21 17:24:01
UTC ---
Another example:
[hjl@gnu-6 pr49798]$ cat y.i
union U
{
int *m;
long long d;
};
extern int ;
long long
foo ()
{
union U v = { &};
return v.d;
}
[hjl@gnu-6 pr49798]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -S -o y.s -mx32 -O -msse4 y.i
-da
[hjl@gnu-6 pr49798]$ cat y.s
.file"y.i"
.text
.globlfoo
.typefoo, @function
foo:
.LFB0:
.cfi_startproc
movl$, %eax
ret
.cfi_endproc
.LFE0:
.sizefoo, .-foo
.ident"GCC: (GNU) 4.7.0 20110720 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 pr49798]$ cat y.i.223r.final
;; Function foo (foo, funcdef_no=0, decl_uid=1711, cgraph_uid=0)
(note 1 0 3 NOTE_INSN_DELETED)
(note 3 1 24 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 24 3 2 2 NOTE_INSN_PROLOGUE_END)
(note 2 24 17 2 NOTE_INSN_FUNCTION_BEG)
(insn 17 2 20 2 (set (reg/i:DI 0 ax)
(symbol_ref:DI ("") [flags 0x40] ))
y.i:12 62 {*movdi_internal_rex64}
(nil))
(insn 20 17 25 2 (use (reg/i:DI 0 ax)) y.i:12 -1
(nil))
(note 25 20 26 2 NOTE_INSN_EPILOGUE_BEG)
(jump_insn 26 25 27 2 (return) y.i:12 645 {return_internal}
(nil))
(barrier 27 26 23)
(note 23 27 0 NOTE_INSN_DELETED)
[hjl@gnu-6 pr49798]$
[Bug tree-optimization/49749] Reassociation rank algorithm does not include all non-NULL operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49749 --- Comment #13 from William J. Schmidt 2011-07-21 18:07:42 UTC --- Author: wschmidt Date: Thu Jul 21 18:07:39 2011 New Revision: 176581 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176581 Log: 2011-07-21 Bill Schmidt PR tree-optimization/49749 * tree-ssa-reassoc.c (get_rank): Fix operand scan conditions and remove no-longer-used maxrank variable. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791 --- Comment #9 from Jerry DeLisle 2011-07-21 18:32:31 UTC --- (In reply to comment #8) > Jerry what do you think? I have to admit that I have not the slightest idea > what ionml->touched does - thus, I cannot come up of a possibly failing As you know, the namelist code is difficult to follow and touched was not my invention, but basically it is a flag that tells us that we already encountered this variable or a parent in a previous iteration. I don't have the code in front of me, but I seem to recall there is a comment elsewhere in the file that mentions something about it.
[Bug rtl-optimization/49807] New: Missed byte (subreg) extraction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49807
Summary: Missed byte (subreg) extraction
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
Target: avr
This C source:
#define SPDR (*((char volatile*) 0x2c))
void read_adc (long big)
{
SPDR = big >> 24;
SPDR = big >> 16;
SPDR = big >> 8;
SPDR = big;
}
compiles with
avr-gcc -S -Os -dp -mmcu=atmega8
to:
read_adc:
movw r26,r24 ; 2*movsi/1[length = 2]
movw r24,r22
mov r20,r27 ; 28*ashrsi3_const/3[length = 6]
clr r23
sbrc r20,7
com r23
mov r21,r23
mov r22,r23
out 44-0x20,r20 ; 9*movqi/3[length = 1]
movw r20,r26 ; 29*ashrsi3_const/3[length = 5]
clr r23
sbrc r21,7
com r23
mov r22,r23
out 44-0x20,r20 ; 13*movqi/3[length = 1]
mov r20,r25 ; 30*ashrsi3_const/3[length = 6]
mov r21,r26
mov r22,r27
clr r23
sbrc r22,7
dec r23
out 44-0x20,r20 ; 17*movqi/3[length = 1]
out 44-0x20,r24 ; 20*movqi/3[length = 1]
ret ; 26return[length = 1]
The shifts are done explicitely where the bytes could be saved directly.
Combiner tries insns like
Failed to match this instruction:
(set (mem/v:QI (const_int 44))
(subreg:QI (reg:SI 49) 1))
But they don't match because of MEM_VOLATILE_P so that the MEM
does not match memory_operand as obviously volatile_ok is 0 at that moment.
Must the backend split such insns by hand?
Changing the source like
#define SPDR0 (*((char*) 0x2c))
#define SPDR1 (*((char*) 0x2d))
#define SPDR2 (*((char*) 0x2e))
#define SPDR3 (*((char*) 0x2f))
void read_adc (long big)
{
SPDR0 = big >> 24;
SPDR1 = big >> 16;
SPDR2 = big >> 8;
SPDR3 = big;
}
and it compiles fine:
read_adc:
out 44-0x20,r25 ; 8*movqi/3[length = 1]
out 45-0x20,r24 ; 11*movqi/3[length = 1]
out 46-0x20,r23 ; 14*movqi/3[length = 1]
out 47-0x20,r22 ; 16*movqi/3[length = 1]
ret ; 26return[length = 1]
== configure ==
Target: avr
Configured with: ../../gcc.gnu.org/gcc-4_6-branch/configure --target=avr
--prefix=/local/gnu/install/gcc-4.6-mingw32 --host=i586-mingw32
--build=i686-linux-gnu --enable-languages=c,c++ --disable-nls --disable-shared
--with-dwarf2
Thread model: single
gcc version 4.6.1 20110620 (prerelease) (GCC)
[Bug rtl-optimization/49807] Missed byte (subreg) extraction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49807 --- Comment #1 from Georg-Johann Lay 2011-07-21 19:34:27 UTC --- Created attachment 24804 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24804 C test case as in the initial PR
[Bug rtl-optimization/49807] Missed byte (subreg) extraction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49807 Georg-Johann Lay changed: What|Removed |Added CC||eric.weddington at atmel ||dot com Target Milestone|--- |4.7.0
[Bug c++/49808] New: GCC adds an address-of somewhere!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49808
Summary: GCC adds an address-of somewhere!
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@boost-consulting.com
Compile the following:
template
struct A
{
A() { float r = g(0); }
};
struct f_t
{
float operator() (float x) const { return 1; }
};
f_t f;
A x;
Now replace "g(0)" with "(*g)(0)". It compiles!
It's almost as though I had written
A x;
[Bug bootstrap/49786] [4.7 Regression] bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49786 --- Comment #15 from Ian Lance Taylor 2011-07-21 19:56:28 UTC --- Martin: I was able to reproduce it by configuring using --with-ld to point to a newly built version of gold configured with --enable-plugins. Markus: That patch will fix the problem but will do the wrong thing in many cases, because the division will truncate. My exact gcc configure line: --enable-clocale=gnu' '--with-system-zlib' '--enable-shared' '--with-demangler-in-ld' '--enable-cloog-backend=isl' '--with-ppl=/home/iant/gnu/ppl-0.11-install' '--with-cloog=/home/iant/gnu/cloog-0.16.2-install' '--with-build-config=bootstrap-lto' '--with-fpmath=sse' '--with-ld=/usr/local/google/iant/gold/gold-objdir/gold/ld-new' '--enable-languages=c,c++,fortran,java,lto,objc The ld-new mentioned in the --with-ld option was mainline binutils configured with: --enable-gold --enable-plugins The ppl and cloog mentioned in the gcc configure line were downloaded from ftp://gcc.gnu.org/pub/gcc/infrastructure.
[Bug bootstrap/49786] [4.7 Regression] bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49786 --- Comment #16 from Ian Lance Taylor 2011-07-21 19:56:59 UTC --- Forgot to mention that I ran "make -j6 profiledbootstrap".
[Bug target/49798] .quad instead of .long is used for address for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798
--- Comment #16 from H.J. Lu 2011-07-21 19:59:31
UTC ---
(In reply to comment #9)
> Please compare optimized tree dumps from i686 (a) compilation vs x32 (b):
>
> (b)
>
> foo (union U u)
> {
> double D.2709;
> _Bool D.2704;
> double D.2702;
> int D.2701;
>
> :
> D.2709_8 = VIEW_CONVERT_EXPR(&);
> D.2702_1 = u.d;
> D.2704_3 = D.2702_1 == D.2709_8;
> D.2701_4 = (int) D.2704_3;
> return D.2701_4;
>
> }
>
>
I didn't see it with -mx32. I got
1. -m64 -O
foo (union U u)
{
double D.2709;
_Bool D.2704;
double D.2702;
int D.2701;
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
D.2709_8 = VIEW_CONVERT_EXPR(&);
D.2702_1 = u.d;
D.2704_3 = D.2702_1 == D.2709_8;
D.2701_4 = (int) D.2704_3;
return D.2701_4;
# SUCC: EXIT [100.0%]
}
2. -mx32 -O:
foo (union U u)
{
union U v;
_Bool D.2704;
double D.2703;
double D.2702;
int D.2701;
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
v = {};
v.m = &;
D.2702_1 = u.d;
D.2703_2 = v.d;
D.2704_3 = D.2702_1 == D.2703_2;
D.2701_4 = (int) D.2704_3;
return D.2701_4;
# SUCC: EXIT [100.0%]
}
Did I miss anything?
[Bug target/49798] .quad instead of .long is used for address for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798 --- Comment #17 from Uros Bizjak 2011-07-21 20:12:50 UTC --- (In reply to comment #16) > I didn't see it with -mx32. I got Hm, I also don't get this anymore...
[Bug rtl-optimization/49807] Missed byte (subreg) extraction when storing to volatile mem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49807
--- Comment #2 from Eric Weddington
2011-07-21 20:12:58 UTC ---
(In reply to comment #0)
> This C source:
>
> #define SPDR (*((char volatile*) 0x2c))
Hi Johann,
That's not quite correct. In avr-libc the header file sfr_defs.h will define a
register as this:
#define SPDR (*((volatile char *) 0x2c))
It's a pointer to a volatile char, not a volatile pointer to a char.
> Changing the source like
>
> #define SPDR0 (*((char*) 0x2c))
> #define SPDR1 (*((char*) 0x2d))
> #define SPDR2 (*((char*) 0x2e))
> #define SPDR3 (*((char*) 0x2f))
>
> void read_adc (long big)
> {
>SPDR0 = big >> 24;
>SPDR1 = big >> 16;
>SPDR2 = big >> 8;
>SPDR3 = big;
> }
>
>
> and it compiles fine:
Is your intent to change the address AND remove the volatile keyword? If you
want to test if it's the volatile keyword that is the cause then you should
only change that part:
#define SPDR (*((char *) 0x2c))
void read_adc (long big)
{
SPDR = big >> 24;
SPDR = big >> 16;
SPDR = big >> 8;
SPDR = big;
}
Overall, though, I think you're on the right track. Most users would like to be
able to do the shift-and-assign pattern in C and have it compile to storing the
individual byte without a shift in the assembly. Right now, the only way to do
a workaround to achieve that result is through the use of a union with a struct
and an integer type (like a long). If this issue can be fixed then I think that
this has a chance to reduce a lot of code size problems.
[Bug tree-optimization/49809] New: [4.7 regression] gimple_check failure at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49809 Summary: [4.7 regression] gimple_check failure at -O3 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ebotca...@gcc.gnu.org CC: rsand...@gcc.gnu.org Created attachment 24805 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24805 Reduced testcase The patch 2011-07-19 Richard Sandiford PR tree-optimization/49742 * tree-data-ref.c (get_references_in_stmt): Treat the lhs of a call as a potential write. has introduced regressions in Ada of the form: +===GNAT BUG DETECTED==+ | 4.7.0 20110720 (experimental) [trunk revision 176495] (i586-suse-linux-gnu) GCC error:| | gimple check: expected gimple_assign(error_mark), have | | gimple_call(block) in gimple_assign_lhs, at gimple.h:1736 Reduced testcase suitable for the gnat.dg testsuite attached (to be gnatchop-ed)
[Bug tree-optimization/49749] Reassociation rank algorithm does not include all non-NULL operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49749 --- Comment #14 from William J. Schmidt 2011-07-21 20:27:21 UTC --- Author: wschmidt Date: Thu Jul 21 20:27:17 2011 New Revision: 176585 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176585 Log: 2011-07-21 Bill Schmidt PR tree-optimization/49749 * tree-ssa-reassoc.c (PHI_LOOP_BIAS): New constant. (phi_loop_bias): New function. (get_rank): Bias rank upward for loop-carried dependencies; fix errors in operand scan conditions. Modified: branches/ibm/gcc-4_6-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_6-branch/gcc/tree-ssa-reassoc.c
[Bug rtl-optimization/49807] Missed byte (subreg) extraction when storing to volatile mem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49807 --- Comment #3 from Georg-Johann Lay 2011-07-21 20:34:14 UTC --- > (In reply to comment #2) > That's not quite correct. In avr-libc the header file sfr_defs.h will define a > register as this: > > #define SPDR (*((volatile char *) 0x2c)) (volatile char *) is the same as (char volatile *). Don't confuse it with (char * volatile) etc. > Is your intent to change the address AND remove the volatile keyword? I changed to different addresses in the non-volatile example because otherwise just the last store will survive. > Overall, though, I think you're on the right track. Most users would like to > be > able to do the shift-and-assign pattern in C and have it compile to storing > the > individual byte without a shift in the assembly. Right now, the only way to do > a workaround to achieve that result is through the use of a union with a > struct > and an integer type (like a long). If this issue can be fixed then I think > that > this has a chance to reduce a lot of code size problems. I don't know the exact rationale why volatile_ok is false in combine. It' obviously about volatile correctnet, but I don't see what would break here.
Re: [Bug rtl-optimization/49807] Missed byte (subreg) extraction when storing to volatile mem
On Thu, Jul 21, 2011 at 1:34 PM, gjl at gcc dot gnu.org wrote: > I don't know the exact rationale why volatile_ok is false in combine. > It' obviously about volatile correctnet, but I don't see what would break > here. It can, when dealing optimizations that reduce the size of load/stores of volatile memory. Thanks, Andrew Pinski
[Bug rtl-optimization/49807] Missed byte (subreg) extraction when storing to volatile mem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49807 --- Comment #4 from pinskia at gmail dot com 2011-07-21 20:39:08 UTC --- On Thu, Jul 21, 2011 at 1:34 PM, gjl at gcc dot gnu.org wrote: > I don't know the exact rationale why volatile_ok is false in combine. > It' obviously about volatile correctnet, but I don't see what would break > here. It can, when dealing optimizations that reduce the size of load/stores of volatile memory. Thanks, Andrew Pinski
[Bug rtl-optimization/49807] Missed byte (subreg) extraction when storing to volatile mem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49807 --- Comment #5 from Georg-Johann Lay 2011-07-21 20:46:05 UTC --- In this case it would not reduce the size of the store, but how can this be seen? It cannot be seen from the insn/pattern alone. Do you have an idea how to attack this optimization flaw?
[Bug target/34888] Stack patterns for AVR not optimal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34888 Georg-Johann Lay changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2011.07.21 20:48:36 Resolution|FIXED | Target Milestone|4.5.3 |4.7.0 Ever Confirmed|0 |1 --- Comment #2 from Georg-Johann Lay 2011-07-21 20:48:36 UTC --- Set to NEW again, I didn't read r124854 carefully enough :-/
[Bug target/49600] Bad SSE2 int->float split in i386.md
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49600 --- Comment #5 from uros at gcc dot gnu.org 2011-07-21 21:21:01 UTC --- Author: uros Date: Thu Jul 21 21:20:59 2011 New Revision: 176589 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176589 Log: Backport from mainline 2011-07-04 Uros Bizjak PR target/49600 * config/i386/i386.md (SSE2 int->float split): Push operand 1 in general register to memory for !TARGET_INTER_UNIT_MOVES. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/i386/i386.md
[Bug middle-end/49705] -Wstrict-overflow should not diagnose unevaluated expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49705 --- Comment #7 from ian at gcc dot gnu.org 2011-07-21 21:30:26 UTC --- Author: ian Date: Thu Jul 21 21:30:24 2011 New Revision: 176591 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176591 Log: gcc/c-family: PR middle-end/49705 * c-common.c (c_disable_warnings): New static function. (c_enable_warnings): New static function. (c_fully_fold_internal): Change local unused_p to bool. Call c_disable_warnings and c_enable_warnings rather than change c_inhibit_evaluation_warnings. gcc/testsuite: PR middle-end/49705 * gcc.dg/pr49705.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr49705.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/49705] -Wstrict-overflow should not diagnose unevaluated expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49705 Ian Lance Taylor changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #8 from Ian Lance Taylor 2011-07-21 21:32:01 UTC --- Fixed in mainline.
[Bug middle-end/47654] [4.6/4.7 Regression] gcc.dg/vect/no-section-anchors-vect-outer-4h.c FAILs with -floop-block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47654 --- Comment #10 from Sebastian Pop 2011-07-21 22:58:02 UTC --- Author: spop Date: Thu Jul 21 22:57:59 2011 New Revision: 176605 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176605 Log: Infer types based on lb and ub. 2011-07-21 Sebastian Pop PR middle-end/47654 PR middle-end/49649 * graphite-clast-to-gimple.c (type_for_clast_term): Pass v1 and v2 in parameter. Initialize v1 and v2 based on the values returned by clast_name_to_lb_ub. (type_for_clast_red): Pass v1 and v2 in parameter, and set their values. (type_for_clast_bin): Same. (type_for_clast_expr): Same. (type_for_clast_eq): Update calls to type_for_clast_expr. (type_for_clast_for): Same. (build_iv_mapping): Same. * graphite-ppl.h (value_min): New. * gcc.dg/graphite/run-id-pr47654.c: New. Added: trunk/gcc/testsuite/gcc.dg/graphite/run-id-pr47654.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-clast-to-gimple.c trunk/gcc/graphite-ppl.h trunk/gcc/testsuite/ChangeLog
[Bug middle-end/49649] [4.7 Regression] FAIL: libgomp.graphite/force-parallel-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49649 --- Comment #2 from Sebastian Pop 2011-07-21 22:58:02 UTC --- Author: spop Date: Thu Jul 21 22:57:59 2011 New Revision: 176605 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176605 Log: Infer types based on lb and ub. 2011-07-21 Sebastian Pop PR middle-end/47654 PR middle-end/49649 * graphite-clast-to-gimple.c (type_for_clast_term): Pass v1 and v2 in parameter. Initialize v1 and v2 based on the values returned by clast_name_to_lb_ub. (type_for_clast_red): Pass v1 and v2 in parameter, and set their values. (type_for_clast_bin): Same. (type_for_clast_expr): Same. (type_for_clast_eq): Update calls to type_for_clast_expr. (type_for_clast_for): Same. (build_iv_mapping): Same. * graphite-ppl.h (value_min): New. * gcc.dg/graphite/run-id-pr47654.c: New. Added: trunk/gcc/testsuite/gcc.dg/graphite/run-id-pr47654.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-clast-to-gimple.c trunk/gcc/graphite-ppl.h trunk/gcc/testsuite/ChangeLog
[Bug middle-end/49649] [4.7 Regression] FAIL: libgomp.graphite/force-parallel-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49649 Sebastian Pop changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Sebastian Pop 2011-07-21 23:03:07 UTC --- Fixed.
[Bug middle-end/47654] [4.6/4.7 Regression] gcc.dg/vect/no-section-anchors-vect-outer-4h.c FAILs with -floop-block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47654 Sebastian Pop changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Sebastian Pop 2011-07-21 23:02:51 UTC --- Fixed.
[Bug bootstrap/49810] New: [4.7 Regression] ld: Unsatisfied symbol "strsignal(int)" in file collect2.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49810 Summary: [4.7 Regression] ld: Unsatisfied symbol "strsignal(int)" in file collect2.o Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 /test/gnu/gcc/objdir/./prev-gcc/g++ -B/test/gnu/gcc/objdir/./prev-gcc/ -B/opt/gn u64/gcc/gcc-4.7/hppa64-hp-hpux11.11/bin/ -nostdinc++ -B/test/gnu/gcc/objdir/prev -hppa64-hp-hpux11.11/libstdc++-v3/src/.libs -B/test/gnu/gcc/objdir/prev-hppa64-h p-hpux11.11/libstdc++-v3/libsupc++/.libs -I/test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -L/test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs -L/test/gnu/gcc/objdir/prev-hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o Tcollect2 \ collect2.o collect2-aix.o tlink.o libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a ld: Unsatisfied symbol "strsignal(int)" in file collect2.o 1 errors. collect2: error: ld returned 1 exit status
[Bug bootstrap/49810] [4.7 Regression] ld: Unsatisfied symbol "strsignal(int)" in file collect2.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49810 --- Comment #1 from John David Anglin 2011-07-22 00:05:29 UTC --- This occurs in stage2. It seems we are now using C++ by default but there isn't a C++ version of libiberty.
[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791 --- Comment #10 from Jerry DeLisle 2011-07-22 01:28:19 UTC --- (In reply to comment #6) > (In reply to comment #3) > > If the bug reporter can, I think he should convert all the input files to > > the > > Fortran 90 syntax of namelists. However, one needs to be careful to not > > inadvertently to change the meaning (e.g. remove the wrong "(1)") and it > > might > > affect many files. > > > > I can change the test suite, but since we also use the Intel and PGI > compilers, > I wouldn't be able to guarantee other people won't get confused with this. Regardless of how we end up resolving this bug, if you can change your namelist files to be "more correct" you should do so. The idea of legacy behavior support is to be practical for those who have no control over older codes. I will comment further on the patch itself after I have a review our code.
[Bug c++/49811] New: Crash at __do_global_dtors_aux when compiled with '-shared -static'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49811
Summary: Crash at __do_global_dtors_aux when compiled with
'-shared -static'
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nn.d...@gmail.com
Created attachment 24806
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24806
Program which crashes when run.
While trying to statically include a library for a game, I compiled with both
'-shared' and '-static'. I ran the program and it crashed with "Segmentation
fault".
I reduced the program down to the minimum required to make it crash. When I
compiled the test with 'gcc -o segment_test -shared -static main.cpp' and ran
the program ('./segment_test'), the program still crashed with the same error
as the original.
System information:
openSUSE 11.3
Linux linux-d9bc 2.6.34.8-0.2-default #1 SMP 2011-04-06 18:11:26 +0200 i686
i686 i386 GNU/Linux
GCC is packaged in gcc-4.4-4.2-i586.rpm from
http://download.opensuse.org/distribution/11.2/repo/oss/
[Bug c++/49811] Crash at __do_global_dtors_aux when compiled with '-shared -static'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49811 --- Comment #1 from Nathan 2011-07-22 04:16:08 UTC --- Created attachment 24807 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24807 GCC output when run with additional '-v -save-temps'
[Bug target/48155] Reload doesn't handle subreg properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48155
Paul Bone changed:
What|Removed |Added
CC||pbone at csse dot
||unimelb.edu.au
--- Comment #4 from Paul Bone 2011-07-22
05:57:44 UTC ---
I'm seeing the same problem in gcc 4.4 and 4.6, I did not test 4.5:
paul@semillion:~/code/mercury-compiler-rotd-2011-06-23/compiler$ gcc-4.4 -v -c
-o /tmp/out.o -O1 ml_backend.ml_closure_gen.i
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)
COLLECT_GCC_OPTIONS='-v' '-c' '-o' '/tmp/out.o' '-O1' '-mtune=generic'
'-march=i586'
/usr/lib/gcc/i486-linux-gnu/4.4.5/cc1 -fpreprocessed
ml_backend.ml_closure_gen.i -quiet -dumpbase ml_backend.ml_closure_gen.i
-mtune=generic -march=i586 -auxbase-strip /tmp/out.o -O1 -version -o
/tmp/ccbABR7o.s
GNU C (Debian 4.4.5-8) version 4.4.5 (i486-linux-gnu)
compiled by GNU C version 4.4.5, GMP version 4.3.2, MPFR version
3.0.0-p3.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127992
Compiler executable checksum: 0192d925385d4e6642a93c63f245f907
ml_backend.ml_closure_gen.c:32: warning:
‘mercury__ml_backend__ml_closure_gen__ml_gen_maybe_pseudo_type_info_defn_4_0’
used but never defined
ml_backend.ml_closure_gen.c: In function ‘ml_backend__ml_closure_gen_module11’:
ml_backend.ml_closure_gen.c:230: error: unable to find a register to spill in
class ‘DIREG’
ml_backend.ml_closure_gen.c:230: error: this is the insn:
(insn 123 122 124 11 ml_backend.ml_closure_gen.c:105 (parallel [
(set (mem:SI (reg/f:SI 136) [0 S4 A32])
(reg/v:SI 80 [ MR_tempr3 ]))
(set (reg/v:SI 82 [ MR_tempr1 ])
(plus:SI (reg/f:SI 136)
(const_int 4 [0x4])))
]) 852 {*strsetsi_1} (expr_list:REG_DEAD (reg/f:SI 136)
(nil)))
ml_backend.ml_closure_gen.c:230: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/cccXoZX2.out file, please attach this to
your bugreport.
I will attach the generated test case.
[Bug target/48155] Reload doesn't handle subreg properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48155 --- Comment #5 from Paul Bone 2011-07-22 05:59:24 UTC --- (In reply to comment #4) Sorry, this comment was filed against the wrong bug. Please ignore/delete it.
[Bug middle-end/47725] [x32] error: unable to find a register to spill in class DIREG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47725
--- Comment #19 from Paul Bone 2011-07-22
06:01:30 UTC ---
I'm seeing the same problem in gcc 4.4 and 4.6, I did not test 4.5:
paul@semillion:~/code/mercury-compiler-rotd-2011-06-23/compiler$ gcc-4.4 -v -c
-o /tmp/out.o -O1 ml_backend.ml_closure_gen.i
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)
COLLECT_GCC_OPTIONS='-v' '-c' '-o' '/tmp/out.o' '-O1' '-mtune=generic'
'-march=i586'
/usr/lib/gcc/i486-linux-gnu/4.4.5/cc1 -fpreprocessed
ml_backend.ml_closure_gen.i -quiet -dumpbase ml_backend.ml_closure_gen.i
-mtune=generic -march=i586 -auxbase-strip /tmp/out.o -O1 -version -o
/tmp/ccbABR7o.s
GNU C (Debian 4.4.5-8) version 4.4.5 (i486-linux-gnu)
compiled by GNU C version 4.4.5, GMP version 4.3.2, MPFR version
3.0.0-p3.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127992
Compiler executable checksum: 0192d925385d4e6642a93c63f245f907
ml_backend.ml_closure_gen.c:32: warning:
‘mercury__ml_backend__ml_closure_gen__ml_gen_maybe_pseudo_type_info_defn_4_0’
used but never defined
ml_backend.ml_closure_gen.c: In function ‘ml_backend__ml_closure_gen_module11’:
ml_backend.ml_closure_gen.c:230: error: unable to find a register to spill in
class ‘DIREG’
ml_backend.ml_closure_gen.c:230: error: this is the insn:
(insn 123 122 124 11 ml_backend.ml_closure_gen.c:105 (parallel [
(set (mem:SI (reg/f:SI 136) [0 S4 A32])
(reg/v:SI 80 [ MR_tempr3 ]))
(set (reg/v:SI 82 [ MR_tempr1 ])
(plus:SI (reg/f:SI 136)
(const_int 4 [0x4])))
]) 852 {*strsetsi_1} (expr_list:REG_DEAD (reg/f:SI 136)
(nil)))
ml_backend.ml_closure_gen.c:230: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/cccXoZX2.out file, please attach this to
your bugreport.
I will attach the generated test case.
[Bug middle-end/47725] [x32] error: unable to find a register to spill in class DIREG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47725
--- Comment #20 from Paul Bone 2011-07-22
06:07:11 UTC ---
Created attachment 24808
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24808
Test case generated by Mercury Compiler
This is a test case generated by the Mercury compiler, it has been reduced just
enough code to cause the bug to occur. It can be reproduced in gcc 4.4 and 4.6
at an optimization level of -O1 but not -O0. The output of GCC is:
paul@semillion:~/code/mercury-compiler-rotd-2011-06-23/compiler$ gcc-4.4 -v -c
-o /tmp/out.o -O1 ml_backend.ml_closure_gen.i
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)
COLLECT_GCC_OPTIONS='-v' '-c' '-o' '/tmp/out.o' '-O1' '-mtune=generic'
'-march=i586'
/usr/lib/gcc/i486-linux-gnu/4.4.5/cc1 -fpreprocessed
ml_backend.ml_closure_gen.i -quiet -dumpbase ml_backend.ml_closure_gen.i
-mtune=generic -march=i586 -auxbase-strip /tmp/out.o -O1 -version -o
/tmp/ccbABR7o.s
GNU C (Debian 4.4.5-8) version 4.4.5 (i486-linux-gnu)
compiled by GNU C version 4.4.5, GMP version 4.3.2, MPFR version
3.0.0-p3.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127992
Compiler executable checksum: 0192d925385d4e6642a93c63f245f907
ml_backend.ml_closure_gen.c:32: warning:
‘mercury__ml_backend__ml_closure_gen__ml_gen_maybe_pseudo_type_info_defn_4_0’
used but never defined
ml_backend.ml_closure_gen.c: In function ‘ml_backend__ml_closure_gen_module11’:
ml_backend.ml_closure_gen.c:230: error: unable to find a register to spill in
class ‘DIREG’
ml_backend.ml_closure_gen.c:230: error: this is the insn:
(insn 123 122 124 11 ml_backend.ml_closure_gen.c:105 (parallel [
(set (mem:SI (reg/f:SI 136) [0 S4 A32])
(reg/v:SI 80 [ MR_tempr3 ]))
(set (reg/v:SI 82 [ MR_tempr1 ])
(plus:SI (reg/f:SI 136)
(const_int 4 [0x4])))
]) 852 {*strsetsi_1} (expr_list:REG_DEAD (reg/f:SI 136)
(nil)))
ml_backend.ml_closure_gen.c:230: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/cccXoZX2.out file, please attach this to
your bugreport.
