[Bug middle-end/54337] Dramatic Compilation slow-down on higher Optimizaitons

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #4 from Steven Bosscher  2012-08-21 
07:00:24 UTC ---
Can you please provide the output of your "gcc --version" and of a compiler run
with the extra flag "-ftime-report"?

[Bug fortran/54339] [4.8 Regression] Update gfortran manual for GCC 4.8's TS29113 changes

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Priority|P3  |P5
 CC||burnus at gcc dot gnu.org

[Bug c/54340] New: internal compiler error: Illegal instruction (int main() returns nothing, only when -O2/-O3 used)

[socketpair at gmail dot com]

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

 Bug #: 54340
   Summary: internal compiler error: Illegal instruction (int
main() returns nothing, only when -O2/-O3 used)
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: socketp...@gmail.com


$ gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc test.c 

$ LANG=C gcc -O2 test.c 
test.c: In function 'main':
test.c:6:1: internal compiler error: Illegal instruction
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccYojEN6.out file, please attach this to
your bugreport.

$ cat test.c 
int main (void)
{
  volatile int a;
  if (a == 42)
return 1;
}


If I add "return 0;" to the end of function - problem is fixed. I understand,
that program is not correct, but, as I think, gcc should not fail on that. It
seems, it is optimizer bug.

[Bug fortran/54339] New: [4.8 Regression] Update gfortran manual for GCC 4.8's TS29113 changes

[burnus at gcc dot gnu.org]

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

 Bug #: 54339
   Summary: [4.8 Regression] Update gfortran manual for GCC 4.8's
TS29113 changes
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


That's not a regression – but the manual has to be updated for the TS29113
changes before the 4.8 release – and marking it as regression.

Namely,
  http://gcc.gnu.org/onlinedocs/gfortran/Standards.html
  http://gcc.gnu.org/onlinedocs/gfortran/Interoperability-with-C.html
  http://gcc.gnu.org/onlinedocs/gfortran/TS-29113-status.html

Additionally, the F2003 & F2008 status should be updated.
  http://gcc.gnu.org/onlinedocs/gfortran/Fortran-2003-and-2008-status.html

And, we should consider to also link to the deferred-length string version of
ISO Varying strings at 
http://gcc.gnu.org/onlinedocs/gfortran/Varying-Length-Character-Strings.html

And as always: Read through the whole document – and the internals document –
and consider improvements of all kinds.

[Bug c/54340] internal compiler error: Illegal instruction (int main() returns nothing, only when -O2/-O3 used)

[mikpe at it dot uu.se]

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

--- Comment #1 from Mikael Pettersson  2012-08-21 
07:22:09 UTC ---
You didn't specify the host, but since it's Ubuntu I'm guessing Linux/x86_64.  

I can't reproduce the SIGILL with either 4.7.1, 4.6.3, or 4.5.4 on a Core i7.

Can you reproduce with a gcc built from unpatched upstream sources?  If not
then you should report this to Ubuntu as their gcc is a heavily modified
version.

[Bug c/54340] internal compiler error: Illegal instruction (int main() returns nothing, only when -O2/-O3 used)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||arm-linux-gnueabi

--- Comment #2 from Andrew Pinski  2012-08-21 
07:30:29 UTC ---
I think this is a Linaro toolchain which means you should report this to Ubuntu
and they will most likely report this to Linaro.

[Bug c/54340] internal compiler error: Illegal instruction (int main() returns nothing, only when -O2/-O3 used)

[socketpair at gmail dot com]

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

--- Comment #3 from Коренберг Марк  2012-08-21 
07:32:25 UTC ---
Yes, I tested on gentoo, no error appear.

I have reported to ubuntu bug tracker:
https://bugs.launchpad.net/ubuntu/+source/gcc-4.6/+bug/1039401

[Bug c++/54293] When a reference is bound to subobject of a temporary, lifetime of the temporary is not extended

[jpalecek at web dot de]

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

--- Comment #10 from Jiří Paleček  2012-08-21 07:51:55 
UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > > I agree with your analysis, but would like to point out that there is 
> > > change
> > > planned to essentially this part of the wording due to 
> > > 
> > > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#616
> > > 
> > > Assuming it becomes accepted E1.E2 will become an xvalue in this case (SE
> > > bullet 2 of the P/R)
> > 
> > Thanks for the info, it is interesting (although I can't see the relevance 
> > of
> > this particular change to the issues it should solve, which are basically 
> > about
> > using uninitialized objects).
> 
> Well, this addition *would* change the expected outcome. Because given the CWG
> 616 P/R the expression
> 
> ValueHolder().v
> 
> becomes an xvalue (The special rule about class rvalues is no longer relevant
> here), this means that the compiler shall *not* copy-initialize a temporary as
> described in the very last bullet of 8.5.3/5.
> 
> In other words: In this case IsValid(&ref_int) will hold for the same reasons
> as it holds for IsValid(&ref_obj).

That is true, and I didn't object that. I rather didn't understand how is that
particular change related to solving issues 616, 129, 240 and some others
mentioned there.

[Bug middle-end/54146] Very slow compile with attribute((flatten))

[rguenther at suse dot de]

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

--- Comment #56 from rguenther at suse dot de  
2012-08-21 07:55:14 UTC ---
On Mon, 20 Aug 2012, steven at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
> 
> Steven Bosscher  changed:
> 
>What|Removed |Added
> 
>  Status|NEW |RESOLVED
>  Resolution||WONTFIX
> 
> --- Comment #55 from Steven Bosscher  2012-08-20 
> 19:30:34 UTC ---
> The remaining problem areas are all liveness calculation routines that are
> essentially inherent quadratic problems: DF liveness, IRA liveness, and
> out-of-SSA liveness. 
> 
> I think it would be good to deprecate the flatten attribute...

It still can be useful I think, if only for creating testcases
with arbitrary large functions ;)

[Bug c/54340] internal compiler error: Illegal instruction (int main() returns nothing, only when -O2/-O3 used)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #4 from Richard Guenther  2012-08-21 
08:00:18 UTC ---
.

[Bug fortran/54339] [4.8 Regression] Update gfortran manual for GCC 4.8's TS29113 changes

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug driver/54335] -dm doesn't work

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-21
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-08-21 
08:07:14 UTC ---
It's called -fmem-report.  I suppose simply remove the bogus docs.

[Bug c++/54293] When a reference is bound to subobject of a temporary, lifetime of the temporary is not extended

[daniel.kruegler at googlemail dot com]

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

