[Bug c++/51392] New: Wrong code with -Os when __attribute__((__const__)) function returns structure

[cyp561 at gmail dot com]

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

 Bug #: 51392
   Summary: Wrong code with -Os when __attribute__((__const__))
function returns structure
Classification: Unclassified
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cyp...@gmail.com
Target: x86_64-pc-linux-gnu
 Build: gcc version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5)


Fails with -Os, works with -O2:
4.5.3
Works always:
4.1.2  4.2.4  4.3.6  4.4.6
Fails always:
3.4.6

Only fails if the copy constructor is manually defined.
Works with __attribute__((__pure__)) instead of __attribute__((__const__)).
Still fails with printf and #include  removed.

Maybe it's somehow illegal with __attribute__((__const__)) to return a
structure with a manually defined copy constructor?



Testcase, reduced as much as I could:
/*

$ g++ -O2 -o error error.cpp
$ ./error
(-11 1 4)
$ g++ -Os -o error error.cpp
$ ./error
(1790250 1127603896 -1465067344)
Aborted
$ ./error
(1801140 -1464045896 574146144)
Aborted

*/

extern "C" void abort();

struct Vector3f
{
Vector3f() {}
Vector3f(int x, int y, int z) : x(x), y(y), z(z) {}
Vector3f(Vector3f const &v) : x(v.x), y(v.y), z(v.z) {}  // Essential

int x, y, z;
};

__attribute__((__const__))
Vector3f pie_SurfaceNormal3fv(Vector3f a, Vector3f b)
{
return Vector3f(a.y*b.z - a.z*b.y, a.z*b.x - a.x*b.z, a.x*b.y - a.y*b.x);
}

void normalsOnTile(Vector3f *normals)
{
Vector3f b(3, 5, 7);
Vector3f c(4, 8, 9);

*normals = pie_SurfaceNormal3fv(b, c);
}

#include 

int main()
{
Vector3f normals;
normalsOnTile(&normals);
printf("(%d %d %d)\n", normals.x, normals.y, normals.z);
if (normals.x != -11)
abort();
}

[Bug target/51381] Internal compiler error for arm target

[eric.valette at free dot fr]

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

--- Comment #8 from eric.valette at free dot fr 2011-12-03 10:32:39 UTC ---
(In reply to comment #6)
> I guess I've been hit by the Emit-conditions-in-push_multi problem. I applied
> the patch below after verifying ist upstream but have not yet rebuild gcc
> 
> http://old.nabble.com/ARM%3A-Emit-conditions-in-push_multi-td32379089.html#a32386142

Does not solve the problem.

[Bug c++/51347] [trans-mem] Segfault on templates with -O1 -fgnu-tm

[roman at tsisyk dot com]

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

--- Comment #3 from Roman Tsisyk  2011-12-03 10:37:02 
UTC ---
Works for me.
Thanks for the fix.

[Bug c/51391] Differences between setting Winline in command-line and through pragma GCC diagnostic

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-03
 CC||manu at gcc dot gnu.org
  Component|preprocessor|c
Summary|pragma GCC diag ignored |Differences between setting
   |then warning of Winline |Winline in command-line and
   |activates -fno-inline   |through pragma GCC
   ||diagnostic
 Ever Confirmed|0   |1

--- Comment #13 from Manuel López-Ibáñez  2011-12-03 
10:59:21 UTC ---
As Andrew explained, this is because the pragma uses handle_option, but
command-line options go through a different code path that sets those defaults. 

I am pretty sure there are many more cases of this. The short-term fix is to
duplicate that logic also in common_handle_option in a new case for
OPT_Winline. The long term fix is to encode the dependencies in .opt files and
let the awk scripts to generate the necessary code to handle all cases. But my
awk skills are not so good.

The fix is probably a one-line change, plus testcase and changelog (but of
course, one needs to build gcc and regression test the patches, so don't expect
anyone else to fix this anytime soon).

[Bug c/51391] Differences between setting Winline in command-line and through pragma GCC diagnostic

[manu at gcc dot gnu.org]

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

--- Comment #14 from Manuel López-Ibáñez  2011-12-03 
11:04:48 UTC ---
This patch fixes the issue:

Index: gcc/opts.c
===
--- gcc/opts.c  (revision 180166)
+++ gcc/opts.c  (working copy)
@@ -1423,10 +1423,20 @@ common_handle_option (struct gcc_options

   enable_warning_as_error (arg, value, lang_mask, handlers,
   opts, opts_set, loc, dc);
   break;

+case OPT_Winline:
+  if (opts->x_optimize == 0)
+   {
+ /* Inlining does not work if not optimizing,
+so force it not to be done.  */
+ opts->x_warn_inline = 0;
+ opts->x_flag_no_inline = 1;
+   }
+  break;
+
 case OPT_Wlarger_than_:
   opts->x_larger_than_size = value;
   opts->x_warn_larger_than = value != -1;
   break;


Feel free to take it and prepare it for submission:

http://gcc.gnu.org/contribute.html#patches

[Bug target/51393] New: Wrong parameter type for _mm256_insert_epi64 in avxintrin.h

[Jeremie.Detrey at loria dot fr]

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

 Bug #: 51393
   Summary: Wrong parameter type for _mm256_insert_epi64 in
avxintrin.h
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jeremie.det...@loria.fr


Created attachment 25978
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25978
Minimal example.

In avxintrin.h:762, the second parameter (__D) of the function
_mm256_insert_epi64 is declared as int where it should be long long.

This results in an uncorrect behavior (truncation to 32 bits then sign
extension) when the attached minimal program is compiled with options -O3
-mavx. A look at the corresponding assembler code confirms this:

  [...]
  vpxor   %xmm0, %xmm0, %xmm0
  movslq  %ebx, %rax
  vpinsrq $0, %rax, %xmm0, %xmm0
  [...]

[Bug target/51393] Wrong parameter type for _mm256_insert_epi64 in avxintrin.h

[Jeremie.Detrey at loria dot fr]

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

--- Comment #1 from Jérémie Detrey  2011-12-03 
11:21:17 UTC ---
Created attachment 25979
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25979
Patch to fix the reported typo.

This simple patch should fix the typo in avxintrin.h.

[Bug fortran/50684] [4.6/4.7 Regression] Incorrect error for move_alloc on element inside intent(in) pointer

[burnus at gcc dot gnu.org]

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

--- Comment #13 from Tobias Burnus  2011-12-03 
11:30:23 UTC ---
Author: burnus
Date: Sat Dec  3 11:30:18 2011
New Revision: 181967

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181967
Log:
2011-12-03  Tobias Burnus  

PR fortran/50684
* check.c (variable_check): Fix intent(in) check.

2011-12-03  Tobias Burnus  

PR fortran/50684
* gfortran.dg/move_alloc_8.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/move_alloc_8.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/48699] [4.6/4.7 Regression] [OOP] MOVE_ALLOC inside SELECT TYPE

[burnus at gcc dot gnu.org]

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

--- Comment #22 from Tobias Burnus  2011-12-03 
11:33:42 UTC ---
Actually, my comment 21 was a bit premature: FROM type TO class is valid, only
FROM class TO type is invalid. Corrected at:
   http://gcc.gnu.org/ml/fortran/2011-12/msg6.html

However, the test case of comment 8 (select_type_23.f03) is invalid - but for
other reasons. Cf. PR 48887.

[Bug fortran/48699] [4.6/4.7 Regression] [OOP] MOVE_ALLOC inside SELECT TYPE

[sfilippone at uniroma2 dot it]

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

--- Comment #23 from Salvatore Filippone  
2011-12-03 12:00:43 UTC ---
Yes, TYPE FROM and polymorphic TO is exactly the typical usage I have (indeed,
it also was the original test case)
Thanks

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  2011-12-03 
12:06:08 UTC ---
patch implementing __is_final submitted for approval:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00231.html

[Bug c++/51369] [c++0x] [4.7 Regression] ICE using constexpr in template

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-03
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1

[Bug fortran/50684] [4.6/4.7 Regression] Incorrect error for move_alloc on element inside intent(in) pointer

[burnus at gcc dot gnu.org]

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

--- Comment #14 from Tobias Burnus  2011-12-03 
12:57:41 UTC ---
Author: burnus
Date: Sat Dec  3 12:57:38 2011
New Revision: 181969

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181969
Log:
2011-12-03  Tobias Burnus  

PR fortran/50684
* check.c (variable_check): Fix intent(in) check.

2011-12-03  Tobias Burnus  

PR fortran/50684
* gfortran.dg/move_alloc_8.f90: New.


Added:
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/move_alloc_8.f90
Modified:
branches/gcc-4_6-branch/gcc/fortran/ChangeLog
branches/gcc-4_6-branch/gcc/fortran/check.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug fortran/50684] [4.6/4.7 Regression] Incorrect error for move_alloc on element inside intent(in) pointer

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #15 from Tobias Burnus  2011-12-03 
12:58:22 UTC ---
FIXED on the trunk (4.7) and on 4.6 branch.

