[Bug target/39469] Calculated values replaced with constants even if the constants cost more than the calculations

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||arm*-*-*
  Component|middle-end  |target

--- Comment #4 from Andrew Pinski  2012-01-02 
08:54:44 UTC ---
The ARM backend should do a splitter just like the rs6000 back-end does if it
is faster/smaller to load a constant via the instructions.

[Bug tree-optimization/51070] [4.6/4.7 Regression] ICE verify_gimple failed

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

Summary|[4.6 Regression] ICE|[4.6/4.7 Regression] ICE
   |verify_gimple failed|verify_gimple failed

--- Comment #6 from Richard Guenther  2012-01-02 
09:08:52 UTC ---
Confirmed.

[Bug fortran/51682] Coarray ICEs when compiling with -fdefault-integer-8

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2012-01-02 
09:54:44 UTC ---
Author: burnus
Date: Mon Jan  2 09:54:37 2012
New Revision: 182781

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182781
Log:
2012-01-02  Tobias Burnus  

PR fortran/51682
* trans-intrinsic.c (trans_this_image, trans_image_index,
trans_num_images, conv_intrinsic_cobound): Fold_convert the
caf_num_images/caf_this_images variables to the correct int kind.

2012-01-02  Tobias Burnus  

PR fortran/51682
* gfortran.dg/coarray/image_index_3.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/coarray/image_index_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/51682] Coarray ICEs when compiling with -fdefault-integer-8

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||burnus at gcc dot gnu.org
 Resolution||FIXED

--- Comment #2 from Tobias Burnus  2012-01-02 
09:57:45 UTC ---
FIXED on the 4.7 trunk.

Thanks for the report Dominique!

[Bug c++/51722] Options "-g3" or "-ggdb3" or "-g3 -gdwarf-2" and other "-g..level3" - internal compiler error

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-01-02 
10:15:57 UTC ---
Try disabling PCH, too.  If PCH is required to reproduce the bug also
include all preprocessed headers to build the PCH.

[Bug tree-optimization/51721] -Warray-bounds false positives and inconsistencies

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-02
 Ever Confirmed|0   |1

