[Bug c++/48266] New: deprecated("message") fails to print message

[gcc at magfr dot user.lysator.liu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48266



   Summary: deprecated("message") fails to print message

   Product: gcc

   Version: 4.6.0

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: g...@magfr.user.lysator.liu.se





Created attachment 23765

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23765

Compile with g++ -S -o /dev/null foo.cpp to repeat



In the attached program I would have expected the string "message" to show up

three times (line 7, 8 and 10) instead of only one time (line 8).



Note that all the lines do get a deprecation warning, it is only the message

that is missing.

[Bug c/48267] New: incorrect signed overflow warning when a pointer cannot possibly overflow

[eggert at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48267



   Summary: incorrect signed overflow warning when a pointer

cannot possibly overflow

   Product: gcc

   Version: 4.5.2

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: egg...@gnu.org





I ran into this problem when compiling the GNU Emacs trunk with a GCC

4.5.2 that I built on RHEL 5.5 (x86-64).  I narrowed it down to the

following stripped-down test case.  This smells different from the previous

bug report I filed in this area (PR48228) on the same platform.



When I compile the following program with "gcc -S -Wstrict-overflow -O2"

GCC reports "warning: assuming pointer wraparound does not occur when comparing

P +- C1 with P +- C2".  This warning is incorrect, since

signed overflow is obviously impossible in this function: the only

pointers computed are head_table and head_table + 1, which are both

in range.  Changing the "+ 1" to "+ 7" generates even more warnings,

though the program is still correct.



int head_table[7];



int

foo (void)

{

  const int *p;

  int x = 0;



  for (p = head_table; p < head_table + 1; p++)

x ^= *p;

  return x;

}

[Bug libstdc++/48257] std::string::assign() corrupts std::string static data when called on emptyString1 using emptyString2.data()

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #5 from Paolo Carlini  2011-03-24 
08:02:51 UTC ---

Jon is absolutely right. Please, always refer to the Standard for the complete

specifications. And yes exceeding max_size for the total length leads to an

exception being thrown, this is what _M_check_length is for.

[Bug target/48262] [4.7 Regression] Subversion id 171341 breaks various vectorization files on powerpc

[rsandifo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48262



rsand...@gcc.gnu.org  changed:



   What|Removed |Added



 CC||rsandifo at gcc dot gnu.org



--- Comment #8 from rsandifo at gcc dot gnu.org  
2011-03-24 08:52:21 UTC ---

Unfortunately, this kind of target.md fallout was to

some extent expected.  Thanks Andrew for fixing it.

[Bug c++/48268] New: Incomplete Type (seems auto/c++0x specific)

[dtag00 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48268

   Summary: Incomplete Type (seems auto/c++0x specific)
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dta...@gmail.com


Hi,

the following program yields an incomplete type error on GCC 4.5.1 in the
highlighted line "auto x=...". That shouldn't be the case right? It compiles
fine in the comeau online compiler.
I am compiling with
$ g++ a.cpp -std=gnu++0x
Error Message:
a.cpp: In function ‘int main()’:
a.cpp:14: error: ‘x’ has incomplete type

--

struct Foo
{
template
static T add(T a, T b)
{
return a+b;
}
};

typedef double (*padd)(double, double);

int main()
{
auto x=&Foo::add; // yields incomplete type on gcc, works on comeau
online
padd y=&Foo::add; // works on both
}

--

Thanks

[Bug c++/44500] [C++0x] Bogus narrowing conversion error

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500



--- Comment #16 from Jason Merrill  2011-03-24 
08:58:46 UTC ---

The committee closed my DR as not a defect.  We could still downgrade this

error to a pedwarn, though.



http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_closed.html#1078

[Bug c++/44500] [C++0x] Bogus narrowing conversion error

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500



Jason Merrill  changed:



   What|Removed |Added



 Status|SUSPENDED   |RESOLVED

 Resolution||INVALID



--- Comment #17 from Jason Merrill  2011-03-24 
08:59:43 UTC ---

Actually, it's already a permerror, so -fpermissive will allow your code to

compile without changes.

[Bug libstdc++/48257] std::string::assign() corrupts std::string static data when called on emptyString1 using emptyString2.data()

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257



--- Comment #6 from Jonathan Wakely  2011-03-24 
09:29:28 UTC ---

Also, GCC 4.1.2 is ancient and not supported here, you should either report

bugs to the vendor of your version (Red Hat) or refer to a supported version.



As for being disrespectful, the bug was invalid and I know that for a fact,

which is why I didn't wait for you to agree.  You don't need to reopen the bug

in order to post a new comment if you'd like pointers to the relevant pieces of

the standard or the code.

[Bug c++/48268] Incomplete Type (seems auto/c++0x specific)

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48268



--- Comment #1 from Jonathan Wakely  2011-03-24 
09:32:33 UTC ---

Seems to be fixed already on trunk, and probably 4.6.0

[Bug libstdc++/48257] std::string::assign() corrupts std::string static data when called on emptyString1 using emptyString2.data()

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257



--- Comment #7 from Jonathan Wakely  2011-03-24 
09:37:03 UTC ---

(In reply to comment #4)

> 

> I don't see any errors being thrown. I am not trying to nit-pick but I've

> raised this issue because I was affected by it and had to spend several days

> isolating it. It would have made my life a whole lot easier if, as you claim,

> libstdc++ had thrown an error.



I never claimed there'd be an exception throw in your original example, I said

it's undefined behaviour.  An exception is thrown if n > max_size()



> Just a request, but please let the discussion complete before you go ahead and

> mark the bug as Resolved-Invalid. I don't mind it being marked invalid, but I

> consider it disrespectful for you to not even wait for my response and rushing

> to mark it as invalid. Once we're through discussing, I will mark it invalid

> myself if necessary.



That's not how it works, most users do not close their own bugs, maintainers

don't want to keep revisiting old bugs to see if the user has decided to accept

the resolution yet.

[Bug rtl-optimization/48263] [4.7 Regression]: build fails for cris-elf in libgfortran

[rsandifo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48263



rsand...@gcc.gnu.org  changed:



   What|Removed |Added



 AssignedTo|unassigned at gcc dot   |rsandifo at gcc dot gnu.org

   |gnu.org |



--- Comment #3 from rsandifo at gcc dot gnu.org  
2011-03-24 09:38:21 UTC ---

Testing a patch.

[Bug libstdc++/48257] std::string::assign() corrupts std::string static data when called on emptyString1 using emptyString2.data()

[mohsinrzaidi at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257



--- Comment #8 from Mohsin  2011-03-24 09:50:11 
UTC ---

(In reply to comment #6)

> Also, GCC 4.1.2 is ancient and not supported here, you should either report

> bugs to the vendor of your version (Red Hat) or refer to a supported version.

> 



In my last comment, I did not post snippets to old code - I posted them off the

latest code.



> As for being disrespectful, the bug was invalid and I know that for a fact,

> which is why I didn't wait for you to agree.  You don't need to reopen the bug

> in order to post a new comment if you'd like pointers to the relevant pieces 
> of

> the standard or the code.



Agreed.

[Bug libstdc++/48257] std::string::assign() corrupts std::string static data when called on emptyString1 using emptyString2.data()

[mohsinrzaidi at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257



--- Comment #9 from Mohsin  2011-03-24 09:52:56 
UTC ---

(In reply to comment #7)

> (In reply to comment #4)

> > 

> > I don't see any errors being thrown. I am not trying to nit-pick but I've

> > raised this issue because I was affected by it and had to spend several days

> > isolating it. It would have made my life a whole lot easier if, as you 
> > claim,

> > libstdc++ had thrown an error.

> 

> I never claimed there'd be an exception throw in your original example, I said

> it's undefined behaviour.  An exception is thrown if n > max_size()

> 



Agreed.



> > Just a request, but please let the discussion complete before you go ahead 
> > and

> > mark the bug as Resolved-Invalid. I don't mind it being marked invalid, but 
> > I

> > consider it disrespectful for you to not even wait for my response and 
> > rushing

> > to mark it as invalid. Once we're through discussing, I will mark it invalid

> > myself if necessary.

> 

> That's not how it works, most users do not close their own bugs, maintainers

> don't want to keep revisiting old bugs to see if the user has decided to 
> accept

> the resolution yet.



Agreed.(In reply to comment #7)

> (In reply to comment #4)

> > 

> > I don't see any errors being thrown. I am not trying to nit-pick but I've

> > raised this issue because I was affected by it and had to spend several days

> > isolating it. It would have made my life a whole lot easier if, as you 
> > claim,

> > libstdc++ had thrown an error.

> 

> I never claimed there'd be an exception throw in your original example, I said

> it's undefined behaviour.  An exception is thrown if n > max_size()

> 

> > Just a request, but please let the discussion complete before you go ahead 
> > and

> > mark the bug as Resolved-Invalid. I don't mind it being marked invalid, but 
> > I

> > consider it disrespectful for you to not even wait for my response and 
> > rushing

> > to mark it as invalid. Once we're through discussing, I will mark it invalid

> > myself if necessary.

> 

> That's not how it works, most users do not close their own bugs, maintainers

> don't want to keep revisiting old bugs to see if the user has decided to 
> accept

> the resolution yet.



Agreed, thanks.

[Bug middle-end/48269] New: Incorrect fortify warning for a packed struct member

[ismail at namtrac dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48269

   Summary: Incorrect fortify warning for a packed struct member
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ism...@namtrac.org


[~]> g++-4.6 -m32 -O2 -fstack-protector -c kis_droneframe.ii 
In file included from packet.h:37:0,
 from kis_droneframe.cc:28:
packet_ieee80211.h:248:40: warning: ‘packed’ attribute ignored [-Wattributes]
packet_ieee80211.h:253:43: warning: ‘packed’ attribute ignored [-Wattributes]
packet_ieee80211.h:273:43: warning: ‘packed’ attribute ignored [-Wattributes]
In file included from /usr/include/stdio.h:912:0,
 from util.h:24,
 from kis_droneframe.cc:25:
In function ‘int snprintf(char*, size_t, const char*, ...)’,
inlined from ‘virtual int KisDroneFramework::SendSource(int,
pst_packetsource*, int)’ at kis_droneframe.cc:507:49:
/usr/include/bits/stdio2.h:66:75: warning: call to int
__builtin___snprintf_chk(char*, unsigned int, int, unsigned int, const char*,
...) will always overflow destination buffer [enabled by default]

Now the said line is;

snprintf((char *) spkt->type_str, 16, "%s",
 in_int->strong_source->FetchType().c_str());


where spkt is defined as;

struct drone_source_packet {
uint16_t source_hdr_len;
uint32_t source_content_bitmap;
drone_trans_uuid uuid;
// Kill this source, the rest of the data is empty
uint16_t invalidate;
// Null-terminated strings
uint8_t name_str[16];
uint8_t interface_str[16];
uint8_t type_str[16];
uint8_t channel_hop;
uint16_t channel_dwell;
uint16_t channel_rate;
} __attribute__((__packed__));

Using gcc version 4.6.0 20110314 [gcc-4_6-branch revision 170941] (SUSE Linux)

[Bug middle-end/48269] Incorrect fortify warning for a packed struct member

[ismail at namtrac dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48269



--- Comment #1 from Ismail "cartman" Donmez  
2011-03-24 09:55:23 UTC ---

Created attachment 23766

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23766

Preprocessed source

[Bug middle-end/48269] Incorrect fortify warning for a packed struct member

[marcus at jet dot franken.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48269



marcus at jet dot franken.de changed:



   What|Removed |Added



 CC||marcus at jet dot

   ||franken.de



--- Comment #2 from marcus at jet dot franken.de 2011-03-24 09:58:48 UTC ---

there is a malloc(sizeof(struct1)+sizeof(struct2))

and the struct 1 has 



uint8_t data[0] 

at the end, where struct2* = struct1*->data;



the malloc() seems to allocate insufficient memory, spo the overflow checker

triggers.

[Bug middle-end/48270] New: [4.7 Regression] New test failures

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48270



   Summary: [4.7 Regression] New test failures

   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: i...@gcc.gnu.org





On Linux/x86, revision 171381:



http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg00805.html



caused



FAIL: gcc.c-torture/execute/builtins/strlen-2.c compilation,  -O3

-fomit-frame-pointer  (internal compiler error)

FAIL: gcc.c-torture/execute/builtins/strlen-2.c compilation,  -O3 -g  (internal

compiler error)

FAIL: gcc.c-torture/execute/cbrt.c compilation,  -O3 -fomit-frame-pointer 

(internal compiler error)

FAIL: gcc.c-torture/execute/cbrt.c compilation,  -O3 -g  (internal compiler

error)

FAIL: gcc.c-torture/execute/pr33870-1.c compilation,  -O3 -fomit-frame-pointer 

(internal compiler error)

FAIL: gcc.c-torture/execute/pr33870-1.c compilation,  -O3 -fomit-frame-pointer

-funroll-all-loops -finline-functions  (internal compiler error)

FAIL: gcc.c-torture/execute/pr33870-1.c compilation,  -O3 -fomit-frame-pointer

-funroll-loops  (internal compiler error)

FAIL: gcc.c-torture/execute/pr33870-1.c compilation,  -O3 -g  (internal

compiler error)

FAIL: gcc.c-torture/execute/pr33870.c compilation,  -O3 -fomit-frame-pointer 

(internal compiler error)

FAIL: gcc.c-torture/execute/pr33870.c compilation,  -O3 -fomit-frame-pointer

-funroll-all-loops -finline-functions  (internal compiler error)

FAIL: gcc.c-torture/execute/pr33870.c compilation,  -O3 -fomit-frame-pointer

-funroll-loops  (internal compiler error)

FAIL: gcc.c-torture/execute/pr33870.c compilation,  -O3 -g  (internal compiler

error)

FAIL: gcc.c-torture/unsorted/bad.c,  -O3 -fomit-frame-pointer   (internal

compiler error)

FAIL: gcc.c-torture/unsorted/bad.c,  -O3 -g   (internal compiler error)

FAIL: gcc.dg/vect/pr43842.c (internal compiler error)

FAIL: gcc.dg/vect/pr43842.c (test for excess errors)

FAIL: gfortran.dg/bounds_check_9.f90  -O3 -fomit-frame-pointer  (internal

compiler error)

FAIL: gfortran.dg/bounds_check_9.f90  -O3 -fomit-frame-pointer  (test for

excess errors)

FAIL: gfortran.dg/bounds_check_9.f90  -O3 -fomit-frame-pointer

-funroll-all-loops -finline-functions  (internal compiler error)

FAIL: gfortran.dg/bounds_check_9.f90  -O3 -fomit-frame-pointer

-funroll-all-loops -finline-functions  (test for excess errors)

FAIL: gfortran.dg/bounds_check_9.f90  -O3 -fomit-frame-pointer -funroll-loops 

(internal compiler error)

FAIL: gfortran.dg/bounds_check_9.f90  -O3 -fomit-frame-pointer -funroll-loops 

(test for excess errors)

FAIL: gfortran.dg/bounds_check_9.f90  -O3 -g  (internal compiler error)

FAIL: gfortran.dg/bounds_check_9.f90  -O3 -g  (test for excess errors)

FAIL: gfortran.dg/bounds_check_fail_2.f90  -O3 -fomit-frame-pointer  (internal

compiler error)

FAIL: gfortran.dg/bounds_check_fail_2.f90  -O3 -fomit-frame-pointer  (test for

excess errors)

FAIL: gfortran.dg/bounds_check_fail_2.f90  -O3 -fomit-frame-pointer

-funroll-all-loops -finline-functions  (internal compiler error)

FAIL: gfortran.dg/bounds_check_fail_2.f90  -O3 -fomit-frame-pointer

-funroll-all-loops -finline-functions  (test for excess errors)

FAIL: gfortran.dg/bounds_check_fail_2.f90  -O3 -fomit-frame-pointer

-funroll-loops  (internal compiler error)

FAIL: gfortran.dg/bounds_check_fail_2.f90  -O3 -fomit-frame-pointer

-funroll-loops  (test for excess errors)

FAIL: gfortran.dg/bounds_check_fail_2.f90  -O3 -g  (internal compiler error)

FAIL: gfortran.dg/bounds_check_fail_2.f90  -O3 -g  (test for excess errors)

[Bug libstdc++/48257] std::string::assign() corrupts std::string static data when called on emptyString1 using emptyString2.data()

[mohsinrzaidi at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257



--- Comment #10 from Mohsin  2011-03-24 10:21:56 
UTC ---

Two questions here:



1. Is the behaviour undefined for __n < number of elements in __s?



2. For cases undefined in the specs, do we take steps to ensure robustness? I

still cannot digest that a programmer error could corrupt std::string static

memory.

[Bug libstdc++/48257] std::string::assign() corrupts std::string static data when called on emptyString1 using emptyString2.data()

[mohsinrzaidi at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257



--- Comment #11 from Mohsin  2011-03-24 10:24:15 
UTC ---

(In reply to comment #10)

> Two questions here:

> 

> 1. Is the behaviour undefined for __n < number of elements in __s?

>



Oops! I meant for __n >  number of elements in __s. 



>

> 2. For cases undefined in the specs, do we take steps to ensure robustness? I

> still cannot digest that a programmer error could corrupt std::string static

> memory.

[Bug middle-end/48269] Incorrect fortify warning for a packed struct member

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48269



--- Comment #3 from Richard Guenther  2011-03-24 
10:43:29 UTC ---

  D.83064_56 = in_int_3(D)->strong_source;

  D.83065_57 = D.83064_56->_vptr.KisPacketSource;

  D.83086_59 = MEM[(int (*__vtbl_ptr_type) (void) *)D.83065_57 + 92B];

  D.73136 = OBJ_TYPE_REF(D.83086_59;D.83064_56->23) (D.83064_56); [return slot

optimization]

  D.83087_61 = std::basic_string::c_str (&D.73136);

  D.83088_63 = &MEM[(struct drone_source_packet *)dpkt_1 + 12B].interface_str;

  __s_143 = (char * restrict) D.83088_63;

  D.85546_145 = 16;

  __builtin___snprintf_chk (__s_143, 16, 1, D.85546_145, "%s", D.83087_61);

  std::basic_string::~basic_string (&D.73136);

  D.83064_65 = in_int_3(D)->strong_source;

  D.83065_66 = D.83064_65->_vptr.KisPacketSource;

  D.83090_68 = MEM[(int (*__vtbl_ptr_type) (void) *)D.83065_66 + 96B];

  D.73137 = OBJ_TYPE_REF(D.83090_68;D.83064_65->24) (D.83064_65); [return slot

optimization]

  D.83091_70 = std::basic_string::c_str (&D.73137);

  D.83092_72 = &MEM[(struct drone_source_packet *)dpkt_1 + 12B].type_str;

  __s_147 = (char * restrict) D.83092_72;

  D.85552_149 = 9;

  __builtin___snprintf_chk (__s_147, 16, 1, D.85552_149, "%s", D.83091_70);





so for some reason we compute the object size of *D.38092_72 as 9.  We

allocated

dpkt_1 as



  dpkt_1 = malloc (89);



which looks like enough.



C testcase:



typedef struct {

unsigned int sentinel;

char data[0];

} drone_packet;

typedef struct {

char type_str[16];

char channel_hop;

} drone_source_packet;

drone_packet *

foo(char *x)

{

  drone_packet *dpkt = __builtin_malloc(sizeof(drone_packet)

+ sizeof(drone_source_packet));

  drone_source_packet *spkt = (drone_source_packet *) dpkt->data;

  __builtin___snprintf_chk (spkt->type_str, 16, 

1, __builtin_object_size (spkt->type_str, 1), 

"%s", x);

  return dpkt;

}

[Bug middle-end/48269] [4.6 Regression] Incorrect fortify warning for a packed struct member

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48269



Richard Guenther  changed:



   What|Removed |Added



   Keywords||diagnostic

   Target Milestone|--- |4.6.1

Summary|Incorrect fortify warning   |[4.6 Regression] Incorrect

   |for a packed struct member  |fortify warning for a

   ||packed struct member

[Bug c++/48268] Incomplete Type (seems auto/c++0x specific)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48268



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||paolo.carlini at oracle dot

   ||com

  Known to work||4.6.0, 4.7.0

 Resolution||WORKSFORME



--- Comment #2 from Paolo Carlini  2011-03-24 
10:56:29 UTC ---

Indeed, 4_6-branch is also fine.

[Bug middle-end/48269] [4.6 Regression] Incorrect fortify warning for a packed struct member

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48269



Richard Guenther  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2011.03.24 11:14:23

 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #4 from Richard Guenther  2011-03-24 
11:14:23 UTC ---

I have a patch.

gcc-bugs@gcc.gnu.org

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46562



--- Comment #5 from Richard Guenther  2011-03-24 
11:23:34 UTC ---

Author: rguenth

Date: Thu Mar 24 11:23:29 2011

New Revision: 171386



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171386

Log:

2011-03-24  Richard Guenther  



PR tree-optimization/46562

* tree.c (build_invariant_address): New function.

* tree.h (build_invariant_address): Declare.

* tree-dfa.c (get_addr_base_and_unit_offset): Wrap around

a renamed function moved ...

* tree-flow-inline.h (get_addr_base_and_unit_offset_1): ... here.

Take valueization callback parameter.

* tree-flow.h (gimple_fold_stmt_to_constant): Declare.

* gimple-fold.h: New file.

* tree-ssa-ccp.c (ccp_fold): Use gimple_fold_stmt_to_constant_1.

(ccp_fold, fold_const_aggregate_ref,

fold_ctor_reference, fold_nonarray_ctor_reference,

fold_array_ctor_reference, fold_string_cst_ctor_reference,

get_base_constructor): Move ...

* gimple-fold.c: ... here.

(gimple_fold_stmt_to_constant_1): New function

split out from ccp_fold.  Take a valueization callback parameter.

Valueize all operands.

(gimple_fold_stmt_to_constant): New wrapper function.

(fold_const_aggregate_ref_1): New function split out from

fold_const_aggregate_ref.  Take a valueization callback parameter.

(fold_const_aggregate_ref): Wrap fold_const_aggregate_ref_1.

* tree-ssa-sccvn.c (simplify_binary_expression): Simplify

invariant POINTER_PLUS_EXPRs to invariant form.

(vn_valueize): New function.

(try_to_simplify): Simplify by using gimple_fold_stmt_to_constant.

* tree-vrp.c (vrp_valueize): New function.

(vrp_visit_assignment_or_call): Use gimple_fold_stmt_to_constant

to fold statements to constants.

* tree-ssa-pre.c (eliminate): Properly guard propagation of

function declarations.

* Makefile.in (tree-ssa-sccvn.o, tree-vrp.o, gimple-fold.o,

tree-ssa-ccp.o): Add gimple-fold.h dependencies.



* c-c++-common/pr46562-2.c: New testcase.

* c-c++-common/pr46562.c: Likewise.



Added:

trunk/gcc/gimple-fold.h

trunk/gcc/testsuite/c-c++-common/pr46562-2.c

trunk/gcc/testsuite/c-c++-common/pr46562.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/Makefile.in

trunk/gcc/gimple-fold.c

trunk/gcc/ipa-split.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-dfa.c

trunk/gcc/tree-flow-inline.h

trunk/gcc/tree-flow.h

trunk/gcc/tree-ssa-ccp.c

trunk/gcc/tree-ssa-pre.c

trunk/gcc/tree-ssa-sccvn.c

trunk/gcc/tree-vrp.c

trunk/gcc/tree.c

trunk/gcc/tree.h

[Bug libstdc++/48257] std::string::assign() corrupts std::string static data when called on emptyString1 using emptyString2.data()

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257



--- Comment #12 from Jonathan Wakely  2011-03-24 
11:27:44 UTC ---

(In reply to comment #11)

> (In reply to comment #10)

> > Two questions here:

> > 

> > 1. Is the behaviour undefined for __n < number of elements in __s?

> >

> 

> Oops! I meant for __n >  number of elements in __s. 



Yes!  The standard defines the behaviour of string::assign when s contains at

least n elements. When that precondition isn't met the definition doesn't apply

i.e. it's undefined.





> > 2. For cases undefined in the specs, do we take steps to ensure robustness? 



Where possible, yes, that's what -D_GLIBCXX_DEBUG tries to do.  But in general

it's not possible to verify that the supplied string meets the required length.

Given a const char*, how do you tell if it points to an array of at least n

chars?  You can't.



It would be possible to check that the supplied const char* is not the shared

static "empty string" representation, but that would add overhead and still

wouldn't prevent similar errors like:



  string s("oops", 999);



> > I

> > still cannot digest that a programmer error could corrupt std::string static

> > memory.



Really?  A sufficiently malicious/careless programmer can corrupt pretty much

anything!



In any case, if you try your original example with current releases it doesn't

print '4'

[Bug middle-end/48270] [4.7 Regression] New test failures

[irar at il dot ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48270



Ira Rosen  changed:



   What|Removed |Added



 CC||irar at il dot ibm.com



--- Comment #1 from Ira Rosen  2011-03-24 11:45:28 UTC 
---

I can't reproduce these failures on x86_64-suse-linux.



Ira

[Bug c++/44500] [C++0x] Bogus narrowing conversion error

[gpiez at web dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500



--- Comment #18 from Gunther Piez  2011-03-24 11:45:47 UTC 
---

I have chosen the "recommended" way and added a cast, -fpermissive would allow

to many other dubious constructs to pass. Still I think c++ should get rid of

implicit integer conversions :-)

gcc-bugs@gcc.gnu.org

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46562



Richard Guenther  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.7.0



--- Comment #6 from Richard Guenther  2011-03-24 
11:59:40 UTC ---

Fixed.

[Bug middle-end/48270] [4.7 Regression] New test failures

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48270



Richard Guenther  changed:



   What|Removed |Added



 Target||i?86-*-*

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2011.03.24 12:01:03

   Target Milestone|--- |4.7.0

 Ever Confirmed|0   |1



--- Comment #2 from Richard Guenther  2011-03-24 
12:01:03 UTC ---

Confirmed with -m32 testing on x86_64-linux.  HJ, instead of saying Linux/x86

please fill in the target field (x86 is at least now ambiguous).

[Bug c++/48266] deprecated("message") fails to print message

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48266



Richard Guenther  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2011.03.24 12:04:24

 Ever Confirmed|0   |1

   Severity|minor   |enhancement



--- Comment #1 from Richard Guenther  2011-03-24 
12:04:24 UTC ---

I think the optional message is only supported by the C frontend at

the moment.

[Bug middle-end/48270] [4.7 Regression] New test failures

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48270



H.J. Lu  changed:



   What|Removed |Added



 Status|NEW |UNCONFIRMED

   Target Milestone|4.7.0   |---

 Ever Confirmed|1   |0



--- Comment #3 from H.J. Lu  2011-03-24 12:10:58 
UTC ---

(In reply to comment #2)

> Confirmed with -m32 testing on x86_64-linux.  HJ, instead of saying Linux/x86

> please fill in the target field (x86 is at least now ambiguous).



It failed for me with both -m32/-m64.  That is what I meant by Linux/x86.

Valgrind reports:



==32103== Invalid read of size 1

==32103==at 0x935283: tree_ssa_phiopt_worker (tree-ssa-phiopt.c:1512)

==32103==by 0x7AE895: execute_one_pass (passes.c:1554)

==32103==by 0x7AEB74: execute_pass_list (passes.c:1609)

==32103==by 0x7AEB86: execute_pass_list (passes.c:1610)

==32103==by 0x8A6345: tree_rest_of_compilation (tree-optimize.c:422)

==32103==by 0xA4D7E9: cgraph_expand_function (cgraphunit.c:1576)

==32103==by 0xA4FF19: cgraph_optimize (cgraphunit.c:1635)

==32103==by 0xA50499: cgraph_finalize_compilation_unit (cgraphunit.c:1096)

==32103==by 0x77080C: write_global_declarations (langhooks.c:303)

==32103==by 0x84F1AD: toplev_main (toplev.c:591)

==32103==by 0x37CCA1EDDC: (below main) (in /lib64/libc-2.13.so)

==32103==  Address 0xc97df98 is 24 bytes inside a block of size 112 free'd

==32103==at 0x4A05187: free (vg_replace_malloc.c:325)

==32103==by 0x875BF4: free_data_refs (tree-data-ref.c:4671)

==32103==by 0x935205: tree_ssa_phiopt_worker (tree-ssa-phiopt.c:1497)

==32103==by 0x7AE895: execute_one_pass (passes.c:1554)

==32103==by 0x7AEB74: execute_pass_list (passes.c:1609)

==32103==by 0x7AEB86: execute_pass_list (passes.c:1610)

==32103==by 0x8A6345: tree_rest_of_compilation (tree-optimize.c:422)

==32103==by 0xA4D7E9: cgraph_expand_function (cgraphunit.c:1576)

==32103==by 0xA4FF19: cgraph_optimize (cgraphunit.c:1635)

==32103==by 0xA50499: cgraph_finalize_compilation_unit (cgraphunit.c:1096)

[Bug middle-end/48267] incorrect signed overflow warning when a pointer cannot possibly overflow

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48267



Richard Guenther  changed:



   What|Removed |Added



   Keywords||diagnostic

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2011.03.24 12:14:46

  Component|c   |middle-end

 Ever Confirmed|0   |1

  Known to fail||4.5.2, 4.7.0



--- Comment #1 from Richard Guenther  2011-03-24 
12:14:46 UTC ---

Confirmed.  Happens from



#1  0x007307e7 in fold_undefer_overflow_warnings (issue=1 '\001', 

stmt=0x75b373c0, code=2)

at /space/rguenther/src/svn/trunk/gcc/fold-const.c:281

281   warning_at (locus, OPT_Wstrict_overflow, "%s", warnmsg);

(gdb) 

#2  0x00afdfdf in evaluate_stmt (stmt=0x75b373c0)

at /space/rguenther/src/svn/trunk/gcc/tree-ssa-ccp.c:2117

2117  fold_undefer_overflow_warnings (is_constant, stmt, 0);

(gdb)

#3  0x00aff7c5 in visit_cond_stmt (stmt=0x75b373c0, 

taken_edge_p=0x7fffda48)

at /space/rguenther/src/svn/trunk/gcc/tree-ssa-ccp.c:2443

2443  val = evaluate_stmt (stmt);

(gdb) 

#4  0x00aff8f8 in ccp_visit_stmt (stmt=0x75b373c0, 

taken_edge_p=0x7fffda48, output_p=0x7fffda40)

at /space/rguenther/src/svn/trunk/gcc/tree-ssa-ccp.c:2501

2501return visit_cond_stmt (stmt, taken_edge_p);



(gdb) call debug_gimple_stmt (stmt)

if (p_1 < &head_table[1])



which calls fold_binary with &head_table < &head_table[1] and in the end warns

here:



8688  if (code != EQ_EXPR

8689  && code != NE_EXPR

8690  && bitpos0 != bitpos1

8691  && (pointer_may_wrap_p (base0, offset0, bitpos0)

8692  || pointer_may_wrap_p (base1, offset1, bitpos1)))

8693fold_overflow_warning (("assuming pointer wraparound

does not "

8694"occur when comparing P +- C1

with "

8695"P +- C2"),

8696  

WARN_STRICT_OVERFLOW_CONDITIONAL)



because we call pointer_may_wrap_p with base0 which isn't an address

but an object which is bogus.  It's argument has to depend on

indirect_base in which case we stripped an ADDR_EXPR.

[Bug c++/48265] [4.6/4.7 Regression] [C++0x] ICE: SIGSEGV (recursion in value_dependent_expression_p) when variable is used uninitialised

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48265



Richard Guenther  changed:



   What|Removed |Added



   Target Milestone|--- |4.6.1

[Bug c/48264] Simple dummy program fails with Segmentation Fault upon -shared linking

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48264



Richard Guenther  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #2 from Richard Guenther  2011-03-24 
12:17:05 UTC ---

I guess you want to use -fpie instead.

[Bug middle-end/48270] [4.7 Regression] New test failures

[irar at il dot ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48270



--- Comment #4 from Ira Rosen  2011-03-24 12:18:28 UTC 
---

I tried -m32 too, but I don't see any failures.

[Bug tree-optimization/48271] New: ICE: SIGSEGV in tree_ssa_dominator_optimize (tree-ssa-dom.c:2964) with -O -ftree-vrp -fno-guess-branch-probability -fnon-call-exceptions

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48271



   Summary: ICE: SIGSEGV in tree_ssa_dominator_optimize

(tree-ssa-dom.c:2964) with -O -ftree-vrp

-fno-guess-branch-probability -fnon-call-exceptions

   Product: gcc

   Version: 4.7.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: zso...@seznam.cz

  Host: x86_64-pc-linux-gnu

Target: x86_64-pc-linux-gnu





Created attachment 23767

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23767

reduced testcase



Compiler output:

$ gcc -O -ftree-vrp -fno-guess-branch-probability -fnon-call-exceptions

testcase.C

==32527== Invalid read of size 8

==32527==at 0xAE00C0: tree_ssa_dominator_optimize (tree-ssa-dom.c:2964)

==32527==by 0x948AC5: execute_one_pass (passes.c:1556)

==32527==by 0x948DB4: execute_pass_list (passes.c:1611)

==32527==by 0x948DC6: execute_pass_list (passes.c:1612)

==32527==by 0xA8D345: tree_rest_of_compilation (tree-optimize.c:422)

==32527==by 0xC5D7A1: cgraph_expand_function (cgraphunit.c:1576)

==32527==by 0xC5FEF9: cgraph_optimize (cgraphunit.c:1635)

==32527==by 0xC60479: cgraph_finalize_compilation_unit (cgraphunit.c:1096)

==32527==by 0x5B8137: cp_write_global_declarations (decl2.c:4000)

==32527==by 0xA35707: toplev_main (toplev.c:591)

==32527==by 0x6445B6C: (below main) (in /lib64/libc-2.11.3.so)

==32527==  Address 0x8 is not stack'd, malloc'd or (recently) free'd

==32527== 

testcase.C: In function 'void stCheckReverseTrain()':

testcase.C:113:6: internal compiler error: Segmentation fault

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.



Tested revisions:

r171337 - crash

4.6 r170955 - OK

4.5 r170955 - crash

4.4 r170955 - OK

[Bug middle-end/48270] [4.7 Regression] New test failures

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48270



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed|2011-03-24 12:01:03 |2011.03.24 12:23:03

 Ever Confirmed|0   |1



--- Comment #5 from Dominique d'Humieres  2011-03-24 
12:23:03 UTC ---

Confirmed on x86_64-apple-darwin10.7.0 with both -m32 and -m64. There is no ICE

at revision 171364 and the only candidate for the regression is revision

171381.

[Bug lto/48259] Internal compiler errors in lto1

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48259



Richard Guenther  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2011.03.24 12:24:22

 Ever Confirmed|0   |1



--- Comment #2 from Richard Guenther  2011-03-24 
12:24:22 UTC ---

At least LTOing libstdc++ should work, I'm not sure about libgcc, but if

no functions of libgcc end up being used it shouldn't break.



Hm, I can't reproduce it with 4.6.



rguenther@murzim:/tmp> g++-4.6 -flto -O2 1.C 2.C 3.s

rguenther@murzim:/tmp> g++-4.6 -flto -O2 1.C 2.C 3.s -fno-use-linker-plugin

rguenther@murzim:/tmp> g++-4.6 -flto -O2 1.C 2.C 3.s -fuse-linker-plugin

rguenther@murzim:/tmp> g++-4.6 -flto -O2 1.C 2.C 3.s -flto-partition=none

rguenther@murzim:/tmp> 



nor with trunk.  Can you be more specific about what linker you use?  Maybe

show -v output of a failing compile?

[Bug tree-optimization/48271] ICE: SIGSEGV in tree_ssa_dominator_optimize (tree-ssa-dom.c:2964) with -O -ftree-vrp -fno-guess-branch-probability -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48271



Richard Guenther  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2011.03.24 12:34:35

 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from Richard Guenther  2011-03-24 
12:34:35 UTC ---

Program received signal SIGSEGV, Segmentation fault.

0x00d8ad0f in single_succ_p (bb=0x0)

at /space/rguenther/src/svn/trunk/gcc/basic-block.h:545

545   return EDGE_COUNT (bb->succs) == 1;

(gdb) up

#1  0x00d8a8c9 in tree_ssa_dominator_optimize ()

at /space/rguenther/src/svn/trunk/gcc/tree-ssa-dom.c:737

737   if (single_succ_p (bb) == 1



so it seems the CFG is not in the same state as it was when setting that

bit.  Which seems sort-of obvious as we thread jumps before doing this

cleanup.  I suppose simply checking for the existance of the block is

enough.



I have such a patch.

[Bug middle-end/48270] [4.7 Regression] New test failures

[irar at il dot ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48270



--- Comment #6 from Ira Rosen  2011-03-24 12:36:18 UTC 
---

My guess is that I freed data-refs too early. Could someone please check if

this patch fixes the failures:



Index: tree-ssa-phiopt.c

===

--- tree-ssa-phiopt.c   (revision 171384)

+++ tree-ssa-phiopt.c   (working copy)

@@ -1494,8 +1494,6 @@ cond_if_else_store_replacement (basic_bl

   else_ddrs = VEC_alloc (ddr_p, heap, 1);

   compute_all_dependences (then_datarefs, &then_ddrs, NULL, false);

   compute_all_dependences (else_datarefs, &else_ddrs, NULL, false);

-  free_data_refs (then_datarefs);

-  free_data_refs (else_datarefs);

   blocks[0] = then_bb;

   blocks[1] = else_bb;

   blocks[2] = join_bb;

@@ -1517,6 +1515,8 @@ cond_if_else_store_replacement (basic_bl

 {

   free_dependence_relations (then_ddrs);

   free_dependence_relations (else_ddrs);

+  free_data_refs (then_datarefs);

+  free_data_refs (else_datarefs);

   VEC_free (gimple, heap, then_stores);

   VEC_free (gimple, heap, else_stores);

   return false;

@@ -1539,6 +1539,8 @@ cond_if_else_store_replacement (basic_bl

 {

   free_dependence_relations (then_ddrs);

   free_dependence_relations (else_ddrs);

+  free_data_refs (then_datarefs);

+  free_data_refs (else_datarefs);

   VEC_free (gimple, heap, then_stores);

   VEC_free (gimple, heap, else_stores);

   return false;

@@ -1558,6 +1560,8 @@ cond_if_else_store_replacement (basic_bl

   free_dependence_relations (else_ddrs);

   VEC_free (gimple, heap, then_stores);

   VEC_free (gimple, heap, else_stores);

+  free_data_refs (then_datarefs);

+  free_data_refs (else_datarefs);



   return ok;

 }



Thanks,

Ira

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245



--- Comment #19 from Iain Sandoe  2011-03-24 12:40:52 
UTC ---

AFAICT, comment #12 is OK on *-darwin9 including cross-cris-elf.

given that Mike has approved, 

if someone could chip in with a test on x86-64-darwin10, I would think you

could apply it.

[Bug middle-end/48272] New: internal compiler error: in setup_insn_reg_pressure_info, at haifa-sched.c:1124

[sebastian.heg...@tu-dresden.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48272

   Summary: internal compiler error: in
setup_insn_reg_pressure_info, at haifa-sched.c:1124
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.heg...@tu-dresden.de
  Host: ia64-unknown-linux-gnu
Target: ia64-unknown-linux-gnu
 Build: ia64-unknown-linux-gnu


Created attachment 23768
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23768
The preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, compressed with gzip.

I am trying to compile boost v1.44.0 ("www.boost.org") library on IA-64, which
fails with:

libs/iostreams/src/zlib.cpp: In member function
‘boost::iostreams::zlib_error::zlib_error(int)’:
libs/iostreams/src/zlib.cpp:72:7: internal compiler error: in
setup_insn_reg_pressure_info, at haifa-sched.c:1124

I'm seeing this popping up several times, so I'll only report the first
occurence.


Terminal output:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/h0/radar-08/modules-ia64/gcc/4.6.0/bin/../libexec/gcc/ia64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: ia64-unknown-linux-gnu
Configured with: ../gcc-4.6.0/configure
--prefix=/home/radar-08/modules-ia64/gcc/4.6.0
--with--mpfr=/home/radar-08/modules-ia64/gcc/4.6.0
--with-gmp=/home/radar-08/modules-ia64/gcc/4.6.0
--with-mpc=/home/radar-08/modules-ia64/gcc/4.6.0
--with-libelf=/home/radar-08/modules-ia64/gcc/4.6.0 --enable-lto --enable-gold
--enable-bootstrap --enable-build-with-cxx
Thread model: posix
gcc version 4.6.0 20110323 (prerelease) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-ftemplate-depth=128' '-O3' '-fopenmp'
'-O3' '-fno-signed-zeros' '-fno-trapping-math' '-fassociative-math'
'-freciprocal-math' '-fpeel-loops' '-fipa-pta' '-flto' '-fsched-pressure'
'-fgcse-sm' '-fgcse-las' '-fgcse-after-reload' '-falign-functions=16'
'-fgraphite-identity' '-fivopts' '-ftree-sra' '-ftracer' '-funroll-loops'
'-fvariable-expansion-in-unroller' '-ftree-loop-ivcanon'
'-ftree-loop-distribution' '-floop-interchange' '-floop-strip-mine'
'-floop-block' '-ftree-loop-im' '-ftree-vectorize' '-ftree-slp-vectorize'
'-ftree-vectorizer-verbose=1' '-finline' '-fearly-inlining'
'-findirect-inlining' '-finline-functions-called-once' '-finline-limit=10'
'--param' 'large-function-growth=1' '--param' 'inline-unit-growth=1'
'-finline-functions' '-Wno-inline' '-Wall' '-pthread' '-fPIC' '-D'
'BOOST_ALL_NO_LIB=1' '-D' 'BOOST_IOSTREAMS_DYN_LINK=1' '-D'
'BOOST_IOSTREAMS_USE_DEPRECATED' '-D' 'NDEBUG' '-I' '.' '-c' '-o'
'bin.v2/libs/iostreams/build/gcc-4.6.0/release/threading-multi/zlib.o'
'-shared-libgcc' '-pthread'

/home/h0/radar-08/modules-ia64/gcc/4.6.0/bin/../libexec/gcc/ia64-unknown-linux-gnu/4.6.0/cc1plus
-E -quiet -v -I . -iprefix
/home/h0/radar-08/modules-ia64/gcc/4.6.0/bin/../lib/gcc/ia64-unknown-linux-gnu/4.6.0/
-D_GNU_SOURCE -D_REENTRANT -D BOOST_ALL_NO_LIB=1 -D BOOST_IOSTREAMS_DYN_LINK=1
-D BOOST_IOSTREAMS_USE_DEPRECATED -D NDEBUG libs/iostreams/src/zlib.cpp
-Wno-inline -Wall -ftemplate-depth=128 -fopenmp -fno-signed-zeros
-fno-trapping-math -fassociative-math -freciprocal-math -fpeel-loops -fipa-pta
-flto -fsched-pressure -fgcse-sm -fgcse-las -fgcse-after-reload
-falign-functions=16 -fgraphite-identity -fivopts -ftree-sra -ftracer
-funroll-loops -fvariable-expansion-in-unroller -ftree-loop-ivcanon
-ftree-loop-distribution -floop-interchange -floop-strip-mine -floop-block
-ftree-loop-im -ftree-vectorize -ftree-slp-vectorize
-ftree-vectorizer-verbose=1 -finline -fearly-inlining -findirect-inlining
-finline-functions-called-once -finline-limit=10 -finline-functions -fPIC
-O3 -O3 -fpch-preprocess -o zlib.ii
ignoring nonexistent directory
"/home/h0/radar-08/modules-ia64/gcc/4.6.0/bin/../lib/gcc/ia64-unknown-linux-gnu/4.6.0/../../../../ia64-unknown-linux-gnu/include"
ignoring duplicate directory
"/home/h0/radar-08/modules-ia64/gcc/4.6.0/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0"
ignoring duplicate directory
"/home/h0/radar-08/modules-ia64/gcc/4.6.0/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/ia64-unknown-linux-gnu"
ignoring duplicate directory
"/home/h0/radar-08/modules-ia64/gcc/4.6.0/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/backward"
ignoring duplicate directory
"/home/h0/radar-08/modules-ia64/gcc/4.6.0/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.6.0/include"
ignoring duplicate directory
"/home/h0/radar-08/modules-ia64/gcc/4.6.0/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.6.0/include-fixed"
ignoring nonexistent directory
"/home/h0/radar-08/modules-ia64/gcc/4.6.0/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.6.0/../../..

[Bug middle-end/48269] [4.6 Regression] Incorrect fortify warning for a packed struct member

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48269



--- Comment #5 from Richard Guenther  2011-03-24 
12:45:02 UTC ---

Author: rguenth

Date: Thu Mar 24 12:44:58 2011

New Revision: 171388



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171388

Log:

2011-03-24  Richard Guenther  



PR middle-end/48269

* tree-object-size.c (addr_object_size): Do not double-account

for MEM_REF offsets.



* gcc.dg/builtin-object-size-10.c: New testcase.



Added:

trunk/gcc/testsuite/gcc.dg/builtin-object-size-10.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-object-size.c

[Bug middle-end/48272] internal compiler error: in setup_insn_reg_pressure_info, at haifa-sched.c:1124

[sebastian.heg...@tu-dresden.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48272



--- Comment #1 from sebastian.heg...@tu-dresden.de 2011-03-24 12:46:54 UTC ---

Compiles fine when leaving out "-fsched-pressure"

[Bug middle-end/48270] [4.7 Regression] New test failures

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48270



--- Comment #7 from Richard Guenther  2011-03-24 
12:49:13 UTC ---

I'm testing this patch.

[Bug target/48273] New: [4.6/4.7 Regression] ICE: in create_copy_of_insn_rtx, at sel-sched-ir.c:5604 with -fsel-sched-pipelining -fselective-scheduling2 -march=core2

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48273



   Summary: [4.6/4.7 Regression] ICE: in create_copy_of_insn_rtx,

at sel-sched-ir.c:5604 with -fsel-sched-pipelining

-fselective-scheduling2 -march=core2

   Product: gcc

   Version: 4.7.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: zso...@seznam.cz

  Host: x86_64-pc-linux-gnu

Target: x86_64-pc-linux-gnu





Created attachment 23769

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23769

reduced testcase



Compiler output:

$ gcc -O -fschedule-insns2 -fsel-sched-pipelining -fselective-scheduling2

-funroll-all-loops -march=core2 testcase.C

testcase.C: In function 'void foo()':

testcase.C:7:1: internal compiler error: in create_copy_of_insn_rtx, at

sel-sched-ir.c:5604

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.



Tested revisions:

r171337 - crash

4.6 r170955 - crash

4.5 r170955 - crash

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[david.kirkby at onetel dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072



--- Comment #16 from Dr. David Kirkby  
2011-03-24 13:22:28 UTC ---

(In reply to comment #15)

> Let me try and recap.

> 

> The initial report was that 5.3 TL10 did *not* have the error.  I discovered

> that 5.3 TL10 SP03 does.  See [1].

> 

> APAR IZ81343[2] and its sister APARs addresses this issue.  It is shipped (for

> example) in 5.3 TL10 SP05 as IZ81339.

> 

> After you apply that APAR, you get a new issue where the linker now spews out:

> 

> ld: 0711-596 SEVERE ERROR: Object expand.o

> An RLD for section 2 (.data) refers to symbol 852,

> but the storage class of the symbol is not C_EXT or C_HIDEXT.



This is odd. I have 



-bash-4.1$ oslevel -rq

Known Recommended Maintenance Levels



5300-12

5300-11

5300-10

5300-09

5300-08

5300-07

5300-06

5300-05

5300-04

5300-03

5300-02

5300-01

5300-00



and whilst I can't see how to get the information on the service pack, I have

service pack 2. 



https://www-304.ibm.com/support/docview.wss?uid=isg1IZ83065



dated 17th Jan 2011. 



So why am I getting the error on this bug report (ld: 0711-593 SEVERE ERROR:

Symbol C_BSTAT) and not ld: 0711-596 SEVERE ERROR? 



If I understand you correctly, you are saying ld: 0711-593 SEVERE ERROR: Symbol

C_BSTAT) was fixed in AIX 5.3 5300-10 Service Pack 3, which is dated March 24,

2010



https://www-304.ibm.com/support/docview.wss?uid=isg1SSRVAIX53TL10071505_161



That is some 10 months prior to the service pack I have. 



I suspect I am mis-understanding something. 



I'm using a 32-bit RS/6000 7025 F50, with 4 x 332 MHz CPUs, 3 GB RAM, which I

know is an antique in computer terms. 



Dave

[Bug target/48237] [4.6/4.7 Regression] ICE: in final_scan_insn, at final.c:2651 with -fselective-scheduling2 -mtune=core2

[uros at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48237



--- Comment #2 from uros at gcc dot gnu.org 2011-03-24 13:35:30 UTC ---

Author: uros

Date: Thu Mar 24 13:35:26 2011

New Revision: 171391



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171391

Log:

PR target/48237

* config/i386/i386.md (*movdf_internal_rex64): Do not split

alternatives that can be handled with movq or movabsq insn.

(*movdf_internal): Disable for !TARGET_64BIT.

(*movdf_internal_nointeger): Ditto.

* config/i386/i386.c (ix86_print_operand): Handle DFmode immediates.



testsuite/ChangeLog:



PR target/48237

* gcc.target/i386/pr48237.c: New test.





Added:

trunk/gcc/testsuite/gcc.target/i386/pr48237.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/i386/i386.c

trunk/gcc/config/i386/i386.md

trunk/gcc/testsuite/ChangeLog

[Bug c/48274] New: C frontend emit invalid promotions

[matz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48274

   Summary: C frontend emit invalid promotions
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org


This came up in the context of a stricter consistency checker for types in
our middle end.  I believe the C frontend emits invalid promotions for calls
to prototyped functions:

% cat x.c
unsigned passchar (char c);
unsigned passflt (float f);
unsigned passva (int i, ...);
char blachar (char c, float f)
{
  return passchar (c) + passflt (f) + passva(1, f);
}
% ./cc1 x.c -fdump-tree-original
% cat x.c.003t.original
;; Function blachar (null)
;; enabled by -tree-original
{
  return (char) (((unsigned char) passchar ((int) c) + (unsigned char) passflt
(f)) + (unsigned char) passva (1, (double) f));
}

The emitted code doesn't depend on the -std=xxx setting.  What I believe
is invalid here is the call to passchar().  First, it's a prototyped
function, hence 6.5.2.2 #7 is invoked:

#7: ... the arguments are implicitly converted, as if by assignment, to the
types of the corresponding parameters, taking the type of each parameter
to be the unqualified version of its declared type. The ellipsis notation
...

Hence, as if by assignment.  types of assignment expressions is that of the
left operand after lvalue conversions.  In this case the left operand is
the corresponding parameter (char c), hence I don't think there's much
leeway to read this as actually passing an 'int'.

This sort of looks as if the argument passer applies either default argument
promotions (6.5.2.2 #6, but that would mean it also had to promote the
float in passflt() call to double), or integer promotions (which would be
completely off) to arguments for calls to prototyped functions.

[Bug c/48274] C frontend emit invalid promotions

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48274



--- Comment #1 from joseph at codesourcery dot com  2011-03-24 14:01:18 UTC ---

Does the target in question define TARGET_PROMOTE_PROTOTYPES to return 

true?  If so, the front end is behaving as requested by the target - while 

it would be better for this to be implemented as a lowering phase some 

time after the front end is finished, to the extent that the hook 

represents meaningful ABI or optimization information, that's not the 

internal interface at present.

[Bug target/48262] [4.7 Regression] Subversion id 171341 breaks various vectorization files on powerpc

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48262



--- Comment #9 from Dominique d'Humieres  2011-03-24 
14:16:54 UTC ---

On powerpc-apple-darwin9, all the tests ran by vect.exp pass with the patches

in comments #5 and #6 on top of revision 171367.

[Bug target/42949] ICE: reload_cse_simplify_operands, at postreload.c:396

[ibolton at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42949



Ian Bolton  changed:



   What|Removed |Added



 Status|NEW |WAITING

 CC||ibolton at gcc dot gnu.org



--- Comment #3 from Ian Bolton  2011-03-24 14:24:23 
UTC ---

For gcc 4.5 r171282, arm-none-linux-gnueabi, I can run this command without

error:



arm-none-linux-gnueabi-g++ ~/investigate/pr42949.i -B. -c -O1 -mfpu=vfp



It also works for trunk (r171212).



I therefore think this is fixed or has ceased to be, but it would be good to

get confirmation someone else.

[Bug target/48250] ICE in reload_cse_simplify_operands, at postreload.c:403

[ibolton at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48250



Ian Bolton  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

  Known to work||4.5.3

Version|4.6.0   |4.7.0

   Keywords||ice-on-valid-code

   Last reconfirmed||2011.03.24 14:34:13

 CC||ibolton at gcc dot gnu.org

 Ever Confirmed|0   |1

  Known to fail||4.7.0



--- Comment #1 from Ian Bolton  2011-03-24 14:34:13 
UTC ---

Confirmed on trunk, r171212.



Works on latest 4.5 (r171282).



I don't think this is the same bug as PR42949 because that one has now ceased

to occur - for me at least.

[Bug middle-end/48270] [4.7 Regression] New test failures

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48270



Richard Guenther  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org

   |gnu.org |

   Target Milestone|--- |4.7.0



--- Comment #8 from Richard Guenther  2011-03-24 
14:36:41 UTC ---

Works for me, I'm going to apply it.

[Bug middle-end/48270] [4.7 Regression] New test failures

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48270



--- Comment #9 from Richard Guenther  2011-03-24 
14:39:40 UTC ---

Author: rguenth

Date: Thu Mar 24 14:39:36 2011

New Revision: 171394



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171394

Log:

2011-03-24  Richard Guenther  



PR tree-optimization/48270

* tree-ssa-phiopt.c (cond_if_else_store_replacement): Do

not free datarefs before ddrs.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/tree-ssa-phiopt.c

[Bug tree-optimization/48271] ICE: SIGSEGV in tree_ssa_dominator_optimize (tree-ssa-dom.c:2964) with -O -ftree-vrp -fno-guess-branch-probability -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48271



--- Comment #2 from Richard Guenther  2011-03-24 
14:43:22 UTC ---

Author: rguenth

Date: Thu Mar 24 14:43:16 2011

New Revision: 171395



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171395

Log:

2011-03-24  Richard Guenther  



PR tree-optimization/48271

* tree-ssa-dom.c (tree_ssa_dominator_optimize): Only cleanup

blocks that still exist.



* g++.dg/torture/pr48271.C: New testcase.



Added:

trunk/gcc/testsuite/g++.dg/torture/pr48271.C

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-ssa-dom.c

[Bug middle-end/48270] [4.7 Regression] New test failures

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48270



Richard Guenther  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #10 from Richard Guenther  2011-03-24 
14:43:53 UTC ---

Fixed.

[Bug tree-optimization/48271] ICE: SIGSEGV in tree_ssa_dominator_optimize (tree-ssa-dom.c:2964) with -O -ftree-vrp -fno-guess-branch-probability -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48271



Richard Guenther  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #3 from Richard Guenther  2011-03-24 
14:43:56 UTC ---

Fixed for 4.7.

[Bug c/48274] C frontend emit invalid promotions

[matz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48274



--- Comment #2 from Michael Matz  2011-03-24 14:51:08 
UTC ---

It's x86_64-linux and indeed it does define that hook.  Like 19 other targets.

This is quite inconvenient.  The target should have a say in what instructions

are generated (as in influencing the setup of RTL call, and setup of arguments

in the callee, also at RTL), not on the types the middle end sees.  Sigh.

[Bug c/48274] C frontend emit invalid promotions

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48274



Richard Guenther  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2011.03.24 14:58:31

 Ever Confirmed|0   |1



--- Comment #3 from Richard Guenther  2011-03-24 
14:58:31 UTC ---

With similar promotions done to return values I got away by simply removing

the offending code from the FE ... there definitely _is_ code in backends

to influence argument passing at call expansion time and at least Fortran

doesn't seem to care for these hooks (which also means C interface Fortran

calls are "wrong").



So I suggest simply trying to remove this code from the FE ;)

[Bug c/48274] C frontend emit invalid promotions

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48274



--- Comment #4 from Richard Guenther  2011-03-24 
15:00:23 UTC ---

FYI



2007-07-09  Richard Guenther  



* decl.c (start_preparsed_function): Do not promote return type.

[Bug middle-end/48269] [4.6 Regression] Incorrect fortify warning for a packed struct member

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48269



Richard Guenther  changed:



   What|Removed |Added



  Known to work||4.7.0



--- Comment #6 from Richard Guenther  2011-03-24 
15:01:48 UTC ---

Fixed for 4.7 sofar.

[Bug target/48262] [4.7 Regression] Subversion id 171341 breaks various vectorization files on powerpc

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48262



--- Comment #10 from Michael Meissner  2011-03-24 
15:02:47 UTC ---

The vec_extract patches look good.



However, I think the movmisalign patch is a band-aid.  The exander should call

force_reg if the predicates don't match for movmisalign (probably ternary ops)

like it does for every other RTL expansion.

[Bug target/42949] ICE: reload_cse_simplify_operands, at postreload.c:396

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42949



--- Comment #4 from Mikael Pettersson  2011-03-24 
15:13:17 UTC ---

(In reply to comment #3)

> For gcc 4.5 r171282, arm-none-linux-gnueabi, I can run this command without

> error:

> 

> arm-none-linux-gnueabi-g++ ~/investigate/pr42949.i -B. -c -O1 -mfpu=vfp

> 

> It also works for trunk (r171212).

> 

> I therefore think this is fixed or has ceased to be, but it would be good to

> get confirmation someone else.



You tested with an EABI compiler.  The original report stated that the ICE

occurs with arm-linux configurations, i.e. OABI, but not with EABI

configurations.

[Bug objc++/48275] New: getter=namespace failing with .mm

[jos at kuijpersvof dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48275

   Summary: getter=namespace failing with .mm
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: objc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@kuijpersvof.nl


gcc fails to compile when using objc++ and having getter=namespace.

I don't have the latest revision of the trunk, so someone should verify it is
still there or not.

$ cat test.h
@interface Test
{
int ns;
}
@property (getter=namespace) int ns;

@end

$ cat gccbug.mm
#import "test.h"

$ gcc-4.6 -lobjc -o test gccbug.mm
In file included from gccbug.mm:1:0:
test.h:5:19: error: expected identifier before ânamespaceâ
test.h:5:19: error: expected â)â before ânamespaceâ

[Bug testsuite/48276] New: FAIL: gcc.target/i386/pr47502-2.c on x86_64-apple-darwin10.7.0 with -m32

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48276



   Summary: FAIL: gcc.target/i386/pr47502-2.c on

x86_64-apple-darwin10.7.0 with -m32

   Product: gcc

   Version: 4.7.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: testsuite

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: domi...@lps.ens.fr

CC: h...@gcc.gnu.org





gcc.target/i386/pr47502-2.c fails on x86_64-apple-darwin10.7.0 with -m32



FAIL: gcc.target/i386/pr47502-2.c (test for excess errors)



The failure is



[macbook] f90/bug% gcc47 -c -m32 -O2

/opt/gcc/_clean/gcc/testsuite/gcc.target/i386/pr47502-2.c

/opt/gcc/_clean/gcc/testsuite/gcc.target/i386/pr47502-2.c: In function 'foo':

/opt/gcc/_clean/gcc/testsuite/gcc.target/i386/pr47502-2.c:8:3: error:

inconsistent operand constraints in an 'asm'

[Bug target/48173] [4.6 regression] bootstrap error on arm-linux-gnueabi (defaulting to armv4t)

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48173

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.1

[Bug target/48273] [4.6/4.7 Regression] ICE: in create_copy_of_insn_rtx, at sel-sched-ir.c:5604 with -fsel-sched-pipelining -fselective-scheduling2 -march=core2

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48273

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.1

[Bug debug/48253] [4.6/4.7 Regression] Further .debug_aranges issues

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48253

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.1

[Bug target/48209] FAIL: gcc.c-torture/execute/pr47917.c execution

[sje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48209

--- Comment #12 from Steve Ellcey  2011-03-24 16:29:24 
UTC ---
Author: sje
Date: Thu Mar 24 16:29:18 2011
New Revision: 171404

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171404
Log:
2011-03-24  Steve Ellcey  

PR target/48209
* gcc.c-torture/execute/pr47917.c: Move this...
* gcc.dg/torture/pr47917.c: to here and add xfails.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr47917.c
  - copied, changed from r171278,
trunk/gcc/testsuite/gcc.c-torture/execute/pr47917.c
Removed:
trunk/gcc/testsuite/gcc.c-torture/execute/pr47917.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/27357] 20 % increase code size in 4.1 vs 3.4.5

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27357

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.24 16:33:55
 CC||rguenth at gcc dot gnu.org
  Known to work||3.4.5, 4.6.0
 Ever Confirmed|0   |1

--- Comment #5 from Richard Guenther  2011-03-24 
16:33:55 UTC ---
Seems to be fixed for 4.6.  Now on to a way to add object-size testcases ...

[Bug target/48209] FAIL: gcc.c-torture/execute/pr47917.c execution

[sje at cup dot hp.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48209

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #13 from Steve Ellcey  2011-03-24 16:37:01 
UTC ---
Resolved by XFAIL'ing test on *-*-hpux10* and *-*-hpux1[12]*.

[Bug target/48273] [4.6/4.7 Regression] ICE: in create_copy_of_insn_rtx, at sel-sched-ir.c:5604 with -fsel-sched-pipelining -fselective-scheduling2 -march=core2

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48273

Uros Bizjak  changed:

   What|Removed |Added

 Target|x86_64-pc-linux-gnu |i686-pc-linux-gnu
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.24 16:43:05
 Ever Confirmed|0   |1

--- Comment #1 from Uros Bizjak  2011-03-24 16:43:05 
UTC ---
-m32 is also needed to trigger this ICE, so i686-pc-linux-gnu.

[Bug target/48273] [4.6/4.7 Regression] ICE: in create_copy_of_insn_rtx, at sel-sched-ir.c:5604 with -fsel-sched-pipelining -fselective-scheduling2 -march=core2

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48273

--- Comment #2 from Uros Bizjak  2011-03-24 16:46:08 
UTC ---
(gdb) bt
#0  fancy_abort (file=0xd77f00 "../../gcc-svn/trunk/gcc/sel-sched-ir.c", 
line=5604, function=0xd78e40 "create_copy_of_insn_rtx")
at ../../gcc-svn/trunk/gcc/diagnostic.c:892
#1  0x007bac89 in create_copy_of_insn_rtx (insn_rtx=0x71f33780)
at ../../gcc-svn/trunk/gcc/sel-sched-ir.c:5604
#2  0x007cdf30 in emit_bookkeeping_insn (insn=0x71f33820, 
lparams=0x7fffd870, static_params=Unhandled dwarf expression opcode
0xf3
)
at ../../gcc-svn/trunk/gcc/sel-sched.c:4767
#3  generate_bookkeeping_insn (insn=0x71f33820, lparams=0x7fffd870, 
static_params=Unhandled dwarf expression opcode 0xf3
) at ../../gcc-svn/trunk/gcc/sel-sched.c:4805
#4  move_op_at_first_insn (insn=0x71f33820, lparams=0x7fffd870, 
static_params=Unhandled dwarf expression opcode 0xf3
) at ../../gcc-svn/trunk/gcc/sel-sched.c:6073
#5  0x007c7009 in code_motion_path_driver (insn=0x71f33820, 
orig_ops=0x0, path=, local_params_in=0x7fffd870, 
static_params=0x7fffdaa0) at ../../gcc-svn/trunk/gcc/sel-sched.c:6638
#6  0x007c668f in code_motion_process_successors (insn=0x71f33aa0, 
orig_ops=0x1414978, path=0x14149f0, static_params=0x7fffdaa0)
at ../../gcc-svn/trunk/gcc/sel-sched.c:6354
#7  0x007c71dc in code_motion_path_driver (insn=0x71f33aa0, 
orig_ops=0x1414978, path=0x14149f0, local_params_in=0x7fffda70, 
static_params=0x7fffdaa0) at ../../gcc-svn/trunk/gcc/sel-sched.c:6600

(gdb) up
#1  0x007bac89 in create_copy_of_insn_rtx (insn_rtx=0x71f33780)
at ../../gcc-svn/trunk/gcc/sel-sched-ir.c:5604
5604  gcc_assert (NONJUMP_INSN_P (insn_rtx));
(gdb) li
5599
5600  if (DEBUG_INSN_P (insn_rtx))
5601return create_insn_rtx_from_pattern (copy_rtx (PATTERN (insn_rtx)),
5602 insn_rtx);
5603
5604  gcc_assert (NONJUMP_INSN_P (insn_rtx));
5605
5606  res = create_insn_rtx_from_pattern (copy_rtx (PATTERN (insn_rtx)),
5607  NULL_RTX);
5608  return res;

(gdb) p debug_rtx (insn_rtx)
(call_insn 6 0 0 3 (call (mem:QI (symbol_ref:SI ("bar") [flags 0x41]
) [0 bar S1 A8])
(const_int 0 [0])) pr48273.c:6 618 {*call_0}
 (nil)
(nil))

[Bug target/48273] [4.6/4.7 Regression] ICE: in create_copy_of_insn_rtx, at sel-sched-ir.c:5604 with -fsel-sched-pipelining -fselective-scheduling2 -march=core2

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48273

--- Comment #3 from Zdenek Sojka  2011-03-24 16:54:05 
UTC ---
(In reply to comment #1)
> -m32 is also needed to trigger this ICE, so i686-pc-linux-gnu.

Yes, sorry, originally I tested the code as C++ code, and in that case, -m32 is
not needed.

[Bug rtl-optimization/48263] [4.7 Regression]: build fails for cris-elf in libgfortran

[rsandifo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48263

--- Comment #4 from rsandifo at gcc dot gnu.org  
2011-03-24 17:23:22 UTC ---
Author: rsandifo
Date: Thu Mar 24 17:23:18 2011
New Revision: 171418

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171418
Log:
gcc/
PR rtl-optimization/48263
* optabs.c (expand_binop_directly): Reinstate convert_modes code
and original commutative_p handling.  Use maybe_gen_insn.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/optabs.c

[Bug target/48273] [4.6/4.7 Regression] ICE: in create_copy_of_insn_rtx, at sel-sched-ir.c:5604 with -fsel-sched-pipelining -fselective-scheduling2 -march=core2

[amonakov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48273

Alexander Monakov  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||amonakov at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |amonakov at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from Alexander Monakov  2011-03-24 
17:32:39 UTC ---
So the assert disagrees with the rest of the scheduler on whether calls may be
cloned.  I'll talk to Andrey about amending one or the other.

[Bug middle-end/48270] [4.7 Regression] New test failures

[irar at il dot ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48270

--- Comment #11 from Ira Rosen  2011-03-24 17:32:54 UTC 
---
Thanks!

[Bug rtl-optimization/48263] [4.7 Regression]: build fails for cris-elf in libgfortran

[rsandifo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48263

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from rsandifo at gcc dot gnu.org  
2011-03-24 17:35:26 UTC ---
Fixed on trunk.

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245

--- Comment #20 from Dominique d'Humieres  
2011-03-24 18:46:41 UTC ---
> AFAICT, comment #12 is OK on *-darwin9 including cross-cris-elf.
> given that Mike has approved, 
> if someone could chip in with a test on x86-64-darwin10, I would think you
> could apply it.

I have bootstrapped gcc on x86-64-darwin10 with the patch in comment #12 on top
of revision 171401 without failures for the tests ran by lto.exp (full test by
tomorrow).

Now I wonder what are the tests

gcc/testsuite/gcc.dg/lto/20100722-1_0.c
gcc/testsuite/gcc.dg/lto/20110201-1_0.c
gcc/testsuite/gcc.dg/lto/pr46940_0.c
gcc/testsuite/gcc.dg/lto/pr47188_0.c
gcc/testsuite/gcc.dg/pr43157.c

supposed to test? pr46940_0.c fails because "only weak aliases are supported"
on darwin and the other tests pass even without plugin support.

[Bug debug/48204] [4.5/4.6/4.7 Regression] ICE: in decimal_to_decnumber, at dfp.c:115 with -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-fre -g

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48204

--- Comment #3 from Jakub Jelinek  2011-03-24 
18:59:02 UTC ---
Author: jakub
Date: Thu Mar 24 18:58:58 2011
New Revision: 171423

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171423
Log:
PR debug/48204
* simplify-rtx.c (simplify_const_unary_operation): Call
real_convert when changing mode class with FLOAT_EXTEND.

* gcc.dg/dfp/pr48204.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/dfp/pr48204.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/48277] New: [4.7 Regression] ICE for g++.dg/ext/altivec-cell-1.C on powerpc*-*-*

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48277

   Summary: [4.7 Regression] ICE for g++.dg/ext/altivec-cell-1.C
on powerpc*-*-*
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: ja...@redhat.com


Between revisions 171020 and 171087 g++.dg/ext/altivec-cell-1.C has started to
fail

FAIL: g++.dg/ext/altivec-cell-1.C (internal compiler error)

(compare http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg01568.html and
http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg01761.html). The ICE is

[karma] f90/bug% /opt/gcc/gcc4.7w/bin/gcc -maltivec
/opt/gcc/work/gcc/testsuite/g++.dg/ext/altivec-cell-1.C
/opt/gcc/work/gcc/testsuite/g++.dg/ext/altivec-cell-1.C: In function 'int
tf(__vector(4) int, int)':
/opt/gcc/work/gcc/testsuite/g++.dg/ext/altivec-cell-1.C:42:27: internal
compiler error: in finish_call_expr, at cp/semantics.c:2162

and is caused/exposed by the change in revision 171053.

[Bug debug/48204] [4.5/4.6 Regression] ICE: in decimal_to_decnumber, at dfp.c:115 with -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-fre -g

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48204

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||4.7.0
Summary|[4.5/4.6/4.7 Regression]|[4.5/4.6 Regression] ICE:
   |ICE: in |in decimal_to_decnumber, at
   |decimal_to_decnumber, at|dfp.c:115 with
   |dfp.c:115 with  |-fno-tree-ccp
   |-fno-tree-ccp   |-fno-tree-dominator-opts
   |-fno-tree-dominator-opts|-fno-tree-fre -g
   |-fno-tree-fre -g|
  Known to fail|4.7.0   |

--- Comment #4 from Jakub Jelinek  2011-03-24 
19:14:27 UTC ---
Fixed on the trunk so far.

[Bug target/48262] [4.7 Regression] Subversion id 171341 breaks various vectorization files on powerpc

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48262

--- Comment #11 from Michael Meissner  2011-03-24 
19:44:12 UTC ---
I was wrong with my previous comment about movmisalign, and both patches look
good.

[Bug target/48262] [4.7 Regression] Subversion id 171341 breaks various vectorization files on powerpc

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48262

--- Comment #12 from Dominique d'Humieres  
2011-03-24 20:00:17 UTC ---
What about the patch in http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01595.html
? Does it come on top of the patches in comments #5 and #6 or does it replace
them?

[Bug target/48262] [4.7 Regression] Subversion id 171341 breaks various vectorization files on powerpc

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48262

--- Comment #13 from Michael Meissner  2011-03-24 
20:09:06 UTC ---
My reading of the patches, is the rs6000 port was broken, and Andrew's two
patches fixes this.

Richard's patch would have the effect that we wouldn't notice if the two
patches aren't installed.  But it is always better to have correct RTL, so I
would say even if Richard's patch goes in, we should apply Andrew's two patches
as well.

[Bug c/48278] New: [4.5 Regression] linking results in undefined references to _savegpr_* _restgpr_*_x

[wd at denx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48278

   Summary: [4.5 Regression] linking results in undefined
references to _savegpr_* _restgpr_*_x
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: w...@denx.de
  Host: x86_64-redhat-linux
Target: PowerPC
 Build: x86_64-redhat-linux


This is a follow-up on bug 43810, as requested by comment 18:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810#c18

The problem is not fixed yet, we see it when trying to enable
--enable-target-optspace for the Poky / Yocto builds, for details please see
comment 19:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810#c19

The original bug report referred to a powerpc-eabispe target only, but we see
this with other powerpc confiugrations as well (Ilya's build was for a plain
vanilla ppc603e system).

[Bug c/48278] [4.5 Regression] linking results in undefined references to _savegpr_* _restgpr_*_x

[wd at denx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48278

--- Comment #1 from Wolfgang Denk  2011-03-24 21:18:22 UTC 
---
See also bug 45053; sorry I missed that.

[Bug fortran/48279] New: segfault in gfc_check_vardef_context

[adrian at llnl dot gov]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48279

   Summary: segfault in gfc_check_vardef_context
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: adr...@llnl.gov


I have found gfortran 4.6-rc2 (and also svn r171355) to segfault in
gfc_check_vardef_context().
The code spans over 3 modules, but I used delta to come up with the following
minimal example: 

$ cat sidl_string_array.F03

module sidl_string_array
  type sidl_string_1d
  end type sidl_string_1d
  interface set
module procedure &
  setg1_p
  end interface
contains
  subroutine setg1_p(array, index, val)
type(sidl_string_1d), intent(inout) :: array
  end subroutine setg1_p
end module sidl_string_array

$ cat s_Hard.F03
module s_Hard
  use sidl_string_array
  type, bind(c) :: s_Hard_t
  end type s_Hard_t
  interface set_d_interface
  end interface 
  interface get_d_string
module procedure get_d_string_p
  end interface 
  contains ! Derived type member access functions
type(sidl_string_1d) function get_d_string_p(s)
  type(s_Hard_t), intent(in) :: s
end function get_d_string_p
subroutine set_d_objectArray_p(s, d_objectArray)
end subroutine set_d_objectArray_p
end module s_Hard

$ cat main.F03 
  subroutine initHard(h, ex)
use s_Hard
type(s_Hard_t), intent(inout) :: h
call set(get_d_string(h), 0, 'Three')
  end subroutine initHard

$ gfortran -c sidl_string_array.F03 -o sidl_string_array.o
$ gfortran -c s_Hard.F03 -o s_Hard.o
s_Hard.F03:3.27:

  type, bind(c) :: s_Hard_t
   1
Warning: Derived type 's_hard_t' with BIND(C) attribute at (1) is empty, and
may be inaccessible by the C companion processor

$ gfortran main.F03
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/48279] segfault in gfc_check_vardef_context

[adrian at llnl dot gov]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48279

Adrian Prantl  changed:

   What|Removed |Added

 CC||adrian at llnl dot gov

--- Comment #1 from Adrian Prantl  2011-03-24 23:06:21 
UTC ---
Sorry, I forgot to mention that the machine was an x86_64 with Ubuntu 10.04.

[Bug c++/48280] New: [4.5/4.6/4.7 Regression] [C++0x] ICE: tree check: expected var_decl or function_decl, have template_decl in check_bases_and_members, at cp/class.c:4695

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48280

   Summary: [4.5/4.6/4.7 Regression] [C++0x] ICE: tree check:
expected var_decl or function_decl, have template_decl
in check_bases_and_members, at cp/class.c:4695
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


- testcase.C -
struct S {
  template < typename > S (const S &) = default;
};
--

Compiler output:
$ gcc -std=c++0x testcase.C 
testcase.C:2:41: error: 'S::S(const S&)' cannot be defaulted
testcase.C:1:8: internal compiler error: tree check: expected var_decl or
function_decl, have template_decl in check_bases_and_members, at
cp/class.c:4695
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r171399 - crash
4.6 r170955 - crash
4.5 r170955 - crash
4.4 r170955 - OK

[Bug fortran/48279] segfault in gfc_check_vardef_context

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48279

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.24 23:58:42
 CC||kargl at gcc dot gnu.org
 Ever Confirmed|0   |1
   Severity|blocker |normal

--- Comment #2 from Dominique d'Humieres  2011-03-24 
23:58:42 UTC ---
There is a change of behavior between revisions 166533 and 167096. At revisions
4.5.2 and 166533 one gets:

pr48279.f90:16.27:

  type, bind(c) :: s_Hard_t
   1
Error: Derived type 's_hard_t' at (1) is empty
pr48279.f90:32.14:

use s_Hard
  1
Fatal Error: Can't open module file 's_hard.mod' for reading at (1): No such
file or directory

The change is likely due to revision 166633.

[Bug fortran/48279] segfault in gfc_check_vardef_context

[adrian at llnl dot gov]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48279

Adrian Prantl  changed:

   What|Removed |Added

   Severity|normal  |blocker

--- Comment #3 from Adrian Prantl  2011-03-25 00:06:15 
UTC ---
(In reply to comment #2)
> There is a change of behavior between revisions 166533 and 167096. At 
> revisions
> 4.5.2 and 166533 one gets:
> 
> pr48279.f90:16.27:
> 
>   type, bind(c) :: s_Hard_t
>1
> Error: Derived type 's_hard_t' at (1) is empty
> pr48279.f90:32.14:
> 
> use s_Hard
>   1
> Fatal Error: Can't open module file 's_hard.mod' for reading at (1): No such
> file or directory
> 
> The change is likely due to revision 166633.

feel free to use 

module s_Hard
  use sidl_string_array
  use iso_c_binding
  type, bind(c) :: s_Hard_t
 integer(kind=c_int) :: dummy
  end type s_Hard_t
  interface set_d_interface
  end interface 
  interface get_d_string
module procedure get_d_string_p
  end interface 
  contains ! Derived type member access functions
type(sidl_string_1d) function get_d_string_p(s)
  type(s_Hard_t), intent(in) :: s
end function get_d_string_p
subroutine set_d_objectArray_p(s, d_objectArray)
end subroutine set_d_objectArray_p
end module s_Hard

instead. It shouldn't complain.

[Bug c++/48281] New: internal compiler error: in record_reference, at cgraphbuild.c:60

[swestrup at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48281

   Summary: internal compiler error: in record_reference, at
cgraphbuild.c:60
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: swest...@gmail.com


The code that triggered this bug is almost certainly in error, but as its
caused an internal compiler error, it seemed worth reporting. That said, I
don't really know *what* caused the bug, except to say that it happened when I
declared my four matrix variables in the attached code (M a ... M d) to be
static.

The code is one unit test from an ongoing project, and I've provided the plain
.cpp code (for reference) and a pre-processed file so you have a chance to
reproduce the bug.

In case it matters, here are my system specs:

$ g++ --version
g++ (Debian 4.6.0~rc1-2) 4.6.0 20110320 (prerelease)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ uname -a
Linux timelord 2.6.36-zen2-sti-02 #4 ZEN SMP PREEMPT Fri Jan 7 13:21:12 EST
2011 x86_64 GNU/Linux

[Bug c++/48281] internal compiler error: in record_reference, at cgraphbuild.c:60

[swestrup at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48281

--- Comment #1 from Stirling Westrup  2011-03-25 
00:41:11 UTC ---
Created attachment 23770
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23770
c++ code that was preprocessed to generated previous attachment.

[Bug c++/48281] internal compiler error: in record_reference, at cgraphbuild.c:60

[swestrup at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48281

--- Comment #2 from Stirling Westrup  2011-03-25 
00:46:02 UTC ---
It seems that the preprocessed file that generates the error is 3KB in size,
and is being rejected by Bugzilla. How the heck am I supposed to submit it now?

[Bug c++/48281] internal compiler error: in record_reference, at cgraphbuild.c:60

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48281

--- Comment #3 from Jonathan Wakely  2011-03-25 
00:52:44 UTC ---
compress the file e.g. with gzip

[Bug c++/48281] internal compiler error: in record_reference, at cgraphbuild.c:60

[swestrup at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48281

--- Comment #4 from Stirling Westrup  2011-03-25 
00:57:00 UTC ---
Created attachment 23771
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23771
Minimal test case that triggers the error.

Okay, I've managed to pare the original code down to the bare minimum that
causes the error. This should be much easier to debug.

[Bug c++/48281] internal compiler error: in record_reference, at cgraphbuild.c:60

[swestrup at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48281

--- Comment #5 from Stirling Westrup  2011-03-25 
00:59:04 UTC ---
Created attachment 23772
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23772
Preprocessed version of minimal test case.

Here's a preprocessed version of the minimal test case, just in case you have
some use for it.

[Bug c++/48281] [4.6/4.7 Regression] [C++0x] internal compiler error: in record_reference, at cgraphbuild.c:60

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48281

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.25 01:03:15
Summary|internal compiler error: in |[4.6/4.7 Regression]
   |record_reference, at|[C++0x] internal compiler
   |cgraphbuild.c:60|error: in record_reference,
   ||at cgraphbuild.c:60
 Ever Confirmed|0   |1

--- Comment #6 from Jonathan Wakely  2011-03-25 
01:03:15 UTC ---
confirmed