--- Comment #11 from Daniel Krügler  
2012-08-21 08:07:28 UTC ---
(In reply to comment #10)
> > In other words: In this case IsValid(&ref_int) will hold for the same 
> > reasons
> > as it holds for IsValid(&ref_obj).
> 
> That is true, and I didn't object that. I rather didn't understand how is that
> particular change related to solving issues 616, 129, 240 and some others
> mentioned there.

Sorry, I misunderstood your comment. This particular 616 wording change was a
"side-step" change that was done as part of the issue (it was recognized while
discussing it), the drafting note during the Kona meeting says:

"Drafting note: This change addresses core issue 240, third item in a
minimally-intrusive way [..]"

[Bug middle-end/54337] Dramatic Compilation slow-down on higher Optimizaitons

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|UNCONFIRMED |RESOLVED
Version|unknown |4.7.1
 Resolution||DUPLICATE

--- Comment #5 from Richard Guenther  2012-08-21 
08:09:55 UTC ---
Sort-of "confirmed", though you should expect compile-time increases from -O0
to
-O[123] and I don't think the increases are unreasonable, esp. for C++ code
which
can see a lot if inlining.

> /usr/bin/time g++-4.7 -S -o /dev/null t.C -O0
2.24user 0.09system 0:02.84elapsed 82%CPU (0avgtext+0avgdata
918736maxresident)k
22384inputs+0outputs (97major+62614minor)pagefaults 0swaps
> /usr/bin/time g++-4.7 -S -o /dev/null t.C -O1
11.24user 0.15system 0:11.43elapsed 99%CPU (0avgtext+0avgdata
1045616maxresident)k
0inputs+0outputs (0major+113102minor)pagefaults 0swaps
> /usr/bin/time g++-4.7 -S -o /dev/null t.C -O2
16.67user 0.38system 0:17.12elapsed 99%CPU (0avgtext+0avgdata
1189056maxresident)k
2504inputs+0outputs (11major+199132minor)pagefaults 0swaps
> /usr/bin/time g++-4.7 -S -o /dev/null t.C -O3
17.79user 0.30system 0:18.20elapsed 99%CPU (0avgtext+0avgdata
1203280maxresident)k
328inputs+0outputs (2major+200860minor)pagefaults 0swaps

-O3 time-report:

 alias stmt walking  :   2.87 (16%) usr   0.02 ( 4%) sys   2.96 (16%) wall 
 1 kB ( 0%) ggc
 tree PTA:   4.59 (26%) usr   0.01 ( 2%) sys   4.63 (25%) wall 
  1313 kB ( 1%) ggc

so I think we have a duplicate for this kind of issue.  SCCVN walks over
non-aliased stores are not limited and can expose quadratic complexity
if there are no aliases in the function that stop the walk.  PR46590
comes to my mind which already tracks this.

*** This bug has been marked as a duplicate of bug 46590 ***

[Bug tree-optimization/46590] [4.6/4.7/4.8 Regression] long compile time with -O2 and many loops

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||nbhargava at google dot com

--- Comment #22 from Richard Guenther  2012-08-21 
08:09:55 UTC ---
*** Bug 54337 has been marked as a duplicate of this bug. ***

[Bug fortran/48636] Enable more inlining with -O2 and higher

[hubicka at gcc dot gnu.org]

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

--- Comment #18 from Jan Hubicka  2012-08-21 
08:14:33 UTC ---
With loop_iterations hint, we should now hint the bar function of testcase in
comment #4, but we don't because the value is used conditionally:

  # iftmp.11_3 = PHI <_12(3), 1(2)>
  a.0_16 = a_11(D)->data;
  _17 = a_11(D)->dim[0].ubound;
  _18 = a_11(D)->dim[0].lbound;
  _19 = _17 - _18;
  ubound.0_20 = _19 + 1;
  stride.3_21 = a_11(D)->dim[1].stride;
  _22 = a_11(D)->dim[1].ubound;
  _23 = a_11(D)->dim[1].lbound;
  _24 = _22 - _23;
  ubound.2_25 = _24 + 1;
  _27 = -iftmp.11_3;
  offset.4_28 = _27 - stride.3_21;
  *x_35(D) = 0.0;
  _53 = stride.3_21 >= 0;
  _56 = ubound.2_25 > 0;
  _57 = _53 & _56;
  _59 = stride.3_21 < 0;
  _60 = _57 | _59;
  _66 = _59 | _60;
  if (_66 != 0)
goto ;
  else
goto ;

  :
  iftmp.13_68 = (integer(kind=4)) ubound.2_25;

  :
  # iftmp.13_4 = PHI 
  if (iftmp.13_4 > 0)
goto ;
  else
goto ;

Martin, does this work with your PHI patch? (i.e. do you get "loop iterations"
in -fdump-ipa-inline?)

Next step will be to teach inliner to inline into functions called once when
callee is important and some propagation happens.

Honza

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

--- Comment #5 from Richard Guenther  2012-08-21 
08:26:03 UTC ---
(In reply to comment #4)
> It was introduced between revision 189101 and revision 189664
> on cxx-conversion branch.  Unfortunately, since branch was broken
> between those 2 revisions, I can't bisect further.

I only see

r189664 | dnovillo | 2012-07-19 16:40:11 +0200 (Thu, 19 Jul 2012) | 3 lines


Merge from trunk rev 189106.

"inbetween" those two revisions. r189668 is another merge from trunk,
so is r188963.  So I suspect a mismerge in r189106, r188963 was

r188963 | dnovillo | 2012-06-25 23:10:33 +0200 (Mon, 25 Jun 2012) | 7 lines

Merge from trunk

Merged revisions
188725-188729,188731,188733,188738-188749,188751-188755,188759,
188764-188765,188771,188776,188778,188780-188789,188791-188796,188802-188808,188
814-188815,188818,188820-188824,188826-188827,188829,188833,188838,188840-188843
,188847,188849,188852-188853,188856-188860,188865-188872,188874-188876,10-18
8881,14-15,188891,188893,188900-188902,188906-188909,188913,188915-18891
8,188922 via svnmerge from 
svn+ssh://gcc.gnu.org/svn/gcc/trunk

HJ, maybe you can help narrowing down things by trying different optimization
levels?  I see that using a memleak checker may not be possible with
10G memory usage.

Note that -fmem-report does not track all allocations, esp. heap hashtables
are not tracked.

[Bug middle-end/54224] [4.8 Regression] Bogus -Wunused-function warning with static function

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  2012-08-21 
08:48:49 UTC ---
* Regarding the inlining issue: I think that's known, cf. bug 48636 comment 18.

* It seems as if the TREE_USED part should be handled on the Fortran FE side
  for both (PRIVATE) module variables and module procedures

* Internal procedures should also be warned for; it probably requires some
  Fortran FE work as well as some middle-end work as there is currently also
  no warning for the GNU C extension.

[Bug fortran/54221] [4.8 Regression] Explicit private access specifier signals "unexpected defined but not used [-Wunused-function]" warning

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |4.8.0
Summary|Explicit private access |[4.8 Regression] Explicit
   |specifier signals   |private access specifier
   |"unexpected defined but not |signals "unexpected defined
   |used [-Wunused-function]"   |but not used
   |warning |[-Wunused-function]"
   ||warning

--- Comment #4 from Tobias Burnus  2012-08-21 
08:53:48 UTC ---
I mark this now as regression in the Fortran front-end to keep better track of
PR middle-end/54224: It seems as if part of the fix has to be done in the
Fortran front-end.

In this PR, the issue of having a different result with PRIVATE vs. "PRIVATE ::
entry_name" is now fixed.

It remains the issue that there is no warning for unused internal procedures
(or unused nested functions in C), no warning of unused PRIVATE module
variables and a spurious warning for *used* PRIVATE module procedures. Those
are tracked in PR 54224. Additionally, there is the issue that the private
module procedures is not inlined, see other PR and PR 48636 comment 18.

[Bug tree-optimization/46590] [4.6/4.7/4.8 Regression] long compile time with -O2 and many loops

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #23 from Steven Bosscher  2012-08-21 
09:42:42 UTC ---
(In reply to comment #13)
> The I/O parts of the FRE cost are due to value-numbering stores in
> visit_reference_op_store.  They can be drastically cut by an equivalent
> of (not generating code)
> 
> Index: trans-io.c
> ===
> --- trans-io.c  (revision 167111)
> +++ trans-io.c  (working copy)
> @@ -1670,6 +1670,7 @@ build_dt (tree function, gfc_code * code
>gfc_init_block (&post_iu_block);
> 
>var = gfc_create_var (st_parameter[IOPARM_ptype_dt].type, "dt_parm");
> +  gfc_add_modify (&block, var, build_constructor (TREE_TYPE (var), NULL));
> 
>set_error_locus (&block, var, &code->loc);
> 

You didn't post/commit this, but it looks like a reasonable change to me.

[Bug tree-optimization/46590] [4.6/4.7/4.8 Regression] long compile time with -O2 and many loops

[rguenther at suse dot de]

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

--- Comment #24 from rguenther at suse dot de  
2012-08-21 09:59:41 UTC ---
On Tue, 21 Aug 2012, steven at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
> 
> Steven Bosscher  changed:
> 
>What|Removed |Added
> 
>  CC||steven at gcc dot gnu.org
> 
> --- Comment #23 from Steven Bosscher  2012-08-21 
> 09:42:42 UTC ---
> (In reply to comment #13)
> > The I/O parts of the FRE cost are due to value-numbering stores in
> > visit_reference_op_store.  They can be drastically cut by an equivalent
> > of (not generating code)
> > 
> > Index: trans-io.c
> > ===
> > --- trans-io.c  (revision 167111)
> > +++ trans-io.c  (working copy)
> > @@ -1670,6 +1670,7 @@ build_dt (tree function, gfc_code * code
> >gfc_init_block (&post_iu_block);
> > 
> >var = gfc_create_var (st_parameter[IOPARM_ptype_dt].type, "dt_parm");
> > +  gfc_add_modify (&block, var, build_constructor (TREE_TYPE (var), NULL));
> > 
> >set_error_locus (&block, var, &code->loc);
> > 
> 
> You didn't post/commit this, but it looks like a reasonable change to me.

I think this is obsolete now with Michas change to have CLOBBERs.  Or
if still useful, the above should be a CLOBBER now.

Richard.

[Bug c++/54341] New: [4.7 / 4.8 Regression] ICE (segfault) in cx_check_missing_mem_inits, at cp/semantics.c:6093

[doko at gcc dot gnu.org]

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

 Bug #: 54341
   Summary: [4.7 / 4.8 Regression] ICE (segfault) in
cx_check_missing_mem_inits, at cp/semantics.c:6093
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gcc.gnu.org


[forwarded from http://bugs.debian.org/685430]

works with 4.6, fails with current 4.7 branch and trunk:

#include 


class VTableClass {
public:
virtual void someVirtualMethod() { }
};

class SomeClass : public std::enable_shared_from_this< SomeClass >, public
VTableClass { };

SomeClass* createInstance()
{
return new SomeClass;
}


g++ -std=c++0x -c testcase.cc 
testcase.cc: In constructor 'constexpr SomeClass::SomeClass()':
testcase.cc:9:7: internal compiler error: in cx_check_missing_mem_inits, at
cp/semantics.c:6093
 class SomeClass : public std::enable_shared_from_this< SomeClass >, public
VTableClass { };
   ^
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug c++/54333] sprinf and fprintf work not always equal

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|enhancement |normal

[Bug rtl-optimization/54342] New: [4.8 Regression] Wrong mode of call argument

[vbyakovl23 at gmail dot com]

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

 Bug #: 54342
   Summary: [4.8 Regression] Wrong mode of call argument
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vbyakov...@gmail.com


The argument of call has mode OI rather than V8SF. Test case

-
#include 

typedef union un1
{
__m256 x;
float f;
} UN1;
UN1 u;
extern __m256 y;
extern int bar2(UN1);

int foo2 ()
{
u.x = y;
return bar2(u);
}
--

Dump after expand

(note 4 2 5 3 [bb 3] NOTE_INSN_BASIC_BLOCK) 

(insn 5 4 6 3 (set (reg/f:DI 62) 
(symbol_ref:DI ("u")  )) er.c:13 -1 
 (nil)) 

(insn 6 5 7 3 (set (reg:V8SF 63) 
(mem/c:V8SF (symbol_ref:DI ("y") [flags 0x40]  ) [2 y+0 S32 A256])) er.c:13 -1 
 (nil)) 

(insn 7 6 8 3 (set (mem/c:V8SF (reg/f:DI 62) [0 u.x+0 S32 A256]) 
(reg:V8SF 63)) er.c:13 -1 
 (nil)) 

(insn 8 7 9 3 (set (reg/f:DI 65) 
(symbol_ref:DI ("u")  )) er.c:14 -1 
 (nil)) 

(insn 9 8 10 3 (set (reg:OI 64) 
(mem/c:OI (reg/f:DI 65) [3 u+0 S32 A256])) er.c:14 -1 
 (nil)) 

(insn 10 9 11 3 (set (reg:OI 21 xmm0) 
(reg:OI 64)) er.c:14 -1 
 (nil)) 

(call_insn/j 11 10 12 3 (parallel [ 
(set (reg:SI 0 ax) 
(call (mem:QI (symbol_ref:DI ("bar2") [flags 0x41] 
) [0 bar2 S1 A8]) 
(const_int 0 [0]))) 
(unspec [ 
(const_int 1 [0x1]) 
] UNSPEC_CALL_NEEDS_VZEROUPPER) 
]) er.c:14 -1 
 (nil) 
(expr_list:REG_DEP_TRUE (use (reg:OI 21 xmm0)) 
(nil)))

Following patch fixes that.

diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
index 53554a9..bb39e7f 100644
--- a/gcc/stor-layout.c
+++ b/gcc/stor-layout.c
@@ -1639,7 +1639,8 @@ compute_record_mode (tree type)
   /* If we only have one real field; use its mode if that mode's size
  matches the type's size.  This only applies to RECORD_TYPE.  This
  does not apply to unions.  */
-  if (TREE_CODE (type) == RECORD_TYPE && mode != VOIDmode
+  if ((TREE_CODE (type) == RECORD_TYPE || TREE_CODE (type) == UNION_TYPE)
+  && mode != VOIDmode
   && host_integerp (TYPE_SIZE (type), 1)
   && GET_MODE_BITSIZE (mode) == TREE_INT_CST_LOW (TYPE_SIZE (type)))
 SET_TYPE_MODE (type, mode);

[Bug rtl-optimization/54342] [4.8 Regression] Wrong mode of call argument

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

--- Comment #1 from Richard Guenther  2012-08-21 
11:08:27 UTC ---
> diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
> index 53554a9..bb39e7f 100644
> --- a/gcc/stor-layout.c
> +++ b/gcc/stor-layout.c
> @@ -1639,7 +1639,8 @@ compute_record_mode (tree type)
>/* If we only have one real field; use its mode if that mode's size
>   matches the type's size.  This only applies to RECORD_TYPE.  This
>   does not apply to unions.  */
> -  if (TREE_CODE (type) == RECORD_TYPE && mode != VOIDmode
> +  if ((TREE_CODE (type) == RECORD_TYPE || TREE_CODE (type) == UNION_TYPE)
> +  && mode != VOIDmode
>&& host_integerp (TYPE_SIZE (type), 1)
>&& GET_MODE_BITSIZE (mode) == TREE_INT_CST_LOW (TYPE_SIZE (type)))
>  SET_TYPE_MODE (type, mode);

Reading the comment immediately makes the patch suspicious.

[Bug rtl-optimization/54342] [4.8 Regression] Wrong mode of call argument

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-08-21 
11:10:13 UTC ---
Btw, please elaborate on why you consider this a bug.

[Bug rtl-optimization/54342] [4.8 Regression] Wrong mode of call argument

[vbyakovl23 at gmail dot com]

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

--- Comment #3 from Vladimir Yakovlev  2012-08-21 
11:18:39 UTC ---
I'm working on vzeroupper insertion and my implementation inserts vzeroupper
before the call because VALID_AVX256_REG_MODE returns false.

[Bug c++/54341] [4.7/4.8 Regression] ICE (segfault) in cx_check_missing_mem_inits, at cp/semantics.c:6093

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-21
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2012-08-21 
11:36:23 UTC ---
Seems closely related to PR54253.

[Bug rtl-optimization/54343] New: RTL postreload leaks DF memory

[rguenth at gcc dot gnu.org]

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

 Bug #: 54343
   Summary: RTL postreload leaks DF memory
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


With valgrind on the testcase from PR54146 you can see leaks of the kind

==28803== 3,984 bytes in 249 blocks are definitely lost in loss record 28,125
of 29,883
==28803==at 0x4C29ADD: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==28803==by 0xCE28D7: xmalloc (xmalloc.c:147)
==28803==by 0x6B064D: df_refs_add_to_chains(df_collection_rec*,
basic_block_def*, rtx_def*) (df-scan.c:2669)
==28803==by 0x6B5144: df_bb_refs_record(int, bool) (df-scan.c:3644)
==28803==by 0x6B524C: df_scan_blocks() (df-scan.c:678)
==28803==by 0x7B6B7D: rest_of_handle_reload() (ira.c:4390)
==28803==by 0x818C4A: execute_one_pass(opt_pass*) (passes.c:2157)
==28803==by 0x818F94: execute_pass_list(opt_pass*) (passes.c:2212)
==28803==by 0x818FA6: execute_pass_list(opt_pass*) (passes.c:2213)
==28803==by 0x68F583: expand_function(cgraph_node*) (cgraphunit.c:1609)
==28803==by 0x6909E8: compile() (cgraphunit.c:1714)
==28803==by 0x690F64: finalize_compilation_unit() (cgraphunit.c:2089)

do_reload re-adds the live problem and calls run_fast_dce.  Either that
or subsequent passes that end up removing instructions do not bother
with freeing associated DF info.  At least I don't see that delete_insn
calls df_insn_delete or so.  Thus keeping DF initialized throughout
postreload may be not the best idea ...

[Bug c++/54341] [4.7/4.8 Regression] ICE (segfault) in cx_check_missing_mem_inits, at cp/semantics.c:6093

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  2012-08-21 
11:46:12 UTC ---
Reduced:

template
struct enable_shared_from_this
{
  constexpr enable_shared_from_this();

private:
  int mem;
};

class VTableClass {
public:
virtual void someVirtualMethod() { }
};

class SomeClass : public enable_shared_from_this< SomeClass >, public
VTableClass { };

SomeClass* createInstance()
{
return new SomeClass;
}

[Bug rtl-optimization/54343] RTL postreload leaks DF memory

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-21
 Ever Confirmed|0   |1

--- Comment #1 from Steven Bosscher  2012-08-21 
11:50:19 UTC ---
> Thus keeping DF initialized throughout
> postreload may be not the best idea ...

The problem is not in DF, but in the passes that don't properly update the info
for it. Hopefully with df_refs in an alloc-pool it'll be easier where the ref
vecs leak from...

[Bug c++/54253] [C++11] constexpr constructor crashes with polymorphic base classes

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  2012-08-21 
11:53:53 UTC ---
Related to PR54341

[Bug target/54344] New: Issue with multiple "arch=" function attributes.

[einar.sjurso+gnu at gmail dot com]

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

 Bug #: 54344
   Summary: Issue with multiple "arch=" function attributes.
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: einar.sjurso+...@gmail.com


#include 
#include 

int __attribute__ ((__target__ ("arch=corei7-avx", "tune=corei7-avx")))
printf_avx(const char *restrict format, ...)
{
va_list ap;
va_start(ap, format);
const int ret = vfprintf(stdout, format, ap);
va_end(ap);
return ret;
}

int __attribute__ ((__target__ ("arch=atom", "tune=atom"))) printf_noavx(const
char *restrict format, ...)
{
va_list ap;
va_start(ap, format);
const int ret = vfprintf(stdout, format, ap);
va_end(ap);
return ret;
}

Given this silly example, vmovaps will ge generated in printf_noavx.

[Bug tree-optimization/54345] New: jump threading leaks e->aux heap memory

[rguenth at gcc dot gnu.org]

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

 Bug #: 54345
   Summary: jump threading leaks e->aux heap memory
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: memory-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


valgrind shows

==30772== 64 bytes in 4 blocks are definitely lost in loss record 15,347 of
29,883
==30772==at 0x4C29ADD: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==30772==by 0xCE28C7: xmalloc (xmalloc.c:147)
==30772==by 0x99C8E8: thread_through_all_blocks(bool)
(tree-ssa-threadupdate.c:1134)
==30772==by 0x92BDCF: tree_ssa_dominator_optimize() (tree-ssa-dom.c:790)
==30772==by 0x818C3A: execute_one_pass(opt_pass*) (passes.c:2157)
==30772==by 0x818F84: execute_pass_list(opt_pass*) (passes.c:2212)
==30772==by 0x818F96: execute_pass_list(opt_pass*) (passes.c:2213)
==30772==by 0x68F583: expand_function(cgraph_node*) (cgraphunit.c:1609)
==30772==by 0x6909E8: compile() (cgraphunit.c:1714)
==30772==by 0x690F64: finalize_compilation_unit() (cgraphunit.c:2089)
==30772==by 0x564956: cp_write_global_declarations() (decl2.c:4024)
==30772==by 0x8AABF4: compile_file() (toplev.c:560)

that would be easily solvable by using an obstack for the allocation
of the two pointers.  That would be cheaper as well.  It's lifetime
would be thread_through_all_blocks ().

[Bug middle-end/54146] Very slow compile with attribute((flatten))

[rguenth at gcc dot gnu.org]

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

--- Comment #57 from Richard Guenther  2012-08-21 
13:34:28 UTC ---
Author: rguenth
Date: Tue Aug 21 13:34:19 2012
New Revision: 190562

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190562
Log:
2012-08-21  Richard Guenther  

Backport from mainline
2012-08-16  Richard Guenther  

PR middle-end/54146
* tree-ssa-loop-niter.c (find_loop_niter_by_eval): Free the
exit vector.
* ipa-pure-const.c (analyze_function): Use FOR_EACH_LOOP_BREAK.
* cfgloop.h (FOR_EACH_LOOP_BREAK): Fix.
* tree-ssa-structalias.c (handle_lhs_call): Properly free rhsc.
* tree-ssa-loop-im.c (analyze_memory_references): Adjust.
(tree_ssa_lim_finalize): Free all mem_refs.
* tree-ssa-sccvn.c (extract_and_process_scc_for_name): Free
scc when bailing out.
* modulo-sched.c (sms_schedule): Use FOR_EACH_LOOP_BREAK.
* ira-build.c (loop_with_complex_edge_p): Free loop exit vector.
* graphite-sese-to-poly.c (scop_ivs_can_be_represented): Use
FOR_EACH_LOOP_BREAK.

2012-08-17  Richard Guenther  

* tree-sra.c (modify_function): Free redirect_callers vector.
* ipa-split.c (split_function): Free args_to_pass vector.
* tree-vect-stmts.c (vectorizable_operation): Do not pre-allocate
vec_oprnds.
(new_stmt_vec_info): Do not pre-allocate STMT_VINFO_SAME_ALIGN_REFS.
* tree-vect-slp.c (vect_free_slp_instance): Free the instance.
(vect_analyze_slp_instance): Free everything.
(destroy_bb_vec_info): Free the SLP instances.

2012-08-17  Richard Guenther  

* params.def (integer-share-limit): Decrease from 256 to 251,
add rationale.

2012-08-21  Richard Guenther  

* tree-ssa-loop-im.c (tree_ssa_lim_finalize): Properly free
the affine expansion cache.

Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/cfgloop.h
branches/gcc-4_7-branch/gcc/graphite-sese-to-poly.c
branches/gcc-4_7-branch/gcc/ipa-pure-const.c
branches/gcc-4_7-branch/gcc/ipa-split.c
branches/gcc-4_7-branch/gcc/ira-build.c
branches/gcc-4_7-branch/gcc/modulo-sched.c
branches/gcc-4_7-branch/gcc/params.def
branches/gcc-4_7-branch/gcc/tree-sra.c
branches/gcc-4_7-branch/gcc/tree-ssa-loop-im.c
branches/gcc-4_7-branch/gcc/tree-ssa-loop-niter.c
branches/gcc-4_7-branch/gcc/tree-ssa-sccvn.c
branches/gcc-4_7-branch/gcc/tree-ssa-structalias.c
branches/gcc-4_7-branch/gcc/tree-vect-slp.c
branches/gcc-4_7-branch/gcc/tree-vect-stmts.c

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[dnovillo at google dot com]

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

--- Comment #6 from dnovillo at google dot com  
2012-08-21 13:38:24 UTC ---
On 2012-08-20 22:59 , hjl.tools at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
>
> --- Comment #4 from H.J. Lu  2012-08-21 02:59:15 
> UTC ---
> It was introduced between revision 189101 and revision 189664
> on cxx-conversion branch.  Unfortunately, since branch was broken
> between those 2 revisions, I can't bisect further.
>

There was no rev 189101 in cxx-conversion.  That is a trunk revision. 
In that range of revisions, there are only merges from trunk until rev 
188129, which introduces the new hash table.

Prior to that, we have rev 188059, which makes cosmetic changes to 
configure.ac.

If it's related to the hash table, then comparing rev 188059 vs rev 
188129 may show the regression.


Diego.

[Bug c++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'

[jojelino at gmail dot com]

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

--- Comment #5 from gee  2012-08-21 13:38:57 UTC ---
I think symbol _ZTCSt* need to be included in libstdc++/config/abi/pre/gnu.ver
so that shared-library can export these symbols unless user   did append
--disable-symvers.
nothing need to be done such as reverting the commit or so.

[Bug middle-end/54146] Very slow compile with attribute((flatten))

[stevenb.gcc at gmail dot com]

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

--- Comment #58 from stevenb.gcc at gmail dot com  2012-08-21 13:56:27 UTC ---
FWIW, I think all patches addressing parts of this bug are candidates
for back-porting to release branches. They are all almost trivial.

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  2012-08-21 13:58:05 
UTC ---
(In reply to comment #6)
> 
> If it's related to the hash table, then comparing rev 188059 vs rev 
> 188129 may show the regression.
> 

Neither rev 188059 nor rev 188129 will build:

../../../../gcc/gcc/graphite-sese-to-poly.c: In function \u2018void
build_sese_conditions_before(dom_walk_data*, basic_block)\u2019:
../../../../gcc/gcc/graphite-sese-to-poly.c:1357:2: error: call of overloaded
\u2018VEC_safe_push_1(vec_t**, NULL, const char [44], int,
const char [29])\u2019 is ambiguous
../../../../gcc/gcc/graphite-sese-to-poly.c:1357:2: note: candidates are: 
In file included from ../../../../gcc/gcc/basic-block.h:25:0,
 from ../../../../gcc/gcc/tree-flow.h:27,
 from ../../../../gcc/gcc/graphite-sese-to-poly.c:24:
../../../../gcc/gcc/vec.h:674:1: note: T& VEC_safe_push_1(vec_t**, T, const
char*, unsigned int, const char*) [with T = gimple_statement_d*;
vec_allocation_t A = (vec_allocation_t)0u]
../../../../gcc/gcc/vec.h:682:1: note: T* VEC_safe_push_1(vec_t**, const T*,
const char*, unsigned int, const char*) [with T = gimple_statement_d*;
vec_allocation_t A = (vec_allocation_t)0u]
make[2]: *** [graphite-sese-to-poly.o] Error 1
  2692,40   99%

[Bug tree-optimization/54346] New: combine permutations

[glisse at gcc dot gnu.org]

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

 Bug #: 54346
   Summary: combine permutations
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org


Hello,

when we have two VEC_PERM_EXPR with constant mask, where one is the only user
of the result of the other one, it would be good to compose/merge them into a
single VEC_PERM_EXPR. However, it is too hard for backends to always generate
optimal code for shuffles, so we want to do the optimization only if we know it
actually helps. Currently this means when the composed permutation is the
identity. In the future, it could mean asking the backend.

See the conversation that started at:
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00676.html

and around this message for cost hooks (which could also help the vectorizer):
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00973.html

Related bug is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147 but that one
is about RTL (unless x86 eventually follows ARM and decides to implement _mm_*
functions in terms of __builtin_shuffle).

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[dnovillo at google dot com]

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

--- Comment #8 from dnovillo at google dot com  
2012-08-21 14:06:34 UTC ---
On 2012-08-21 09:58 , hjl.tools at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
>
> --- Comment #7 from H.J. Lu  2012-08-21 13:58:05 
> UTC ---
> (In reply to comment #6)
>>
>> If it's related to the hash table, then comparing rev 188059 vs rev
>> 188129 may show the regression.
>>
>
> Neither rev 188059 nor rev 188129 will build:
>
> ../../../../gcc/gcc/graphite-sese-to-poly.c: In function \u2018void
> build_sese_conditions_before(dom_walk_data*, basic_block)\u2019:
> ../../../../gcc/gcc/graphite-sese-to-poly.c:1357:2: error: call of overloaded
> \u2018VEC_safe_push_1(vec_t**, NULL, const char [44], 
> int,
> const char [29])\u2019 is ambiguous
> ../../../../gcc/gcc/graphite-sese-to-poly.c:1357:2: note: candidates are:
> In file included from ../../../../gcc/gcc/basic-block.h:25:0,
>   from ../../../../gcc/gcc/tree-flow.h:27,
>   from ../../../../gcc/gcc/graphite-sese-to-poly.c:24:
> ../../../../gcc/gcc/vec.h:674:1: note: T& VEC_safe_push_1(vec_t**, T, const
> char*, unsigned int, const char*) [with T = gimple_statement_d*;
> vec_allocation_t A = (vec_allocation_t)0u]
> ../../../../gcc/gcc/vec.h:682:1: note: T* VEC_safe_push_1(vec_t**, const 
> T*,
> const char*, unsigned int, const char*) [with T = gimple_statement_d*;
> vec_allocation_t A = (vec_allocation_t)0u]
> make[2]: *** [graphite-sese-to-poly.o] Error 1
>2692,40   
> 99%
>

Huh, odd.  Can you try this patchlet on top of those revs?  It builds 
for me with this applied:

diff --git a/gcc/graphite-sese-to-poly.c b/gcc/graphite-sese-to-poly.c
index cdabd73..5712e58 100644
--- a/gcc/graphite-sese-to-poly.c
+++ b/gcc/graphite-sese-to-poly.c
@@ -1354,7 +1354,7 @@ build_sese_conditions_before (struct dom_walk_data 
*dw_data,
if (e->flags & EDGE_TRUE_VALUE)
 VEC_safe_push (gimple, heap, *cases, stmt);
else
-   VEC_safe_push (gimple, heap, *cases, NULL);
+   VEC_safe_push (gimple, heap, *cases, (gimple) NULL);
  }

gbb = gbb_from_bb (bb);

[Bug tree-optimization/46590] [4.6/4.7/4.8 Regression] long compile time with -O2 and many loops

[rguenth at gcc dot gnu.org]

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

--- Comment #25 from Richard Guenther  2012-08-21 
14:10:38 UTC ---
I have a patch for the SCCVN issue, but trying to gather current trunk status
first.

[Bug tree-optimization/46590] [4.6/4.7/4.8 Regression] long compile time with -O2 and many loops

[rguenth at gcc dot gnu.org]

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

--- Comment #26 from Richard Guenther  2012-08-21 
14:56:41 UTC ---
For a somewhat reduced testcase I now get at -O1:

 alias stmt walking  : 105.51 (45%) usr   0.33 (24%) sys
 tree SSA rewrite:  22.01 ( 9%) usr   0.04 ( 3%) sys
 tree SSA incremental:  25.25 (11%) usr   0.07 ( 5%) sys
 dominance frontiers :  35.35 (15%) usr   0.02 ( 1%) sys
 dominance computation   :  14.60 ( 6%) usr   0.09 ( 7%) sys
 TOTAL : 234.28 1.38

as previously said most of the non-alias-stmt walk time is spent
on loop header copying.  WIth -O1 -fno-tree-ch we have

 alias stmt walking  : 101.52 (68%) usr   0.37 (34%) sys
 tree SSA rewrite:   4.14 ( 3%) usr   0.01 ( 1%) sys
 tree SSA incremental:   8.00 ( 5%) usr   0.02 ( 2%) sys
 dominance frontiers :   6.14 ( 4%) usr   0.01 ( 1%) sys
 dominance computation   :   4.74 ( 3%) usr   0.06 ( 6%) sys
 TOTAL : 150.14 1.09

limiting stmt walk results in the ability to arbitrarily scale down its cost
with a param (we can either limit alias oracle query numbers or SCCVN
table lookups).  With 100 alias oracle queries per load/store we end up with

 alias stmt walking  :   1.60 ( 3%) usr   0.05 ( 5%) sys

with 100 SCCVN table lookups the figure is

 alias stmt walking  :   1.60 ( 3%) usr   0.06 ( 6%) sys

one assumes the lookups are expensive, the other one assumes the walk itself
is.
Increasing the latter to 1000 SCCVN table lookup produces

 alias stmt walking  :   9.24 (16%) usr   0.18 (19%) sys

which is around the expected 10-fold increase (but still reasonable given
the artificial nature of the testcase).  We could also, instead of
limiting each walk to a constant cost, have a per-function budget that
we can use up first before limiting further walks individually (helps
to not regress reasonably sized cases).

[Bug target/54347] New: REAL_VALUE_TO_TARGET_LONG_DOUBLE shouldn't be used in i386

[hjl.tools at gmail dot com]

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

 Bug #: 54347
   Summary: REAL_VALUE_TO_TARGET_LONG_DOUBLE shouldn't be used in
i386
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com


i386.c has

  /* The __float80 type.  */
  float80_type_node = long_double_type_node;
  if (TYPE_MODE (float80_type_node) != XFmode)
{
  /* The __float80 type.  */
  float80_type_node = make_node (REAL_TYPE);

  TYPE_PRECISION (float80_type_node) = 80;
  layout_type (float80_type_node);
}
  lang_hooks.types.register_builtin_type (float80_type_node, "__float80");

and

i386-interix.h:#undef LONG_DOUBLE_TYPE_SIZE
i386-interix.h:#define LONG_DOUBLE_TYPE_SIZE 64

long double may not be 80-bit.  But i386.c has

   case XFmode:
  REAL_VALUE_TO_TARGET_LONG_DOUBLE (r, l);
  parts[2] = gen_int_mode (l[2], SImode);
  break;

It assumes long double is in XFmode.  It should simply use

real_to_target (l, &r, mode);

instead of

REAL_VALUE_TO_TARGET_LONG_DOUBLE (r, l);

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  2012-08-21 16:20:37 
UTC ---
Revision 188059 is bad:

f951: out of memory allocating 36872 bytes after a total of 583266304 bytes

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[dnovillo at google dot com]

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

--- Comment #10 from dnovillo at google dot com  
2012-08-21 16:44:10 UTC ---
On Tue, Aug 21, 2012 at 12:20 PM, hjl.tools at gmail dot com
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
>
> --- Comment #9 from H.J. Lu  2012-08-21 16:20:37 
> UTC ---
> Revision 188059 is bad:
>
> f951: out of memory allocating 36872 bytes after a total of 583266304 bytes

Thanks.  Does rev 188129 show the same thing?  The next revisions to try are:

188040 (TREE_CHECK macros)
187954 (merge from trunk)
187836 (initial VEC conversion)
187735 (merge from trunk)

I now have access to SPEC2006, I'll try a build.

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2012-08-20 00:00:00 |2012-08-21
 Ever Confirmed|0   |1

--- Comment #11 from H.J. Lu  2012-08-21 16:51:24 
UTC ---
It is caused by revision 187836:

http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00833.html

The C++ implementation of vec.[ch] has a massive memory leak.

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[dnovillo at gcc dot gnu.org]

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

Diego Novillo  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #12 from Diego Novillo  2012-08-21 
16:55:34 UTC ---
Thanks.  I'll work on a fix.

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu  2012-08-21 17:10:09 
UTC ---
It can be reproduced with -frecord-marker=4 -O -funswitch-loops.

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|gcc-bugs at gcc dot gnu.org |

--- Comment #17 from Paolo Carlini  2012-08-21 
17:20:06 UTC ---
Jon, are you actively working on this? I found this last message:

  http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01477.html

Let me know if I can help...

[Bug c++/2778] -fdump-translation-unit [Simple patch supplied, needs review]

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|gcc-bugs at gcc dot gnu.org |

--- Comment #14 from Paolo Carlini  2012-08-21 
17:23:34 UTC ---
Gaby, are you actively working on this?

[Bug libstdc++/54307] [4.7 regression] increases in memory usage by some C++11 (and C++03) standard containers

[matt at use dot net]

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

--- Comment #3 from Matt Hargett  2012-08-21 17:26:55 UTC 
---
Paolo, what about list? Does VC11 achieve the size GCC 4.6 has by not
being compliant somehow?

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely  2012-08-21 
17:26:16 UTC ---
No, not at present. I tried using default_init_uninitialized_part but it either
missed cases or produce ICEs, and I never solved the problems. I can send you
my work-in-progress when I get home, it would be great if you could help me
with the issues I don't understand.

[Bug libstdc++/54307] [4.7 regression] increases in memory usage by some C++11 (and C++03) standard containers

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2012-08-21 
17:35:25 UTC ---
I have no idea what they are doing in their implementation, there are of course
trade offs. When we decide to globally break the ABI to implement a C++11
Standard Conforming std:list we mean to add a data member to provide an O(1)
list<>::size(), that is what we already "experimented" in 4.7.0. Unless of
course over the next months somebody suggests something else which goes well
together with our other design choices.

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[hjl.tools at gmail dot com]

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

--- Comment #14 from H.J. Lu  2012-08-21 17:41:10 
UTC ---
It failed even with

diff --git a/gcc/tree-ssa-loop.c b/gcc/tree-ssa-loop.c
index 3d650bf..30ac4b5 100644
--- a/gcc/tree-ssa-loop.c
+++ b/gcc/tree-ssa-loop.c
@@ -149,7 +149,7 @@ tree_ssa_loop_unswitch (void)
 static bool
 gate_tree_ssa_loop_unswitch (void)
 {
-  return flag_unswitch_loops != 0;
+  return false;
 }

 struct gimple_opt_pass pass_tree_unswitch =

[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez  2012-08-21 
17:46:26 UTC ---
My bad... I'm on this.

[Bug c++/54341] [4.7/4.8 Regression] ICE (segfault) in cx_check_missing_mem_inits, at cp/semantics.c:6093

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||jason at redhat dot com
   Target Milestone|--- |4.7.2

--- Comment #3 from H.J. Lu  2012-08-21 17:50:43 
UTC ---
It is caused by revision 184001:

http://gcc.gnu.org/ml/gcc-cvs/2012-02/msg00220.html

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[paolo.carlini at oracle dot com]

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

--- Comment #19 from Paolo Carlini  2012-08-21 
17:54:12 UTC ---
Eh, I'm of course not sure that I can help but I quickly went through the
exchange on gcc-patches and got the impression that your work was already in an
advanced stage, thus we should try to finish it! I'm pretty sure that we can
make it in time for 4.8.0 (maybe with one or two more rounds of focused tips
from Jason)

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[hjl.tools at gmail dot com]

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

--- Comment #15 from H.J. Lu  2012-08-21 17:57:59 
UTC ---
It failed with

diff --git a/gcc/passes.c b/gcc/passes.c
index b6fe18e..10174c4 100644
--- a/gcc/passes.c
+++ b/gcc/passes.c
@@ -1449,7 +1449,6 @@ init_optimization_passes (void)
 NEXT_PASS (pass_lim);
 NEXT_PASS (pass_copy_prop);
 NEXT_PASS (pass_dce_loop);
-NEXT_PASS (pass_tree_unswitch);
 NEXT_PASS (pass_scev_cprop);
 NEXT_PASS (pass_record_bounds);
 NEXT_PASS (pass_check_data_deps);

Somehow just processing the -funswitch-loops command-line option
triggers this problem.

[Bug driver/54335] -dm doesn't work

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2012-08-21 18:03:17 
UTC ---
There are:

opts.c:typedef char *char_p; /* For DEF_VEC_P.  */
opts.c:DEF_VEC_P(char_p);
opts.c:DEF_VEC_ALLOC_P(char_p,heap);
opts-global.c:typedef const char *const_char_p; /* For DEF_VEC_P.  */
opts-global.c:DEF_VEC_P(const_char_p);
opts-global.c:DEF_VEC_ALLOC_P(const_char_p,heap);

Will they cause problems if other files define similar types?

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[hjl.tools at gmail dot com]

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

--- Comment #16 from H.J. Lu  2012-08-21 18:08:49 
UTC ---
There are:

opts.c:typedef char *char_p; /* For DEF_VEC_P.  */
opts.c:DEF_VEC_P(char_p);
opts.c:DEF_VEC_ALLOC_P(char_p,heap);
opts-global.c:typedef const char *const_char_p; /* For DEF_VEC_P.  */
opts-global.c:DEF_VEC_P(const_char_p);
opts-global.c:DEF_VEC_ALLOC_P(const_char_p,heap);

Will they cause problems if other files define similar types?

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[dnovillo at google dot com]

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

--- Comment #17 from dnovillo at google dot com  
2012-08-21 18:19:10 UTC ---
On 2012-08-21 14:08 , hjl.tools at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
>
> --- Comment #16 from H.J. Lu  2012-08-21 18:08:49 
> UTC ---
> There are:
>
> opts.c:typedef char *char_p; /* For DEF_VEC_P.  */
> opts.c:DEF_VEC_P(char_p);
> opts.c:DEF_VEC_ALLOC_P(char_p,heap);
> opts-global.c:typedef const char *const_char_p; /* For DEF_VEC_P.  */
> opts-global.c:DEF_VEC_P(const_char_p);
> opts-global.c:DEF_VEC_ALLOC_P(const_char_p,heap);
>
> Will they cause problems if other files define similar types?
>

They shouldn't.  DEF_VEC_* expands to a NOP now.  The allocation 
strategy is only needed during the actual allocation call.  So, in the 
case of opts.c, that would be in add_comma_separated_to_vector() (the 
call to VEC_safe_push).

Those two vectors are only used for -finstrument-options..., though.  So 
that does not seem related.

The call to postpone_unknown_option_warning in opts-global.c seems also 
unrelated.  It's only used when processing unknown options.  That vector 
is popped when the unknown options are freed, so that can't be it either.

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[dnovillo at google dot com]

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

--- Comment #18 from dnovillo at google dot com  
2012-08-21 18:31:51 UTC ---
OK, I think this is the hunk that's causing grief:

diff --git a/gcc/df-scan.c b/gcc/df-scan.c
index 39f444f..35100d1 100644
--- a/gcc/df-scan.c
+++ b/gcc/df-scan.c
@@ -4392,7 +4392,6 @@ df_bb_verify (basic_block bb)
if (!INSN_P (insn))
  continue;
df_insn_refs_verify (&collection_rec, bb, insn, true);
-  df_free_collection_rec (&collection_rec);
  }

/* Do the artificial defs and uses.  */


I remember that I ran into this during the VEC conversion 
(http://gcc.gnu.org/ml/gcc/2012-05/msg00271.html) and after some 
discussion I ended up convincing myself that taking it out was harmless. 
  Clearly, I was wrong.

I've hooked gdb to the running f951 and it's stuck in df_bb_verify().

Odd that this has not triggered anywhere else.

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[hjl.tools at gmail dot com]

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

--- Comment #19 from H.J. Lu  2012-08-21 18:54:45 
UTC ---
(In reply to comment #15)
> It failed with
> 
> diff --git a/gcc/passes.c b/gcc/passes.c
> index b6fe18e..10174c4 100644
> --- a/gcc/passes.c
> +++ b/gcc/passes.c
> @@ -1449,7 +1449,6 @@ init_optimization_passes (void)
>  NEXT_PASS (pass_lim);
>  NEXT_PASS (pass_copy_prop);
>  NEXT_PASS (pass_dce_loop);
> -NEXT_PASS (pass_tree_unswitch);
>  NEXT_PASS (pass_scev_cprop);
>  NEXT_PASS (pass_record_bounds);
>  NEXT_PASS (pass_check_data_deps);
> 
> Somehow just processing the -funswitch-loops command-line option
> triggers this problem.

With --enable-gather-detailed-mem-stats, I got

Alloc-pool Kind Elt size  Pools  Allocated (elts)Peak
(elts)Leak (elts)

-df_scan ref base   64 18   24808192(387628)   11869056(   
185454)  0( 0)
-df_scan ref artificial 72 18   15168528(210674)2044944(   
 28402)  0( 0)
+df_scan ref base   64 18  513091264(   8017051)  500077440(  
7813710)  0( 0)
+df_scan ref artificial 72 18  599905368(   8332019)2044944(   
 28402)  0( 0)
 elt_loc_list   32 277982112(249441)2399488(   
 74984)  0( 0)  
-df_scan ref regular72 18   71483184(992822)   45955584(   
638272)  0( 0)
+df_scan ref regular72 18 2091195360(  29044380) 2065579776( 
28688608)  0( 0)
 df_scan insn   56 187681016(137161)3340848(   
 59658)  0( 0)

-Total  15775  253131240
+Total  16067 3345899232

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[dnovillo at google dot com]

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

--- Comment #20 from dnovillo at google dot com  
2012-08-21 19:07:33 UTC ---
On 2012-08-21 14:54 , hjl.tools at gmail dot com wrote:

> With --enable-gather-detailed-mem-stats, I got
>
> Alloc-pool Kind Elt size  Pools  Allocated (elts)Peak
> (elts)Leak (elts)
>
> -df_scan ref base   64 18   24808192(387628)   11869056(
> 185454)  0( 0)
> -df_scan ref artificial 72 18   15168528(210674)2044944(
>   28402)  0( 0)
> +df_scan ref base   64 18  513091264(   8017051)  500077440(
> 7813710)  0( 0)
> +df_scan ref artificial 72 18  599905368(   8332019)2044944(
>   28402)  0( 0)
>   elt_loc_list   32 277982112(249441)2399488(
>   74984)  0( 0)
> -df_scan ref regular72 18   71483184(992822)   45955584(
> 638272)  0( 0)
> +df_scan ref regular72 18 2091195360(  29044380) 2065579776(
> 28688608)  0( 0)
>   df_scan insn   56 187681016(137161)3340848(
>   59658)  0( 0)
>
> -Total  15775  253131240
> +Total  16067 3345899232
>

That agrees with what I found, thanks.  I've added a link to the 
discussion about the df verifier.  The vectors need to be cleared, but I 
can't just free the vectors:

Stack vectors must be initially allocated with VEC_stack_alloc.
gcc/df-scan.c: In function 'unsigned int df_count_refs(bool, bool, bool)':
gcc/df-scan.c:1507:1: internal compiler error: in vec_reserve, at vec.h:
  }

[Bug rtl-optimization/54343] RTL postreload leaks DF memory

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #2 from Steven Bosscher  2012-08-21 
19:20:10 UTC ---
May be related to PR54332 ...

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[steven at gcc dot gnu.org]

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

--- Comment #21 from Steven Bosscher  2012-08-21 
19:19:58 UTC ---
(In reply to comment #18)
> Odd that this has not triggered anywhere else.

It may have triggered elsewhere, see PR54343 ...

[Bug c++/20420] Incorrectly Accepts double declarations

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|gcc-bugs at gcc dot gnu.org |
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
  Known to fail||

--- Comment #7 from Paolo Carlini  2012-08-21 
19:25:05 UTC ---
Currently, the original testcase is *almost* handled correctly - we need
something like the below to avoid an ICE with enums - but we still accept the
snippet in Comment #4: I just checked and apparently per C++11 too we should
reject it. Looking a bit into this, maybe for now I will end up submitting only
the patchlet.

Index: name-lookup.c
===
--- name-lookup.c(revision 190569)
+++ name-lookup.c(working copy)
@@ -441,7 +441,8 @@ supplement_binding_1 (cxx_binding *binding, tree d
  template in order to handle late matching of underlying
  type on an opaque-enum-declaration followed by an
  enum-specifier.  */
-  || (TREE_CODE (TREE_TYPE (target_decl)) == ENUMERAL_TYPE
+  || (processing_template_decl
+  && TREE_CODE (TREE_TYPE (target_decl)) == ENUMERAL_TYPE
   && TREE_CODE (TREE_TYPE (target_bval)) == ENUMERAL_TYPE
   && (dependent_type_p (ENUM_UNDERLYING_TYPE
 (TREE_TYPE (target_decl)))

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[hjl.tools at gmail dot com]

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

--- Comment #22 from H.J. Lu  2012-08-21 19:27:50 
UTC ---
This seems to work:

diff --git a/gcc/df-scan.c b/gcc/df-scan.c
index 35100d1..39f444f 100644
--- a/gcc/df-scan.c
+++ b/gcc/df-scan.c
@@ -4392,6 +4392,7 @@ df_bb_verify (basic_block bb)
   if (!INSN_P (insn))
 continue;
   df_insn_refs_verify (&collection_rec, bb, insn, true);
+  df_free_collection_rec (&collection_rec);
 }

   /* Do the artificial defs and uses.  */
diff --git a/gcc/vec.h b/gcc/vec.h
index cc7e819..3a298ff 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -1031,21 +1031,9 @@ vec_reserve (vec_t *vec_, int reserve MEM_STAT_DECL)
   sizeof (T), false
   PASS_MEM_STAT);
   else
-{
-  /* Only allow stack vectors when re-growing them.  The initial
- allocation of stack vectors must be done with the
- VEC_stack_alloc macro, because it uses alloca() for the
- allocation.  */
-  if (vec_ == NULL)
-{
-  fprintf (stderr, "Stack vectors must be initially allocated "
-   "with VEC_stack_alloc.\n");
-  gcc_unreachable ();
-}
-  return (vec_t *) vec_stack_o_reserve (vec_, reserve,
-   offsetof (vec_t, vec),
-   sizeof (T) PASS_MEM_STAT);
-}
+return (vec_t *) vec_stack_o_reserve (vec_, reserve,
+ offsetof (vec_t, vec),
+ sizeof (T) PASS_MEM_STAT);
 }

[Bug c++/54348] New: wrong error reported for type mismatch in conditional expression : "error: no match for ternary 'operator?:' in 'false ?"

[jason.vas.dias at gmail dot com]

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

 Bug #: 54348
   Summary: wrong error reported for type mismatch in conditional
expression : "error: no match for ternary 'operator?:'
in 'false ?"
Classification: Unclassified
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jason.vas.d...@gmail.com


Having  made the simple mistake of returning an object of a different type
in the '? ( ... )' and ': ( ... )' clauses of a ternary expression ,
I'd expect and it would be helpful if g++ would emit the "C" error
  "error: type mismatch in conditional expression" and not
  "error: no match for ternary 'operator?:' in 'false ? ..."
This is extremely confusing, as it suggests that the ternary expression
 somehow contains an unbalanced number of parentheses or something.

This code triggers the issue:


#include 
#include 
using namespace std;
void f()
{
  struct strct { string name, items ;};
  list  myItems;
  string myName("");
  string as  ( (   (&(((strct*)0)  -> items)) 
== (&(((strct*)0) -> name))
   ) ? myItems 
 : myName
 )
 ;
}


Compilation with gcc-4.6.0 & gcc-4.6.3 returns this error:

$ g++ -c gxx_bug.cpp
gxx_bug.cpp: In function 'void f()':
gxx_bug.cpp:12:14: error: no match for ternary 'operator?:' in 'false ? myItems
: myName'

whereas changing 'list  myItems' to 'string myItems' allows compilation
to succeed.

Shouldn't g++ be complaining about initializing a string with a list
rather than this cryptic "no match for ternary 'operator?:'" here ?

[Bug c++/54348] confusing error reported for type mismatch in conditional expression : "error: no match for ternary 'operator?:' in 'false ?"

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-21
Summary|wrong error reported for|confusing error reported
   |type mismatch in|for type mismatch in
   |conditional expression :|conditional expression :
   |"error: no match for|"error: no match for
   |ternary 'operator?:' in |ternary 'operator?:' in
   |'false ?"   |'false ?"
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2012-08-21 
19:44:55 UTC ---
In mainline the diagnostics is better because we output the types. But I agree
that given that the conditional operator cannot be overloaded the error message
could be more clear.

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[dnovillo at google dot com]

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

--- Comment #23 from dnovillo at google dot com  
2012-08-21 19:50:12 UTC ---
On 2012-08-21 15:27 , hjl.tools at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
>
> --- Comment #22 from H.J. Lu  2012-08-21 19:27:50 
> UTC ---
> This seems to work:
>
> diff --git a/gcc/df-scan.c b/gcc/df-scan.c
> index 35100d1..39f444f 100644
> --- a/gcc/df-scan.c
> +++ b/gcc/df-scan.c
> @@ -4392,6 +4392,7 @@ df_bb_verify (basic_block bb)
> if (!INSN_P (insn))
>   continue;
> df_insn_refs_verify (&collection_rec, bb, insn, true);
> +  df_free_collection_rec (&collection_rec);
>   }
>
> /* Do the artificial defs and uses.  */
> diff --git a/gcc/vec.h b/gcc/vec.h
> index cc7e819..3a298ff 100644
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -1031,21 +1031,9 @@ vec_reserve (vec_t *vec_, int reserve MEM_STAT_DECL)
> sizeof (T), false
> PASS_MEM_STAT);
> else
> -{
> -  /* Only allow stack vectors when re-growing them.  The initial
> - allocation of stack vectors must be done with the
> - VEC_stack_alloc macro, because it uses alloca() for the
> - allocation.  */
> -  if (vec_ == NULL)
> -{
> -  fprintf (stderr, "Stack vectors must be initially allocated "
> -   "with VEC_stack_alloc.\n");
> -  gcc_unreachable ();
> -}
> -  return (vec_t *) vec_stack_o_reserve (vec_, reserve,
> -   offsetof (vec_t, vec),
> -   sizeof (T) PASS_MEM_STAT);
> -}
> +return (vec_t *) vec_stack_o_reserve (vec_, reserve,
> + offsetof (vec_t, vec),
> + sizeof (T) PASS_MEM_STAT);
>   }
>

The problem with this is that you are switching a stack vec into a heap 
vec.  This may not always be what the caller wanted.


The other alternative is to truncate the vectors after the call to 
df_insn_refs_verify().

[Bug c++/54348] confusing error reported for type mismatch in conditional expression : "error: no match for ternary 'operator?:' in 'false ?"

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-08-21 
19:51:53 UTC ---
(In reply to comment #0)
> Shouldn't g++ be complaining about initializing a string with a list
> rather than this cryptic "no match for ternary 'operator?:'" here ?

No, not really.

The object being initialized by the result of the condition expression is
irrelevant, the conditional expression isn't valid whether or not you're using
it to initialize another object.

In this reduced version it wouldn't make sense to refer to initializing any
object with any other:

struct A {} a;
struct B {} b;

void f()
{
false ? a : b;
}

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[hjl.tools at gmail dot com]

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

--- Comment #24 from H.J. Lu  2012-08-21 19:53:14 
UTC ---
(In reply to comment #23)
> 
> The problem with this is that you are switching a stack vec into a heap 
> vec.  This may not always be what the caller wanted.

My patch just restores the old behavior.

> 
> The other alternative is to truncate the vectors after the call to 
> df_insn_refs_verify().

This should be a separate patch, not the part of C++ conversion.

[Bug c++/54348] confusing error reported for type mismatch in conditional expression : "error: no match for ternary 'operator?:' in 'false ?"

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2012-08-21 
20:08:02 UTC ---
Indeed.

About my own reply, I'm not sure, the wording here is pretty subtle, we already
handle separately the ambiguous overloading case. ICC refers explicitly to the
types being incompatible, maybe focusing on the types is more clear when the
operator at issue cannot be overloaded.

[Bug c++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'

[jojelino at gmail dot com]

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

--- Comment #6 from gee  2012-08-21 20:10:01 UTC ---
Created attachment 28065
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28065
proposed patch

just added one line.
_ZTC* is then exported.

[Bug c++/54348] confusing error reported for type mismatch in conditional expression : "error: no match for ternary 'operator?:' in 'false ?"

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2012-08-21 
20:24:15 UTC ---
I think clang's "incompatible operand types" is simple and fairly clear

[Bug c++/54348] confusing error reported for type mismatch in conditional expression : "error: no match for ternary 'operator?:' in 'false ?"

[jason.vas.dias at gmail dot com]

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

--- Comment #5 from Jason Vas Dias  2012-08-21 
20:27:36 UTC ---
Oops, I was interrupted adding this comment to my initial comment - will
respond
to subsequent commment next :

Incidentally, I found this issue while developing a C++-98 replacement for
C-99 designated initializers for specific structs with generated macros :

#include 
#include 
using namespace std;

struct strct 
{
string name, items ;
strct (string n, string i) : name(n), items(i){}
};

#define tok(t) t

#define the_struct_strct_member( member, a0, a1, a2, a3 )\
( (&(((struct strct*)0) -> member ) == &(((struct strct*)0) -> a0)) \
   ? a1\
   :( ( &(((struct strct*)0) -> member) ==  &(((struct strct*)0) -> a2) ) \
  ? a3\
  : NULL\
)\
)

#define struct_strct( a0, a1, a2, a3 )\
(the_struct_strct_member( tok(name)  , a0, a1, a2, a3 ),\
 the_struct_strct_member( tok(items) , a0, a1, a2, a3 )\
)

void f()
{

  string myItems;
  string myName("");

  strct s  struct_strct( items, myItems, name, myName ) ;
}


This works!

[Bug c++/54348] confusing error reported for type mismatch in conditional expression : "error: no match for ternary 'operator?:' in 'false ?"

[jason.vas.dias at gmail dot com]

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

--- Comment #6 from Jason Vas Dias  2012-08-21 
20:29:53 UTC ---
(In reply to comment #1)
> In mainline the diagnostics is better because we output the types. But I agree
> that given that the conditional operator cannot be overloaded the error 
> message
> could be more clear.

yes, that is all I'm saying

[Bug c++/54348] confusing error reported for type mismatch in conditional expression : "error: no match for ternary 'operator?:' in 'false ?"

[jason.vas.dias at gmail dot com]

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

--- Comment #7 from Jason Vas Dias  2012-08-21 
20:34:06 UTC ---
(In reply to comment #2)
> (In reply to comment #0)
> > Shouldn't g++ be complaining about initializing a string with a list
> > rather than this cryptic "no match for ternary 'operator?:'" here ?
> 
> No, not really.
> 
> The object being initialized by the result of the condition expression is
> irrelevant, the conditional expression isn't valid whether or not you're using
> it to initialize another object.
> 
> In this reduced version it wouldn't make sense to refer to initializing any
> object with any other:
> 
> struct A {} a;
> struct B {} b;
> 
> void f()
> {
> false ? a : b;
> }

but this is not the same. surely ? the above is not a valid statement -
I was saying:

  some_type some_object = false ? a : b;

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[dnovillo at google dot com]

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

--- Comment #25 from dnovillo at google dot com  
2012-08-21 20:49:16 UTC ---
On 2012-08-21 15:53 , hjl.tools at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
>
> --- Comment #24 from H.J. Lu  2012-08-21 19:53:14 
> UTC ---
> (In reply to comment #23)
>>
>> The problem with this is that you are switching a stack vec into a heap
>> vec.  This may not always be what the caller wanted.
>
> My patch just restores the old behavior.

You are right.  This was always the case.  I added the extra check to 
guard against inadvertent *initial* heap allocations for stack vectors.

But now that I see the old code, this was always the case.  The 
subsequent stack operations after the first round around the loop will 
move the stacks into the heap.

The patch is OK with a ChangeLog and bootstrap testing.


Thanks!  Diego.

[Bug c++/54348] confusing error reported for type mismatch in conditional expression : "error: no match for ternary 'operator?:' in 'false ?"

[jason.vas.dias at gmail dot com]

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

--- Comment #8 from Jason Vas Dias  2012-08-21 
20:52:12 UTC ---
All I'm suggesting is that g++ should try to find the most basic error, 
which is that different type objects are returned as the result of a
conditional expression, and not  "no match for ternary 'operator?:'" -
what does this mean, it was searching namespace std:: for string::operator::?:
?
then this succeeded, and it found it could not apply it because the types
were different - shouldn't it complain about the root cause, that the types
were different, rather than the symptom of not being able to satisfy
operator std::string::?:() ?

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[hjl at gcc dot gnu.org]

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

--- Comment #26 from hjl at gcc dot gnu.org  2012-08-21 
21:07:07 UTC ---
Author: hjl
Date: Tue Aug 21 21:07:01 2012
New Revision: 190576

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190576
Log:
Restore df_free_collection_rec call in df_bb_verify

PR middle-end/54332
* df-scan.c (df_bb_verify): Restore df_free_collection_rec call
inside the insn traversal loop.

* vec.h (vec_reserve): Remove the stack allocation check.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/df-scan.c
trunk/gcc/vec.h

[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #27 from H.J. Lu  2012-08-21 21:11:11 
UTC ---
Fixed.

[Bug rtl-optimization/54343] RTL postreload leaks DF memory

[dnovillo at gcc dot gnu.org]

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

Diego Novillo  changed:

   What|Removed |Added

 CC||dnovillo at gcc dot gnu.org

--- Comment #3 from Diego Novillo  2012-08-21 
21:25:20 UTC ---
HJ's fix for PR 54332 will probably fix this one, too.  Could you re-test?

Thanks.

[Bug middle-end/53676] [4.7 regression] empty loop is not always removed now

[matt at use dot net]

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

--- Comment #12 from Matt Hargett  2012-08-21 21:40:11 UTC 
---
I've been doing research into LLVM 3.1 and other GCC versions. LLVM 3.1
correctly eliminate the (near) empty loop, and their current trunk does not
regress like 4.7 has.

Is the trunk patch coupled to other changes that are too invasive for 4.7? I'm
confused and curious about what optimization regressions are serious enough to
warrant a back port, if any.

[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate

[noloader at gmail dot com]

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

--- Comment #7 from Jeffrey Walton  2012-08-21 
22:08:38 UTC ---
(In reply to comment #1)

> Also using -fPIC instead of -fPIE is always ok.  So I doubt there is a really
> issue here.  Since the differences between PIC and PIE comes down to if 
> symbols
> are overridable.  PIC is conservative at optimizing.


-fPIC/-pic apparently breaks other GNU tools:

./configure CFLAGS="-Wall -Wextra -Wconversion -fPIC -pic
-Wno-unused-parameter -Wformat=2 -Wformat-security
-fstack-protector-all -Wstrict-overflow -Wl,-z,noexecstack
-Wl,-z,relro -Wl,-z,now"
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/home/jeffrey/sipwitch-1.3.1':
configure: error: C compiler cannot create executables
See `config.log' for more details

[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)

[olegendo at gcc dot gnu.org]

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

--- Comment #33 from Oleg Endo  2012-08-21 
23:35:02 UTC ---
Author: olegendo
Date: Tue Aug 21 23:34:54 2012
New Revision: 190579

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190579
Log:
PR target/39423
* config/sh/sh.md (*movhi_index_disp): Add support for SH2A movu.w insn.

PR target/39423
* gcc.target/sh/pr39423-2.c: New.


Added:
trunk/gcc/testsuite/gcc.target/sh/pr39423-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/20420] Incorrectly Accepts double declarations

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  2012-08-22 
00:01:27 UTC ---
For Comment #4: the validate_nonmember_using_decl call at the beginning of
do_local_using_decl returns NULL_TREE for the second using declaration, but we 
ignore that and return without error. That doesn't seem right for VAR_DECLs.

This combo patchlet passes testing:

Index: name-lookup.c
===
--- name-lookup.c(revision 190569)
+++ name-lookup.c(working copy)
@@ -441,7 +441,8 @@ supplement_binding_1 (cxx_binding *binding, tree d
  template in order to handle late matching of underlying
  type on an opaque-enum-declaration followed by an
  enum-specifier.  */
-  || (TREE_CODE (TREE_TYPE (target_decl)) == ENUMERAL_TYPE
+  || (processing_template_decl
+  && TREE_CODE (TREE_TYPE (target_decl)) == ENUMERAL_TYPE
   && TREE_CODE (TREE_TYPE (target_bval)) == ENUMERAL_TYPE
   && (dependent_type_p (ENUM_UNDERLYING_TYPE
 (TREE_TYPE (target_decl)))
@@ -2581,7 +2582,11 @@ do_local_using_decl (tree decl, tree scope, tree n

   decl = validate_nonmember_using_decl (decl, scope, name);
   if (decl == NULL_TREE)
-return;
+{
+  if (TREE_CODE (orig_decl) == VAR_DECL)
+error ("%qD is already declared in this scope", name);
+  return;
+}

   if (building_stmt_list_p ()
   && at_function_scope_p ())

[Bug tree-optimization/54317] [4.8 Regression] FAIL: c45532m c45532n c45532o c45532p

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  2012-08-22 06:19:17 
UTC ---
Actually, I reviewed my patch and I just found a bug, which can be seen on
x86_64 with:
extern void g();
void f(unsigned __int128 x){
  unsigned __int128 n2 = 1; n2 <<= 127;
  if(x>n2)return;
  unsigned __int128 y = x + x;
  if (y == 42) g();
}

(using gmp in tree-vrp would have been so much less trouble...)

I'll try to fix that soon and we'll see if the failures disappear.