--- Comment #4 from Richard Guenther  2012-01-02 
10:19:13 UTC ---
(In reply to comment #2)
> This is a common problem with the -Warray-bounds warning, first jump threading
> (during vrp1) optimizes it into just a single s == 17 check, followed by
> a[11] = 0; b[11] = 0; c[17] = 0; d[11] = 0; if true and a[s] = 0; etc. if 
> false
> (well, at the end of vrp1 the constants aren't in the array refs yet, but they
> are propagated there afterwards), and as no optimization figures out the weird
> if (s >> 1 == 0) check (if (s < 2) would DTRT) to determine that s is not 17,
> vrp2 warns about those accesses.
> Perhaps for -Warray-bounds (at least if not -Warray-bounds=2 or similar) we
> shouldn't warn on code that has been jump threaded, anyway, I don't think that
> is solvable for 4.7 easily.
> 
> What we perhaps could do more easily for this testcase (and could improve code
> too) is during VRP for:
> :
>   D.1716_2 = s_1(D) >> 1;
>   if (D.1716_2 == 0)
> goto ;
>   else
> goto ;
> (or any other constant after >>, both signed and unsigned right shift, and ==
> or !=) insert ASSERT_EXPRs into both bbs, saying that the SSA_NAME in rhs1 of
> the
> shift is in/out of second ==/!= operand << rhs2 of shift, -""- + ((1 << rhs2) 
> -
> 1) range.  In this case it would be ASSERT_EXPRs that s_1(D) <= 1 at the start
> of bb 3 (and if bb 12 had only one predecessor, also that s_1(D) > 1 at bb 12
> start).  Richard, what do you think about that?

Yeah, if that turns out to be a common pattern, though maybe restrict it to
==/!= 0 tests?  (if that simplifies the patch)

[Bug tree-optimization/51719] [4.7 Regression] ICE: verify_gimple failed: LHS in noreturn call with -fpartial-inlining -fprofile-use and exceptions

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-02
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-01-02 
10:20:54 UTC ---
Confirmed.

[Bug gcov-profile/51717] [4.7 Regression] FAIL: gcc.misc-tests/gcov-14.c (test for excess errors)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||nathan at acm dot org
   Target Milestone|--- |4.7.0
Summary|FAIL:   |[4.7 Regression] FAIL:
   |gcc.misc-tests/gcov-14.c|gcc.misc-tests/gcov-14.c
   |(test for excess errors)|(test for excess errors)

[Bug gcov-profile/51715] [4.7 Regression] FAIL: gcc.misc-tests/gcov-13.c execution test

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||nathan at acm dot org
   Target Milestone|--- |4.7.0
Summary|FAIL:   |[4.7 Regression] FAIL:
   |gcc.misc-tests/gcov-13.c|gcc.misc-tests/gcov-13.c
   |execution test  |execution test

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-02
   Target Milestone|--- |4.7.0
Summary|FreeBSD uses unsupported|[4.7 Regression] FreeBSD
   |C++11 features when |uses unsupported C++11
   |__cplusplus == 201103L  |features when __cplusplus
   ||== 201103L
 Ever Confirmed|0   |1

[Bug tree-optimization/51721] -Warray-bounds false positives and inconsistencies

[jakub at gcc dot gnu.org]

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

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-01-02 
10:24:55 UTC ---
Created attachment 26216
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26216
gcc47-pr51721.patch

Uptested patch, this time even with testcases.  Restricting just to
EQ_EXPR/NE_EXPR would save just 3 extra stmts and two ifs in the patch, and
restricting to EQ_EXPR/NE_EXPR with constant 0 as opposed to any constant
wouldn't simplify the patch at all.

[Bug tree-optimization/51692] [4.7 Regression] ICE on several valgrind tests

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Guenther  2012-01-02 
10:26:37 UTC ---
Mine.

[Bug target/51687] gcc is killed when compiling med-3.0.4

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-01-02
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2012-01-02 
10:30:51 UTC ---
Can't reproduce it either - the testcase uses a mere 40MB for 4.7 and 4.6.2
on x86_64-linux with -m32.

Please check why your OS kills the process (and which process is killed).

[Bug c++/2316] g++ fails to overload on language linkage

[marc.glisse at normalesup dot org]

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

--- Comment #38 from Marc Glisse  2012-01-02 
10:39:35 UTC ---
Thanks for the comments.

(In reply to comment #36)
> The library should overload qsort, then the libitm/clone.cc change wouldn't be
> needed

Indeed, that was the meaning of my comment "provide the true qsort prototype
instead", I'll do that next time.


(In reply to comment #37)
> I think the change to tree.c should not be done as it is middle-end code.  
> That
> should be in the C++ front-end specific code instead.  That is the middle-end
> should not care about the difference between extern "C" function types and
> extern "C++" ones.

That makes sense. I am surprised to see that I only use the new function once
outside of the cp/ directory, and I don't even know whether that is really
necessary. On the other hand, there may be other places I missed that need to
preserve this information while building variants of the type. And keeping it
in tree.c avoids duplicating this code. Maybe it would make sense to keep it in
the middle-end, making the extra field an opaque "extra information" that the
middle-end needs to preserve if it ever builds type variants? Although if it
clones the function in some way, preserving the linkage may not make that much
sense. (I don't have any experience so I may talk nonsense ;-)

This information is supposed to be related to the calling convention (although
the g++ ABI uses the same in all cases), which I guess is relevant to pass down
to middle and back-end (then it isn't opaque anymore).

The functions like __builtin_memcpy declared in tree.c should probably have "C"
linkage. Which means it might be better if I switched to using a non-zero value
for "C++" linkage (or at least make build_function_type build a C linkage type
by default) so I don't interfere as much with the rest.

So many choices... Well, that's for the next holidays unless someone else wants
to work on it.

[Bug tree-optimization/51680] [4.7 Regression] g++ 4.7 fails to inline trivial template stuff

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Guenther  2012-01-02 
10:43:03 UTC ---
Analyzing function body size: float add1(float)
Accounting size:2.00, time:0.00 on new predicate:(not inlined)

 BB 2 predicate:(true)
  D.2207_2 = x_1(D) + 1.0e+0;
freq:1.00 size:  1 time:  1
Accounting size:1.00, time:1.00 on predicate:(true)
  return D.2207_2;
freq:1.00 size:  1 time:  2
Will be eliminated by inlining
Accounting size:1.00, time:2.00 on predicate:(not inlined)

Inline summary for float add1(float)/0 inlinable
  self time:   3
  global time: 0
  self size:   4
  global size: 0
  self stack:  0
  global stack:0
size:1.00, time:1.00, predicate:(true)
size:3.00, time:2.00, predicate:(not inlined)
  calls:

float add1(float) (float x)
{
  float D.2207;

:
  D.2207_2 = x_1(D) + 1.0e+0;
  return D.2207_2;

}


Analyzing function body size: void process_fun_at(const Fun&, T) [with Fun =
float(float); T = float]
Accounting size:2.00, time:0.00 on new predicate:(not inlined)

 BB 2 predicate:(true)
  D.2206_3 = fun_1(D) (x_2(D));
freq:1.00 size:  5 time: 17
  D.2205_4 = D.2206_3;
freq:1.00 size:  0 time:  0
  process (D.2205_4);
freq:1.00 size:  2 time: 11
  return;
freq:1.00 size:  1 time:  2
Will be eliminated by inlining
Accounting size:1.00, time:2.00 on predicate:(not inlined)

Inline summary for void process_fun_at(const Fun&, T) [with Fun = float(float);
T = float]/2 inlinable
  self time:   30
  global time: 0
  self size:   10
  global size: 0
  self stack:  0
  global stack:0
size:0.00, time:0.00, predicate:(true)
size:3.00, time:2.00, predicate:(not inlined)
  calls:
void process(float)/3 function body not available
  loop depth: 0 freq:1000 size: 2 time: 11 callee size: 0 stack: 0
indirect call loop depth: 0 freq:1000 size: 5 time: 17

Inline summary for void test(float)/1 inlinable
  self time:   14
  global time: 0
  self size:   6
  global size: 0
  self stack:  0
  global stack:0
size:0.00, time:0.00, predicate:(true)
size:3.00, time:2.00, predicate:(not inlined)
  calls:
void process_fun_at(const Fun&, T) [with Fun = float(float); T = float]/2
function not considered for inlining
  loop depth: 0 freq:1000 size: 3 time: 12 callee size: 5 stack: 0

void test(float) (float i)
{
:
  process_fun_at (add1, i_1(D));
  return;

}

during early inlining we decide:

;; Function void test(float) (_Z4testf, funcdef_no=2, decl_uid=2196,
cgraph_uid=1)

Considering inline candidate void process_fun_at(const Fun&, T) [with Fun =
float(float); T = float].
   Estimating body: void process_fun_at(const Fun&, T) [with Fun =
float(float); T = float]/2
   Known to be false: not inlined
   size:7 time:28
   Estimating body: void process_fun_at(const Fun&, T) [with Fun =
float(float); T = float]/2
   Known to be false: not inlined
   size:7 time:28
  will not early inline: void test(float)/1->void process_fun_at(const Fun&, T)
[with Fun = float(float); T = float]/2, callee is not leaf and code would grow
by 4
Iterations: 0
void test(float) (float i)
{
:
  process_fun_at (add1, i_1(D));

because we'd replace one call with two.  Not sure what the

Inline summary for void process_fun_at(const Fun&, T) [with Fun = float(float);
T = float]/2 inlinable
...
size:0.00, time:0.00, predicate:(true)
size:3.00, time:2.00, predicate:(not inlined)

lines mean.  Honza?

[Bug other/51679] spurious parenthesis for -fassociative-math in manual and man page

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2012-01-02 
10:46:04 UTC ---
Author: rguenth
Date: Mon Jan  2 10:46:01 2012
New Revision: 182785

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182785
Log:
2012-01-02  Richard Guenther  

PR other/51679
* invoke.texi (fassociative-math): Remove spurious paranthesis.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

[Bug other/51679] spurious parenthesis for -fassociative-math in manual and man page

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Richard Guenther  2012-01-02 
10:46:25 UTC ---
Fixed.

[Bug other/51678] 'make pdf' is broken in libiberty

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2012-01-02 
10:47:19 UTC ---
Must be broken since forever or caused by your host TeX installation.

[Bug c/51676] -Wsuggest-attribute={pure,const} should give line number of declaration, not definition

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-02
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2012-01-02 
10:48:54 UTC ---
Yeah, it's pretty difficult (read: impossible) to implement.  Consider
multiple declarations as well ...

[Bug c++/51675] [C++11][4.7 Regression] Cannot create constexpr unions

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug c++/51669] [4.7 Regression] ICE verify-gimple with openmp

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Known to work||4.6.2
   Target Milestone|--- |4.7.0
Summary|ICE verify-gimple with  |[4.7 Regression] ICE
   |openmp  |verify-gimple with openmp

--- Comment #3 from Richard Guenther  2012-01-02 
10:54:40 UTC ---
Works with 4.6.

[Bug bootstrap/51686] "make install-strip-gcc" didn't install liblto-plugin* files

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-01-02 
10:59:08 UTC ---
Author: rguenth
Date: Mon Jan  2 10:59:04 2012
New Revision: 182788

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182788
Log:
2012-01-02  Richard Guenther  

PR bootstrap/51686
* Makefile.def (install-strip-gcc): Depend on install-strip-lto-plugin.
* Makefile.in: Regenerate.

Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in

[Bug bootstrap/51686] "make install-strip-gcc" didn't install liblto-plugin* files

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2012-01-02 
11:02:15 UTC ---
Author: rguenth
Date: Mon Jan  2 11:02:10 2012
New Revision: 182790

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182790
Log:
2012-01-02  Richard Guenther  

PR bootstrap/51686
* Makefile.def (install-strip-gcc): Depend on install-strip-lto-plugin.
* Makefile.in: Regenerate.

Modified:
branches/gcc-4_6-branch/ChangeLog
branches/gcc-4_6-branch/Makefile.def
branches/gcc-4_6-branch/Makefile.in

[Bug bootstrap/51686] "make install-strip-gcc" didn't install liblto-plugin* files

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.3

--- Comment #5 from Richard Guenther  2012-01-02 
11:02:25 UTC ---
Fixed.

[Bug middle-end/51728] [4.7 Regression]: libstdc++ 25_algorithms/count_if/1.cc, 25_algorithms/partition_point/1.cc, 25_algorithms/search/1.cc SEGV ICE

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Component|regression  |middle-end
   Target Milestone|--- |4.7.0

[Bug target/50616] lto1.exe: internal compiler error: invalid resolution in the resolution file

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||lto
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-01-02
  Component|lto |target
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2012-01-02 
11:17:47 UTC ---
Please attach the resolution file (you can obtain it by adding -v -save-temps
to the command-line, the file is the one mentioned as argument to the
-fresolution= command-line argument to lto1.exe)

What binutils version are you using?  I suspect a mismatch between
binutils/gcc here.

[Bug target/51726] LTO and attribute 'selectany'

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-02
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-01-02 
11:19:41 UTC ---
It's a target bug - the target should ignore the attribute on extern
declarations.

case VAR_DECL:
  if (lookup_attribute ("selectany", DECL_ATTRIBUTES (decl)))
{
  if (DECL_INITIAL (decl)
  /* If an object is initialized with a ctor, the static
 initialization and destruction code for it is present in
 each unit defining the object.  The code that calls the
 ctor is protected by a link-once guard variable, so that
 the object still has link-once semantics,  */
  || TYPE_NEEDS_CONSTRUCTING (TREE_TYPE (decl)))
make_decl_one_only (decl, DECL_ASSEMBLER_NAME (decl));
  else
error ("%q+D:'selectany' attribute applies only to "
   "initialized objects", decl);
}

thus, restrict processing to !DECL_EXTERNAL

[Bug bootstrap/51725] [4.7 regression] segfault in stage 3 when compiling gcc/opts.c for sparc64-linux

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-02
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

[Bug c++/51724] no matching function for call; confused by earlier errors, bailing out

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0
  Known to fail||4.6.2

--- Comment #2 from Richard Guenther  2012-01-02 
11:23:25 UTC ---
Confirmed, the branch ICEs like

t.C: In member function ‘void solver::foo(solver::type)
[with T = int, Plugin = plugin<>, solver::type = int]’:
t.C:39:32:   instantiated from here
t.C:33:3: error: no matching function for call to ‘plugin<>::foo(solver >&, solver >::type&)’
t.C:33:3: note: candidates are:

in dependent_type_p, at cp/pt.c:18102
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Fixed on trunk.

[Bug testsuite/51703] FAIL: gfortran.dg/io_real_boz_[345].f90 -O (test for excess errors)

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2012-01-02 
11:24:32 UTC ---
Seemingly fixed by http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00026.html

Thanks for the report - and thanks to Richard for the patch. Please confirm
that it is now fixed - and close the bug.

[Bug target/51729] New: dspr2-MULT.c and dspr2-MULTU.c fail for MIPS

[rsandifo at gcc dot gnu.org]

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

 Bug #: 51729
   Summary: dspr2-MULT.c and dspr2-MULTU.c fail for MIPS
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rsand...@gcc.gnu.org


dspr2-MULT.c and dspr2-MULTU.c are supposed to test that we use the
DSP accumulator registers to parallelise multiplications.  They don't
work in 4.7, and I'm about to XFAIL them.  There seem to be two main
problems:

* The cost of moving between DSP accumulators is greater than the cost
  of moving a DSP register to or from memory.  When I last looked,
  this was enough to make the register allocator consider memory to
  be cheaper.

  This isn't a problem without -mdsp because there is then only one
  accumulator register, LO+HI.  (Note that we no longer allow HI and
  LO to store independent values.)  The cost of moving between accumulators
  is therefore ignored.

  On some (many?) targets, moving something out of an accumulator
  and back again _is_ more expensive than storing an accumulator
  to memory, so this isn't necessarily a bug in the backend.

* Even if we massage the costs to avoid that problem, each of the pseudos
  that we'd like to use accumulators has one "=ka" constraint and one
  "d" constraint.  At one point this meant that DSP_REGS and GENERAL_REGS
  had the same cost, and reg_alloc_order could be used to prefer accumulators:

http://gcc.gnu.org/ml/gcc/2010-12/msg00471.html
http://gcc.gnu.org/ml/gcc/2011-01/msg00093.html

  But GENERAL_REGS now seems to have a lower cost, and since GENERAL_REGS
  are much easier to spill than DSP_REGS, it's hard to argue with that.

[Bug target/51729] dspr2-MULT.c and dspr2-MULTU.c fail for MIPS

[rsandifo at gcc dot gnu.org]

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

--- Comment #1 from rsandifo at gcc dot gnu.org  
2012-01-02 11:33:39 UTC ---
Author: rsandifo
Date: Mon Jan  2 11:33:35 2012
New Revision: 182793

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182793
Log:
gcc/testsuite/
PR target/51729
* gcc.target/mips/dspr2-MULT.c: Remove -ffixed-hi -ffixed-lo.
XFAIL.
* gcc.target/mips/dspr2-MULTU.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/mips/dspr2-MULT.c
trunk/gcc/testsuite/gcc.target/mips/dspr2-MULTU.c

[Bug rtl-optimization/47477] [4.6/4.7/4.8 regression] Sub-optimal mov at end of method

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
   Target Milestone|4.7.0   |4.8.0
Summary|[4.6/4.7 regression]|[4.6/4.7/4.8 regression]
   |Sub-optimal mov at end of   |Sub-optimal mov at end of
   |method  |method

--- Comment #9 from Jakub Jelinek  2012-01-02 
11:36:32 UTC ---
Postponing for 4.8, as agreed by Richard this is stage1 material and
unfortunately has been forgotten during 4.7 stage1.  From quick glance at it,
we want to reimplement get_unwidened and the narrowing integer conversion part
of convert_to_integer on GIMPLE, must likely in forwprop.

[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0

[dodji at seketeli dot org]

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

--- Comment #15 from dodji at seketeli dot org  
2012-01-02 12:01:45 UTC ---
> It would be very helpful to get this into 4.6.3 too if it's safe

Sure thing.  I am currently testing the patch on 4.6.  Thanks for the
head-up.

[Bug c/51730] New: [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7

[jakub at gcc dot gnu.org]

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

 Bug #: 51730
   Summary: [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h
check fails with GCC 4.7
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: js...@gcc.gnu.org


During a distro mass rebuild, I found that many packages still have configure
generated with autoconf 2.60 through 2.67, and these autoconf contain a not
strictly valid C:
 /* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
reported by James Lemley on 2005-10-05; see
   
http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
This test is not quite right, since xlc is allowed to
reject this program, as the initializer for xlcbug is
not one of the forms that C requires support for.
However, doing the test right would require a runtime
test, and that would make cross-compilation harder.
Let us hope that IBM fixes the xlc bug, and also adds
support for this kind of constant expression.  In the
meantime, this test will reject xlc, which is OK, since
our stdbool.h substitute should suffice.  We also test
this with GCC, where it should work, to detect more
quickly whether someone messes up the test in the
future.  */
 char digs[] = "0123456789";
 int xlcbug = 1 / (&(digs + 5)[-2 + (_Bool) 1] == &digs[4] ? 1 : -1);
check.  Until http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172958
GCC has been accepting this though, and I suppose we don't want to fold array
refs that way when generating code.  Would it be possible to fold it that way
(try harder) just when we know we are not going to generate code based on it
(or when we know we'd error out otherwise)?  I know it sounds like an ugly
hack,
unfortunately autoconf 2.6[0-7] generated configure scripts are going to be
around for many years and the stdbool.h checks would fail in hundreds of
packages.

[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

--- Comment #1 from Jakub Jelinek  2012-01-02 
12:14:38 UTC ---
Note that autoconf 2.59 and earlier didn't contain this and autoconf 2.68
removed it again, as it started failing with newer xlc version too.

[Bug c++/51731] New: code generation bug in negative indices in arrays on 64-bit targets

[m.hekkelman at cmbi dot ru.nl]

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

 Bug #: 51731
   Summary: code generation bug in negative indices in arrays on
64-bit targets
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m.hekkel...@cmbi.ru.nl


Created attachment 26217
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26217
source file containing a fully self contained bug description

When compiling the attached code with -O3 the generated code is incorrect as
can be seen by the output of the program. The problem was introduced in gcc
4.5, earlier versions did not have this problem.

[Bug target/51681] [4.7 Regression]: ICE in gcc.dg/torture/vshuf-v2si.c on ia64

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |ubizjak at gmail dot com
   |gnu.org |

--- Comment #3 from Uros Bizjak  2012-01-02 12:29:05 
UTC ---
I am testing patches for both issues.

[Bug target/51681] [4.7 Regression]: ICE in gcc.dg/torture/vshuf-v2si.c on ia64

[ubizjak at gmail dot com]

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

--- Comment #4 from Uros Bizjak  2012-01-02 12:31:24 
UTC ---
(In reply to comment #1)

> FAIL: gcc.dg/torture/vshuf-v8qi.c  -O2  execution test

It is not related to original failure; following patchlet fixes the failure:

--cut here--
@@ -11207,7 +11210,7 @@ expand_vec_perm_broadcast (struct expand_vec_perm_
   elt *= BITS_PER_UNIT;
   temp = gen_reg_rtx (DImode);
   emit_insn (gen_extzv (temp, gen_lowpart (DImode, d->op0),
-   GEN_INT (elt), GEN_INT (8)));
+   GEN_INT (8), GEN_INT (elt)));
   emit_insn (gen_mux1_brcst_qi (d->target, gen_lowpart (QImode, temp)));
   break;

--cut here--

[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

[burnus at gcc dot gnu.org]

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

--- Comment #11 from Tobias Burnus  2012-01-02 
12:30:42 UTC ---
See also RFC patch: http://gcc.gnu.org/ml/fortran/2011-10/msg00136.html
and reply: http://gcc.gnu.org/ml/fortran/2011-10/msg00138.html

[Bug target/51681] [4.7 Regression]: ICE in gcc.dg/torture/vshuf-v2si.c on ia64

[ubizjak at gmail dot com]

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

--- Comment #5 from Uros Bizjak  2012-01-02 12:35:25 
UTC ---
Patch:

--cut here--
Index: ia64.c
===
--- ia64.c  (revision 182780)
+++ ia64.c  (working copy)
@@ -11085,7 +11085,7 @@ static bool
 expand_vec_perm_shrp (struct expand_vec_perm_d *d)
 {
   unsigned i, nelt = d->nelt, shift, mask;
-  rtx tmp, op0, op1;;
+  rtx tmp, hi, lo;

   /* ??? Don't force V2SFmode into the integer registers.  */
   if (d->vmode == V2SFmode)
@@ -11101,6 +11101,11 @@ expand_vec_perm_shrp (struct expand_vec_perm_d *d)
   if (d->testing_p)
 return true;

+  hi = shift < nelt ? d->op1 : d->op0;
+  lo = shift < nelt ? d->op0 : d->op1;
+
+  shift %= nelt;
+
   shift *= GET_MODE_UNIT_SIZE (d->vmode) * BITS_PER_UNIT;

   /* We've eliminated the shift 0 case via expand_vec_perm_identity.  */
@@ -3,11 +8,9 @@ expand_vec_perm_shrp (struct expand_vec_perm_d *d)
 shift = 64 - shift;

   tmp = gen_reg_rtx (DImode);
-  op0 = (shift < nelt ? d->op0 : d->op1);
-  op1 = (shift < nelt ? d->op1 : d->op0);
-  op0 = gen_lowpart (DImode, op0);
-  op1 = gen_lowpart (DImode, op1);
-  emit_insn (gen_shrp (tmp, op0, op1, GEN_INT (shift)));
+  hi = gen_lowpart (DImode, hi);
+  lo = gen_lowpart (DImode, lo);
+  emit_insn (gen_shrp (tmp, hi, lo, GEN_INT (shift)));

   emit_move_insn (d->target, gen_lowpart (d->vmode, tmp));
   return true;
--cut here--

Just a bunch of mix-ups; where high/low part goes, shift value is not adjusted
after operand swap, and shift value is compared in *bits* to number of
elements.

[Bug fortran/51529] [OOP] gfortran.dg/class_to_type_1.f03 is miscompiled: Uninitialized variable used

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  2012-01-02 12:46:14 
UTC ---
Author: pault
Date: Mon Jan  2 12:46:08 2012
New Revision: 182796

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182796
Log:
2012-01-02  Paul Thomas  

PR fortran/51529
* trans-array.c (gfc_array_allocate): Null allocated memory of
newly allocted class arrays.

PR fortran/46262
PR fortran/46328
PR fortran/51052
* interface.c(build_compcall_for_operator): Add a type to the
expression.
* trans-expr.c (conv_base_obj_fcn_val): New function.
(gfc_conv_procedure_call): Use base_expr to detect non-variable
base objects and, ensuring that there is a temporary variable,
build up the typebound call using conv_base_obj_fcn_val.
(gfc_trans_class_assign): Pick out class procedure pointer
assignments and do the assignment with no further prcessing.
(gfc_trans_class_array_init_assign, gfc_trans_class_init_assign
gfc_trans_class_assign): Move to top of file.
* gfortran.h : Add 'base_expr' field to gfc_expr.
* resolve.c (get_declared_from_expr): Add 'types' argument to
switch checking of derived types on or off.
(resolve_typebound_generic_call): Set the new argument.
(resolve_typebound_function, resolve_typebound_subroutine):
Set 'types' argument for get_declared_from_expr appropriately.
Identify base expression, if not a variable, in the argument
list of class valued calls. Assign it to the 'base_expr' field
of the final expression. Strip away all references after the
last class reference.


2012-01-02  Paul Thomas  

PR fortran/46262
PR fortran/46328
PR fortran/51052
* gfortran.dg/typebound_operator_7.f03: New.
* gfortran.dg/typebound_operator_8.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/typebound_operator_7.f03
trunk/gcc/testsuite/gfortran.dg/typebound_operator_8.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dump-parse-tree.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/46262] [OOP] tree check: expected function_type or method_type, have pointer_type

[pault at gcc dot gnu.org]

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

--- Comment #12 from Paul Thomas  2012-01-02 12:46:15 
UTC ---
Author: pault
Date: Mon Jan  2 12:46:08 2012
New Revision: 182796

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182796
Log:
2012-01-02  Paul Thomas  

PR fortran/51529
* trans-array.c (gfc_array_allocate): Null allocated memory of
newly allocted class arrays.

PR fortran/46262
PR fortran/46328
PR fortran/51052
* interface.c(build_compcall_for_operator): Add a type to the
expression.
* trans-expr.c (conv_base_obj_fcn_val): New function.
(gfc_conv_procedure_call): Use base_expr to detect non-variable
base objects and, ensuring that there is a temporary variable,
build up the typebound call using conv_base_obj_fcn_val.
(gfc_trans_class_assign): Pick out class procedure pointer
assignments and do the assignment with no further prcessing.
(gfc_trans_class_array_init_assign, gfc_trans_class_init_assign
gfc_trans_class_assign): Move to top of file.
* gfortran.h : Add 'base_expr' field to gfc_expr.
* resolve.c (get_declared_from_expr): Add 'types' argument to
switch checking of derived types on or off.
(resolve_typebound_generic_call): Set the new argument.
(resolve_typebound_function, resolve_typebound_subroutine):
Set 'types' argument for get_declared_from_expr appropriately.
Identify base expression, if not a variable, in the argument
list of class valued calls. Assign it to the 'base_expr' field
of the final expression. Strip away all references after the
last class reference.


2012-01-02  Paul Thomas  

PR fortran/46262
PR fortran/46328
PR fortran/51052
* gfortran.dg/typebound_operator_7.f03: New.
* gfortran.dg/typebound_operator_8.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/typebound_operator_7.f03
trunk/gcc/testsuite/gfortran.dg/typebound_operator_8.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dump-parse-tree.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/51052] [OOP] Internal compiler error in gfc_conv_component

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  2012-01-02 12:46:16 
UTC ---
Author: pault
Date: Mon Jan  2 12:46:08 2012
New Revision: 182796

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182796
Log:
2012-01-02  Paul Thomas  

PR fortran/51529
* trans-array.c (gfc_array_allocate): Null allocated memory of
newly allocted class arrays.

PR fortran/46262
PR fortran/46328
PR fortran/51052
* interface.c(build_compcall_for_operator): Add a type to the
expression.
* trans-expr.c (conv_base_obj_fcn_val): New function.
(gfc_conv_procedure_call): Use base_expr to detect non-variable
base objects and, ensuring that there is a temporary variable,
build up the typebound call using conv_base_obj_fcn_val.
(gfc_trans_class_assign): Pick out class procedure pointer
assignments and do the assignment with no further prcessing.
(gfc_trans_class_array_init_assign, gfc_trans_class_init_assign
gfc_trans_class_assign): Move to top of file.
* gfortran.h : Add 'base_expr' field to gfc_expr.
* resolve.c (get_declared_from_expr): Add 'types' argument to
switch checking of derived types on or off.
(resolve_typebound_generic_call): Set the new argument.
(resolve_typebound_function, resolve_typebound_subroutine):
Set 'types' argument for get_declared_from_expr appropriately.
Identify base expression, if not a variable, in the argument
list of class valued calls. Assign it to the 'base_expr' field
of the final expression. Strip away all references after the
last class reference.


2012-01-02  Paul Thomas  

PR fortran/46262
PR fortran/46328
PR fortran/51052
* gfortran.dg/typebound_operator_7.f03: New.
* gfortran.dg/typebound_operator_8.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/typebound_operator_7.f03
trunk/gcc/testsuite/gfortran.dg/typebound_operator_8.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dump-parse-tree.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/46328] [OOP] type-bound operator call with non-trivial polymorphic operand

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  2012-01-02 12:46:15 
UTC ---
Author: pault
Date: Mon Jan  2 12:46:08 2012
New Revision: 182796

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182796
Log:
2012-01-02  Paul Thomas  

PR fortran/51529
* trans-array.c (gfc_array_allocate): Null allocated memory of
newly allocted class arrays.

PR fortran/46262
PR fortran/46328
PR fortran/51052
* interface.c(build_compcall_for_operator): Add a type to the
expression.
* trans-expr.c (conv_base_obj_fcn_val): New function.
(gfc_conv_procedure_call): Use base_expr to detect non-variable
base objects and, ensuring that there is a temporary variable,
build up the typebound call using conv_base_obj_fcn_val.
(gfc_trans_class_assign): Pick out class procedure pointer
assignments and do the assignment with no further prcessing.
(gfc_trans_class_array_init_assign, gfc_trans_class_init_assign
gfc_trans_class_assign): Move to top of file.
* gfortran.h : Add 'base_expr' field to gfc_expr.
* resolve.c (get_declared_from_expr): Add 'types' argument to
switch checking of derived types on or off.
(resolve_typebound_generic_call): Set the new argument.
(resolve_typebound_function, resolve_typebound_subroutine):
Set 'types' argument for get_declared_from_expr appropriately.
Identify base expression, if not a variable, in the argument
list of class valued calls. Assign it to the 'base_expr' field
of the final expression. Strip away all references after the
last class reference.


2012-01-02  Paul Thomas  

PR fortran/46262
PR fortran/46328
PR fortran/51052
* gfortran.dg/typebound_operator_7.f03: New.
* gfortran.dg/typebound_operator_8.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/typebound_operator_7.f03
trunk/gcc/testsuite/gfortran.dg/typebound_operator_8.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dump-parse-tree.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug target/51345] [avr] Devices with 8-bit SP need their own multilib(s)

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay  2012-01-02 
12:52:00 UTC ---
Author: gjl
Date: Mon Jan  2 12:51:57 2012
New Revision: 182797

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182797
Log:
contrib/
PR target/51345
* gcc_update (files_and_dependencies): Add
gcc/config/avr/t-multilib, gcc/config/avr/multilib.h.

libgcc/
PR target/51345
* config/avr/lib1funcs.S: Remove FIXME comments.
(SPEED_DIV): Depend on __AVR_HAVE_8BIT_SP__.
gcc/
PR target/51345
* config.gcc (tm_file target=avr]): Add avr/avr-multilib.h
(tmake_file target=avr): Add avr/t-multilib.

* config/avr/avr-c.c (avr_cpu_cpp_builtins): Use AVR_HAVE_8BIT_SP
to built-in define __AVR_HAVE_8BIT_SP__, __AVR_HAVE_16BIT_SP__.
* config/avr/genmultilib.awk: New file.
* config/avr/t-multilib: New auto-generated file.
* config/avr/multilib.h: New auto-generated file.
* config/avr/t-avr (AVR_MCUS): New variable.
(genopt.sh): Use it.
(s-mlib): Depend on t-multilib.
(t-multilib, multilib.h): New dependencies.
(s-avr-mlib): New rule to build t-multilib, multilib.h from AVR_MCUS.
(MULTILIB_OPTIONS): Remove.
(MULTILIB_MATCHES): Remove.
(MULTILIB_DIRNAMES): Remove.
(MULTILIB_EXCEPTIONS): Remove:
* config/avr/genopt.sh: Don't use hard coded file name;
pass AVR_MCUS from t-avr instead.


Added:
trunk/gcc/config/avr/genmultilib.awk
trunk/gcc/config/avr/multilib.h
trunk/gcc/config/avr/t-multilib
Modified:
trunk/contrib/ChangeLog
trunk/contrib/gcc_update
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
trunk/gcc/config/avr/avr-c.c
trunk/gcc/config/avr/avr-mcus.def
trunk/gcc/config/avr/genopt.sh
trunk/gcc/config/avr/t-avr
trunk/libgcc/ChangeLog
trunk/libgcc/config/avr/lib1funcs.S

[Bug fortran/51052] [OOP] Internal compiler error in gfc_conv_component

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #9 from Paul Thomas  2012-01-02 13:00:36 
UTC ---
Fixed on trunk.

Thanks for the report

Paul

[Bug fortran/46328] [OOP] type-bound operator call with non-trivial polymorphic operand

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #8 from Paul Thomas  2012-01-02 13:01:21 
UTC ---
Fixed on trunk.

Thanks for the report

Paul

[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  2012-01-02 13:03:35 UTC ---
On Mon, 2 Jan 2012, jakub at gcc dot gnu.org wrote:

>  char digs[] = "0123456789";
>  int xlcbug = 1 / (&(digs + 5)[-2 + (_Bool) 1] == &digs[4] ? 1 : -1);
> check.  Until http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172958
> GCC has been accepting this though, and I suppose we don't want to fold array
> refs that way when generating code.  Would it be possible to fold it that way
> (try harder) just when we know we are not going to generate code based on it
> (or when we know we'd error out otherwise)?  I know it sounds like an ugly

As I understand it, the point of that commit was that the conversion of 
all array references to pointer arithmetic (losing all information about 
signs of indices) was problematic.  But it should still be valid to fold a 
comparison that way: if the addresses being compared have the same base 
object and all offsets are constant integers, a final byte offset for each 
address can be computed mod the size of the address space and it's OK to 
fold based on comparing those offsets (if the actual, signed offsets 
involved overflow anywhere, that would have been execution-time undefined 
behavior).  That is, I think it would be better to fix this by improving 
the folding of address comparisons, rather than by changing how array 
references are expanded.

[Bug fortran/46262] [OOP] tree check: expected function_type or method_type, have pointer_type

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #13 from Paul Thomas  2012-01-02 13:03:12 
UTC ---
Fixed on trunk.

Thanks to everybody for the reports and testcases.

Paul

[Bug other/51732] New: typo in man gcc: "runt-time check"

[martinwguy at gmail dot com]

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

 Bug #: 51732
   Summary: typo in man gcc: "runt-time check"
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: martinw...@gmail.com


"man gcc" says:

-mno-8bit-idiv
   On some processors, like Intel Atom, 8bit unsigned integer divide
   is much faster than 32bit/64bit integer divide.  This option will
   generate a runt-time check.  If both dividend and divisor are
   within range of 0 to 255, 8bit unsigned integer divide will be used
   instead of 32bit/64bit integer divide.

Can we fix "runt-time"? This is new in gcc-4.6

[Bug fortran/51529] [OOP] gfortran.dg/class_to_type_1.f03 is miscompiled: Uninitialized variable used

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #7 from Paul Thomas  2012-01-02 13:04:43 
UTC ---
Fixed on trunk.

Thanks for the reports

Paul

[Bug fortran/51334] [OOP] ICE with type-bound operator: tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_conv_component_ref, at fortran/trans-expr.c:556

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||pault at gcc dot gnu.org
 Resolution||FIXED

--- Comment #2 from Paul Thomas  2012-01-02 13:08:18 
UTC ---
Fixed on trunk by r182796.  (Forgot to put this in the ChangeLogs!).

Thanks for the report

Paul

[Bug tree-optimization/45397] [4.5/4.6/4.7 Regression] Issues with integer narrowing conversions

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #6 from Kai Tietz  2012-01-02 13:09:09 
UTC ---
Hmm, we could solve this via forward-propagation in gimple, too.
I have a patch which does this, but not sure if it is material for current
stage.  The missing patterns in forward-propagation are:
  - X ==/!= X -> true/false,
  - (type) X ==/!= (type) X -> true/false
  - X code Y ==/!= X code Z -> Y ==/!= Z (with code +, -, or ^).
  - (type) X ==/!= Y & CST -> X ==/!= (type-of-X) (Y & CST) if type-of-X has
smaller, or equal precision as type and is unsigned, and type-of-x and type are
of integral kind,
  and CST fits into type-of-X.
  - (type) (X op CST) -> (type) X op CST' with CST' = (type) X; and type has
smaller or equal precision to type-of-x and both types are of integral kind.
(for op = +,-,&,|,^)
  - (type) ((type2) X op Y) -> X op (type) Y, if type has smaller or equal
precision to type2 and type-of-x is compatible to type, all types are of
integral kind, and op is a +,-,&,|,or ^ expression.

[Bug fortran/51634] [OOP] ICE with polymorphic operators

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #1 from Paul Thomas  2012-01-02 13:28:13 
UTC ---
Fixed on trunk as long as explicit allocations are inserted, as below.

I will raise a separate PR for the lack of automatic allocate on assign for
class objects with derived type components.

Thanks for the report.

Paul

module field_module
  implicit none
  private
  public :: field
  type :: field
real, allocatable :: f(:)
  contains
procedure :: multiply_real  => multiply
procedure :: copy   => copy_field
generic   :: operator(*)=> multiply_real
generic   :: assignment(=)  => copy
  end type

contains
  subroutine copy_field (lhs, rhs)
class(field), intent(inout) :: lhs
class(field), intent(in) :: rhs
if (allocated (lhs%f)) deallocate (lhs%f)
allocate (lhs%f(size (rhs%f, 1)))
lhs%f = rhs%f
  end subroutine

  function multiply(lhs,rhs)
class(field) ,intent(in) :: lhs
real ,intent(in)  :: rhs
class(field) ,allocatable :: multiply
integer :: i
allocate(multiply, source = field([(0.0, i = 1, size (lhs%f, 1))]))
multiply%f = lhs%f * rhs
  end function
end module field_module

program main
  use field_module
  implicit none
  type(field) :: f, g
  real :: dt, half
  allocate (g%f(2), source = [1.0, 2.0])
  dt = 7
  half = 0.5
  f = g * dt * half
  print *, f%f
end program main

[Bug fortran/51733] New: [OOP] No allocate on assign for class objects with allocatable components.

[pault at gcc dot gnu.org]

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

 Bug #: 51733
   Summary: [OOP] No allocate on assign for class objects with
allocatable components.
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pa...@gcc.gnu.org


The testcase in PR51634 needs explicit allocations, as in the final comment.

PR51634 was closed, since the nesting of typebound operators is fixed.

Paul

[Bug middle-end/51728] [4.7 Regression]: libstdc++ 25_algorithms/count_if/1.cc, 25_algorithms/partition_point/1.cc, 25_algorithms/search/1.cc SEGV ICE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #1 from Jakub Jelinek  2012-01-02 
13:47:46 UTC ---
ICEs in exactly the same spot as PR51725 and the same fix cures it.

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

[Bug bootstrap/51725] [4.7 regression] segfault in stage 3 when compiling gcc/opts.c for sparc64-linux

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2012-01-02 
13:47:46 UTC ---
*** Bug 51728 has been marked as a duplicate of this bug. ***

[Bug bootstrap/51725] [4.7 regression] segfault in stage 3 when compiling gcc/opts.c for sparc64-linux

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-01-02 
13:52:14 UTC ---
Seems that canonical vs. non-canonical VALUEs are mixed up.
In cselib_invalidate_mem, we don't terminate the loop:
  addr = cselib_lookup (XEXP (x, 0), VOIDmode, 0, GET_MODE (x));
  mem_chain = &addr->addr_list;
  for (;;)
{
  if ((*mem_chain)->elt == v)
{
  unchain_one_elt_list (mem_chain);
  break;
}

  mem_chain = &(*mem_chain)->next;
}
because v is here a canonical_cselib_val of (*mem_chain)->elt.  We could
perhaps
compare here canonical_cselib_val ((*mem_chain)->elt) == v instead, or just
canonicalizing the mem_elt value early when inserting it into
addr_list/*_containing_mem fixes this too:
--- gcc/cselib.c.jj2012-01-01 19:54:46.0 +0100
+++ gcc/cselib.c2012-01-02 14:46:51.180804640 +0100
@@ -1264,6 +1264,8 @@ add_mem_for_addr (cselib_val *addr_elt,
 {
   struct elt_loc_list *l;

+  mem_elt = canonical_cselib_val (mem_elt);
+
   /* Avoid duplicates.  */
   for (l = mem_elt->locs; l; l = l->next)
 if (MEM_P (l->loc)

ALex?

[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-01-02
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #3 from Richard Guenther  2012-01-02 
14:01:19 UTC ---
(In reply to comment #2)
> On Mon, 2 Jan 2012, jakub at gcc dot gnu.org wrote:
> 
> >  char digs[] = "0123456789";
> >  int xlcbug = 1 / (&(digs + 5)[-2 + (_Bool) 1] == &digs[4] ? 1 : 
> > -1);
> > check.  Until http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172958
> > GCC has been accepting this though, and I suppose we don't want to fold 
> > array
> > refs that way when generating code.  Would it be possible to fold it that 
> > way
> > (try harder) just when we know we are not going to generate code based on it
> > (or when we know we'd error out otherwise)?  I know it sounds like an ugly
> 
> As I understand it, the point of that commit was that the conversion of 
> all array references to pointer arithmetic (losing all information about 
> signs of indices) was problematic.  But it should still be valid to fold a 
> comparison that way: if the addresses being compared have the same base 
> object and all offsets are constant integers, a final byte offset for each 
> address can be computed mod the size of the address space and it's OK to 
> fold based on comparing those offsets (if the actual, signed offsets 
> involved overflow anywhere, that would have been execution-time undefined 
> behavior).  That is, I think it would be better to fix this by improving 
> the folding of address comparisons, rather than by changing how array 
> references are expanded.

I think what changed is that we keep &digs[4] in the IL now, rather than
representing it as &digs + 4.  So it seems to be some missed folding.

Indeed we have (char *) &digs + 4 == &digs[4]

I'll look into this.

[Bug fortran/51733] [OOP] No allocate on assign for class objects with allocatable components.

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org
 Blocks||51634

--- Comment #1 from Tobias Burnus  2012-01-02 
14:07:17 UTC ---
See also the test case in PR 51634.

[Bug fortran/51733] [OOP] No allocate on assign for class objects with allocatable components.

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2012-01-02 
14:11:03 UTC ---
(Mixed up the test cases. The PR mentioned in comment 1 is the same as in
comment 0 - and a good test case. I mixed it up with PR 46262 comment 3, which
is a longer example which also requires allocation on assignment.)

[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2012-01-02 
14:15:39 UTC ---
Like

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 182784)
+++ gcc/fold-const.c(working copy)
@@ -8886,6 +8886,13 @@ fold_comparison (location_t loc, enum tr
  indirect_base0 = true;
}
  offset0 = TREE_OPERAND (arg0, 1);
+ if (host_integerp (offset0, 1)
+ && (TREE_INT_CST_LOW (offset0)
+ & ((unsigned HOST_WIDE_INT)-1 << (HOST_BITS_PER_WIDE_INT -
exact_log2 (BITS_PER_UNIT == 0)
+   {
+ bitpos0 = TREE_INT_CST_LOW (offset0) * BITS_PER_UNIT;
+ offset0 = NULL_TREE;
+   }
}

   base1 = arg1;
@@ -8909,6 +8916,13 @@ fold_comparison (location_t loc, enum tr
  indirect_base1 = true;
}
  offset1 = TREE_OPERAND (arg1, 1);
+ if (host_integerp (offset1, 1)
+ && (TREE_INT_CST_LOW (offset1)
+ & ((unsigned HOST_WIDE_INT)-1 << (HOST_BITS_PER_WIDE_INT -
exact_log2 (BITS_PER_UNIT == 0)
+   {
+ bitpos1 = TREE_INT_CST_LOW (offset1) * BITS_PER_UNIT;
+ offset1 = NULL_TREE;
+   }
}

   /* A local variable can never be pointed to by

to be beautified ...

[Bug bootstrap/51734] New: [4.7 Regression] Bootstrap fails in libada

[rguenth at gcc dot gnu.org]

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

 Bug #: 51734
   Summary: [4.7 Regression] Bootstrap fails in libada
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
Target: s390-*-linux


When linking libgnat.so we fail like

a-calfor.o: In function `ada__calendar__formatting__split':
/home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s390-suse-linux/gcc/ada/rts/a
-calfor.adb:399:(.text+0x3aa): relocation truncated to fit: R_390_GOT12 against 
symbol `ada__calendar__time_error' defined in .data.rel section in a-calend.o
a-calfor.o: In function `ada__calendar__formatting__split__4':
/home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s390-suse-linux/gcc/ada/rts/a
-calfor.adb:444:(.text+0x7ba): relocation truncated to fit: R_390_GOT12 against 
symbol `ada__calendar__time_error' defined in .data.rel section in a-calend.o
a-calfor.o: In function `ada__calendar__formatting__split__2':
/home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s390-suse-linux/gcc/ada/rts/a
-calfor.adb:492:(.text+0x898): relocation truncated to fit: R_390_GOT12 against 
symbol `ada__calendar__time_error' defined in .data.rel section in a-calend.o
a-calfor.o: In function `ada__calendar__formatting__split__3':
/home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s390-suse-linux/gcc/ada/rts/a
-calfor.adb:540:(.text+0x97c): relocation truncated to fit: R_390_GOT12 against 
symbol `ada__calendar__time_error' defined in .data.rel section in a-calend.o
a-calfor.o: In function `ada__calendar__formatting__time_of__2':
/home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s390-suse-linux/gcc/ada/rts/a
-calfor.adb:603:(.text+0xfcc): relocation truncated to fit: R_390_GOT12 against 
symbol `ada__calendar__days_in_month' defined in .rodata section in a-calend.o

[more similar errors in other files omitted]

make[5]: *** [gnatlib-shared-default] Error 1
make[5]: Leaving directory
`/home/abuild/rpmbuild/BUILD/gcc-4.7.0-20111220/obj-s
390-suse-linux/gcc/ada'


GCC was configured like

+ CFLAGS='-fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tables
-fasynchron
ous-unwind-tables -g -U_FORTIFY_SOURCE'
+ CXXFLAGS='-fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tables
-fasynchr
onous-unwind-tables -g -U_FORTIFY_SOURCE'
+ XCFLAGS='-fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tables
-fasynchro
nous-unwind-tables -g -U_FORTIFY_SOURCE'
+ TCFLAGS='-fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tables
-fasynchro
nous-unwind-tables -g -U_FORTIFY_SOURCE'
+ GCJFLAGS='-fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tables
-fasynchr
onous-unwind-tables -g -U_FORTIFY_SOURCE'
+ ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man
-
-libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj
-c++,java,ada --enable-checking=yes --with-gxx-include-dir=/usr/include/c++/4.7 
--enable-ssp --disable-libssp --disable-libitm --disable-plugin
--with-bugurl=ht
tp://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux' --disable-libgcj
--disabl
e-libmudflap --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit
--enab
le-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-run
time-libs --enable-linker-build-id --program-suffix=-4.7 --enable-linux-futex
--
without-system-libunwind --with-tune=z196 --with-arch=z10
--with-long-double-128
 --enable-decimal-float --build=s390-suse-linux

[Bug bootstrap/51734] [4.7 Regression] Bootstrap fails in libada

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug bootstrap/51725] [4.7 regression] segfault in stage 3 when compiling gcc/opts.c for sparc64-linux

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  2012-01-02 
14:58:30 UTC ---
While the http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51725#c5 change might not
be a complete solution, I think it is right and desirable, because
new_elt_loc_list doesn't add the MEM location to mem_elt's locs, but to its
canonical_cselib_val's locs (if different from mem_elt of course), and at that
point we'd be adding e.g. into addr_list as well as first_containing_mem chain
something that didn't get any MEM locs.

[Bug c++/51722] Options "-g3" or "-ggdb3" or "-g3 -gdwarf-2" and other "-g..level3" - internal compiler error

[ylalym at gmail dot com]

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

--- Comment #3 from Yuriy Lalym  2012-01-02 15:06:30 
UTC ---
Without PCH errors aren't present.
> all preprocessed headers to build the PCH

#include 

It is enough one header for error origin.

[Bug c++/51722] Options "-g3" or "-ggdb3" or "-g3 -gdwarf-2" and other "-g..level3" - internal compiler error

[ylalym at gmail dot com]

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

--- Comment #4 from Yuriy Lalym  2012-01-02 15:16:03 
UTC ---
main.cpp
---
#include 

int main(int argc, char *argv[])
{
  QCoreApplication a(argc, argv);

  return a.exec();
}

---
pch.h
---
#include 

g++-4.7 -m64 -pipe -g3 -gdwarf-4 -fvar-tracking-assignments -Wall -W
-D_REENTRANT -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/default -I.
-I/usr/include/QtCore -I/usr/include -I. -x c++-header -c pch.h -o
untitled5.gch/c++
g++-4.7 -c -include untitled5 -m64 -pipe -g3 -gdwarf-4
-fvar-tracking-assignments -Wall -W -D_REENTRANT -DQT_CORE_LIB -DQT_SHARED
-I/usr/share/qt4/mkspecs/default -I. -I/usr/include/QtCore -I/usr/include -I.
-o main.o main.cpp
*** glibc detected *** /usr/local/lib/gcc/x86_64-suse-linux/4.7.0/cc1plus:
double free or corruption (out): 0x0010c180 ***

[Bug c++/51669] [4.7 Regression] ICE verify-gimple with openmp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2012-01-02 
15:29:20 UTC ---
Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181332 aka PR51060.
Slightly more reduced testcase:

template  const T & min (const T &, const T &);

void
foo ()
{
#pragma omp parallel num_threads (min (4, 5))
  ;
}

which ICEs starting with r181332 with just -fopenmp.

struct A { A (); ~A (); };
int foo (const A &);

void
foo ()
{
#pragma omp parallel num_threads (foo (A ()))
  ;
}

apparently ICEd already in 4.2 though.  Guess the C++ FE needs to insert some
CLEANUP_POINT_EXPRs around the omp stmts.

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Guenther  2012-01-02 
15:52:45 UTC ---
(In reply to comment #20)
> 
> Fortunately it seems that this bug was the last issue that needed to be fixed.
> Firefox now builds fine with -lto and -g.

Can you also check the following variant?

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 182784)
+++ gcc/dwarf2out.c (working copy)
@@ -22501,15 +22501,8 @@ dwarf2out_finish (const char *filename)
  else if (TYPE_P (node->created_for))
context = TYPE_CONTEXT (node->created_for);

- gcc_assert (context
- && (TREE_CODE (context) == FUNCTION_DECL
- || TREE_CODE (context) == NAMESPACE_DECL));
-
- origin = lookup_decl_die (context);
- if (origin)
-   add_child_die (origin, die);
- else
-   add_child_die (comp_unit_die (), die);
+ origin = get_context_die (context);
+ add_child_die (origin, die);
}
}
 }

[Bug c++/20140] template function complains about "char-array initialized from wide string"

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  
2012-01-02 16:15:55 UTC ---
Author: paolo
Date: Mon Jan  2 16:15:49 2012
New Revision: 182805

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182805
Log:
/cp
2012-01-02  Paolo Carlini  

PR c++/20140
* typeck2.c (digest_init_r): Use copy_init when initializing
an array of chars.

/testsuite
2012-01-02  Paolo Carlini  

PR c++/20140
* g++.dg/template/init9.C: New.


Added:
trunk/gcc/testsuite/g++.dg/template/init9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/20140] template function complains about "char-array initialized from wide string"

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #5 from Paolo Carlini  2012-01-02 
16:16:52 UTC ---
Fixed for 4.7.0.

[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  2012-01-02 
16:23:42 UTC ---
Maybe I'm just tired (sorry in case) but I really don't see how this can
possibly work: *negative* index?!? Can you explain?

[Bug c++/51669] [4.7 Regression] ICE verify-gimple with openmp

[jakub at gcc dot gnu.org]

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

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-01-02 
16:29:29 UTC ---
Created attachment 26218
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26218
gcc47-pr51669.patch

Untested fix.

[Bug bootstrap/51735] New: [4.7 regression] stage 3 bootstrap failure compiling tree-ssa-pre.c with r182760

[krebbel at gcc dot gnu.org]

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

 Bug #: 51735
   Summary: [4.7 regression] stage 3 bootstrap failure compiling
tree-ssa-pre.c with r182760
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kreb...@gcc.gnu.org


Bootstrap started failing on s390x with r182760:

/home/andreas/git/gcc-head/gcc/tree-ssa-pre.c: In function ‘bool
insert_aux(basic_block)’:
/home/andreas/git/gcc-head/gcc/tree-ssa-pre.c:3791:1: internal compiler error:
Segmentation fault

This might be a duplicate of PR51725.

[Bug bootstrap/51735] [4.7 regression] stage 3 bootstrap failure compiling tree-ssa-pre.c with r182760

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Target||s390x-ibm-linux
   Priority|P3  |P2
   Host||s390x-ibm-linux
  Build||s390x-ibm-linux

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[markus at trippelsdorf dot de]

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

--- Comment #22 from Markus Trippelsdorf  
2012-01-02 16:52:49 UTC ---
(In reply to comment #21)
> (In reply to comment #20)
> > 
> > Fortunately it seems that this bug was the last issue that needed to be 
> > fixed.
> > Firefox now builds fine with -lto and -g.
> 
> Can you also check the following variant?

Yes. This one is also OK.

[Bug bootstrap/51735] [4.7 regression] stage 3 bootstrap failure compiling tree-ssa-pre.c with r182760

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2012-01-02 
16:54:47 UTC ---
Is the segfault in the
  for (;;)
{
  if ((*mem_chain)->elt == v)
{
  unchain_one_elt_list (mem_chain);
  break;
}

  mem_chain = &(*mem_chain)->next;
}
loop (or, does the #c5 patch from that PR fix it)?

[Bug c++/51462] [c++0x] ICE in cx_check_missing_mem_inits

[dodji at gcc dot gnu.org]

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

--- Comment #1 from Dodji Seketeli  2012-01-02 
17:00:21 UTC ---
Author: dodji
Date: Mon Jan  2 17:00:13 2012
New Revision: 182806

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182806
Log:
PR c++/51462 - ICE in cx_check_missing_mem_inits

gcc/cp/

PR c++/51462
* semantics.c (cx_check_missing_mem_inits): Don't assert in case
of error.

gcc/testsuite/

PR c++/51462
* g++.dg/cpp0x/constexpr-99.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-99.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/46328] [OOP] type-bound operator call with non-trivial polymorphic operand

[damian at rouson dot net]

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

--- Comment #9 from Damian Rouson  2012-01-02 
17:01:47 UTC ---
Thanks for the fix!  I'm very excited about the way 4.7 is shaping up.  It
appears this will be a very significant release for those interested in the
more advanced capabilities of OOP.

Damian

[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets

[m.hekkelman at cmbi dot ru.nl]

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

--- Comment #2 from M.L. Hekkelman  2012-01-02 
17:03:46 UTC ---
Beste paolo.carlini,

maandag 2 januari 2012, 17:23:42, schreef je:

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

> --- Comment #1 from Paolo Carlini  
> 2012-01-02 16:23:42 UTC ---
> Maybe I'm just tired (sorry in case) but I really don't see how this can
> possibly work: *negative* index?!? Can you explain?

It  is  a  technique  that  dates back to, who knows when. It is even 
common practice to have a zero sized array in the struct, like this:

struct page
{
   charkeys[1024];
   int offsets[0];
};

This  way you have a fixed size page you can write to disk containing 
non  terminated strings in keys and the direct offsets to the keys in 
the   offsets  arrays. Fill the page until the keys and offsets would 
collide with the addition of a new key.

E.g. the B-Tree implementation of the HFS file system in MacOS
Classic uses this.

I  have  used  code like this for many years now, and this code works 
with all compilers I'm aware off but not with gcc 4.5 and 4.6.

[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||INVALID

--- Comment #3 from Jakub Jelinek  2012-01-02 
17:10:17 UTC ---
Having a zero-sized array at the end of a struct is surely a commonly used
technique, close to standard flexible array members, but that is not what you
are doing.  Trying to reference data.e[-1] through data.e[-9] is of course not
valid C++ (nor C) when e is an array (it might be valid if e was a pointer and
pointed into the middle of some array).

[Bug c++/51462] [c++0x] ICE in cx_check_missing_mem_inits

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #2 from Dodji Seketeli  2012-01-02 
17:10:15 UTC ---
Should be fixed in 4.7 (trunk)

[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0

[dodji at gcc dot gnu.org]

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

--- Comment #16 from Dodji Seketeli  2012-01-02 
17:08:50 UTC ---
Author: dodji
Date: Mon Jan  2 17:08:45 2012
New Revision: 182807

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182807
Log:
PR debug/49951 - jumpy stepping at end of scope in C++

gcc/cp/

PR debug/49951
* decl.c (cxx_maybe_build_cleanup): Don't set location of the call
to the destructor.

gcc/testsuite/

PR debug/49951
* g++.dg/gcov/gcov-2.C: Adjust.

Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/decl.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/gcov/gcov-2.C

[Bug c++/51151] Invalid -Woverflow warning in C++ frontend

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  2012-01-02 
17:34:19 UTC ---
Andreas, can we close this?

[Bug c++/51151] Invalid -Woverflow warning in C++ frontend

[aaw at gcc dot gnu.org]

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

--- Comment #7 from Ollie Wild  2012-01-02 17:35:07 UTC 
---
I'm on vacation until Jan. 6.

For compiler related questions, please email c-compiler-t...@google.com.

If you need to contact a manager, please email lp-m...@google.com.

Thanks,
Ollie

[Bug c++/49976] Cross (Linux->AIX) GCC crashes with Segmentation fault

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2012-01-02 
17:44:09 UTC ---
Thanks Iain, if you could manage to test on the branch too - when possible - it
would be great. Or at some point we can as well close the issue as worksforme
in mainline, 4_6-branch is getting old.

[Bug c++/51322] [C++11] wrong mangling with argument packs

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  2012-01-02 
17:46:41 UTC ---
Jason, are you aware of this mangling issue? Looks like something we may want
to fix rather early.

[Bug c++/48051] sorry, unimplemented: mangling overload

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||zeratul976 at hotmail dot
   ||com

--- Comment #2 from Paolo Carlini  2012-01-02 
17:48:45 UTC ---
*** Bug 47335 has been marked as a duplicate of this bug. ***

[Bug c++/47335] [C++0x] "sorry, unimplemented: mangling overload"

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #5 from Paolo Carlini  2012-01-02 
17:48:45 UTC ---
Closing as duplicate of 48051. If I'm doing something wrong, please re-open,
and sorry ;)

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

[Bug c++/51666] NSDMI parse fails for template'd intializer

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2012-01-02 
17:53:23 UTC ---
Author: jason
Date: Mon Jan  2 17:53:16 2012
New Revision: 182809

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182809
Log:
DR 325
PR c++/51666
* parser.c (cp_parser_cache_defarg): Split out...
(cp_parser_parameter_declaration): ...from here.
(cp_parser_save_nsdmi): Use it.
(cp_parser_cache_group): Remove CPP_COMMA support.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-defer5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/51675] [C++11][4.7 Regression] Cannot create constexpr unions

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2012-01-02 
17:53:32 UTC ---
Author: jason
Date: Mon Jan  2 17:53:28 2012
New Revision: 182810

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182810
Log:
DR 1359
PR c++/51675
* method.c (walk_field_subobs): Don't check for uninitialized
fields in a union.
(synthesized_method_walk): Check here.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-union2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/49204] [C++0x] remaining issues in

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-01-02 
17:56:19 UTC ---
(In reply to comment #2)
> We should also make std::async check the system load when deciding whether to
> run asynchronously or deferred.  We should be able to reuse GNU Make's code 
> for
> deciding whether to run a new job or not, see load_too_high() in job.c

It turns out that calling get_nprocs() (via
std::thread::hardware_concurrency()) and getloadavg() from several threads
concurrently is a really bad idea, so I'm working on a simple implementation
that just compares the number of active async jobs to the number of processors.

[Bug c++/51322] [C++11] wrong mangling with argument packs

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-01-02
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug c++/51689] GCC apparently is inconsistent with warning about invalid brace-elision use

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  2012-01-02 
18:01:58 UTC ---
In this area we have also PR25137.

[Bug tree-optimization/51719] [4.7 Regression] ICE: verify_gimple failed: LHS in noreturn call with -fpartial-inlining -fprofile-use and exceptions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  2012-01-02 
18:18:13 UTC ---
Created attachment 26219
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26219
gcc47-pr51719.patch

Untested fix.

[Bug c++/51722] Options "-g3" or "-ggdb3" or "-g3 -gdwarf-2" and other "-g..level3" - internal compiler error

[ylalym at gmail dot com]

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

--- Comment #5 from Yuriy Lalym  2012-01-02 18:50:23 
UTC ---
gcc-4.7 -v
Using built-in specs.
COLLECT_GCC=gcc-4.7
COLLECT_LTO_WRAPPER=/usr/local/lib/gcc/x86_64-suse-linux/4.7.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr/local --libdir=/usr/local/lib64
--libexecdir=/usr/local/lib64 --enable-languages=c,c++
--enable-checking=release --with-gxx-include-dir=/usr/local/include/c++/4.7
--enable-ssp --disable-libssp --disable-plugin --with-pkgversion='SUSE Linux'
--disable-libgcj --with-slibdir=/lib64 --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.7
--enable-linux-futex --without-system-libunwind --with-tune=core2
--build=x86_64-suse-linux : (reconfigured) ../configure --prefix=/usr/local
--libdir=/usr/local/lib64 --libexecdir=/usr/local/lib64
--enable-languages=c,c++ --enable-checking=release
--with-gxx-include-dir=/usr/local/include/c++/4.7 --enable-ssp --disable-libssp
--disable-plugin --with-pkgversion='SUSE Linux' --disable-libgcj
--with-slibdir=/lib64 --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-version-specific-runtime-libs
--program-suffix=-4.7 --enable-linux-futex --without-system-libunwind
--with-tune=core2 --build=x86_64-suse-linux
Thread model: posix
gcc version 4.7.0 20120102 (experimental) (SUSE Linux)

[Bug fortran/49110] Deferred-length character result triggers (false positive) error for pure procedures

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #13 from Tobias Burnus  2012-01-02 
18:53:47 UTC ---
(In reply to comment #9)
> ! character, intent(in) :: s(5)   ! Compiles and runs
>  character, intent(in) :: s(:)! Compiles and segfaults
>  character(len=:), allocatable :: a
>  a = repeat('a', size(s))

For that example, try:
  a = ( repeat('a', size(s)) )
Cf. PR 51055.

[Bug c++/51722] Options "-g3" or "-ggdb3" or "-g3 -gdwarf-2" and other "-g..level3" - internal compiler error

[ylalym at gmail dot com]

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

--- Comment #6 from Yuriy Lalym  2012-01-02 18:57:40 
UTC ---
Created attachment 26220
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26220
For example in Comment 4

[Bug fortran/51736] New: generic fortran procedures with allocatable/pointer argument

[wangmianzhi1 at linuxmail dot org]

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

 Bug #: 51736
   Summary: generic fortran procedures with allocatable/pointer
argument
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wangmianz...@linuxmail.org


Created attachment 26221
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26221
a reduced example

According to the f2008 standard (12.4.3.4.5), dummy arguments having
allocatable attribute and pointer attribute should be distinguishable. Thus the
attached reduced code should be valid.
Will this feature be included in the later releases? Or could anyone provide
suggestions to work around? Thank you very much for your help and the great
compiler.