Thanks for the report!

[Bug fortran/51394] New: Rejects legal code involving an allocatable string

[i.thompson at lboro dot ac.uk]

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

 Bug #: 51394
   Summary: Rejects legal code involving an allocatable string
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i.thomp...@lboro.ac.uk


Created attachment 25980
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25980
Terminal i/o

!This code generates an internal compiler error.

module tokens

implicit none

type :: token
  character (:) , allocatable :: string
end type

contains

  subroutine write_token( tok )

implicit none

type (token) , intent (in) :: tok

  end subroutine

end module

[Bug fortran/25708] Module loading is not good at all

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #20 from Jerry DeLisle  2011-12-03 
13:28:30 UTC ---
I don't have time now and others are making good progress.  Unassigning myself.

[Bug rtl-optimization/50904] [4.7 regression] pessimization when -fno-protect-parens is enabled by -Ofast

[dominiq at lps dot ens.fr]

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

--- Comment #36 from Dominique d'Humieres  
2011-12-03 14:54:40 UTC ---
> Kind of, though, -ffast-math by itself already is on the verge of violating 
> the
> standard. 

I disagree with this statement at least for codes that does not use IEEE
intrinsic modules (not yet implemented in gfortran).  Indeed the interaction
between -ffast-math and IEEE intrinsic modules will have to be discussed and
documented when these modules will be implemented (see pr50724 for the kind of
problems).

> I think -fno-protect-parens could be enabled by -ffast-math as that
> means that one does not really care about the exact value.

PLEEEASE DON'T. The situation is bad enough with -Ofast to not make it worse:
with -fno-protect-parens gfortran no longer complies with the Fortran standard
(7.1.5.2.4 quoted in comment #23) and IMO SHOULD NOT be part of any compound
option.

Note that if I am using -ffast-math, it is not because I do "not really care
about the exact value". It is mostly because I KNOW that exceptions will be the
signature of either a bug in my code and/or a bad choice of the parameters
leading to numerical instabilities. In top of that, I think that the concept of
"exact value" for floating-point numbers is ill-posed and as a consequence I do
accept that the least significant digits may depend on the way I write the code
or it is optimized (small fluctuations for well-posed methods, large ones
otherwise).

> If we want to add add extra protection for
>  tem = x + 2.d0**52
>  x = tem - 2.d0**52
> we probably need to add yet another flag as there are surely users, which want
> to have protected parentheses but allow for optimizations in the 'tmp' case.

If I need an extra protection, I'll put parentheses and I don't need yet
another flag. However, since the logic of the optimization is surprising the
first time you hit it, it could (should) be documented.

[Bug middle-end/50628] [4.7 Regression] gfortran.fortran-torture/execute/entry_4.f90 fails

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  
2011-12-03 15:18:06 UTC ---
On x86_64-apple-darwin10, the patch in comment #12 fixes the pr without new
regression. Thanks.

[Bug libstdc++/50871] [C++0x] G++ fails to reject explicitly-defaulted function definition with different exception spec in system headers

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  2011-12-03 
15:34:53 UTC ---
It occurs to me we could use a diagnostic pragma to disable warnings about
variadic templates in our headers, instead of marking them as system headers.
That wouldn't work currently because the variadic templates warning is [enabled
by default] so there's no option to disable it.

