[Bug tree-optimization/53774] Reassociator generates non-canonical addition

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  
2012-06-27 08:28:27 UTC ---
On Tue, 26 Jun 2012, wschmidt at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53774
> 
> --- Comment #3 from William J. Schmidt  
> 2012-06-26 18:42:41 UTC ---
> I wonder why fp_6(D) gets a rank of zero.  Is it an uninitialized variable or 
> a
> parameter?  Parms are supposed to get small positive numbers for ranks.  Maybe
> the "right" fix is to force fp_6(D) to get a nonzero rank?

Yes, fp_6(D) is not initialized.

It also seems that ranks for non-constants are based on zero, too,
as for example loop-carried PHIs also might get a rank of zero.

Parameters get ranks starting off 3 (see init_reassoc).  I suppose
we could instead of walking over DECL_ARGUMENTS simply walk over all
SSA names and assign ranks to all default-defs instead.  I'm going
to test that.

Ah, it's

  if (TREE_CODE (SSA_NAME_VAR (e)) == PARM_DECL
  && SSA_NAME_IS_DEFAULT_DEF (e))
return find_operand_rank (e);

  stmt = SSA_NAME_DEF_STMT (e);
  if (gimple_bb (stmt) == NULL)
return 0;

in get_rank - that will return zero for all non-param default-defs,
even for the static chain we try to setup properly :/

Yeah, the following works - thanks for the hint ;)

Index: gcc/tree-ssa-reassoc.c
===
--- gcc/tree-ssa-reassoc.c  (revision 188987)
+++ gcc/tree-ssa-reassoc.c  (working copy)
@@ -383,14 +383,10 @@ get_rank (tree e)
   int i, n;
   tree op;

-  if (TREE_CODE (SSA_NAME_VAR (e)) == PARM_DECL
- && SSA_NAME_IS_DEFAULT_DEF (e))
+  if (SSA_NAME_IS_DEFAULT_DEF (e))
return find_operand_rank (e);

   stmt = SSA_NAME_DEF_STMT (e);
-  if (gimple_bb (stmt) == NULL)
-   return 0;
-
   if (gimple_code (stmt) == GIMPLE_PHI)
return phi_rank (stmt);