[Bug lto/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto

[howarth at nitro dot med.uc.edu]

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

--- Comment #7 from Jack Howarth  2011-12-03 
15:49:49 UTC ---
(In reply to comment #6)
> could you please check the status of this with XCode 4. / Darwin11.
> 
> AFAICT, this (duplicate __image_info sections) appears to be resolved.. 
> 
> .. although the Undefined symbols for architecture 
> .objc_class_name_myRootObject might well still be present.

Current gcc trunk now just shows warnings of the form...

ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in
/var/tmp//ccsj97TC.lto.o

in objc.log for Xcode 4.2.1 on Lion. The undefined
.objc_class_name_myRootObject symbols
are still present.

[Bug target/50193] ARM: ICE on a | (b << negative-constant)

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||konstantinos.margaritis at
   ||linaro dot org

--- Comment #4 from Matthias Klose  2011-12-03 
15:58:45 UTC ---
*** Bug 50947 has been marked as a duplicate of this bug. ***

[Bug target/50947] ICE on armhf with llvm-2.x

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

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

--- Comment #3 from Matthias Klose  2011-12-03 
15:58:45 UTC ---
duplicate of PR50193

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

[Bug c++/51392] Wrong code with -Os when __attribute__((__const__)) function returns structure

[cybersphinx.gcc at dispostable dot com]

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

cybersphinx  changed:

   What|Removed |Added

 CC||cybersphinx.gcc at
   ||dispostable dot com

--- Comment #1 from cybersphinx  
2011-12-03 16:27:09 UTC ---
With Debian's gcc 4.6.2-5 the testcase fails with -Os, -O1, -O2, ok with -O0,
-O3, -Ofast. 4.5.3-9 fails with -Os, -O1, ok with -O0, -O2, -O3.

[Bug debug/50317] [4.7 Regression] missing DW_OP_GNU_implicit_pointer

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  2011-12-03 
16:40:05 UTC ---
Author: jakub
Date: Sat Dec  3 16:39:56 2011
New Revision: 181971

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181971
Log:
PR debug/50317
* tree-ssa.c (target_for_debug_bind): Also allow is_gimple_reg_type
vars that aren't referenced.
(tree-ssa-live.c (remove_unused_locals): Don't clear TREE_ADDRESSABLE
of unreferenced local vars.
* cfgexpand.c (expand_debug_expr): For DEBUG_IMPLICIT_PTR allow also
TREE_ADDRESSABLE vars that satisfy target_for_debug_bind.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/tree-ssa-live.c
trunk/gcc/tree-ssa.c

[Bug target/51393] Wrong parameter type for _mm256_insert_epi64 in avxintrin.h

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-03
 CC||jakub at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Jakub Jelinek  2011-12-03 
16:56:23 UTC ---
The patch looks good, but patches should be sent to gcc-patches at gcc.gnu.org
mailing list, with a proper ChangeLog entry.  This one is short enough that it
doesn't need copyright assignment, can you please send it there?  Thanks.

[Bug fortran/51394] Rejects legal code involving an allocatable string

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||burnus at gcc dot gnu.org
 Depends on||45170

--- Comment #1 from Tobias Burnus  2011-12-03 
17:06:53 UTC ---
I think this bug is effectively a duplicate of PR 51075.

Deferred-length characters are unfortunately not yet supported as components in
derived types.

[Bug c++/51239] ICE with variadic template alias

[dodji at gcc dot gnu.org]

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

--- Comment #2 from Dodji Seketeli  2011-12-03 
17:23:43 UTC ---
A candidate patch for this has been submitted to
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00163.html

[Bug target/51393] Wrong parameter type for _mm256_insert_epi64 in avxintrin.h

[Jeremie.Detrey at loria dot fr]

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

--- Comment #3 from Jérémie Detrey  2011-12-03 
17:25:10 UTC ---
Done, thanks!

[Bug c++/51180] [C++0x] inner class alias-definition variadic template error

[dodji at gcc dot gnu.org]

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

--- Comment #5 from Dodji Seketeli  2011-12-03 
17:25:02 UTC ---
A candidate patch for this has been submitted to
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00163.html

[Bug testsuite/51059] FAIL: gcc.misc-tests/gcov-14.c (test for excess errors) on *-apple-darwin*

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth at nitro dot
   ||med.uc.edu

--- Comment #12 from Jack Howarth  2011-12-03 
18:20:08 UTC ---
This still fails on darwin11 under Xcode 4.2.1 as

Executing on host: /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20111202/gcc/testsuite/gcc.misc-tests/gcov-14.c
   -O2 -fprofile-arcs -ftest-coverage -flat_namespace -undefined suppress  -lm 
 -m32 -o ./gcov-14.exe(timeout = 300)
PASS: gcc.misc-tests/gcov-14.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc::/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc
dyld: Symbol not found: _Foo
  Referenced from:
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/testsuite/gcc/./gcov-14.exe
  Expected in: flat namespace
 in
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/testsuite/gcc/./gcov-14.exe
FAIL: gcc.misc-tests/gcov-14.c execution test
Executing on host: /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/gcov  -a
gcov-14.c(timeout = 300)
gcov-14.gcda:cannot open data file, assuming not executed^M
File
'/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20111202/gcc/testsuite/gcc.misc-tests/gcov-14.c'^M
No executable lines^M
^M
FAIL: gcc.misc-tests/gcov-14.c gcov failed: gcov-14.c.gcov does not exist

[Bug c++/51395] New: [4.5/4.6 Regression] ICE in dependent_type_p (endless (?) recursion)

[doko at gcc dot gnu.org]

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

 Bug #: 51395
   Summary: [4.5/4.6 Regression] ICE in dependent_type_p (endless
(?) recursion)
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gcc.gnu.org


Created attachment 25981
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25981
test case

the ICE is seen with 4.5 and 4.6 branches, not with 4.4 and trunk.

$ g++-4.4 -std=c++0x t.cpp
t.cpp: In function 'F2 operator|(F1, F2)':
t.cpp:2: error: expected primary-expression before '[' token
t.cpp:2: error: expected primary-expression before '=' token
t.cpp:2: error: expected primary-expression before ']' token
t.cpp:2: error: expected primary-expression before 'unsigned'
t.cpp:2: error: expected ';' before '{' token
t.cpp:2: error: 'x' was not declared in this scope
t.cpp: At global scope:
t.cpp:4: error: expected primary-expression before '[' token
t.cpp:4: error: expected primary-expression before ']' token
t.cpp:4: error: expected primary-expression before 'float'
t.cpp:4: error: unable to deduce 'auto' from ''
t.cpp:5: error: expected ',' or ';' before '{' token


$ g++-4.5 -std=c++0x t.cpp 
g++-4.5: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.


$ g++-4.6 -std=c++0x t.cpp 
g++-4.6: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,



$ /usr/lib/gcc-snapshot/bin/g++ -std=c++0x t.cpp 
t.cpp: In instantiation of 'operator|(F1, F2) [with F1 =
::; F2 =
]::':
t.cpp:2:75:   required from 'struct operator|(F1, F2) [with F1 =
::; F2 =
]::'
t.cpp:2:83:   required from 'F2 operator|(F1, F2) [with F1 =
::; F2 = ]'
t.cpp:16:26:   required from here
t.cpp:2:83: error: no match for call to '(const) (float)'
t.cpp:9:15: note: candidates are:
t.cpp:2:83: note: :: (*)() 
t.cpp:2:83: note:   candidate expects 1 argument, 2 provided
t.cpp:9:17: note: 
t.cpp:9:17: note:   candidate expects 0 arguments, 1 provided
t.cpp:2:83: error: return-statement with a value, in function returning 'void'
[-fpermissive]
t.cpp: In instantiation of 'F2 operator|(F1, F2) [with F1 =
::; F2 = ]':
t.cpp:16:26:   required from here
t.cpp:2:83: error: could not convert '{f2, f1}' from 'operator|(F1, F2) [with
F1 = ::; F2 =
]::' to ''

[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 #8 from Dodji Seketeli  2011-12-03 
18:23:38 UTC ---
A candidate analysis and patch has been posted to
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00250.html for comments.

[Bug fortran/48887] [4.7 Regression][OOP] SELECT TYPE: Associate name shall not be a pointer/allocatable

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2011-12-03 
18:30:40 UTC ---
Author: burnus
Date: Sat Dec  3 18:30:36 2011
New Revision: 181975

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181975
Log:
2011-12-03  Tobias Burnus  

PR fortran/48887
* match.c (select_type_set_tmp): Don't set allocatable/pointer
attribute.
* class.c (gfc_build_class_symbol): Handle
attr.select_type_temporary.

2011-12-03  Tobias Burnus  

PR fortran/48887
* gfortran.dg/select_type_24.f90: New.
* gfortran.dg/select_type_23.f03: Add dg-error.
* gfortran.dg/class_45a.f03: Add missing TARGET attribute.


Added:
trunk/gcc/testsuite/gfortran.dg/select_type_24.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/class_45a.f03
trunk/gcc/testsuite/gfortran.dg/select_type_23.f03

[Bug lto/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto

[iains at gcc dot gnu.org]

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

--- Comment #8 from Iain Sandoe  2011-12-03 18:30:44 
UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > could you please check the status of this with XCode 4. / Darwin11.

> Current gcc trunk now just shows warnings of the form...
> 
> ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in
> /var/tmp//ccsj97TC.lto.o

hmmm.. OK there's some difference between D10 and D11 then..

please could you produce and attach the asm (-fverbose-asm) for the test-case
using current trunk. 

and note your config + any patches applied.

thanks.

> in objc.log for Xcode 4.2.1 on Lion. The undefined
> .objc_class_name_myRootObject symbols
> are still present.

This is expected - it is:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48109
(and needs another pass at the fix).

[Bug fortran/48887] [4.7 Regression][OOP] SELECT TYPE: Associate name shall not be a pointer/allocatable

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #6 from Tobias Burnus  2011-12-03 
18:34:13 UTC ---
FIXED on the 4.7 trunk.

[Bug tree-optimization/51315] gcc 4.6.2 miscompilation with -ftree-sra (included in -O2) on Debian/sparc

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #5 from Mikael Pettersson  2011-12-03 
18:35:26 UTC ---
(In reply to comment #3)
> I suspect it's a dupe of PR50569 or PR50444.

It's not, this one is caused by r161655 (Richard G's big MEM-REF change):
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html

Comparing the code from r161654 and r161655, targeting sparc-linux, we see:

--- pr51315.s-r161654   2011-12-03 18:58:02.0 +0100
+++ pr51315.s-r161655   2011-12-03 19:12:41.0 +0100
@@ -22,7 +22,7 @@
.type   pack_unpack, #function
.proc   04
 pack_unpack:
-   save%sp, -104, %sp
+   save%sp, -96, %sp
callstrlen, 0
 mov%i1, %o0
add %i1, %o0, %i5
@@ -35,7 +35,7 @@
 .LL12:
cmp %g1, 115
be,a.LL11
-ldub   [%i0], %g2
+lduh   [%i0], %o0
cmp %i5, %i1
 .LL14:
bleu,a  .LL13
@@ -48,16 +48,8 @@
cmp %g1, 108
bne .LL12
 add%i1, 1, %i1
-   ldub[%i0], %g4
-   ldub[%i0+1], %g3
-   ldub[%i0+2], %g2
-   ldub[%i0+3], %g1
-   stb %g4, [%fp-8]
-   stb %g3, [%fp-7]
-   stb %g2, [%fp-6]
-   stb %g1, [%fp-5]
calldo_something, 0
-ld [%fp-8], %o0
+ld [%i0], %o0
cmp %i5, %i1
bgu .LL8
 add%i0, 4, %i0
@@ -67,12 +59,10 @@
 restore
 .LL11:
 .LL6:
-   ldub[%i0+1], %g1
-   stb %g2, [%fp-2]
-   stb %g1, [%fp-1]
add %i0, 2, %i0
+   sll %o0, 16, %o0
calldo_something, 0
-ldsh   [%fp-2], %o0
+sra%o0, 16, %o0
b   .LL14
 cmp%i5, %i1
.size   pack_unpack, .-pack_unpack

> (And if you hate alignment bugs like me you might also want to know about the
> 4.5-only PR46483.)

Minor correction: PR46483 also affects gcc-4.4.

[Bug testsuite/51059] FAIL: gcc.misc-tests/gcov-14.c (test for excess errors) on *-apple-darwin*

[iains at gcc dot gnu.org]

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

--- Comment #13 from Iain Sandoe  2011-12-03 18:36:07 
UTC ---
(In reply to comment #12)
> This still fails on darwin11 under Xcode 4.2.1 as
> 
> Executing on host: /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/xgcc
> -B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/
> /sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20111202/gcc/testsuite/gcc.misc-tests/gcov-14.c
>-O2 -fprofile-arcs -ftest-coverage -flat_namespace -undefined suppress  
> -lm 
>  -m32 -o ./gcov-14.exe(timeout = 300)
> PASS: gcc.misc-tests/gcov-14.c (test for excess errors)
> Setting LD_LIBRARY_PATH to
> :/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc::/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc
> dyld: Symbol not found: _Foo
>   Referenced from:
> /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/testsuite/gcc/./gcov-14.exe
>   Expected in: flat namespace
>  in
> /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/testsuite/gcc/./gcov-14.exe
> FAIL: gcc.misc-tests/gcov-14.c execution test
> Executing on host: /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/gcov  -a
> gcov-14.c(timeout = 300)
> gcov-14.gcda:cannot open data file, assuming not executed^M
> File
> '/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20111202/gcc/testsuite/gcc.misc-tests/gcov-14.c'^M
> No executable lines^M
> ^M
> FAIL: gcc.misc-tests/gcov-14.c gcov failed: gcov-14.c.gcov does not exist

I guess it's not supporting "-undefined suppress" ... _Foo is not meant to be
found at link time.
 (that is the intention of adding -flat_namespace -undefined suppress).

I suppose you could try adding -Wl,-U,_Foo instead ...

[Bug testsuite/51059] FAIL: gcc.misc-tests/gcov-14.c (test for excess errors) on *-apple-darwin*

[howarth at nitro dot med.uc.edu]

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

--- Comment #14 from Jack Howarth  2011-12-03 
19:01:40 UTC ---
Adding -Wl,-U,_Foo doesn't help on darwin11. Perhaps the darwin linker
developer might have some insights?

[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

[manu at gcc dot gnu.org]

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

--- Comment #9 from Manuel López-Ibáñez  2011-12-03 
19:03:54 UTC ---
(In reply to comment #8)
> A candidate analysis and patch has been posted to
> http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00250.html for comments.

What I don't understand is how, according to your analysis, this worked before
revision 149722 and how that patch could possibly change the behavior.

[Bug testsuite/51059] FAIL: gcc.misc-tests/gcov-14.c (test for excess errors) on *-apple-darwin*

[iains at gcc dot gnu.org]

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

--- Comment #15 from Iain Sandoe  2011-12-03 19:05:30 
UTC ---
(In reply to comment #14)
> Adding -Wl,-U,_Foo doesn't help on darwin11. Perhaps the darwin linker
> developer might have some insights?

regrettably, I think this is associated with the already-reported weak symbol
breakage.
I think we'll either have to live with the fail or XFAIL it until we get some
feedback on that.

[Bug c/51391] Differences between setting Winline in command-line and through pragma GCC diagnostic

[pnewell at cs dot cmu.edu]

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

--- Comment #15 from pnewell at cs dot cmu.edu 2011-12-03 19:10:39 UTC ---
Manu:

Yes, Andrew did a great job of letting me know what the issue was and gave me
the necessary information to have a work-around within 1/2 hour. Fantastic
turnaround in my book, many thanks to him!

I appreciate the confirm that it is a bug. I can also believe that if they go
through different code paths there is a good chance there are more of these
"opps" situations. I'd rather not use #pragmas, but with third party code it
becomes necessary to get rid of all the warnings one can't do anything about
(except tell the third party ... and that hasn't produced any results yet).

I am not surprised that the fix is quick but the build/testing makes it a bit
of a question whether someone is going to want to do all that legwork. It isn't
exactly a show-stopper (smile) and, since I am stuck on F14 until spring of
2012, I wouldn't be able to make use of the patch until I upgrade. But the fix
is there (thanks) and I'll just see what happens.

Mostly, I wanted to tell both Andrew and you that I very impressed with how
this bug was handled. A very prompt response, solid info on what the issue is,
and an honest assessment of its chances for fixing. This is the first bug I
have submitted to gcc bugzilla and I certainly feel that it was worth the
effort for me to package up an example to send to you.

Thanks,
Paul

[Bug c++/51373] [C++0x] ICE for static pointer to member initialized in-class

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #1 from Daniel Krügler  
2011-12-03 19:17:09 UTC ---
(In reply to comment #0)
> gcc version 4.7.0 2012 (experimental) (GCC) 

Also in 4.7.0 2026 (experimental)

> Two seemingly relate ICEs when dealing with pointer to member:
> 
> struct foo {
> int a = 42;
> static int foo::*b = &foo::a;
> };

b needs to have a constexpr specifier here, but it ICEs also with that one
added. Even with the constexpr specifier that declaration should be ill-formed,
because the class definition must be complete for an in-class static data
member initializer. Also, the initializer for a is not needed to reproduce the
error.

> struct foo {
> int a = 42;
> static int foo::*b;
> auto& c = b;
> };
> internal compiler error: in unify_one_argument, at cp/pt.c:15008

The declaration of c cannot use auto (only static data members may do) and the
ICE does no longer occur after the fix. In addition, the declaration of a is
not needed to reproduce the problem.

[Bug tree-optimization/35629] [4.4/4.5/4.6/4.7 Regression] gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times profile fails

[pinskia at gcc dot gnu.org]

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

--- Comment #12 from Andrew Pinski  2011-12-03 
19:18:31 UTC ---
(In reply to comment #11)

Oh it fixes PR 50971 also which was my aim.

[Bug tree-optimization/35629] [4.4/4.5/4.6/4.7 Regression] gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times profile fails

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski  2011-12-03 
19:17:13 UTC ---
I have a couple of improvements for find_subloop_latch_edge_by_ivs which fixes
this testcase (though the dump output is slightly different but the number of
loops is correct and the subloops are done correctly).

[Bug c++/51373] [C++0x] ICE for static pointer to member initialized in-class

[daniel.kruegler at googlemail dot com]

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

--- Comment #2 from Daniel Krügler  
2011-12-03 19:33:55 UTC ---
(In reply to comment #1)

> Even with the constexpr specifier that declaration should be ill-formed,
> because the class definition must be complete for an in-class static data
> member initializer. 

I just recognize that the class definition must not be complete to make the
pointer of member formation a constant expression. So, the code of the first
example should be well-formed after addition of constexpr to the static data
member.

[Bug testsuite/51057] FAIL: gfortran.dg/quad_2.f90 -O0 execution test on powerpc*-*-*

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  2011-12-03 20:36:43 
UTC ---
whilst I appreciate that there are wider issues with IBM long double (and its
availability) 
[I read the two PRs you cross-referenced].

In this case, it appears to be a different situation.
- what Dominique is indicating is that the tests are likely failing on an IBM
long double target because the number of mantissa bits is 106 rather than the
112 for float128.

So I wonder what opportunities exist for adjusting the test expectation
depending on the target.
(since this, presumably, will affect all IBM long double targets).

from 'c' we have some #defines that would allow us to detect the IBM case on
ppc  (although, presumably because it's provided by a library, we don't get the
same for x86).  It would even be a reasonable first approximation to assume IBM
long double on ppc and float128 on x86.

---

This would allow some kind of target capability test in tcl - which could
thence regulate some conditional compilation of the Fortran, I guess?  I assume
the Fortran can't see the 'c' defines (ISTR a PR about that somewhen).

[Bug tree-optimization/51396] New: [4.7 Regression] ICE: verify_flow_info failed: BB 4 can not throw but has an EH edge with -O2 -fnon-call-exceptions -mfma4

[zsojka at seznam dot cz]

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

 Bug #: 51396
   Summary: [4.7 Regression] ICE: verify_flow_info failed: BB 4
can not throw but has an EH edge with -O2
-fnon-call-exceptions -mfma4
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 25982
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25982
reduced testcase

Compiler output:
$ gcc -O2 -fnon-call-exceptions -mfma4 testcase.C 
testcase.C: In function 'void pow2(int, complex)':
testcase.C:17:1: error: BB 4 can not throw but has an EH edge
testcase.C:17:1: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Originally, it crashed with:
$ head -n 1 tmp.ii 
# 1
"/mnt/svn/gcc-trunk/libstdc++-v3/testsuite/tr1/8_c_compatibility/complex/overloads_int.cc"
$ gcc -O2 -fnon-call-exceptions -mfma4 tmp.ii 
/mnt/svn/gcc-trunk/libstdc++-v3/testsuite/tr1/8_c_compatibility/complex/overloads_int.cc:
In function 'void test01()':
/mnt/svn/gcc-trunk/libstdc++-v3/testsuite/tr1/8_c_compatibility/complex/overloads_int.cc:26:6:
internal compiler error: in expand_builtin_eh_common, at except.c:1953
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Tested revisions:
r181968 - crash
4.6 r180325 - OK

[Bug target/51381] Internal compiler error for arm target

[mikpe at it dot uu.se]

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

--- Comment #9 from Mikael Pettersson  2011-12-03 
20:45:02 UTC ---
Created attachment 25983
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25983
reduced test case in C

The big test case easily reduced to the following snippet:

void round_int(void)
{
__asm__ __volatile__("vmov.F64 d1,%0" : : "Dv"(0.5f) : "d1");
}

Compiled with -march=armv7-a -mtune=cortex-a9 -mfloat-abi=hard -mfpu=vfpv3-d16
it ICEs trunk @ r181973 as follows:

pr51381.c: In function 'round_int':
pr51381.c:6:1: internal compiler error: in fp_immediate_constant, at
config/arm/arm.c:13418

Current gcc 4.6 and 4.5 also ICE in fp_immediate_constant().  gcc-4.4 rejects
the command line options (sorry, unimplemented: -mfloat-abi=hard and VFP).

[Bug testsuite/51057] FAIL: gfortran.dg/quad_2.f90 -O0 execution test on powerpc*-*-*

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  
2011-12-03 20:46:36 UTC ---
On Sat, Dec 03, 2011 at 08:36:43PM +, iains at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51057
> 
> --- Comment #2 from Iain Sandoe  2011-12-03 
> 20:36:43 UTC ---
> whilst I appreciate that there are wider issues with IBM long double (and its
> availability) 
> [I read the two PRs you cross-referenced].
> 
> In this case, it appears to be a different situation.
> - what Dominique is indicating is that the tests are likely failing on an IBM
> long double target because the number of mantissa bits is 106 rather than the
> 112 for float128.

113 bits for IEEE binary 128 format.


> So I wonder what opportunities exist for adjusting the test expectation
> depending on the target.
> (since this, presumably, will affect all IBM long double targets).
> 
> from 'c' we have some #defines that would allow us to detect the IBM case on
> ppc  (although, presumably because it's provided by a library, we don't get 
> the
> same for x86).  It would even be a reasonable first approximation to assume 
> IBM
> long double on ppc and float128 on x86.

This test came into being when libquadmath came into the tree.
The correct, and only, solution for targets whose long double
representation is double-double math is to XFAIL the test on those
targets.

[Bug lto/51325] [4.7 Regression] ICE with -flto and union in template

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #2 from Zdenek Sojka  2011-12-03 20:51:37 
UTC ---
Probably the same as PR51262

[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 #10 from dodji at seketeli dot org  
2011-12-03 20:55:15 UTC ---
> What I don't understand is how, according to your analysis, this
> worked before revision 149722 and how that patch could possibly
> change the behavior.

OK, you caught me.  I admit I haven't really looked at that patch
before starting debugging this issue.  So now I might have an
additional theory.  :-)

I think that before the commit r149722, the call expression to the
destructor simply had no location.  And that patch added a location to
it.  So we didn't have the jumpy behaviour because we were ignoring
the presence of the call to the destructor, from a stepping point of
view.

Here is why I am thinking that.

The call to the destructor of "m" ends up being generated by
build_cxx_call, in cp/call.c.  At the time of the patch, that function
started with:

tree
build_cxx_call (tree fn, int nargs, tree *argarray)
{
  tree fndecl;
  fn = build_call_a (fn, nargs, argarray);
  ...
}

So it was calling build_call_a, that the patch modified as:

--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -362,7 +362,8 @@ build_call_a (tree function, int n, tree *argarray)
argarray[i], t);
}

-  function = build_call_array (result_type, function, n, argarray);
+  function = build_call_array_loc (input_location,
+   result_type, function, n, argarray);
   TREE_HAS_CONSTRUCTOR (function) = is_constructor;
   TREE_NOTHROW (function) = nothrow;

See how the call to build_call_array got changed into a call
tobuild_call_array_loc.

The change that turned build_call_array into build_call_array_loc in
tree.c was:

 tree
-build_call_array (tree return_type, tree fn, int nargs, const tree *args)
+build_call_array_loc (location_t loc, tree return_type, tree fn,
+  int nargs, const tree *args)
 {
   tree t;
   int i;
@@ -8549,6 +8550,7 @@ build_call_array (tree return_type, tree fn, int
nargs, const tree *args)
   for (i = 0; i < nargs; i++)
 CALL_EXPR_ARG (t, i) = args[i];
   process_call_operands (t);
+  SET_EXPR_LOCATION (t, loc);
   return t;
 }

See how the patch adds a location to the resulting call expression
there.  Without that, the previous build_call_array just had no
location, I think.

The change you had to do on gcc/testsuite/g++.dg/gcov/gcov-2.C doesn't
seem to argue against this theory:

@@ -20,7 +20,7 @@ private:

 void foo()
 {
-  C c;/* count(1) */
+  C c;/* count(2) */
   c.seti (1);/* count(1) */
 }

Here we see that before the patch, there was only one call issued on
the line of C c; - and that was probably the call to the constructor.
After, there were two calls on that line, and I think that was the
call to the destructor that added up.  Note that we didn't have any
call on the line of the closing '}', for instance.

Now I am thinking that maybe it would be best to have the call to the
destructor be on the last statement of the block, rather than on the
'}', if we'd have a location for that call at all.

[Bug testsuite/51057] FAIL: gfortran.dg/quad_2.f90 -O0 execution test on powerpc*-*-*

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  2011-12-03 21:08:26 
UTC ---
(In reply to comment #3)
> On Sat, Dec 03, 2011 at 08:36:43PM +, iains at gcc dot gnu.org wrote:

> This test came into being when libquadmath came into the tree.
> The correct, and only, solution for targets whose long double
> representation is double-double math is to XFAIL the test on those
> targets.

Elsewhere in the test suite, if a test is meaningless or impossible to complete
in the absence of a capability - the test is made conditional on that
capability, rather than having a long list of XFAILs.

If this is really not possible here, then I'll prepare an XFAIL patch, but it's
not an ideal solution.

[Bug testsuite/51057] FAIL: gfortran.dg/quad_2.f90 -O0 execution test on powerpc*-*-*

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  
2011-12-03 21:22:39 UTC ---
On Sat, Dec 03, 2011 at 09:08:26PM +, iains at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51057
> 
> --- Comment #4 from Iain Sandoe  2011-12-03 
> 21:08:26 UTC ---
> (In reply to comment #3)
> > On Sat, Dec 03, 2011 at 08:36:43PM +, iains at gcc dot gnu.org wrote:
> 
> > This test came into being when libquadmath came into the tree.
> > The correct, and only, solution for targets whose long double
> > representation is double-double math is to XFAIL the test on those
> > targets.
> 
> Elsewhere in the test suite, if a test is meaningless or impossible
> to complete in the absence of a capability - the test is made
> conditional on that capability, rather than having a long list of XFAILs.

Well, there is 

! { dg-require-effective-target fortran_large_real }

but I believe that that is insufficient in detecting ppc's use
of a double-double representation for its long double.  I also
don't know if there is an equivalent effective-target to provide
the required differentiation.

> If this is really not possible here, then I'll prepare an XFAIL
> patch, but it's not an ideal solution.

It's not a long list if you XFAIL this for all ppc systems.
You need something along the lines

! { dg-do run { target { ! { ppc*-*-* } } } }

[Bug testsuite/51057] FAIL: gfortran.dg/quad_2.f90 -O0 execution test on powerpc*-*-*

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||ebotcazou at libertysurf
   ||dot fr, ro at CeBiTec dot
   ||Uni-Bielefeld.DE

--- Comment #6 from Dominique d'Humieres  2011-12-03 
22:01:22 UTC ---
The main problem with this test is not ppc platform implementing real(16) as
two real(8), but rather platforms that don't have sqrtl (see
http://gcc.gnu.org/ml/fortran/2011-11/msg00079.html ).

Now this test has been motivated by the libquadmath, but is not specific and I
don't see why it should be xfailed if real(16) is available on a platform as
long as it gives a sensible answer as it is the case for ppc.

[Bug c++/51397] New: static_assert message formatting

[d...@boost-consulting.com]

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

 Bug #: 51397
   Summary: static_assert message formatting
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@boost-consulting.com


I just noticed that GCC can be overly-helpful ;-) when formatting a
static assertion message:

static_assert('X' != '\130',"'X' has the wrong value");

gives me

error: static assertion failed: "\'X\' has the wrong value"

I suggest that GCC should drop the surrounding quotes and not try to
escape any characters in the message.  Otherwise, things like

#define static_assert_(x) static_assert(x, #x)
static_assert_('X' != '\130')

turn out quite badly.

The point of this facility is, after all, to help programmers report legible
errors!

[Bug testsuite/51057] FAIL: gfortran.dg/quad_2.f90 -O0 execution test on powerpc*-*-*

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  
2011-12-03 22:24:30 UTC ---
On Sat, Dec 03, 2011 at 10:01:22PM +, dominiq at lps dot ens.fr wrote:
> 
> --- Comment #6 from Dominique d'Humieres  
> 2011-12-03 22:01:22 UTC ---
> The main problem with this test is not ppc platform implementing real(16) as
> two real(8), but rather platforms that don't have sqrtl (see
> http://gcc.gnu.org/ml/fortran/2011-11/msg00079.html ).

Did you read the thread?  I specifically recommended that
the testcase should be XFAILed for the missing sqrtl, too;
because no one is going to implement a suitable sqrtl in
c99_functions.c.

> Now this test has been motivated by the libquadmath, but is not specific and I
> don't see why it should be xfailed if real(16) is available on a platform as
> long as it gives a sensible answer as it is the case for ppc.

The test is designed to test float128 (aka IEEE 754 binary 128 format).
Double-double math gives you 106 bits of precision, which means it is
impossible to meet the requirements of a 113 bit precision type.
Lowering the accuracy of the test to allow ppc to pass opens up the
possibility of missing a bug in libquadmath when someone makes a
change to the library.

[Bug testsuite/51057] FAIL: gfortran.dg/quad_2.f90 -O0 execution test on powerpc*-*-*

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  2011-12-03 
23:15:32 UTC ---
(In reply to comment #5)
> It's not a long list if you XFAIL this for all ppc systems.
>You need something along the lines
>
> ! { dg-do run { target { ! { ppc*-*-* } } } }

(In reply to comment #7)
> Did you read the thread?  I specifically recommended that
> the testcase should be XFAILed for the missing sqrtl, too;
> because no one is going to implement a suitable sqrtl in
> c99_functions.c.

So the list will be longer than ppc*-*-*.

> Lowering the accuracy of the test to allow ppc to pass opens up the
> possibility of missing a bug in libquadmath when someone makes a
> change to the library.

I am impressed by the coverage! what about

--- /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/quad_2.f902011-11-06
20:24:56.0 +0100
+++ /opt/gcc/work/gcc/testsuite/gfortran.dg/quad_2.f902011-12-04
00:08:16.0 +0100
@@ -48,8 +48,13 @@ program test_qp
  case (16)
if (str1 /= "   1.000") call abort()
if (str2 /= "1.000") call abort()
-   if (str3 /= "   1.41421356237309504880168872420969798") call abort()
-   if (str4 /= "1.41421356237309504880168872420969798") call abort()
+   if (size (real_kinds) >= 4) then
+ if (str3 /= "   1.41421356237309504880168872420969798") call abort()
+ if (str4 /= "1.41421356237309504880168872420969798") call abort()
+   else
+ if (str3(1:37) /= "   1.41421356237309504880168872420969") call
abort()
+ if (str4(1:34) /= "1.41421356237309504880168872420969") call abort()
+   end if
block
  real(qp), volatile :: fp2a
  fp2a = 2.0_qp

?

[Bug testsuite/51057] FAIL: gfortran.dg/quad_2.f90 -O0 execution test on powerpc*-*-*

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  
2011-12-03 23:36:01 UTC ---
On Sat, Dec 03, 2011 at 11:15:32PM +, dominiq at lps dot ens.fr wrote:
> (In reply to comment #5)
> > It's not a long list if you XFAIL this for all ppc systems.
> >You need something along the lines
> >
> > ! { dg-do run { target { ! { ppc*-*-* } } } }
> 
> (In reply to comment #7)
> > Did you read the thread?  I specifically recommended that
> > the testcase should be XFAILed for the missing sqrtl, too;
> > because no one is going to implement a suitable sqrtl in
> > c99_functions.c.
> 
> So the list will be longer than ppc*-*-*.
> 

As others report failures, then I suppose the answer is yes.
If you don't like this option, implement a suitable sqrtl().
Go re-read my responses in the other and then read

http://svnweb.freebsd.org/base/head/lib/msun/src/e_sqrtl.c?revision=176720&view=markup

It's only 159 lines of code. 

> > Lowering the accuracy of the test to allow ppc to pass opens up the
> > possibility of missing a bug in libquadmath when someone makes a
> > change to the library.
> 
> I am impressed by the coverage! what about
> 
> --- /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/quad_2.f902011-11-06
> 20:24:56.0 +0100
> +++ /opt/gcc/work/gcc/testsuite/gfortran.dg/quad_2.f902011-12-04
> 00:08:16.0 +0100
> @@ -48,8 +48,13 @@ program test_qp
>   case (16)
> if (str1 /= "   1.000") call abort()
> if (str2 /= "1.000") call abort()
> -   if (str3 /= "   1.41421356237309504880168872420969798") call abort()
> -   if (str4 /= "1.41421356237309504880168872420969798") call abort()
> +   if (size (real_kinds) >= 4) then
> + if (str3 /= "   1.41421356237309504880168872420969798") call abort()
> + if (str4 /= "1.41421356237309504880168872420969798") call abort()
> +   else
> + if (str3(1:37) /= "   1.41421356237309504880168872420969") call
> abort()
> + if (str4(1:34) /= "1.41421356237309504880168872420969") call abort()
> +   end if
> block
>   real(qp), volatile :: fp2a
>   fp2a = 2.0_qp
> 

Why is it so difficult to accept that the test can be XFAILed.
The above is an ugly hack.  Are you going to fix all other
REAL(16) examples with a similar approach?

[Bug target/51381] Internal compiler error for arm target

[eric.valette at free dot fr]

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

--- Comment #10 from eric.valette at free dot fr 2011-12-03 23:49:42 UTC ---
Then at least I know how to fix the bug. Thanks a lot for your help. I will use
the C definition instead of inline asm. BTW I have no clue on arm assembler. Is
the asm code correct?

[Bug c++/51398] New: [4.7 Regression] ICE with invalid template parameter

[reichelt at gcc dot gnu.org]

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

 Bug #: 51398
   Summary: [4.7 Regression] ICE with invalid template parameter
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


The following invalid code snippet troggers an ICE on trunk:

==
template struct A
{
  static const int i = N;
};
==

bug.cc:1:10: error: 'void' is not a valid type for a template non-type
parameter
bug.cc:3:24: internal compiler error: tree check: expected tree that contains
'decl common' structure, have 'error_mark' in parameter_of_template_p, at
cp/pt.c:8127
Please submit a full bug report, [etc.]

[Bug c++/51398] [4.7 Regression] ICE with invalid template parameter

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-checking,
   ||ice-on-invalid-code
   Target Milestone|--- |4.7.0

[Bug c++/51399] New: [4.7 Regression] ICE with invalid initializer list

[reichelt at gcc dot gnu.org]

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

 Bug #: 51399
   Summary: [4.7 Regression] ICE with invalid initializer list
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


The following invalid code snippet triggers an ICE on trunk:


#include 

struct A
{
  std::initializer_list x[1] = { 0 };
  A() {}
};


bug.cc:5:41: error: could not convert '0' from 'int' to
'std::initializer_list'
bug.cc: In constructor 'A::A()':
bug.cc:6:7: internal compiler error: tree check: expected tree_list, have
error_mark in perform_member_init, at cp/init.c:624
Please submit a full bug report, [etc.]

[Bug c++/51399] [4.7 Regression] ICE with invalid initializer list

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-checking,
   ||ice-on-invalid-code
   Target Milestone|--- |4.7.0

[Bug c++/51400] New: [c++0x] ICE with constexpr and attribute noreturn

[reichelt at gcc dot gnu.org]

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

 Bug #: 51400
   Summary: [c++0x] ICE with constexpr and attribute noreturn
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


The following valid(?) code snippet triggers an ICE since GCC 4.6.0:

===
constexpr int (*f)() __attribute__((noreturn)) = 0;
===

bug.cc:1:46: internal compiler error: in start_decl, at cp/decl.c:4515
Please submit a full bug report, [etc.]

[Bug c++/51401] New: [c++0x] [4.7 Regression] ICE with invalid use of auto in template

[reichelt at gcc dot gnu.org]

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

 Bug #: 51401
   Summary: [c++0x] [4.7 Regression] ICE with invalid use of auto
in template
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


The following invalid code snippet triggers an ICE on trunk:

=
template struct A
{
  auto i = 0;
};
=

bug.cc:3:12: internal compiler error: tree check: expected tree that contains
'typed' structure, have 'default_arg' in type_unknown_p, at cp/typeck.c:172
Please submit a full bug report, [etc.]

[Bug c++/51401] [c++0x] [4.7 Regression] ICE with invalid use of auto in template

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Keywords||ice-checking,
   ||ice-on-invalid-code
   Target Milestone|--- |4.7.0

[Bug c++/51402] New: [4.6/4.7 Regression] ICE with invalid template parameter

[reichelt at gcc dot gnu.org]

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

 Bug #: 51402
   Summary: [4.6/4.7 Regression] ICE with invalid template
parameter
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


The following invalid code snippet triggers an ICE since GCC 4.6.0:

=
template struct A
{
  template struct B {};
  template struct B {};
};
=

bug.cc:1:10: error: 'void' is not a valid type for a template non-type
parameter
bug.cc:4:33: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in template_class_depth, at cp/pt.c:365
Please submit a full bug report, [etc.]

[Bug c++/51402] [4.6/4.7 Regression] ICE with invalid template parameter

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-checking,
   ||ice-on-invalid-code
   Target Milestone|--- |4.6.3

[Bug c++/51397] static_assert message formatting

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-04
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-12-04 
00:42:23 UTC ---
Indeed, I spotted this two days ago, thanks for reporting it

[Bug c++/51403] New: [4.7 Regression] ICE with invalid template parameter

[reichelt at gcc dot gnu.org]

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

 Bug #: 51403
   Summary: [4.7 Regression] ICE with invalid template parameter
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


The following invalid code snippet triggers an ICE on trunk:


template void foo(T, U, int) {}

void bar()
{
  foo(0, 0, 0);
}


bug.cc:1:22: error: 'void' is not a valid type for a template non-type
parameter
bug.cc: In function 'void bar()':
bug.cc:5:14: internal compiler error: in unify, at cp/pt.c:16222
Please submit a full bug report, [etc.]

[Bug c++/51403] [4.7 Regression] ICE with invalid template parameter

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
   Target Milestone|--- |4.7.0

[Bug c++/51404] New: [c++0x] [4.7 Regression] ICE with invalid use of auto

[reichelt at gcc dot gnu.org]

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

 Bug #: 51404
   Summary: [c++0x] [4.7 Regression] ICE with invalid use of auto
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


The following invalid code snippet triggers an ICE on trunk:

===
int i = auto().x;
===

bug.cc:1:14: error: invalid use of 'auto'
bug.cc:1:15: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]

[Bug c++/51404] [c++0x] [4.7 Regression] ICE with invalid use of auto

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
   Target Milestone|--- |4.7.0

[Bug c++/51405] New: Passing method result to constructor treated as function declaration

[muhineg at gmail dot com]

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

 Bug #: 51405
   Summary: Passing method result to constructor treated as
function declaration
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: muhi...@gmail.com


Created attachment 25984
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25984
Testcase

Passing to constructor result of method with name which was typedefed before
results in treating object creation as function declaration.

The following code should not compile, but it compiles on gcc 4.2.4 and newer
Tested on 4.7.0 ubuntu snapshot, 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3), 4.4.6
(Ubuntu/Linaro 4.4.6-11ubuntu2) and 4.2.4 built from source.

#include 

typedef int Something;

class A
{
  public:
A ()
{
  printf ("A::A\n");
}
};

class B
{
};

int main ()
{
  printf ("start\n");

  A a (B ()->Something ());  //Should produce compile error

  printf ("finish\n");

  return 0;
}

This bug leads to very hard to find bugs in user code - if your class has
operator -> and returned type has method with name which was typedefed. For
example we have DisplayLock class which receives x11 Display* in constructor
and singleton which has "Display* Display ()" method, so code
DisplayLock lock (DisplaySingleton::Instance ()->Display ());
is ignored because Display typedefed as struct _XDisplay Display, and we see no
errors, because there are no access to lock object after creation;

For example:

#include 

typedef int Something;

class A
{
  public:
A (const char* arg)
{
  printf ("A::A '%s'\n", arg);
}
};

class B
{
  public:
class Instance
{
  public:
Instance ()
{
  printf ("B::Instance::Instance\n");
}

B* operator -> () const
{
  static B instance;

  return &instance;
}
};

const char* Something ()
{
  return "Something";
}
};

int main ()
{
  printf ("start '%s'\n", B::Instance ()->Something ());

  A a (B::Instance ()->Something ());

  printf ("finish\n");

  return 0;
}

Expected to print (works on gcc 4.2.4):
B::Instance::Instance
start 'Something'
B::Instance::Instance
A::A 'Something'
finish

But prints (4.4.6, 4.6.1 and 4.7.0):
B::Instance::Instance
start 'Something'
finish

[Bug c++/51313] [4.7 Regression][C++0x] ICE: tree check: expected class 'constant', have 'unary' (nop_expr) in null_ptr_cst_p, at cp/call.c:556

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  
2011-12-04 01:40:40 UTC ---
Author: paolo
Date: Sun Dec  4 01:40:36 2011
New Revision: 181980

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181980
Log:
/cp
2011-12-03  Paolo Carlini  

PR c++/51313
* call.c (null_ptr_cst_p): STRIP_NOPS in c++11 mode too.

/testsuite
2011-12-03  Paolo Carlini  

PR c++/51313
* g++.dg/cpp0x/pr51313.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr51313.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/51313] [4.7 Regression][C++0x] ICE: tree check: expected class 'constant', have 'unary' (nop_expr) in null_ptr_cst_p, at cp/call.c:556

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Paolo Carlini  2011-12-04 
01:42:04 UTC ---
Fixed.

[Bug c++/51405] Passing method result to constructor treated as function declaration

[muhineg at gmail dot com]

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

--- Comment #1 from Ievgen Mukhin  2011-12-04 
01:54:05 UTC ---
Sorry, i was wrong when I wrote that test case compiles on 4.2.4.
4.2.4 throws compilation error as it should: error: base operand of ‘->’ has
non-pointer type ‘B’
But newer versions don't produce this error.

[Bug c++/51405] Passing method result to constructor treated as function declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-04
 Ever Confirmed|0   |1
   Severity|critical|normal

--- Comment #2 from Jonathan Wakely  2011-12-04 
01:59:04 UTC ---
how strange - confirmed

[Bug other/50775] Register allocator sets up frame and frame pointer with low register pressure

[vmakarov at redhat dot com]

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

--- Comment #6 from Vladimir Makarov  2011-12-04 
04:09:06 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> 
> > Wrong profitable hard regs calculation for register files requiring aligned
> > start register was a merging problem with a patch for allocation without 
> > cover
> > classes.
> > 
> > I'll try make a patch this week to solve the problem.
> 
> Thanks you are taking care of this.  Will it also improve the situation for
> 3-byte types as introduced in PR50931? 3-byte types also start in even
> registers.

I think it will improve.

Sorry for the delay with the patch.  The changes are big (the patch is about
1700 lines long) so I need a thorough testing.

[Bug testsuite/51349] [4.7 Regression] FAIL: obj-c++.dg/naming-[34].mm

[mrs at gcc dot gnu.org]

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

m...@gcc.gnu.org  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org

--- Comment #1 from mrs at gcc dot gnu.org  2011-12-04 
06:39:17 UTC ---
Ok.

[Bug c++/51406] New: [4.5/4.6/4.7 Regression][c++0x] Incorrect result of static_cast to rvalue reference to base class.

[roman at binarylife dot net]

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

 Bug #: 51406
   Summary: [4.5/4.6/4.7 Regression][c++0x] Incorrect result of
static_cast to rvalue reference to base class.
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ro...@binarylife.net


$ cat test.cpp 
#include 
#include 

struct A { int a; A() : a(1) {} };
struct B { int b; B() : b(2) {} };
struct X : A, B {};

int main() {
X x;
int a=static_cast(x).a;
int b=static_cast(x).b;
std::cout<<"a="<

[Bug testsuite/51349] [4.7 Regression] FAIL: obj-c++.dg/naming-[34].mm

[mrs at gcc dot gnu.org]

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

--- Comment #2 from mrs at gcc dot gnu.org  2011-12-04 
07:34:32 UTC ---
Author: mrs
Date: Sun Dec  4 07:34:25 2011
New Revision: 181984

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181984
Log:
2011-12-03  Dominique d'Humieres  

PR obj-c++/51349
* obj-c++.dg/naming-3.mm: Adjust for changing error messages.
* obj-c++.dg/naming-4.mm: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/obj-c++.dg/naming-3.mm
trunk/gcc/testsuite/obj-c++.dg/naming-4.mm

[Bug testsuite/51349] [4.7 Regression] FAIL: obj-c++.dg/naming-[34].mm

[mrs at gcc dot gnu.org]

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

m...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from mrs at gcc dot gnu.org  2011-12-04 
07:35:32 UTC ---
Fixed.