@@ -3647,7 +3643,6 @@ init_reassoc (void)
 {
   int i;
   long rank = 2;
-  tree param;
   int *bbs = XNEWVEC (int, last_basic_block + 1);

   /* Find the loops, so that we can prevent moving calculations in
@@ -3666,24 +3661,13 @@ init_reassoc (void)
   bb_rank = XCNEWVEC (long, last_basic_block + 1);
   operand_rank = pointer_map_create ();

-  /* Give each argument a distinct rank.   */
-  for (param = DECL_ARGUMENTS (current_function_decl);
-   param;
-   param = DECL_CHAIN (param))
-{
-  if (gimple_default_def (cfun, param) != NULL)
-   {
- tree def = gimple_default_def (cfun, param);
- insert_operand_rank (def, ++rank);
-   }
-}
-
-  /* Give the chain decl a distinct rank. */
-  if (cfun->static_chain_decl != NULL)
-{
-  tree def = gimple_default_def (cfun, cfun->static_chain_decl);
-  if (def != NULL)
-   insert_operand_rank (def, ++rank);
+  /* Give each default definition a distinct rank.  This includes
+ parameters and the static chain.  */
+  for (i = 1; i < (int) num_ssa_names; ++i)
+{
+  tree name = ssa_name (i);
+  if (name && SSA_NAME_IS_DEFAULT_DEF (name))
+   insert_operand_rank (name, ++rank);
 }

   /* Set up rank for each BB  */

[Bug tree-optimization/53645] Missed optimization for vector integer division lowering

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  2012-06-27 
08:50:00 UTC ---
Created attachment 27709
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27709
gcc48-pr53645.patch

Untested fix.

[Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls

[thomas.orgis at awi dot de]

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

--- Comment #2 from Thomas Orgis  2012-06-27 
08:58:57 UTC ---
Created attachment 27710
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27710
tarball with complete source to reproduce the issue

Ok, then, I feared as much. After taking too much time off the work I get
actually paid for (did I say that scientific programming sucks?) ... here is a
tarball that reproduces the issue for me and is hopefully small enough to serve
as a starting point.

It is a set of modules, most of which should not be relevant, just tedious to
eliminate. The important sources are datafield.f90, bottomwind.f90 and
perturb.f90 ... well just start from dat_init_wind(), which exhibits the bug
when called just after dat_init_density() (with inside call to pert_perturb()).

[Bug rtl-optimization/53706] [4.8 Regression] Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418)

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #20 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-06-27 09:00:52 UTC ---
> --- Comment #19 from Alexandre Oliva  2012-06-27
> 06:30:05 UTC ---
> Alas, it doesn't work on i686 or x86_64: the free_alloc_pool in vt_finalize 
> has
> to be conditional on non-NULL, because we will skip vt_emit_notes (and thus 
> the
> initializer) in some cases.  I'm in awe that this didn't happen on ia64!

An i386-pc-solaris2.10 bootstrap with Uros' patch and the guard added is
now well into building the target libraries, so the bootstrap failure is
gone.  I'll report if I notice any testsuite regressions.

Thanks.
Rainer

[Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls

[thomas.orgis at awi dot de]

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

--- Comment #3 from Thomas Orgis  2012-06-27 
09:03:25 UTC ---
... and not to forget profiles.f90 ... that module links the perturbation in
dat_init_density() to the wind in dat_init_wind(). Changes in there along with
moving perturb to using those same profiles as the wind triggered the bug to
begin with.

So, if it is something broken in my code, it is likely to be found in
profiles.f90 or perturb.f90 ... or bottomwinds.f90 .

[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for multi-word memory splits

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #9 from Andrew Pinski  2012-06-27 
09:24:13 UTC ---
Fixed.

[Bug c++/53783] [4.8 Regression] lambda in lambda in template function rejected

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++

[d.v.a at ngs dot ru]

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

--- Comment #18 from __vic  2012-06-27 10:19:18 UTC ---
GCC 4.7.1 still fails to link .so against static libstdc++.a in 64-bit mode:

$ g++ -shared -fPIC -static-libgcc -static-libstdc++ -o 1.so 1.cpp
/usr/bin/ld:
/opt/gcc-4.6.1/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../lib64/libstdc++.a(globals_io.o):
relocation R_X86_64_32 against `a local symbol' can not be used when making a
shared object; recompile with -fPIC
/opt/gcc-4.6.1/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../lib64/libstdc++.a:
could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [1.so] Error 1

32-bit mode is working:

$ g++ -m32 -shared -fPIC -static-libgcc -static-libstdc++ -o 1.so 1.cpp

[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++

[d.v.a at ngs dot ru]

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

--- Comment #19 from __vic  2012-06-27 10:27:14 UTC ---
I'm sorry, compiler version was 4.6.1 in previous example.
Output for 4.7.1:

$ g++ -shared -fPIC -static-libgcc -static-libstdc++ -o 1.so 1.cpp
/usr/bin/ld:
/opt/gcc-4.7.1/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../lib64/libstdc++.a(compatibility.o):
relocation R_X86_64_32 against `_ZTIN10__cxxabiv115__forced_unwindE' can not be
used when making a shared object; recompile with -fPIC
/opt/gcc-4.7.1/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../lib64/libstdc++.a:
could not read symbols: Bad value
collect2: error: ld returned 1 exit status

[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2012-06-27 
10:32:53 UTC ---
I am testing

Index: gcc/cfgloop.c
===
*** gcc/cfgloop.c   (revision 188987)
--- gcc/cfgloop.c   (working copy)
*** init_loops_structure (struct loops *loop
*** 365,370 
--- 365,406 
loops->tree_root = root;
  }

+ /* Return true if there is a path from FROM to the dominated TO where no
+edge on that path contains FLAGS.  */
+ 
+ static bool
+ path_without_edge_flags (basic_block from, basic_block to, int flags)
+ {
+   do
+ {
+   /* At least one such path to the immediate dominator.  */
+   if (single_pred_p (to))
+   {
+ edge e = single_pred_edge (to);
+ if (e->flags & flags)
+   return false;
+ to = e->src;
+   }
+   else
+   {
+ basic_block dom = get_immediate_dominator (CDI_DOMINATORS, to);
+ edge_iterator ei;
+ edge e;
+ 
+ FOR_EACH_EDGE(e, ei, to->preds)
+   if (!(e->flags & flags)
+   && (e->src == dom
+   || path_without_edge_flags (dom, e->src, flags)))
+ break;
+ 
+ to = dom;
+   }
+ }
+   while (to != from);
+ 
+   return true;
+ }
+ 
  /* Find all the natural loops in the function and save in LOOPS structure and
 recalculate loop_depth information in basic block structures.
 Return the number of natural loops found.  */
*** flow_loops_find (struct loops *loops)
*** 422,430 
 by this block.  A natural loop has a single entry
 node (header) that dominates all the nodes in the
 loop.  It also has single back edge to the header
!from a latch node.  */
  if (latch != ENTRY_BLOCK_PTR
! && dominated_by_p (CDI_DOMINATORS, latch, header))
{
  /* Shared headers should be eliminated by now.  */
  SET_BIT (headers, header->index);
--- 458,470 
 by this block.  A natural loop has a single entry
 node (header) that dominates all the nodes in the
 loop.  It also has single back edge to the header
!from a latch node.
!If there is no regular path from the header to the
!latch do not consider this latch (not worth the
!problems).  */
  if (latch != ENTRY_BLOCK_PTR
! && dominated_by_p (CDI_DOMINATORS, latch, header)
! && path_without_edge_flags (header, latch, EDGE_COMPLEX))
{
  /* Shared headers should be eliminated by now.  */
  SET_BIT (headers, header->index);

[Bug ada/53766] ICE in build_binary_op on Max_Size_In_Storage_Elements with -gnatp

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-06-27
 CC||ebotcazou at gcc dot
   ||gnu.org
Summary|ICE in build_binary_op when |ICE in build_binary_op on
   |using pragma Suppress   |Max_Size_In_Storage_Element
   |(All_Checks)|s with -gnatp
 Ever Confirmed|0   |1

--- Comment #1 from Eric Botcazou  2012-06-27 
10:39:19 UTC ---
The expanded code without -gnatp looks quite different.

[Bug tree-optimization/53774] Reassociator generates non-canonical addition

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2012-06-27 
11:29:08 UTC ---
Author: rguenth
Date: Wed Jun 27 11:29:04 2012
New Revision: 189012

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189012
Log:
2012-06-27  Richard Guenther  

PR tree-optimization/53774
* tree-ssa-reassoc.c (get_rank): All default defs have
precomputed rank.
(init_reassoc): Precompute rank for all SSA default defs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug tree-optimization/53774] Reassociator generates non-canonical addition

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Richard Guenther  2012-06-27 
11:29:08 UTC ---
Author: rguenth
Date: Wed Jun 27 11:29:04 2012
New Revision: 189012

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189012
Log:
2012-06-27  Richard Guenther  

PR tree-optimization/53774
* tree-ssa-reassoc.c (get_rank): All default defs have
precomputed rank.
(init_reassoc): Precompute rank for all SSA default defs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

--- Comment #7 from Richard Guenther  2012-06-27 
11:29:53 UTC ---
Fixed.

[Bug tree-optimization/53774] Reassociator generates non-canonical addition

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Richard Guenther  2012-06-27 
11:29:53 UTC ---
Fixed.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2012-06-27 
11:32:34 UTC ---
Author: rguenth
Date: Wed Jun 27 11:32:30 2012
New Revision: 189013

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189013
Log:
2012-06-27  Richard Guenther  

PR middle-end/53676
* tree-chrec.c (chrec_convert_1): Represent truncation to
a type with undefined overflow as truncation to an unsigned
type converted to the type with undefined overflow.
* tree-scalar-evolution.c (interpret_rhs_expr): For computing
the scalar evolution of a truncated widened operation avoid
looking at the non-existing evolution of the widened operation
result.

* gcc.dg/tree-ssa/scev-6.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chrec.c
trunk/gcc/tree-scalar-evolution.c

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

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Known to work||4.6.3, 4.8.0
Summary|[4.7/4.8 regression] empty  |[4.7 regression] empty loop
   |loop is not always removed  |is not always removed now
   |now |
  Known to fail||4.7.1

--- Comment #8 from Richard Guenther  2012-06-27 
11:32:34 UTC ---
Author: rguenth
Date: Wed Jun 27 11:32:30 2012
New Revision: 189013

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189013
Log:
2012-06-27  Richard Guenther  

PR middle-end/53676
* tree-chrec.c (chrec_convert_1): Represent truncation to
a type with undefined overflow as truncation to an unsigned
type converted to the type with undefined overflow.
* tree-scalar-evolution.c (interpret_rhs_expr): For computing
the scalar evolution of a truncated widened operation avoid
looking at the non-existing evolution of the widened operation
result.

* gcc.dg/tree-ssa/scev-6.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chrec.c
trunk/gcc/tree-scalar-evolution.c

--- Comment #9 from Richard Guenther  2012-06-27 
11:33:12 UTC ---
Fixed for trunk.

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

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Known to work||4.6.3, 4.8.0
Summary|[4.7/4.8 regression] empty  |[4.7 regression] empty loop
   |loop is not always removed  |is not always removed now
   |now |
  Known to fail||4.7.1

--- Comment #9 from Richard Guenther  2012-06-27 
11:33:12 UTC ---
Fixed for trunk.

[Bug gcov-profile/38292] [4.5/4.6/4.7/4.8 Regression] corrupted profile info with -O[23] -fprofile-use

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||doko at gcc dot gnu.org
 Resolution||FIXED

--- Comment #21 from Matthias Klose  2012-06-27 
12:10:26 UTC ---
the python builds works when built using -fprofile-correction

[Bug other/33190] tm.texi describes some non-existing hooks

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com  2012-06-27 13:30:31 UTC ---
On Tue, 26 Jun 2012, steven at gcc dot gnu.org wrote:

> SYSROOT_HEADERS_SUFFIX_SPEC (cppdefault.c gcc.c doc/tm.texi.in)

This is of use with configurations with both glibc and uClibc multilibs 
selected via -muclibc, for example (i.e. for someone building GCC to use 
in setting up the multilibs they want, rather than something where having 
such multilibs is suitable for a default checked-in configuration of GCC).

> SHORT_FRACT_TYPE_SIZE (tree.c defaults.h doc/tm.texi.in config/arm/arm.h
> config/mips/mips.h)
> 
> FRACT_TYPE_SIZE (tree.c defaults.h doc/tm.texi.in config/arm/arm.h
> config/mips/mips.h)
> 
> LONG_FRACT_TYPE_SIZE (tree.c defaults.h doc/tm.texi.in config/arm/arm.h
> config/mips/mips.h)
> 
> LONG_LONG_FRACT_TYPE_SIZE (tree.c defaults.h doc/tm.texi.in config/arm/arm.h
> config/mips/mips.h)
> 
> SHORT_ACCUM_TYPE_SIZE (tree.c defaults.h doc/tm.texi.in config/arm/arm.h
> config/mips/mips.h)
> 
> ACCUM_TYPE_SIZE (tree.c defaults.h doc/tm.texi.in config/arm/arm.h
> config/mips/mips.h)
> 
> LONG_ACCUM_TYPE_SIZE (tree.c defaults.h doc/tm.texi.in config/arm/arm.h
> config/mips/mips.h)
> 
> LONG_LONG_ACCUM_TYPE_SIZE (tree.c defaults.h doc/tm.texi.in config/arm/arm.h
> config/mips/mips.h)
> 
> LIBGCC2_HAS_DF_MODE (doc/tm.texi.in config/rl78/rl78.h config/rx/rx.h
> ../libgcc/fixed-bit.h ../libgcc/libgcc2.c ../libgcc/libgcc2.h)
> 
> SF_SIZE (doc/tm.texi.in ../libgcc/libgcc2.c ../libgcc/libgcc2.h)
> 
> DF_SIZE (doc/tm.texi.in ../libgcc/libgcc2.c ../libgcc/libgcc2.h)
> 
> INTMAX_TYPE (defaults.h doc/tm.texi.in c-family/c-common.c fortran/trans-
> types.c fortran/iso-c-binding.def)
> 
> UINTMAX_TYPE (defaults.h doc/tm.texi.in c-family/c-common.c)

These are all things that logically should be configured in the same way 
as the same properties for other types or modes, even if it so happens 
that no target actually uses a nondefault definition of them at present.  
(For *_SIZE that would ideally be hooks.  See bug 46677 and some patches 
from Joern Rennecke around Nov / Dec 2010; I don't know what the latest 
patch version is.  For *_TYPE typedef names that would ideally be hooks 
returning enums rather than strings.  I'm not sure if Joern had a patch 
there but interfaces were discussed in threads around that time.  For 
those relating to floating-point modes, they should either move the libgcc 
config headers or, better, be predefined by the compiler (they're on the 
list at  of those 
definable by the compiler).)

[Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  2012-06-27 
13:44:43 UTC ---
I have played a little with the attached test (I had to comment out 'use
textdata' and 'use lapack'. On x86_64-apple-darwin10, I do not get any NaN with
4.6.3, 4.7.1, or trunk with the default flag. However if I add
'-finit-real=snan -ffpe-trap=invalid,zero,overflow' to the flags, the line

 single q:   1.6614401858304297NaN 
 NaN

(for '-finit-real=nan') is replaced with

Floating exception

So it seems likely that the code is using uninitialized variable(s) (not
detected by -Wuninitialized). Note that one property of NaN is that they
"propagate", i.e., they can be detected quite far away from the point where
they are generated.

It looks like the bug is in the code rather than in gfortran.

[Bug rtl-optimization/50176] [4.7/4.8 Regression] 4.7 generates spill-fill dealing with char->int conversion

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  2012-06-27 
13:56:48 UTC ---
Created attachment 27711
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27711
gcc48-pr50176.patch

Here is an untested patch (hacked up on 4.7 branch, as the problem on this
testcase seems to be only latent on the trunk).
The patch will change a QImode load followed by SI=zext(QI) into a zero
extending load on the first insn and a noop move on the second insn (which
fwprop later optimizes even further.
I had to add one new insn pattern in i386.md for it to trigger.
But testing it now, it seems that that i386.md change alone is sufficient to
fix up this testcase, because the combiner merges the two patterns then.
I guess if it was different basic blocks it wouldn't, so am not sure if we want
also the fwprop change or not.
I'll bootstrap/regtest the i386.md change separately first.

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[ktietz at gcc dot gnu.org]

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

--- Comment #14 from Kai Tietz  2012-06-27 14:03:13 
UTC ---
Author: ktietz
Date: Wed Jun 27 14:03:08 2012
New Revision: 189016

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189016
Log:
PR preprocessor/37215
* c-ppoutput.c (preprocess_file): Check for nonempty buffer.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-ppoutput.c

[Bug c++/51033] generic vector subscript and shuffle support was not added to C++

[ramana at gcc dot gnu.org]

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

--- Comment #28 from Ramana Radhakrishnan  
2012-06-27 14:19:25 UTC ---
Author: ramana
Date: Wed Jun 27 14:19:17 2012
New Revision: 189017

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

2012-06-27  Ramana Radhakrishnan  

PR C++/51033
* semantics.c (constexpr_call): Fix typo in comment.
(cxx_eval_vec_perm_expr): New.
(cxx_eval_constant_expression): Fold VEC_PERM_EXPRs.

2012-06-27  Ramana Radhakrishnan  

PR c++/51033.
* g++.dg/torture/vshuf-16.inc: New test.
* g++.dg/torture/vshuf-2.inc: New test.
* g++.dg/torture/vshuf-4.inc: New test.
* g++.dg/torture/vshuf-8.inc: New test.
* g++.dg/torture/vshuf-main.inc: New test.
* g++.dg/torture/vshuf-v16hi.C: New test.
* g++.dg/torture/vshuf-v16qi.C: New test.
* g++.dg/torture/vshuf-v2df.C: New test.
* g++.dg/torture/vshuf-v2di.C: New test.
* g++.dg/torture/vshuf-v2sf.C: New test.
* g++.dg/torture/vshuf-v2si.C: New test.
* g++.dg/torture/vshuf-v4df.C: New test.
* g++.dg/torture/vshuf-v4di.C: New test.
* g++.dg/torture/vshuf-v4sf.C: New test.
* g++.dg/torture/vshuf-v4si.C: New test.
* g++.dg/torture/vshuf-v8hi.C: New test.
* g++.dg/torture/vshuf-v8qi.C: New test.
* g++.dg/torture/vshuf-v8si.C: New test.




Added:
trunk/gcc/testsuite/g++.dg/torture/vshuf-16.inc
trunk/gcc/testsuite/g++.dg/torture/vshuf-2.inc
trunk/gcc/testsuite/g++.dg/torture/vshuf-4.inc
trunk/gcc/testsuite/g++.dg/torture/vshuf-8.inc
trunk/gcc/testsuite/g++.dg/torture/vshuf-main.inc
trunk/gcc/testsuite/g++.dg/torture/vshuf-v16hi.C
trunk/gcc/testsuite/g++.dg/torture/vshuf-v16qi.C
trunk/gcc/testsuite/g++.dg/torture/vshuf-v2df.C
trunk/gcc/testsuite/g++.dg/torture/vshuf-v2di.C
trunk/gcc/testsuite/g++.dg/torture/vshuf-v2sf.C
trunk/gcc/testsuite/g++.dg/torture/vshuf-v2si.C
trunk/gcc/testsuite/g++.dg/torture/vshuf-v4df.C
trunk/gcc/testsuite/g++.dg/torture/vshuf-v4di.C
trunk/gcc/testsuite/g++.dg/torture/vshuf-v4sf.C
trunk/gcc/testsuite/g++.dg/torture/vshuf-v4si.C
trunk/gcc/testsuite/g++.dg/torture/vshuf-v8hi.C
trunk/gcc/testsuite/g++.dg/torture/vshuf-v8qi.C
trunk/gcc/testsuite/g++.dg/torture/vshuf-v8si.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/53786] New: [C++11] alias template causes g++ segfault

[mustrumr97 at gmail dot com]

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

 Bug #: 53786
   Summary: [C++11] alias template causes g++ segfault
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mustrum...@gmail.com


template
class list{
public:
template
using tail_=list;
using tail=tail_;
};
using l=list;

will make gcc 4.7.1 segfault
test.cpp:5:32: internal compiler error: Segmentation fault

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[ktietz at gcc dot gnu.org]

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

--- Comment #15 from Kai Tietz  2012-06-27 15:06:21 
UTC ---
Author: ktietz
Date: Wed Jun 27 15:06:16 2012
New Revision: 189019

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189019
Log:
Merged from trunk
PR preprocessor/37215
* c-ppoutput.c (preprocess_file): Check for nonempty buffer.

Modified:
branches/gcc-4_7-branch/gcc/c-family/ChangeLog
branches/gcc-4_7-branch/gcc/c-family/c-ppoutput.c

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #16 from Kai Tietz  2012-06-27 15:10:19 
UTC ---
I won't back-merge change to 4.6.x or earlier branches.
So I change bug to state resolved fixed.

[Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2012-06-27 
15:27:10 UTC ---
(In reply to comment #4)
> However if I add '-finit-real=snan -ffpe-trap=invalid,zero,overflow' to the\
> flags, the line
[...]

For me it fails with:
  #3  0x419D2B in __datafield_MOD_dat_init_wind at datafield.f90:211
  #4  0x41B830 in show_state at test.f90:55
  Floating point exception


However, the problem is in profiles.f90's profile_values, called by:

 function profile_deriv(handle, y) result(deriv)
   ...
   call profile_values(handle, y, deriv=deriv)
end function

 subroutine profile_values(handle, y, deriv, value, aderiv, aderiv2)
...
   if(zero(handle%length)) then
  val(0) = 1
  return
   end if
...
   if(present(value))   value   = val( 0)
...
end subroutine


Do you spot the uninitialized variable?

[Bug rtl-optimization/50176] [4.7/4.8 Regression] 4.7 generates spill-fill dealing with char->int conversion

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  2012-06-27 
15:28:52 UTC ---
Ah, the i386.md part doesn't apply on the trunk, since
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184891
which seems to have fixed this issue for the case where the load and zero
extension is in the same bb.
So, do we want the fwprop.c change for the different bb case (not sure how hard
will it be to come up with a testcase)?

[Bug fortran/35040] usage of init expression in its own definition

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  2012-06-27 
16:17:29 UTC ---
(In reply to comment #3)
> Answer (see link): All these are wrong per answer to an interpretation
> request

For completeness, that is Fortran 95's "90" at
ftp://ftp.nag.co.uk/sc22wg5/N1451-N1500/N1473.txt, which got incorporated in
Fortran 95, Corrigendum 2 (and in Fortran 2003).

[Bug lto/53787] New: Possible lto improvement

[izamyatin at gmail dot com]

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

 Bug #: 53787
   Summary: Possible lto improvement
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com


For following Fortan test t.f90 icc can propagate loop counter value and then
perform complete unroll and gcc doesn't do it

  real x(10)
  n = 10
  call init(x,n)
  print *, x
  end

  subroutine init(x, n)
  real x(10)
   do i=1,n
 x(i) = i*i + 1
   enddo

   return
   end

 Not sure it's completely lto problem though...

ifort flags- -O3 -ipo -inline-level=0
gfortran flags - -O3 -flto -fwhole-program -fno-inline

[Bug c++/51214] [4.7 Regression] [C++11] name lookup issue with c++11 enums

[fabien at gcc dot gnu.org]

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

--- Comment #6 from fabien at gcc dot gnu.org 2012-06-27 17:36:56 UTC ---
Author: fabien
Date: Wed Jun 27 17:36:50 2012
New Revision: 189021

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189021
Log:
gcc/testsuite/ChangeLog

2012-06-27  Fabien Chêne  

PR c++/51214
* g++.dg/cpp0x/forw_enum11.C: New.

gcc/cp/ChangeLog

2012-06-27  Fabien Chêne  

PR c++/51214
* cp-tree.h (insert_late_enum_def_into_classtype_sorted_fields):
Declare.
* class.c (insert_into_classtype_sorted_fields): New.
(add_enum_fields_to_record_type): New.
(count_fields): Adjust the comment.
(add_fields_to_record_type): Likewise.
(finish_struct_1): Move the code that inserts the fields for the
sorted case, into insert_into_classtype_sorted_fields, and call
it.
(insert_late_enum_def_into_classtype_sorted_fields): Define.
* decl.c (finish_enum_value_list): Call
insert_late_enum_def_into_classtype_sorted_fields if a late enum
definition is encountered.

Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/forw_enum11.C
Modified:
branches/gcc-4_7-branch/gcc/cp/ChangeLog
branches/gcc-4_7-branch/gcc/cp/class.c
branches/gcc-4_7-branch/gcc/cp/cp-tree.h
branches/gcc-4_7-branch/gcc/cp/decl.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug fortran/41951] [OOP] Not diagnosing ambiguous operators (TB vs. INTERFACE)

[janus at gcc dot gnu.org]

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

--- Comment #13 from janus at gcc dot gnu.org 2012-06-27 17:38:11 UTC ---
Author: janus
Date: Wed Jun 27 17:38:00 2012
New Revision: 189022

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189022
Log:
2012-06-27  Janus Weil  

PR fortran/41951
PR fortran/49591
* interface.c (check_new_interface): Rename, add 'loc' argument,
make non-static.
(gfc_add_interface): Rename 'check_new_interface'
* gfortran.h (gfc_check_new_interface): Add prototype.
* resolve.c (resolve_typebound_intrinsic_op): Add typebound operator
targets to non-typebound operator list.


2012-06-27  Janus Weil  

PR fortran/41951
PR fortran/49591
* gfortran.dg/typebound_operator_16.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/typebound_operator_16.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/49591] [OOP] Multiple identical specific procedures in type-bound operator not detected

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org 2012-06-27 17:38:11 UTC ---
Author: janus
Date: Wed Jun 27 17:38:00 2012
New Revision: 189022

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189022
Log:
2012-06-27  Janus Weil  

PR fortran/41951
PR fortran/49591
* interface.c (check_new_interface): Rename, add 'loc' argument,
make non-static.
(gfc_add_interface): Rename 'check_new_interface'
* gfortran.h (gfc_check_new_interface): Add prototype.
* resolve.c (resolve_typebound_intrinsic_op): Add typebound operator
targets to non-typebound operator list.


2012-06-27  Janus Weil  

PR fortran/41951
PR fortran/49591
* gfortran.dg/typebound_operator_16.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/typebound_operator_16.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/53787] Possible lto improvement

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  2012-06-27 
17:39:23 UTC ---
AFAICT the subroutine is inlined with '-O3 -fwhole-program' or '-O3
-fwhole-program -flto' for 4.6.3, 4.7.1, and trunk. Indeed the inlining does
not occurs with the addition of -fno-inline, but why do you expect gfortran to
disobey to what you ask it to do?

[Bug fortran/49591] [OOP] Multiple identical specific procedures in type-bound operator not detected

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |

--- Comment #7 from janus at gcc dot gnu.org 2012-06-27 17:51:10 UTC ---
Fixed with r189022. Closing.

[Bug c++/51214] [4.7 Regression] [C++11] name lookup issue with c++11 enums

[fabien at gcc dot gnu.org]

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

fabien at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from fabien at gcc dot gnu.org 2012-06-27 17:53:11 UTC ---
Fixed in 4.7.

[Bug fortran/41951] [OOP] Not diagnosing ambiguous operators (TB vs. INTERFACE)

[janus at gcc dot gnu.org]

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

--- Comment #14 from janus at gcc dot gnu.org 2012-06-27 17:54:29 UTC ---
Comment 12 is fixed with r189022, but comment 11 is still accepted without
error.

[Bug lto/53787] Possible lto improvement

[izamyatin at gmail dot com]

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

--- Comment #2 from Igor Zamyatin  2012-06-27 
17:56:48 UTC ---
The testcase was reduced from some real app. No inlining happened there. 
Do you think this testcase is bad?

[Bug fortran/41951] [OOP] Not diagnosing ambiguous operators (TB vs. INTERFACE)

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #15 from Tobias Burnus  2012-06-27 
18:18:07 UTC ---
(In reply to comment #14)
> Comment 12 is fixed with r189022, but comment 11 is still accepted without
> error.

Note that previous commit also excluded PRIVATE type-bound operators, cf.
http://gcc.gnu.org/ml/fortran/2012-06/msg00149.html.

Whatever a private type-bound operators/assignments are, given that they
automatically become available when use-associating the type. (As they have to
have a pass argument, they won't interfere with other operator declarations.)

[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 #10 from Matt Hargett  2012-06-27 18:26:55 UTC 
---
Is there a fix targeted for 4.7.2? I can apply the patch and do some testing,
if that helps. Let me know what I can do, if anything, so we can make 4.7
deployable for us.

Thanks for the quick turnaround on the trunk commit!

[Bug c++/53788] New: C++11 decltype sfinae static member function check (4.7.1)

[exa7z at live dot com]

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

 Bug #: 53788
   Summary: C++11 decltype sfinae static member function check
(4.7.1)
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ex...@live.com


Greetings all. The following code should *not* compile (one of the ways for
detecting the presence or not of a static member function), because of a typo I
did in T/X substitution in the check function template:

Here is the testcase:
/* BEGIN TESTCASE */

#include 
#include 

template
struct has_static {

// NOTICE THE T/X substitution error, T::fun() should have been X::fun()
// thanks to dgregor in http://llvm.org/bugs/show_bug.cgi?id=13223
template
static std::true_type check(X*, decltype(T::fun())* = 0);

static std::false_type check(...);

typedef decltype(check((T*)(0))) _tmp;

static const bool value = _tmp::value;
};

struct test {
int fun() { return 0; }
};

int main() {
printf("%d\n", has_static::value);
return(0);
}
/* END TESTCASE */

used: g++ (GCC) 4.7.1 with --std=c++0x

According to dgregor's reply in the aforementioned llvm bugzilla entry, clang
is right to not compile this while g++ tacitly accepts it before its time (from
4.5.1 to 4.7.1 at least). Is this something requiring fixing?

thanks.

[Bug middle-end/53616] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org

--- Comment #8 from Pat Haugen  2012-06-27 
19:11:59 UTC ---
This fails on PowerPC also with just -O3. I'll see what I can do about
narrowing down to a smaller testcase.

[Bug c++/53563] [4.5/4.6/4.7/4.8 Regression] ICE in start_decl, at cp/decl.c:4427

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2012-06-27 
19:19:14 UTC ---
Author: jason
Date: Wed Jun 27 19:19:09 2012
New Revision: 189024

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189024
Log:
PR c++/53563
* parser.c (cp_parser_template_id): Add tag_type parm.
(cp_parser_template_name): Likewise.
(cp_parser_id_expression, cp_parser_unqualified_id): Adjust.
(cp_parser_pseudo_destructor_name, cp_parser_type_name): Adjust.
(cp_parser_simple_type_specifier, cp_parser_class_name): Adjust.
(cp_parser_elaborated_type_specifier, cp_parser_class_head): Adjust.

Added:
trunk/gcc/testsuite/g++.dg/parse/template27.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/template/crash74.C

[Bug c++/53563] [4.5/4.6/4.7/4.8 Regression] ICE in start_decl, at cp/decl.c:4427

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||FIXED
   Target Milestone|4.5.4   |4.8.0

--- Comment #4 from Jason Merrill  2012-06-27 
19:20:27 UTC ---
Fixed for 4.8.  Not backporting fixes for error-recovery bugs.

[Bug lto/53787] Possible lto improvement

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-06-27
 Ever Confirmed|0   |1

--- Comment #3 from H.J. Lu  2012-06-27 20:03:24 
UTC ---
Please show the output from GCC that the loop isn't unrolled.

[Bug rtl-optimization/53706] [4.8 Regression] Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418)

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #21 from Hans-Peter Nilsson  2012-06-27 
20:08:34 UTC ---
Adding me to CC as the revision range conincides with some cris-elf regressions
I see but haven't found the time to investigate...

[Bug target/53789] New: ICE in gen_reg_rtx, at emit-rtl.c:864/865 when compiling GNU MPFR on parisc

[vincent-gcc at vinc17 dot net]

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

 Bug #: 53789
   Summary: ICE in gen_reg_rtx, at emit-rtl.c:864/865 when
compiling GNU MPFR on parisc
Classification: Unclassified
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincent-...@vinc17.net


Created attachment 27712
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27712
preprocessed file

When compiling GNU MPFR on a parisc machine (gcc61.fsffrance.org), I get an ICE
(see below). This can be reproduced with:

  /opt/cfarm/release/4.4.1/bin/gcc -O3 tconst_pi.i

where tconst_pi.i is attached. The bug is not reproducible with -O2 only. I
couldn't find a similar bug report (including among the closed bugs), and there
doesn't seem to be a more recent GCC version on this machine.

$ ./config.status -V
MPFR config.status 3.1.1-rc1
configured by ../mpfr-3.1.1-rc1/configure, generated by GNU Autoconf 2.69,
  with options "'--enable-assert=full' '--enable-thread-safe'"
[GMP 4.2.2]
$ gcc --version
gcc (Debian 4.3.2-1.1) 4.3.2
$ make && make check
[...]
../../mpfr-3.1.1-rc1/tests/tconst_log2.c: In function 'main':
../../mpfr-3.1.1-rc1/tests/tconst_log2.c:201: internal compiler error: in
gen_reg_rtx, at emit-rtl.c:865
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [tconst_log2.o] Error 1
make[2]: Leaving directory `/tmp/mpfrtests-vinc17-13638/obj/tests'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/tmp/mpfrtests-vinc17-13638/obj/tests'
make: *** [check-recursive] Error 1

$ ./config.status -V
MPFR config.status 3.1.1-rc1
configured by ./configure, generated by GNU Autoconf 2.69,
  with options "'--enable-assert=full' '--enable-thread-safe'
'CC=/opt/cfarm/release/4.4.1/bin/gcc' 'CFLAGS=-Wall -O3 -mpa-risc-1-1
-std=gnu99'"
[GMP 4.2.2]
$ /opt/cfarm/release/4.4.1/bin/gcc --version
gcc (GCC) 4.4.1
$ make && make check
[...]
tconst_pi.c: In function 'main':
tconst_pi.c:186: internal compiler error: in gen_reg_rtx, at emit-rtl.c:864
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [tconst_pi.o] Error 1
make[2]: Leaving directory `/tmp/mpfrtests-vinc17-1115/mpfr-3.1.1-rc1/tests'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/tmp/mpfrtests-vinc17-1115/mpfr-3.1.1-rc1/tests'
make: *** [check-recursive] Error 1

This also occurred with MPFR 3.0.0 and 3.1.0 (at least).

[Bug middle-end/53790] New: ICE on dereferencing a extern union in asm statement

[samueldotj at gmail dot com]

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

 Bug #: 53790
   Summary: ICE on dereferencing a extern union in asm statement
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: samueld...@gmail.com


Created attachment 27713
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27713
Preprocessed sources

gcc-4.6.3 causes ICE when compiling program which dereferences a extern union
in asm().

It is avoided if the union's structure is made known to the compiler at compile
time.(Defined inside the c file or in an include file).
Removing optimization(-O0) also avoid this problem.

--
typedef long long uint64;

typedef struct s {
uint64 value;
} s_t;

static inline uint64
do_some_asm(s_t const *var)
{
   uint64 value;

   __asm__ __volatile__(
  "xor %1, %0"
  : "=r" (value)
  : "r" (var->value)
   );

   return value;
}

typedef union u u_t;

int main()
{
extern u_t extern_var;
return do_some_asm((s_t *)&extern_var);
}



$gcc -v -save-temps -O3 sample.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure
Thread model: posix
gcc version 4.6.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.3/cc1 -E -quiet -v
sample.c -mtune=generic -march=x86-64 -O3 -fpch-preprocess -o sample.i
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.3/cc1 -fpreprocessed
sample.i -quiet -dumpbase sample.c -mtune=generic -march=x86-64 -auxbase sample
-O3 -version -o sample.s
GNU C (GCC) version 4.6.3 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 4.3.2, MPFR version
2.4.2-p1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.6.3 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 4.3.2, MPFR version
2.4.2-p1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4cf08a0fcb4b2719a02f394936c437ef
sample.c: In function ‘main’:
sample.c:15:17: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Currently I am working around this by applying the following patch.
diff -rupN gcc-4.6.3/gcc/expr.c gcc-4.6.3.new1/gcc/expr.c
--- gcc-4.6.3/gcc/expr.c2012-02-09 09:28:22.0 -0800
+++ gcc-4.6.3.new1/gcc/expr.c   2012-06-20 22:53:10.613748645 -0700
@@ -9182,6 +9182,7 @@ expand_expr_real_1 (tree exp, rtx target
orig_op0 = op0
  = expand_expr (tem,
 (TREE_CODE (TREE_TYPE (tem)) == UNION_TYPE
+  && TYPE_SIZE (TREE_TYPE (tem))
  && (TREE_CODE (TYPE_SIZE (TREE_TYPE (tem)))
  != INTEGER_CST)
  && modifier != EXPAND_STACK_PARM

[Bug middle-end/53790] ICE on dereferencing a extern union in asm statement

[samueldotj at gmail dot com]

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

--- Comment #1 from Samuel Jacob  2012-06-27 
21:18:03 UTC ---
Adding back trace just in case if it is needed..

(gdb) bt
#0  0x005b999e in expand_expr_real_1 (exp=0x770b9580,
target=, tmode=VOIDmode, modifier=EXPAND_NORMAL,
alt_rtl=)
at ../.././gcc/expr.c:9187
#1  0x005bb50d in expand_expr_real (alt_rtl=,
modifier=, tmode=, target=,
exp=0x770b9580)
at ../.././gcc/expr.c:7383
#2  expand_expr_real (exp=0x770b9580, target=,
tmode=, modifier=, alt_rtl=) at
../.././gcc/expr.c:7351
#3  0x005b8e20 in expand_expr (modifier=EXPAND_NORMAL, mode=VOIDmode,
target=0x0, exp=) at ../.././gcc/expr.h:424
#4  expand_expr_real_1 (exp=0x770ba528, target=,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=) at
../.././gcc/expr.c:8992
#5  0x0070d4c3 in expand_expr (modifier=, mode=VOIDmode,
target=0x0, exp=0x770ba528) at ../.././gcc/expr.h:424
#6  expand_asm_operands (string=0x770bd168, outputs=,
inputs=, clobbers=0x770bd438, labels=0x0, vol=1, locus=1486)
at ../.././gcc/stmt.c:898
#7  0x0070e20a in expand_asm_stmt (stmt=) at
../.././gcc/stmt.c:1187
#8  0x00531b68 in expand_gimple_stmt_1 (stmt=0x770a33c0) at
../.././gcc/cfgexpand.c:1922
#9  expand_gimple_stmt (stmt=0x770a33c0) at ../.././gcc/cfgexpand.c:2084
#10 0x00532ca8 in expand_gimple_basic_block (bb=0x7709a1a0) at
../.././gcc/cfgexpand.c:3626
#11 0x0053664e in gimple_expand_cfg () at ../.././gcc/cfgexpand.c:4109
#12 0x00688ee9 in execute_one_pass (pass=0x1084cc0) at
../.././gcc/passes.c:1556
#13 0x00689195 in execute_pass_list (pass=0x1084cc0) at
../.././gcc/passes.c:1611
#14 0x007553c1 in tree_rest_of_compilation (fndecl=0x7709c800) at
../.././gcc/tree-optimize.c:422
#15 0x008955af in cgraph_expand_function (node=0x77e926e0) at
../.././gcc/cgraphunit.c:1576
#16 0x0089720a in cgraph_expand_all_functions () at
../.././gcc/cgraphunit.c:1635
#17 cgraph_optimize () at ../.././gcc/cgraphunit.c:1899
#18 0x0089760a in cgraph_finalize_compilation_unit () at
../.././gcc/cgraphunit.c:1096
#19 0x0049ffd5 in c_write_global_declarations () at
../.././gcc/c-decl.c:9878
#20 0x0071a1a8 in compile_file () at ../.././gcc/toplev.c:591
#21 do_compile () at ../.././gcc/toplev.c:1900
#22 toplev_main (argc=13, argv=0x7fffe318) at ../.././gcc/toplev.c:1963
#23 0x771b1c4d in __libc_start_main () from /lib/libc.so.6
#24 0x0048f971 in _start ()

[Bug middle-end/53790] ICE on dereferencing a extern union in asm statement

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2012-06-27 
21:19:47 UTC ---
I think this could should be rejected as "extern u_t extern_var;" is declaring
a variable with an unknown size.

[Bug middle-end/53790] ICE on dereferencing a extern union in asm statement

[samueldotj at gmail dot com]

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

Samuel Jacob  changed:

   What|Removed |Added

  Known to work||4.5.3

--- Comment #3 from Samuel Jacob  2012-06-27 
21:25:43 UTC ---
(In reply to comment #2)
> I think this could should be rejected as "extern u_t extern_var;" is declaring
> a variable with an unknown size.

I dont understand can you please elaborate - Why declaring a variable of
unknown size is problematic?

[Bug target/53749] ice in expand_shift_1

[rth at gcc dot gnu.org]

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

--- Comment #5 from Richard Henderson  2012-06-27 
21:30:45 UTC ---
Author: rth
Date: Wed Jun 27 21:30:41 2012
New Revision: 189026

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189026
Log:
i386: Fix logic error in r188785

PR target/53749
* config/i386/i386.c (ix86_rtx_costs): Fix typo vs UNITS_PER_WORD
in 2012-06-23 change.  Adjust two other DImode tests as well.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls

[thomas.orgis at awi dot de]

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

Thomas Orgis  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #6 from Thomas Orgis  2012-06-27 
21:31:06 UTC ---
Meh ... I see it. Trapped by those optional fortran dummy arguments. All the
fuss and hassle because of a dumb missing initialization. At least now I know
why this specific configuration crashed (y dimension has length 0).

OK, you're off the hook this time;-) I can kill compiler bug 25 from my list
(not just gfortran) as invalid and so can you with this report.

Thanks for investigating and also showing me the correct syntax to trap missing
initializations (for some reason, I had -finit-real-nan in my flags before ...
which is wrong in more than one way).

[Bug middle-end/53790] ICE on dereferencing a extern union in asm statement

[samueldotj at gmail dot com]

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

--- Comment #4 from Samuel Jacob  2012-06-27 
21:31:25 UTC ---
Also this doesnt happen with extern structures and variables.

ie
typedef struct u u_t;  or typedef int u_t;
is not causing the ICE.

[Bug fortran/53778] bad code (delivering NaN instead of proper result) with -foptimize-sibling-calls

[thomas.orgis at awi dot de]

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

--- Comment #7 from Thomas Orgis  2012-06-27 
21:34:43 UTC ---
Eh, it must have been -finit-real=nan ... so only wrong in one way;-)

[Bug tree-optimization/32120] missed PRE/FRE of a*2+4 and (a+2)*2

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||wschmidt at gcc dot gnu.org
 Resolution||FIXED

--- Comment #12 from William J. Schmidt  
2012-06-27 21:47:49 UTC ---
Fixed by the new strength reduction pass.

[Bug c++/53786] [C++11] alias template causes g++ segfault

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #1 from Daniel Krügler  
2012-06-27 22:18:16 UTC ---
The problem still persists in gcc 4.8.0 20120624 (experimental):

"5|internal compiler error: tree check: accessed elt 2 of tree_vec with 1 elts
in tsubst_pack_expansion, at cp/pt.c:9374"

[Bug c++/53788] C++11 decltype sfinae static member function check (4.7.1)

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #1 from Daniel Krügler  
2012-06-27 22:30:33 UTC ---
The problem also persists in gcc 4.8.0 20120624 (experimental).

Simplified example free from library dependencies:

struct t { static const bool value = true; };
struct f { static const bool value = false; };

template
struct has_static {
  template
  static t check(X*, decltype(T::fun())* = 0);
  static f check(...);

  typedef decltype(check((T*)(0))) ret;
  static const bool value = ret::value;
};

struct test { int fun() { return 0; } };

bool b = has_static::value;

[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion

[jimis at gmx dot net]

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

--- Comment #14 from jimis  2012-06-27 22:58:50 UTC ---
Ping? Can someone review my last patch? I think it's clean enough to be applied
(minus the TODO notes) and extra fixes can come separately later.

[Bug go/53679] Build failure in libgo

[vapier at gentoo dot org]

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

Mike Frysinger  changed:

   What|Removed |Added

 CC||toolchain at gentoo dot org

--- Comment #4 from Mike Frysinger  2012-06-27 
23:09:10 UTC ---
another alternative woul dbe to fix the libgo/ subdir to respect
--disable-werror like all the other places in the gcc tree

[Bug gcov-profile/45891] Guessed profile needs updating after profile-read

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-06-27
 CC||steven at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Steven Bosscher  2012-06-27 
23:16:32 UTC ---
Confirmed. Results in confusing dumps, too.

[Bug tree-optimization/53791] New: Branches not re-ordered using profile-information

[steven at gcc dot gnu.org]

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

 Bug #: 53791
   Summary: Branches not re-ordered using profile-information
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ste...@gcc.gnu.org


Consider the following test case:

extern void abort(void) __attribute__((__noreturn__));

static int __attribute__((__noinline__,__noclone__))
candidate_for_reordering (int x)
{
  asm volatile ("" : : : "memory");
  if (x == 1)
return 2;
  else if (x == 2)
return 4;
  else if (x == 3)
return 8;
  abort ();
}

int accum = 0;

int main (int argc __attribute__((__unused__)),
  char **argv __attribute__((__unused__)))
{
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);

  accum += candidate_for_reordering (1);

  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);

  accum += candidate_for_reordering (2);

  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);
  accum += candidate_for_reordering (3);

  return accum; /* 30*8 + 4 + 2 = 246 */
}


Compiling with -fprofile-generate, doing 3 test runs, and compiling with
-fprofile-use, results in this .040t.feedback_fnsplit dump for the
candidate_for_reordering function:

candidate_for_reordering (intD.0 xD.1241)
{
  intD.0 D.1319;

  # BLOCK 2 freq:1 count:96
  # PRED: ENTRY [100.0%]  count:96 (fallthru,exec)
  # .MEMD.1325_7 = VDEF <.MEMD.1325_6(D)>
  __asm__ __volatile__("" :  :  : "memory");
  # SUCC: 3 [100.0%]  count:96 (fallthru)

  # BLOCK 3 freq:1 count:96
  # PRED: 2 [100.0%]  count:96 (fallthru)
  if (xD.1241_2(D) == 1)
goto ;
  else
goto ;
  # SUCC: 7 [3.1%]  count:3 (true,exec) 4 [96.9%]  count:93 (false,exec)

  # BLOCK 4 freq:9688 count:93
  # PRED: 3 [96.9%]  count:93 (false,exec)
  if (xD.1241_2(D) == 2)
goto ;
  else
goto ;
  # SUCC: 7 [3.2%]  count:3 (true,exec) 5 [96.8%]  count:90 (false,exec)

  # BLOCK 5 freq:9375 count:90
  # PRED: 4 [96.8%]  count:90 (false,exec)
  if (xD.1241_2(D) == 3)
goto ;
  else
goto ;
  # SUCC: 7 [100.0%]  count:90 (true,exec) 6 (false,exec)


  # BLOCK 6
  # PRED: 5 (false,exec)
  # VUSE <.MEMD.1325_7>
  # USE = nonlocal
  # CLB = nonlocal
  abortD.830 ();
  # SUCC:

  # BLOCK 7 freq:1 count:96
  # PRED: 3 [3.1%]  count:3 (true,exec) 4 [3.2%]  count:3 (true,exec) 5
[100.0%]  count:90 (true,exec)
  # D.1319_1 = PHI <2(3), 4(4), 8(5)>
  return D.1319_1;
  # SUCC: EXIT [100.0%]  count:96

}




... and the following assembly (powerpc64):

candidate_for_reordering:
.quad   .L.candidate_for_reordering,.TOC.@tocbase
.previous
.type   candidate_for_reordering, @function
.L.candidate_for_reordering:
mflr 0
std 0,16(1)
stdu 1,-112(1)
cmpwi 7,3,1
beq- 7,.L4
cmpwi 0,3,2
beq- 0,.L5
cmpwi 1,3,3
bne- 1,.L3
li 3,8
.L1:   
addi 1,1,112
ld 4,16(1)
mtlr 4
blr
.L4:   
li 3,2
b .L1
.L5:   
li 3,4
b .L1
.L3:   
bl abort
nop


Note the very obvious (to the human eye, anyway) optimization opportunity to
test for (x == 3) first. GCC is currently (AFAICT) not able to optimize the
order of branches for mutually exclusive conditions using profile info.

This prevents my work to re-implement emit_case_bit_tests as a GIMPLE lowering
pass to have any meaningful impact on the compiler speed with
profiledbootstrap: There are a couple of tree and GIMPLE predicates that would
benefit from this transformation, but it's not happening...

[Bug tree-optimization/22586] GVN-PRE could do strength reduction

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||wschmidt at gcc dot gnu.org
 Resolution||FIXED

--- Comment #5 from William J. Schmidt  2012-06-28 
01:27:43 UTC ---
This specific case is handled by the new strength reduction pass.  Some more
complex scenarios will be added later.

[Bug middle-end/35308] Straight line strength reduction

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Keywords||missed-optimization
   Last reconfirmed||2012-06-28
 CC||wschmidt at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |wschmidt at gcc dot gnu.org
   |gnu.org |
 Resolution|DUPLICATE   |
 Ever Confirmed|0   |1
   Target Milestone|--- |4.8.0

--- Comment #3 from William J. Schmidt  2012-06-28 
01:36:25 UTC ---
Reopening this one since the cases in this bug report (unknown stride,
conditional candidate) are not yet handled by the new strength reduction pass. 
I will re-close once those additional features are in place.

[Bug rtl-optimization/53785] coalescing multiple static instances in function scope

[vincenzo.innocente at cern dot ch]

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

--- Comment #2 from vincenzo Innocente  
2012-06-28 04:43:27 UTC ---
I think that no one can rely on the way statics are initialized to tune side
effects.
The only things to guarantee are that is guarded and, I think, that the order
is preserved (because of possible side effects). in case getId is inlined even
the order can be optimized in my opinion...

Now one can have race conditions, so getId could actually be called by
different threads in a unpredictable way. With a single gard it will become a
unique critical section (or a sort of transactional memory block).
Maybe experts in initialization in multi-threaded environments shall comment
further...

[Bug lto/53777] [lto] lto does not propagate optimization flags from command lines given at "compilation time"

[vincenzo.innocente at cern dot ch]

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

--- Comment #2 from vincenzo Innocente  
2012-06-28 05:07:57 UTC ---
I fully agree that combining code sections to be optimized differently is not
well defined in particular when optimization works looking at a broader scope.
In principle one can imagine that an optimization-flag change should be
considered as an optimization barrier, but that clearly defeats the very
purpose of optimization itself and may lead to code that is less performant
that if compiled with the lower of all options...

Most probably we should go back and understand WHY users choose different
optimization level for different code sections.

In some cases is to workaround a compiler or coding problem

In our specific case the code to be compiled with -Os is "machine generated"
and contains mostly streamers not very sensitive to aggressive optimization
(vectorization helps in some, at best) : we judged that a smaller code (much
smaller actually!) and faster compilation was more effective.
It is packaged in the same library with the class they have to stream for
convenience and dependency management.
In reality I noticed that with lto the compilation time is fully dominated by
those files, so it is surely not "fast-developement" friendly. I suspect that
the final solution will be to segregate them into their own library.

I also experimented with trying to optimize more aggressively some
computational-intensive code segments.
In principle it could make sense, in practice I understand that as soon as
inter-procedural optimization kicks-in having code fragments with Ofast and
other with O2 can make little sense even from a pure numerical point of view:
think of an expression found in both sections that can be factorized out.

I suspect that the only safe way is to to segregate the code requested to be
compiled with different options, for sure if the option is "lower". Most
probably this is not what other users expects.

[Bug c++/53792] New: [C++11][constexpr] improving compiler-time constexpr evaluation

[vincenzo.innocente at cern dot ch]

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

 Bug #: 53792
   Summary: [C++11][constexpr] improving compiler-time constexpr
evaluation
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


Filed under c++ even if it is most probably an optimization issue.

At the moment it looks like that constexpr are evaluated at compile time only
if explicitly assigned to a constexpr constant. There are cases though where
the compiler can infer that the expression can still be evaluated at compile
time even if used in a run-time context.

Take the following quite realistic example of a consexpr "indexing table" used
to access a non-const array using string literals though an inline function.
In principle foo and bar are equivalent.
At the moment gcc evaluates "getIndex" at compile time for bar (where the marco
expansion explicitly instantiates a constexpr int, while it generates runtime
code for foo that uses the inlined function getV.

Would the compiler be able to transform getV in something like the code in the
macro?



constexpr entry theMap[] = {
 {"a", 0},
 {"b", 1},
 {nullptr,2}
};

// filled at run time 
double v[3];


constexpr bool  same(char const *x, char const *y)   {
 return !*x && !*y ? true : (*x == *y && same(x+1, y+1));
}

constexpr int getIndex(char const *label, entry const *entries)   {
 return !entries->label ? entries->index  : same(entries->label, label) ?
entries->index : getIndex(label, entries+1);
}


inline  double __attribute__((always_inline)) getV(const char * name )  {
 return  v[getIndex(name,theMap)];
}



#define SetV(X,NAME) \
constexpr int i_##X = getIndex(NAME, theMap);\
const double X = v[i_##X]


int foo() {
 const double a = getV("a");
 const double b = getV("b");

 if (a==b) return 1;
 return 0;

}

int bar() {
 SetV(a,"a");
 SetV(b,"b");

 if (a==b) return 1;
 return 0;

}