[Bug bootstrap/52878] [4.8 regression] bootstrap failure: "MASK_LONG_DOUBLE_128" redefined

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #4 from Mikael Pettersson  2012-04-16 
07:13:09 UTC ---
Can someone please fix this bootstrap failure?  It's now been three weeks that
trunk hasn't bootstrapped on sparc64-linux.

[Bug tree-optimization/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop

[izamyatin at gmail dot com]

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

--- Comment #6 from Igor Zamyatin  2012-04-16 
07:16:56 UTC ---
Any ideas what exactly does prevent the vectorization in the case of Fortran?

[Bug debug/52935] Unnecessary DW_TAG_pointer_type DIEs in C++

[mark at gcc dot gnu.org]

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

--- Comment #1 from Mark Wielaard  2012-04-16 07:55:35 
UTC ---
GNU C 4.6.3 20120306 (Red Hat 4.6.3-2) -mtune=generic -march=x86-64 -g
produces:

 [1d]structure_type
 name (string) "S"
 byte_size(data1) 8
 decl_file(data1) 1
 decl_line(data1) 1
 sibling  (ref4) [32]
 [27]  member
   name (string) "a"
   decl_file(data1) 1
   decl_line(data1) 1
   type (ref4) [32]
   data_member_location (data1) 0
 [32]pointer_type
 byte_size(data1) 8
 type (ref4) [1d]
 [38]structure_type
 name (string) "T"
 byte_size(data1) 8
 decl_file(data1) 1
 decl_line(data1) 1
 sibling  (ref4) [4d]
 [42]  member
   name (string) "b"
   decl_file(data1) 1
   decl_line(data1) 1
   type (ref4) [32]
   data_member_location (data1) 0
 [4d]variable
 name (string) "t"
 decl_file(data1) 1
 decl_line(data1) 1
 type (ref4) [38]
 external (flag_present) Yes
 location (exprloc) 
  [   0] addr .bss+0

Both DIE 27 and 42 use the same type DIE 32.

While GNU C++ 4.6.3 20120306 (Red Hat 4.6.3-2) -mtune=generic -march=x86-64 -g
gives:

 [1d]structure_type
 name (string) "S"
 byte_size(data1) 8
 decl_file(data1) 1
 decl_line(data1) 1
 sibling  (ref4) [32]
 [27]  member
   name (string) "a"
   decl_file(data1) 1
   decl_line(data1) 1
   type (ref4) [32]
   data_member_location (data1) 0
 [32]pointer_type
 byte_size(data1) 8
 type (ref4) [1d]
 [38]structure_type
 name (string) "T"
 byte_size(data1) 8
 decl_file(data1) 1
 decl_line(data1) 1
 sibling  (ref4) [4d]
 [42]  member
   name (string) "b"
   decl_file(data1) 1
   decl_line(data1) 1
   type (ref4) [4d]
   data_member_location (data1) 0
 [4d]pointer_type
 byte_size(data1) 8
 type (ref4) [1d]
 [53]variable
 name (string) "t"
 decl_file(data1) 1
 decl_line(data1) 1
 type (ref4) [38]
 external (flag_present) Yes
 location (exprloc) 
  [   0] addr .bss+0 

Type DIEs 32 and 4d are the same, the first is used by DIE 27, the second by
DIE 42.

[Bug c++/53003] Internal compiler error on short testcase

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-16
  Known to work||4.6.3
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2012-04-16 
08:17:19 UTC ---
Program received signal SIGSEGV, Segmentation fault.
0x005d2b95 in cp_parser_member_declaration (parser=0x71b33948) at
/home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:19113
19113   error_at (initializer_token_start->location,
Missing separate debuginfos, use: debuginfo-install gmp-4.3.2-4.fc16.x86_64
libmpc-0.9-1.fc16.x86_64 mpfr-3.0.0-4.fc15.x86_64 zlib-1.2.5-6.fc16.x86_64
(gdb) p initializer_token_start 
$1 = (cp_token *) 0x0
(gdb) bt
#0  0x005d2b95 in cp_parser_member_declaration (parser=0x71b33948)
at /home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:19113
#1  0x005b743c in cp_parser_member_specification_opt (parser=) at /home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:18708
#2  cp_parser_class_specifier_1 (parser=0x71b33948) at
/home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:17981
#3  cp_parser_class_specifier (parser=0x71b33948) at
/home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:18192
#4  cp_parser_type_specifier (parser=0x71b33948, flags=,
decl_specs=0x7fffda40, is_declaration=1 '\001', 
declares_class_or_enum=0x7fffd9d8, is_cv_qualifier=) at
/home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:13358
#5  0x005c7518 in cp_parser_decl_specifier_seq (parser=0x71b33948,
flags=1, decl_specs=0x7fffda40, declares_class_or_enum=0x7fffdaa8)
at /home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:10701
#6  0x005d0d2a in cp_parser_simple_declaration (parser=0x71b33948,
function_definition_allowed_p=1 '\001', maybe_range_for_decl=0x0)
at /home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:10352
#7  0x005d2f19 in cp_parser_block_declaration (statement_p=0 '\000',
parser=0x71b33948) at /home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:10303
#8  cp_parser_block_declaration (parser=0x71b33948, statement_p=0 '\000')
at /home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:10229
#9  0x005d8432 in cp_parser_declaration (parser=0x71b33948) at
/home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:10200
#10 cp_parser_declaration (parser=0x71b33948) at
/home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:10107
#11 0x005d6f43 in cp_parser_declaration_seq_opt (parser=0x71b33948)
at /home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:10086
#12 0x005d8ac1 in cp_parser_translation_unit (parser=0x71b33948) at
/home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:3797
#13 c_parse_file () at /home/redi/src/gcc/gcc-4.x/gcc/cp/parser.c:27431
#14 0x006dce15 in c_common_parse_file () at
/home/redi/src/gcc/gcc-4.x/gcc/c-family/c-opts.c:1124
#15 0x00a2f48c in compile_file () at
/home/redi/src/gcc/gcc-4.x/gcc/toplev.c:556
#16 do_compile () at /home/redi/src/gcc/gcc-4.x/gcc/toplev.c:1938
#17 toplev_main (argc=15, argv=0x7fffdd38) at
/home/redi/src/gcc/gcc-4.x/gcc/toplev.c:2014
#18 0x00324b42169d in __libc_start_main (main=0x4b7930 , argc=15,
ubp_av=0x7fffdd38, init=, fini=, 
rtld_fini=, stack_end=0x7fffdd28) at libc-start.c:226
#19 0x004b7961 in _start ()

[Bug c/52977] [4.8 Regression] internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-16
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.8.0
Summary|internal compiler error:|[4.8 Regression] internal
   |Segmentation fault with `-x |compiler error:
   |c-header' or `-x|Segmentation fault with `-x
   |cxx-header' option  |c-header' or `-x
   ||cxx-header' option
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2012-04-16 
08:48:13 UTC ---
Mine then.

[Bug fortran/52968] [OOP] Call to type-bound procedure wrongly rejected

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org 2012-04-16 08:48:18 UTC ---
Author: janus
Date: Mon Apr 16 08:48:11 2012
New Revision: 186486

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186486
Log:
2012-04-16  Janus Weil  

PR fortran/52968
* class.c (gfc_build_class_symbol): Make sure the 'f2k_derived'
namespace is present.


2012-04-16  Janus Weil  

PR fortran/52968
* gfortran.dg/typebound_call_23.f03: New test case.

Added:
trunk/gcc/testsuite/gfortran.dg/typebound_call_23.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/testsuite/ChangeLog

[Bug c/53004] New: Segmentation fault can be overcome with dummy predefined declaration

[gursoyturan at iyte dot edu.tr]

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

 Bug #: 53004
   Summary: Segmentation fault can be overcome with dummy
predefined declaration
Classification: Unclassified
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gursoytu...@iyte.edu.tr


The program compiles, but only runs if a dummy predefined variable is inserted
as below

float dummy=1;

[Bug fortran/52968] [OOP] Call to type-bound procedure wrongly rejected

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from janus at gcc dot gnu.org 2012-04-16 08:53:10 UTC ---
Fixed with r186486. Closing.

Thanks for reporting!

[Bug target/52804] IRA/RELOAD allocate wrong register on ARM for cortex-m0

[amker.cheng at gmail dot com]

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

--- Comment #2 from amker.cheng  2012-04-16 
09:00:08 UTC ---
Any comments?
Or could anyone help me confirm this issue?
Thanks very much.

[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org 2012-04-16 09:04:51 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > > Just out of curiosity: Are you aware of any compiler which swallows this?
> > 
> > No. I've just tried it with PGI (pgf95) but it chokes on "contains" "within 
> > a
> > derived type definition".
> 
> That was probably an older version. I'm pretty sure the more recent versions 
> of
> PGI at least support type-bound procedures.

I just tried ifort 12.1.1.256 and PGI 11.9 on comment #4, and both reject it:


ifort pr52994.f90 
pr52994.f90(32): error #6515: This function, which is specified as the left
side of an assignment statement, is invalid.   [LEFT_HALO]
  a%left_halo(arr) = -666  ! ICE
^


pgf95 pr52994.f90 
PGF90-S-0072-Assignment operation illegal to external procedure left_halo9
(pr52994.f90: 32)
  0 inform,   0 warnings,   1 severes, 0 fatal for test

[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[janus at gcc dot gnu.org]

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

--- Comment #11 from janus at gcc dot gnu.org 2012-04-16 09:11:07 UTC ---
Note that at gfortran correctly rejects the test case with -std=f2003:

  a%left_halo(arr) = -666  ! ICE
  1
Error: Fortran 2008: Pointer functions in variable definition context
(assignment) at (1)

[Bug target/52941] SH Target: Add support for movco.l / movli.l atomics on SH4A

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  2012-04-16 09:14:57 
UTC ---
Created attachment 27164
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27164
WIP patch

The attached patch adds support for movco.l/movli.l insns on SH4A for
-msoft-atomic.  It also adds a new option -mhard-atomic.  For SImode all
hard-atomic patterns should be working.  I've started implementing some of the
QImode and HImode hard-atomic patterns
(atomic_{ior|xor|and|add|sub}_fetch{hi|qi}_hard so far) to see how it would
turn out.

I'm currently using a 4 byte lookup table to get the endian dependent bit
positions for the shift insns which are required to extract/insert the
subwords.  The HImode variants could also be done without the LUT, but I didn't
want to introduce a special case for that.  Ideally, the the LUT would go into
the constant pool, which would allow it to be shared among multiple atomic
insns and also would eliminate the need to branch around it after the atomic
insn.  However, I don't know how to reliably get the the address of a constant
in the constant pool (by using the mova insn).

The atomic_{ior|xor|and|add|sub}_fetch{hi|qi}_hard patterns in the patch seem
to be working OK, but the atomic sequence code turns out rather big.  The
address calculation code could be moved out of the atomic insns so that it
could be CSE'd, but I guess that it would most likely increase register
pressure.  The extu.{b|w} insn in the sequnces can definitely be done before
that in a separate insn, so that it can be eliminated by other passes.  Still,
because of the code size for HImode / QImode hard atomic sequences I think it
would be better to also have a copy of them in libgcc and emit function calls
when compiling with -Os.

Feedback appreciated :)

[Bug tree-optimization/52975] Ofast produces not optimized code for vectorized "converted if"

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-04-16 
09:25:17 UTC ---
Author: rguenth
Date: Mon Apr 16 09:25:14 2012
New Revision: 186488

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186488
Log:
2012-04-16  Richard Guenther  

PR tree-optimization/52975
* tree-ssa-forwprop.c (combine_cond_exprs): New function.
(ssa_forward_propagate_and_combine): Call it for COND_EXPRs
and VEC_COND_EXPRs.  Also combine into VEC_COND_EXPRs condition.
* fold-const.c (operand_equal_p): Handle TARGET_MEM_REF.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/tree-ssa-forwprop.c

[Bug other/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.1
Summary|[4.7, 4.8 Regression] ICE,  |[4.7/4.8 Regression] ICE,
   |segmentation fault in   |segmentation fault in
   |c_tree_printer  |c_tree_printer

[Bug middle-end/52997] [4.8 Regression] FAIL: gcc.dg/c99-intconst-1.c (internal compiler error)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug middle-end/52996] [4.8 Regression] ice in verify_loop_structure, at cfgloop.c:1567

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Guenther  2012-04-16 
09:32:47 UTC ---
Mine.

[Bug target/52941] SH Target: Add support for movco.l / movli.l atomics on SH4A

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo  2012-04-16 09:33:25 
UTC ---
Created attachment 27165
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27165
WIP patch

The temporary string buffers should have been 'static' of course.

[Bug c++/52985] Postincrement not applied after indexing ternary array expression

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-16
  Component|middle-end  |c++
 Ever Confirmed|0   |1
  Known to fail||4.7.1

--- Comment #1 from Richard Guenther  2012-04-16 
09:42:31 UTC ---
Confirmed.  The gimplification looks bogus:

  if (flag != 0) goto ; else goto ;
  :
  D.24018 = __gnu_cxx::__normal_iterator >::operator++ (&it, 0);
  cleanup.1 = 1;
  D.24458 = __gnu_cxx::__normal_iterator >::operator* (&D.24018);
  D.24459 = *D.24458;
  goto ;
  :
  D.24461 = __gnu_cxx::__normal_iterator >::operator* (&D.24018);
  D.24462 = *D.24461;
  :

it is only incremented on one arm.

[Bug tree-optimization/52979] [4.7/4.8 Regression] likely wrong code bug w/packed bitfields

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.6.3
   Keywords||wrong-code
   Last reconfirmed||2012-04-16
  Component|c   |tree-optimization
 Ever Confirmed|0   |1
Summary|likely wrong code bug   |[4.7/4.8 Regression] likely
   |w/packed bitfields  |wrong code bug w/packed
   ||bitfields
   Target Milestone|--- |4.7.1
  Known to fail||4.7.0, 4.8.0

--- Comment #1 from Richard Guenther  2012-04-16 
09:46:28 UTC ---
Confirmed with -O2 -ftree-vectorize.

[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug c/53004] Segmentation fault can be overcome with dummy predefined declaration

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-04-16
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2012-04-16 
09:46:46 UTC ---
There is no attached source code.
Can you attach the source code where you are having the seg fault at runtime?

I bet you have a buffer overflow in your code though.

[Bug c/53004] Segmentation fault can be overcome with dummy predefined declaration

[gursoyturan at iyte dot edu.tr]

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

--- Comment #2 from gursoyturan at iyte dot edu.tr 2012-04-16 09:57:08 UTC ---
Created attachment 27166
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27166
C-Source code

C-source code

[Bug middle-end/52939] [4.7/4.8 Regression] ice in gimple_get_virt_method_for_binfo with -O3

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  2012-04-16 
10:02:12 UTC ---
Author: jamborm
Date: Mon Apr 16 10:02:04 2012
New Revision: 186489

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186489
Log:
2012-04-16  Martin Jambor  

PR middle-end/52939
* gimple-fold.c (gimple_get_virt_method_for_binfo): Bail out if
fold_ctor_reference returns a zero constant.

* testsuite/g++.dg/ipa/pr52939.C: New test.


Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/ipa/pr52939.C
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/gimple-fold.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug c++/53005] New: GCC moves the called C function address and parameters to the wrong stack position, when making C-style calling of C functions in a C function with inline assembly code.

[zhao86.scholar at gmail dot com]

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

 Bug #: 53005
   Summary: GCC moves the called C function address and parameters
to the wrong stack position, when making C-style
calling of C functions in a C function with inline
assembly code.
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zhao86.scho...@gmail.com


Created attachment 27167
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27167
C code to reproduce the bug.

When making C-style calling of C functions in a C function with inline assembly
code, GCC moves the called C function address and parameters to the wrong stack
position, which is overwriting the values of other variables in the stack.   
The problem can be reproduced using the C code in the attached.

The exact version of GCC:
4.2.1

The system type:
i686-apple-darwin11

The options given when GCC was configured/built:
/private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/src/configure
--disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2
--mandir=/share/man --enable-languages=c,objc,c++,obj-c++
--program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin11
--enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/dst-llvmCore/Developer/usr/local
--program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11
--target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1

[Bug middle-end/52939] [4.7/4.8 Regression] ice in gimple_get_virt_method_for_binfo with -O3

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Martin Jambor  2012-04-16 
10:10:48 UTC ---
Fixed.

[Bug c/53005] GCC moves the called C function address and parameters to the wrong stack position, when making C-style calling of C functions in a C function with inline assembly code.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|c++ |c
Version|unknown |4.2.1
   Severity|major   |normal

--- Comment #1 from Jonathan Wakely  2012-04-16 
10:12:41 UTC ---
GCC 4.2 is not supported, please try a current release.

[Bug testsuite/52948] [4.8 Regression] UNRESOLVED: selfassign.c in gcc/g++, one_time_plugin.c in gcc, and dumb_plugin.c in g++

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  2012-04-16 10:14:49 UTC 
---
Author: ro
Date: Mon Apr 16 10:14:40 2012
New Revision: 186490

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186490
Log:
Fix plugin testsuite, remove uses of TODO_dump_func (PR testsuite/52948)

* lib/plugin-support.exp (plugin-test-execute): Properly determine
testcase name.
Use fail, pass instead of unresolved.
Don't log $optstr.

PR testsuite/52948
* g++.dg/plugin/dumb_plugin.c (pass_dumb_plugin_example): Remove
TODO_dump_func.
* g++.dg/plugin/selfassign.c (pass_warn_self_assign): Likewise.
* gcc.dg/plugin/one_time_plugin.c (one_pass): Likewise.
* gcc.dg/plugin/selfassign.c (pass_warn_self_assign): Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/plugin/dumb_plugin.c
trunk/gcc/testsuite/g++.dg/plugin/selfassign.c
trunk/gcc/testsuite/gcc.dg/plugin/one_time_plugin.c
trunk/gcc/testsuite/gcc.dg/plugin/selfassign.c
trunk/gcc/testsuite/lib/plugin-support.exp

[Bug c/52977] [4.8 Regression] internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-04-16 
10:15:35 UTC ---
ugh...

#0  0x004d7255 in gt_pch_p_14lang_tree_node (this_obj=0x75bf64c0, 
x_p=0x75bf64c0, op=0x8b1a27 , cookie=0x7fffdb20)
at ./gt-c-decl.h:1448

case TS_VECTOR:
  if ((void *)(x) == this_obj)
op (&((*x).generic.vector.typed.type), cookie);
  {
size_t i0;
size_t l0 = (size_t)(TYPE_VECTOR_SUBPARTS (TREE_TYPE
((tree)&((*x).generic.vector;
for (i0 = 0; i0 != l0; i0++) {
  if ((void *)(x) == this_obj)
op (&((*x).generic.vector.elts[i0]), cookie);
}
  }
  break;

so we relocate TREE_TYPE before accessing it to find the number of elements.

Other than trying to teach gengtype to compute all required lengths before
changing pointers I only see the less efficient solution of repeating the
element count in-line :/

[Bug c/53005] GCC moves the called C function address and parameters to the wrong stack position, when making C-style calling of C functions in a C function with inline assembly code.

[zhao86.scholar at gmail dot com]

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

--- Comment #2 from Lili Zhao  2012-04-16 
10:17:43 UTC ---
Do you mean we should use a later GCC version?
(In reply to comment #1)
> GCC 4.2 is not supported, please try a current release.

[Bug testsuite/52948] [4.8 Regression] UNRESOLVED: selfassign.c in gcc/g++, one_time_plugin.c in gcc, and dumb_plugin.c in g++

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2012-04/msg00921.htm
   ||l
 CC||ro at gcc dot gnu.org
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |

--- Comment #5 from Rainer Orth  2012-04-16 10:25:34 UTC 
---
Mine, fixed for 4.8.0.

  Rainer

[Bug c/53004] Segmentation fault can be overcome with dummy predefined declaration

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #3 from Andreas Schwab  2012-04-16 10:37:17 
UTC ---
You are using an uninitialized pointer.

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[manu at gcc dot gnu.org]

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

--- Comment #11 from Manuel López-Ibáñez  2012-04-16 
10:43:44 UTC ---
(In reply to comment #10)
> It seems like we could at least add a simple improvement that just checks for
> simple comparisons to 0. That probably catches most code (I often do one set 
> of

You are welcome to try: http://gcc.gnu.org/contribute.html

[Bug c++/39728] diagnostic for private operator= is voluminous and unhelpful

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2012-04-16 
10:44:19 UTC ---
(In reply to comment #1)
>   I think libstdc++ include pathes make the error message useless 

Manu has a patch for that in PR 52974

(In reply to comment #2)
> * What is a "synthesized method"? Where this term comes from? Is this 
> something
> that an average C++ programmer can understand?

Every C++ programmer knows that the compiler implicitly defines special member
functions, including the copy-assignment operator but I don't really like the
terminology. C++ doesn't have methods, it has member functions, and the formal
term in the standard is "implicitly-defined" not synthesized.

[Bug c/53005] GCC moves the called C function address and parameters to the wrong stack position, when making C-style calling of C functions in a C function with inline assembly code.

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2012-04-16 
10:47:15 UTC ---
Yes.

If you got GCC 4.2 from Apple then you could report the bug to Apple, not here.

We do not support GCC 4.2, so it is pointless to report bugs for that version
here, they won't be fixed.  If you want support here, you need to use a
supported version.

[Bug c/53004] Segmentation fault can be overcome with dummy predefined declaration

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  2012-04-16 
10:48:28 UTC ---
And GCC tells you so:

manuel@gcc12:~$ ~/trunk/186353M/build/gcc/cc1 -Wall tmp.c 
tmp.c:3:6: warning: return type of ‘main’ is not ‘int’ [-Wmain]
 void main()
  ^
tmp.c: In function ‘main’:
tmp.c:8:8: warning: ‘prod_vg’ is used uninitialized in this function
[-Wuninitialized]
   multg(prod_vg);
^

Now that -Wuninitialized is separated from -Wmaybe-uninitialized, maybe it is
time to enable it by default.

[Bug c++/39728] diagnostic for private operator= is voluminous and unhelpful

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  2012-04-16 
10:53:50 UTC ---
(In reply to comment #3)
> Every C++ programmer knows that the compiler implicitly defines special member
> functions, including the copy-assignment operator but I don't really like the
> terminology. C++ doesn't have methods, it has member functions, and the formal
> term in the standard is "implicitly-defined" not synthesized.

Indeed. I would consider obvious to do:

sed -i 's/synthesized method/implicitly-defined member function/g' cp/*.c
cp/*.h

Would Jason pre-approve such a patch?

It doesn't fix the actual verbose output Ian is complaining about, but it is a
small positive step.

[Bug middle-end/52996] [4.8 Regression] ice in verify_loop_structure, at cfgloop.c:1567

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-04-16 
10:58:06 UTC ---
Looks like a pre-existing bug to me - when we unswitch loops computing
irreducible regions before / after that can lead to inconsistent results.

Loop preserving leads to different loop structure at the beginning of
RTL unswitching compared to the 4.7 branch.

[Bug c++/52763] Warning if compare between enum and non-enum type

[gccrepo...@gmx-topmail.de]

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

--- Comment #5 from Mikka  2012-04-16 11:01:25 UTC 
---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > But what about cases such as (val1 == (ONE|TWO)) ?
> > > 
> > > (ONE|TWO) is of type 'int' but that code is correct and shouldn't warn
> > 
> > In my opinion, there should be a warning here, because (ONE|TWO) is not in 
> > the
> > enumeration range (there is no definition for 3).
> 
> It is in range.  For enum { NONE = 0, ONE = 1, TWO = 2 } the standard says the
> values of the enumeration are in the range 0 to 3, e.g. it could be 
> represented
> by a two-bit unsigned integer.  The standard sets the rules, not your opinion
> :)
> 
While the standard says, it should be an integer of this range. It does not
say, that the enumeration-type should be able/used to store other values as the
ones, which are defined. Actually it does say, that there is not conversion
from int to enum. So this means here, that we would compare the enum to an
integer with a value, which we shouldn't be able to store in the enumeration in
the first place. "var = 1;" produces as expected an error, "invalid conversion
from ‘int’ to ‘tEnumType’".

> Also, that would warn for perfectly valid (and very common) uses of 
> enumeration
> types for bitmasks, e.g. std::ios::openmode could be defined as an enumeration
> type and you could say
> 
>if (mode == (std::ios::in|std::ios::out))
> 
> where there is no enumerator defined for in|out, but this code is common and
> should not warn.
> 
Just because it is common, it doesn't mean that it's perfect. In my opinion
this is an abuse of the enumeration here. If this is a bitmask, it should be
implemented this way, using either the c-style unions or c++ bitsets or 
something else (custom class, ...). The name enumeration means we are counting
something, not a bitmask.

E.g. "mode = (std::ios::in|std::ios::out)" only works, because the function "|"
is defined using static_cast. For me this is quite a hint, that it's quite not
perfect, but more an abuse.
> > If it was defined (e.g. typedef enum {NONE = 0, ONE = 1, TWO = 2, THREE = 3}
> > tEnumType), result could again be of the enumeration type and there would 
> > be no
> > warning.
> 
> No, the result would still be an int, ONE|TWO has type int, period.
> 
> I think the warning could be useful in some cases, but it needs to be defined
> much more carefully than simply "warning each time a enumeration type is
> compared to a non enumeration type" as you suggested.
I still think the warning should be there in both cases. It shouldn't be a
default warning, as legacy code would produce too many warnings.

For my solution, from now on I will use "enum class", as it does exactly what I
want. While this is not my optimal solution (forcing at least gcc 4.4 for all
project attendees), it will work, somehow.

[Bug tree-optimization/52975] Ofast produces not optimized code for vectorized "converted if"

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-04-16 
11:03:20 UTC ---
Author: rguenth
Date: Mon Apr 16 11:03:16 2012
New Revision: 186491

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186491
Log:
2012-04-16  Richard Guenther  

PR tree-optimization/52975
* tree-if-conv.c (predicate_bbs): Do not simplify inverted
condition but always mark it with TRUTH_NOT_EXPR.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-if-conv.c

[Bug tree-optimization/52975] Ofast produces not optimized code for vectorized "converted if"

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Richard Guenther  2012-04-16 
11:07:29 UTC ---
Fixed.

.L3:
movaps  clus(%rax), %xmm1
movaps  %xmm2, %xmm0
cmpltps %xmm1, %xmm0
andnps  %xmm1, %xmm0
movaps  %xmm0, xsum(%rax)
addq$16, %rax
cmpq$400, %rax
jne .L3

[Bug c++/39728] diagnostic for private operator= is voluminous and unhelpful

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-04-16 
11:10:07 UTC ---
Maybe the most widely used term is "compiler-generated" but I prefer implicity
defined.

(In reply to comment #2)
> * Do not show "In member function", it clutters the output and it is 
> duplicated
> info because they are already mentioned in the note. 

I'm not sure about this suggestion.  

/home/redi/gcc/4.x/include/c++/4.8.0/bits/ios_base.h: In member function
'std::basic_ios& std::basic_ios::operator=(const
std::basic_ios&)':

This is useful info, it tells me the (implicitly-defined) context in which the
private operator= was needed.

/home/redi/gcc/4.x/include/c++/4.8.0/bits/ios_base.h:791:5: error:
'std::ios_base& std::ios_base::operator=(const std::ios_base&)' is private
 operator=(const ios_base&);
 ^

This is useful, it's the private operator= that was needed, but inaccessible.

In file included from /home/redi/gcc/4.x/include/c++/4.8.0/ios:45:0,
 from /home/redi/gcc/4.x/include/c++/4.8.0/istream:40,
 from /home/redi/gcc/4.x/include/c++/4.8.0/fstream:40,
 from f.cc:1:
/home/redi/gcc/4.x/include/c++/4.8.0/bits/basic_ios.h:64:11: error: within this
context
 class basic_ios : public ios_base
   ^

The caret diagnostic is useless here, because an implictly-defined function has
no location.

[Bug c/53005] GCC moves the called C function address and parameters to the wrong stack position, when making C-style calling of C functions in a C function with inline assembly code.

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #4 from Manuel López-Ibáñez  2012-04-16 
11:13:28 UTC ---
See: http://gcc.gnu.org/wiki/FAQ#gcc42apple

[Bug c/53005] GCC moves the called C function address and parameters to the wrong stack position, when making C-style calling of C functions in a C function with inline assembly code.

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  2012-04-16 
11:18:51 UTC ---
Lili Zhao, I forgot to say, but feel free to reopen this if you can reproduce
the bug with GCC 4.7. Thanks for the report anyway, and sorry we cannot help
you.

[Bug tree-optimization/52975] Ofast produces not optimized code for vectorized "converted if"

[vincenzo.innocente at cern dot ch]

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

--- Comment #5 from vincenzo Innocente  
2012-04-16 11:19:26 UTC ---
indeed.
will it be back-ported to 4.7.1?

btw
I find very "elegant" the
movaps(%rdx,%rax), %xmm0
minps%xmm1, %xmm0
movaps%xmm0, (%rcx,%rax)
produced by -Ofast  for
  for (int j=0; j<100 ; ++j)
xsum[j] = (clus[j] > 0) ? 0 : clus[j];

I suppose it is to ask to much to produce the same for
  for (int j=0; j<100 ; ++j) {
xsum[j] = clus[j];
if (xsum[j] > 0) xsum[j] = 0;
  }
and
  for (int j=0; j<100 ; ++j) {
xsum[j] = 0;
if (clus[j] < 0) xsum[j] = clus[j];

in any case I confirm that now all three forms produces the very same code with
-O3 and -Ofast (for the last two) even for march=corei7 (also avx)

I also tested the three variations for
xsum[j] = clus[j];
if (xsum[j] > cut[j]) xsum[j] = 0;

[Bug tree-optimization/52975] Ofast produces not optimized code for vectorized "converted if"

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2012-04-16 
11:40:46 UTC ---
Unless we come up with a testcase that is a regression from an earlier release
a backport is unlikely.

[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  2012-04-16 
11:41:24 UTC ---
(In reply to comment #0)
> This is a request to add a new warning that warns on the subset of 
> -Wconversion
> warnings that involve floating point numbers.  For example, with
> -Wfloat-conversion this would cause a warning:

Should it also warn for non-literals?

int foo(double x)
{
   return x;
}

> I think this could mostly be done by modifying gcc/c-family/c-common.c
> unsafe_conversion_p to add the ability to only warn on conversions where
> REAL_TYPE or REAL_CST are involved.  

Yes, I think it should be easy to implement. You will also need to add a new
option to gcc/c.opt and enable -Wfloat-conversion with -Wconversion (grep for
OPT_Wimplict and how it handles its suboptions).

Unfortunately, I don't have time to work on this, and probably nobody else has,
so you could try to submit a patch: http://gcc.gnu.org/contribute.html

[Bug fortran/51081] Proc-pointer assignment: Rejects valid internal proc, -std=f2008 should mention "F2008"

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org 2012-04-16 12:01:46 UTC ---
(In reply to comment #1)
> First, my example was incomplete. Secondly, I just realized that gfortran
> rejects the program although I think it is valid (ifort also compiles it):
> 
>   subroutine int2()
>  1
> Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'int2' at (1)

I only get this with 4.6.3, but with 4.7 and trunk I get:

  subroutine int2()
 1
Error: 'int2' declared INTRINSIC at (1) does not exist


This error message even appears three times and is just as wrong as the other
one.

[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array

[krisztian.kocsis at optimaster dot eu]

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

--- Comment #4 from Krisztian Kocsis  
2012-04-16 12:07:19 UTC ---
If it is treated as a user error than a warning should be printed because this
changes the behavior of what is dropped and what is not. People expect that
"used thinds" won't be dropped from the final binary and they treate these
sections as "used things" even if it is technically not true.

[Bug debug/52935] Unnecessary DW_TAG_pointer_type DIEs in C++

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.8.0

--- Comment #2 from Jason Merrill  2012-04-16 
12:08:16 UTC ---
Fixed by

2012-04-11  Jason Merrill  

PR debug/45088
* decl.c (grokdeclarator): Strip the injected-class-name typedef
if we are building a declaration or compound type.

[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math

[wschmidt at gcc dot gnu.org]

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

--- Comment #10 from William J. Schmidt  
2012-04-16 12:16:04 UTC ---
Author: wschmidt
Date: Mon Apr 16 12:15:50 2012
New Revision: 186493

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186493
Log:
2012-04-16  Bill Schmidt  

PR tree-optimization/52976
* tree-ssa-reassoc.c (add_to_ops_vec_max_rank): New function.
(undistribute_ops_list): Ops with repeat counts aren't eligible for
undistribution.
(attempt_builtin_powi): Call add_to_ops_vec_max_rank.


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

[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors

[jjcogliati-r1 at yahoo dot com]

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

--- Comment #2 from Joshua Cogliati  2012-04-16 
12:16:45 UTC ---
Yes, it should also warn for non-constants, and also for other floating
decreases in accuracy such as: 

float foo(double x) {
  return x;
}

I should have time to create a patch for this before 4.8 goes into stage 3.  Do
you think it needs a copyright assignment and if so what paperwork would you
need from my employer?

[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

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

--- Comment #11 from William J. Schmidt  
2012-04-16 12:17:48 UTC ---
Fixed.

[Bug libstdc++/53006] New: libstdc++-prettyprinters/shared_ptr.cc FAILs

[ro at gcc dot gnu.org]

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

 Bug #: 53006
   Summary: libstdc++-prettyprinters/shared_ptr.cc FAILs
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: tro...@gcc.gnu.org
  Host: i386-pc-solaris2.11
Target: i386-pc-solaris2.11
 Build: i386-pc-solaris2.11


Since prettyprinters.exp has been enabled recently, the shared_ptr.cc test
FAILs on Solaris 11/x86 only:

FAIL: libstdc++-prettyprinters/shared_ptr.cc print esp
FAIL: libstdc++-prettyprinters/shared_ptr.cc print ewp1
FAIL: libstdc++-prettyprinters/shared_ptr.cc print ewp2
FAIL: libstdc++-prettyprinters/shared_ptr.cc print sp1
FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp1
FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp2

I'm using a 64-bit gdb 7.4 linked with the vendor-supplied libpython2.6.so
(same problem with libpython2.7.so).

In libstdc++.log, I find:

$1 = skipping: 80 return 0;^M
Python Exception  expected string or buffer: ^M
Python Exception  expected string or buffer: ^M
got: $1 = Python Exception  expected string or
buffer: ^M
FAIL: libstdc++-prettyprinters/shared_ptr.cc print esp
skipping: Python Exception  expected string or
buffer: ^M
std::shared_ptr (empty) 0x0^M

Manually running gdb with the equivalent of the generated shared_ptr.gdb file,
I
get:

(gdb) print esp
Python Exception  expected string or buffer: 
Python Exception  expected string or buffer: 
$1 = std::shared_ptr (empty) 0x0

Unfortunately, expect/dejagnu merge stdout and stderr here, causing the mixture
of both streams.

When I set python print-stack full first, I get:

(gdb) print esp
$1 = Traceback (most recent call last):
  File
"/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/../python/libstdcxx/v6/printers.py",
line 777, in __call__
match = self.compiled_rx.match(typename)
TypeError: expected string or buffer

Traceback (most recent call last):
  File
"/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/../python/libstdcxx/v6/printers.py",
line 777, in __call__
match = self.compiled_rx.match(typename)
TypeError: expected string or buffer
std::shared_ptr (empty) 0x0

I cannot really make sense of that (barely knowing python), but if I add

print type(typename)

in printers.py, I find:



Strangely, the same gdb binary works on Solaris 10 with the bundled
libpython2.6.so, so this might be a bug in that library on Solaris 11.

Suggestions?

  Rainer

[Bug libstdc++/53006] libstdc++-prettyprinters/shared_ptr.cc FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-04-16 12:27:06 UTC ---
> Strangely, the same gdb binary works on Solaris 10 with the bundled
> libpython2.6.so, so this might be a bug in that library on Solaris 11.

Indeed when I point gdb at a copy of the Solaris 10 libpython2.6.so on
Solaris 11 via LD_LIBRARY_PATH_64, the test passes as well ;-(  Seems
like a bug in the Solaris 11 libpython, after all.

Rainer

[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  2012-04-16 
12:36:59 UTC ---
(In reply to comment #2)
> I should have time to create a patch for this before 4.8 goes into stage 3.  
> Do
> you think it needs a copyright assignment and if so what paperwork would you
> need from my employer?

I am afraid so. See:
https://www.gnu.org/prep/maintain/maintain.html#Legal-Matters

Write to g...@gcc.gnu.org asking for the documents. There are several people
there dealing with this matter. Also, let us know if you find any problems.

[Bug fortran/51081] Proc-pointer assignment: Rejects valid internal proc, -std=f2008 should mention "F2008"

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-16
 Ever Confirmed|0   |1

--- Comment #4 from janus at gcc dot gnu.org 2012-04-16 12:37:26 UTC ---
(In reply to comment #0)
> Compiling with -std=2003 just prints:
> 
>   Error: Internal procedure 'int' is invalid
>  in procedure pointer assignment at (1)

This is of course easily fixed:

Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 186485)
+++ gcc/fortran/expr.c(working copy)
@@ -3444,9 +3444,10 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_ex
   return FAILURE;
 }
   if (attr.proc == PROC_INTERNAL &&
-  gfc_notify_std (GFC_STD_F2008, "Internal procedure '%s' is "
-  "invalid in procedure pointer assignment at %L",
-  rvalue->symtree->name, &rvalue->where) == FAILURE)
+  gfc_notify_std (GFC_STD_F2008, "Fortran 2008: Internal procedure "
+  "'%s' is invalid in procedure pointer assignment "
+  "at %L", rvalue->symtree->name, &rvalue->where)
+  == FAILURE)
 return FAILURE;
 }
   /* Check for F08:C730.  */



An alternative would be to add the correct label automatically inside
'gfc_notify_std', based on the value of 'GFC_STD_*' passed.

[Bug tree-optimization/53007] New: [4.8 REGRESSION] ICE verify_ssa failed with -Ofast and lto

[vincenzo.innocente at cern dot ch]

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

 Bug #: 53007
   Summary: [4.8 REGRESSION] ICE verify_ssa failed with -Ofast and
lto
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


Created attachment 27168
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27168
tar compressed directory  containing the "test case"

I'm sure it was not the case with
gcc version 4.8.0 20120403 (experimental) (GCC) 

being in lto not easy to produce a reduced test case:
attached the whole directory

tar -zxf buggy.tgz
cd buggy
c++ -Ofast *.c 
[innocent@vinavx0 buggy]$ c++ -O3 *.c -flto
[innocent@vinavx0 buggy]$ c++ -Ofast *.c -flto
In file included from :6:0:
kernel.c: In function 'kernel_measureLU':
kernel.c:188:12: error: definition in block 26 follows the use
 double kernel_measureLU(int N, double min_time, Random R)
^
for SSA_NAME: reassocpow.3_161 in statement:
D.2821_127 = reassocpow.3_161 *
6.6662965923251249478198587894439697265625e-1;
kernel.c:188:12: internal compiler error: verify_ssa failed
 double kernel_measureLU(int N, double min_time, Random R)
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: c++ returned 1 exit status
collect2: error: lto-wrapper returned 1 exit status
[innocent@vinavx0 buggy]$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/afs/cern.ch/user/i/innocent/w2
--enable-languages=c,c++,fortran -enable-gold=yes --enable-lto
--with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64
--with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64
--enable-cloog-backend=isl --with-cloog=/usr/local
--with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC'
CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden -march=native'
-enable-libitm -disable-multilib
Thread model: posix
gcc version 4.8.0 20120416 (experimental) (GCC)

[Bug c/52977] [4.8 Regression] internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2012-04-16 
13:21:37 UTC ---
Author: rguenth
Date: Mon Apr 16 13:21:30 2012
New Revision: 186494

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186494
Log:
2012-04-16  Richard Guenther  

PR middle-end/52977
* tree.h (VECTOR_CST_NELTS): Adjust.
(struct tree_vector): Add explicit length field.
(make_vector_stat): Declare.
(make_vector): Define.
* tree.c (make_vector_stat): New function.
(build_vector_stat): Use it.
* tree-streamer-in.c (streamer_alloc_tree): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-streamer-in.c
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||vincenzo.innocente at cern
   ||dot ch

--- Comment #12 from Richard Guenther  2012-04-16 
13:22:49 UTC ---
*** Bug 53007 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/53007] [4.8 REGRESSION] ICE verify_ssa failed with -Ofast and lto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Richard Guenther  2012-04-16 
13:22:49 UTC ---
Duplicate.

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

[Bug c++/51148] [C++0x] Unexpanded template param packs wrongly accepted in friend class declarations

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[michael.haubenwallner at salomon dot at]

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

--- Comment #37 from Michael Haubenwallner  2012-04-16 13:29:06 UTC ---
A few more references:
The fix for this one issue is:
https://www-304.ibm.com/support/docview.wss?uid=isg1IZ98134

But this introduces /usr/ccs/bin/as coredump during gcc bootstrap
(strstream.o):
https://www-304.ibm.com/support/docview.wss?uid=isg1IV01126

Just guessing, but maybe the whole thing was introduced by:
https://www-304.ibm.com/support/docview.wss?uid=isg1IZ87535

Based on the filesets shown in the APARs for each AIX release/TL/SP, here's a
list of maybe broken/working AIX levels, although I'm unable to verify for
sure, as the broken machines got the interim fix installed here for IV01126
(supersedes interim fix for IZ98134):

 +--++
 | broken since |  fixed since   |
-+--++
AIX 5.3 TL9  ||
TL10 |  SP6 (1107)  |  |
TL11 |  SP6 (1107)  |   SP8 (1140)   |
TL12 |  SP3 (1107)  |   SP5 (1140)   |
-+--++
AIX 6.1 TL2  ||
TL3  |  SP9 (1112)  |  |
TL4  |  SP9 (1112)  |   SP11 (1140)  |
TL5  |  SP5 (1112)  |   SP7  (1140)  |
TL6  |  SP4 (1112)  |   SP6  (1140)  |
TL7  ||
-+--++
AIX 7.1 TL0  |  SP3 (1115)  |  |
TL1  ||
-+--++

Even if AIX 7.1 TL0 SP4 was released at 1140 too, it doesn't seem to contain
IV01126 - maybe TL0 SP5 will do.

[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka  2012-04-16 13:50:35 UTC 
---
How common is this construction in practice?  Adding a warning or making GCC to
imply used attribute is same amount of work - it means teaching GCC about those
and possibly others special purpose sections.  Or alternatively declare all
named sections special purpose and implicitely used.

The code is not conforming any standards.  In past we started taking away
unused
variables/functions that also broke asm constructs and required annotations
without
making an attempt for GCC to parse asm statements.

Section names are easier to parse, indeed, but still the situation is very
symmetric
here.

Honza

[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math

[vincenzo.innocente at cern dot ch]

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

--- Comment #13 from vincenzo Innocente  
2012-04-16 13:53:30 UTC ---
I confirm that "revision 186494" fixed PR53007.
btw:
would it be possible to add the revision number to the oyuout of "c++ -v"?
the current "version id" 
gcc version 4.8.0 20120416 (experimental) (GCC) 
does not uniquely identify the content of the build…

[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math

[rguenther at suse dot de]

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

--- Comment #14 from rguenther at suse dot de  
2012-04-16 13:55:58 UTC ---
On Mon, 16 Apr 2012, vincenzo.innocente at cern dot ch wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52976
> 
> --- Comment #13 from vincenzo Innocente  
> 2012-04-16 13:53:30 UTC ---
> I confirm that "revision 186494" fixed PR53007.
> btw:
> would it be possible to add the revision number to the oyuout of "c++ -v"?
> the current "version id" 
> gcc version 4.8.0 20120416 (experimental) (GCC) 
> does not uniquely identify the content of the build...

It does if you use ./contrib/gcc_update

[Bug c++/51148] [C++0x] Unexpanded template param packs wrongly accepted in friend class declarations

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2012-04-16 
14:15:45 UTC ---
Author: jason
Date: Mon Apr 16 14:15:36 2012
New Revision: 186495

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186495
Log:
PR c++/51148
* friend.c (make_friend_class): Call check_for_bare_parameter_packs.

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

[Bug c++/51148] [C++0x] Unexpanded template param packs wrongly accepted in friend class declarations

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  2012-04-16 
14:24:09 UTC ---
Fixed for 4.8.

[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array

[krisztian.kocsis at optimaster dot eu]

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

--- Comment #6 from Krisztian Kocsis  
2012-04-16 14:35:37 UTC ---
I currently know that glibc uses it but don't know who else use it.
In my projects I always use constructor/destructor attributes because with them
I can control the exection order.

[Bug libitm/53008] New: abort in _ITM_getTMCloneSafe

[daveboutcher at gmail dot com]

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

 Bug #: 53008
   Summary: abort in _ITM_getTMCloneSafe
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libitm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daveboutc...@gmail.com


Created attachment 27169
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27169
testcase for abort in _ITM_getTMCloneSafe

Abort in _ITM_getTMCloneSafe() within atomic transaction calling a function via
a function pointer.  The abort only appears to happen if the function pointer
is defined as __attribute__((transaction_safe)).  Only happens at -O2 and
above.

Fairly minimal testcase attached.

[Bug target/51819] [4.7 Regression] Neon wrong code generation, Error: unsupported alignment for instruction -- `vst1.32 {d2[0]},[r0:64]'

[uweigand at gcc dot gnu.org]

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

--- Comment #6 from Ulrich Weigand  2012-04-16 
15:19:47 UTC ---
Author: uweigand
Date: Mon Apr 16 15:19:43 2012
New Revision: 186498

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186498
Log:
2012-04-16  Ulrich Weigand  

PR target/51819
* config/arm/arm.c (arm_print_operand): Fix invalid alignment
hints for 'A' operand types.

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

[Bug c++/50303] [C++0x] Segfault with variadic template template parameters

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[paolo at gcc dot gnu.org]

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

--- Comment #40 from paolo at gcc dot gnu.org  
2012-04-16 15:32:28 UTC ---
Author: paolo
Date: Mon Apr 16 15:32:22 2012
New Revision: 186499

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186499
Log:
/cp
2012-04-16  Paolo Carlini  

PR c++/49152
* call.c (op_error): Print types; when flag_diagnostics_show_caret
is false print expressions too.
(op_error_string): Add.

/testsuite
2012-04-16  Paolo Carlini  

PR c++/49152
* g++.dg/diagnostic/operator1.C: New.
* g++.dg/ext/label5.C: Adjust.
* g++.dg/ext/va-arg1.C: Likewise.
* g++.dg/other/error20.C: Likewise.
* g++.dg/other/error20.C: Likewise.
* g++.dg/other/error16.C: Likewise.
* g++.dg/other/error10.C: Likewise.
* g++.dg/parse/error30.C: Likewise.
* g++.dg/cpp0x/lambda/lambda-err1.C: Likewise.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-err1.C
trunk/gcc/testsuite/g++.dg/ext/label5.C
trunk/gcc/testsuite/g++.dg/ext/va-arg1.C
trunk/gcc/testsuite/g++.dg/other/error10.C
trunk/gcc/testsuite/g++.dg/other/error16.C
trunk/gcc/testsuite/g++.dg/other/error20.C
trunk/gcc/testsuite/g++.dg/parse/error30.C

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #41 from Paolo Carlini  2012-04-16 
15:36:07 UTC ---
Done.

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[redi at gcc dot gnu.org]

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

--- Comment #42 from Jonathan Wakely  2012-04-16 
15:47:37 UTC ---
Awesome, thank you very very much, Paolo and Manu.

The example in comment 23 can now be added to
http://gcc.gnu.org/wiki/ClangDiagnosticsComparison ;)

[Bug c++/50830] [c++0x] Variadic template, inner class error

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/52932] AVX2 intrinsic _mm256_permutevar8x32_ps has wrong parameter type

[uros at gcc dot gnu.org]

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

--- Comment #13 from uros at gcc dot gnu.org 2012-04-16 16:03:55 UTC ---
Author: uros
Date: Mon Apr 16 16:03:51 2012
New Revision: 186500

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186500
Log:
2012-04-16  Uros Bizjak  

Backport from mainline
2012-04-12  Uros Bizjak  

PR target/52932
* config/i386/avx2intrin.h (_mm256_permutevar8x32_ps): Change second
argument type to __m256i.  Update call to __builtin_ia32_permvarsf256.
* config/i386/sse.md (avx2_permvarv8sf): Change operand 1 to V8SI.
(avx2_permvarv8sf, avx2_permvarv8si): Switch operands 1 and 2.
* config/i386/i386.c (bdesc_args) <__builtin_ia32_permvarsf256>:
Update builtin type to V8SF_FTYPE_V8SF_V8SI.
(ix86_expand_vec_perm): Update calls to gen_avx2_permvarv8si and
gen_avx2_permvarv8sf.

testsuite/ChangeLog:

2012-04-16  Uros Bizjak  

Backport from mainline
2012-04-12  Uros Bizjak  

PR target/52932
* gcc.target/i386/avx2-vpermps-1.c (avx2_test): Use __m256i type for
second function argument.
* gcc.target/i386/avx2-vpermps-2.c (init_permps): Update declaration.
(calc_permps): Update declaration.  Calculate result correctly.
(avx2_test): Change src2 type to union256i_d.
* gcc.target/i386/avx2-vpermd-2.c (calc_permd): Calculate result
correctly.


Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/i386/avx2intrin.h
branches/gcc-4_7-branch/gcc/config/i386/i386.c
branches/gcc-4_7-branch/gcc/config/i386/sse.md
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/avx2-vpermd-2.c
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/avx2-vpermps-1.c
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/avx2-vpermps-2.c

[Bug target/52932] AVX2 intrinsic _mm256_permutevar8x32_ps has wrong parameter type

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #14 from Uros Bizjak  2012-04-16 16:05:00 
UTC ---
Fixed.

[Bug c++/53009] New: pointer to static member function of template class is “invalid” as a template argument of another template class

[blaffablaffa at gmail dot com]

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

 Bug #: 53009
   Summary: pointer to static member function of template class is
“invalid” as a template argument of another template
class
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: blaffabla...@gmail.com


I believe that this bug is somewhat related to #35167: probably g++ thinks that
the address of a static member function of a template class is not a constant
expression, whereas it is. I'm filing a new bug though because the situation
here involves two distinct class templates, the error message is different
("error: template argument 2 is invalid", not helpful at all), and because it's
said in the comments of #35167 that it's fixed if C++11 is used, whereas my
testcase is compiled with and needs C++11 (for variadic templates).

Fails to build with g++ 4.6.2 4.5.4 4.4.6.

[Bug c++/53009] pointer to static member function of template class is “invalid” as a template argument of another template class

[blaffablaffa at gmail dot com]

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

--- Comment #1 from Lorenzo Pistone  2012-04-16 
16:09:16 UTC ---
Created attachment 27170
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27170
testcase

[Bug c++/53009] pointer to static member function of template class is “invalid” as a template argument of another template class

[blaffablaffa at gmail dot com]

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

--- Comment #2 from Lorenzo Pistone  2012-04-16 
16:22:04 UTC ---
I just tested, the problem happens only if the template arguments of
function_proxy are function pointers. More trivial types (int is what I've
tested) just work fine

[Bug c++/49152] pretty printer cannot handle iterators and other complex expressions

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |
 AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot
   |com |gnu.org
Summary|Unhelpful diagnostic for|pretty printer cannot
   |iterator dereference|handle iterators and other
   ||complex expressions

--- Comment #43 from Manuel López-Ibáñez  2012-04-16 
16:26:09 UTC ---
Thanks Paolo. It is nice that by default, we do not print these monsters
anymore. But the pretty-printer is still broken, and the diagnostic is still
broken for -fno-diagnostics-show-caret. So let's keep it around in case someone
decides to fix that or Gabriel changes his mind.

(In any case, I don't expect anyone to fix this any year soon now that it is
not the default anymore, so it should have the lowest priority possible.)

[Bug c++/52008] [C++0x] ICE when adding partial specialization for variadic-templated structure

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  2012-04-16 
16:51:08 UTC ---
This example is problematic because the partial specialization is not more
specialized than the primary template; we should reject it with an error rather
than crashing.

[Bug c++/53009] pointer to static member function of template class is “invalid” as a template argument of another template class

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-16
 Ever Confirmed|0   |1

--- Comment #3 from Jonathan Wakely  2012-04-16 
16:53:46 UTC ---
reduced:

template class function_proxy;

template
struct function_proxy
{
static void wrapper(){ }
};

template class member_helper;

template
struct member_helper
{
static void as_free(Class& obj){ }

static void worker(){
//ERROR HERE: template argument 2 is invalid. Not very helpful message.
(void) function_proxy::wrapper;
}
};

struct Test
{
void test(){ }
};

int main()
{
//does not work
member_helper::worker();
}

[Bug c++/38543] [C++0x] Cannot specialize variadic template function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug libstdc++/53006] libstdc++-prettyprinters/shared_ptr.cc FAILs

[tromey at gcc dot gnu.org]

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

--- Comment #2 from Tom Tromey  2012-04-16 18:01:17 
UTC ---
(In reply to comment #0)

> match = self.compiled_rx.match(typename)

> print type(typename)
> 

This is very odd.  The code in context:

typename = self.get_basic_type(val.type)
if not typename:
return None

# All the types we match are template types, so we can use a
# dictionary.
match = self.compiled_rx.match(typename)

If typename is None, we should have taken the "return None" branch.

I tend to agree it is a python problem as you stated in comment #1.

[Bug c/53010] New: crash due to null ptr deref

[regehr at cs dot utah.edu]

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

 Bug #: 53010
   Summary: crash due to null ptr deref
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu


[regehr@dyson r35]$ current-gcc -m32 -O3 small.c -c
small.c: In function 'fn1':
small.c:3:1: internal compiler error: Segmentation fault
 fn1 ()
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


[regehr@dyson r35]$ cat small.c
int a, b, c, d, e;
void
fn1 ()
{
d = 0;
for (; d <= 1; d++)
;
for (; a; a--)
e = d | b || c;
}


[regehr@dyson r35]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r186501-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r186501-install
--program-prefix=r186501- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120416 (experimental) (GCC)

[Bug c++/53011] New: ice in verify_loop_structure: bad sizes

[dcb314 at hotmail dot com]

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

 Bug #: 53011
   Summary: ice in verify_loop_structure: bad sizes
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com


Created attachment 27171
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27171
C++ source code

I just tried to compile the package libwvstreams-4.6.1-4
on gcc-4.8 trunk dated 20120415 on an AMD x86_64 box.

The compiler said

linuxstreams/wvinterface.cc: In member function 'int
WvInterface::delroute(const WvIPNet&, const WvIPAddr&, int, WvStringParm)':
linuxstreams/wvinterface.cc:479:5: error: size of loop 2 should be 0, not 1
 int WvInterface::delroute(const WvIPNet &dest, const WvIPAddr &gw,
 ^
linuxstreams/wvinterface.cc:479:5: error: bb 89 do not belong to loop 2
 int WvInterface::delroute(const WvIPNet &dest, const WvIPAddr &gw,
 ^
linuxstreams/wvinterface.cc:479:5: error: loop 2's header does not belong
directly to it
 int WvInterface::delroute(const WvIPNet &dest, const WvIPAddr &gw,
 ^
linuxstreams/wvinterface.cc:479:5: internal compiler error: in
verify_loop_structure, at cfgloop.c:1567
 int WvInterface::delroute(const WvIPNet &dest, const WvIPAddr &gw,
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source code attached. Flag -O2 required.

[Bug c++/53012] New: unrelated friend operators in same namespace interfere with operator resolution outside of namespace

[kalaxy at gmail dot com]

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

 Bug #: 53012
   Summary: unrelated friend operators in same namespace interfere
with operator resolution outside of namespace
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kal...@gmail.com


This code fails to compile because of "error: no match for ‘operator<<’ in
‘std::cout << val’":

#include 

namespace one {
class A { };
}

std::ostream& operator<<(std::ostream& os, const ::one::A& ) {
return os << __PRETTY_FUNCTION__;
}


namespace two {
class unrelated_a {
friend std::ostream& operator<< ( std::ostream& out, const unrelated_a&
);
};

class unrelated_b {
friend std::ostream& operator<< ( std::ostream& out, const unrelated_b&
);
};

void output( const one::A& val )
{
std::cout << val << std::endl;
}
}

int main() {
one::A obj ;
two::output( obj );
return 0;
}


Ways to make it compile as expected:
A) remove either of the two (or both) unrelated class friend operators.
B) Move two::output outside of the two namespace.
C) use clang (not trying to be overly snarky here but being unsure myself if it
should be valid code I compiled it using clang with success.)

I've tried this on 4.6.3 and 4.7 with the same results.
$ g++ -v
Using built-in specs.
COLLECT_GCC=./usr/bin/g++
COLLECT_LTO_WRAPPER=/mnt/gcc-4.7/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7.0/configure --prefix=/mnt/gcc-4.7/usr/ :
(reconfigured) ../gcc-4.7.0/configure --prefix=/mnt/gcc-4.7/usr/
--disable-multilib --enable-languages=c++
Thread model: posix
gcc version 4.7.0 (GCC) 


command to reproduce:
./usr/bin/g++ namespace_pain.cpp

compiler output:
namespace_pain.cpp: In function ‘void two::output(const one::A&)’:
namespace_pain.cpp:28:16: error: no match for ‘operator<<’ in ‘std::cout <<
val’
namespace_pain.cpp:28:16: note: candidates are:



alternate command to reproduce:
./usr/bin/g++ namespace_pain.cpp --std=c++11

compiler output for alternate command:
namespace_pain.cpp: In function ‘void two::output(const one::A&)’:
namespace_pain.cpp:28:16: error: cannot bind ‘std::ostream {aka
std::basic_ostream}’ lvalue to ‘std::basic_ostream&&’
In file included from
/mnt/gcc-4.7/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/iostream:40:0,
 from namespace_pain.cpp:1:
/mnt/gcc-4.7/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ostream:600:5:
error:   initializing argument 1 of ‘std::basic_ostream<_CharT, _Traits>&
std::operator<<(std::basic_ostream<_CharT, _Traits>&&, const _Tp&) [with _CharT
= char; _Traits = std::char_traits; _Tp = one::A]’

[Bug c++/41933] [c++0x] lambdas and variadic templates don't work together

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  2012-04-16 
19:21:13 UTC ---
Created attachment 27172
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27172
incomplete patch

Here's the beginning of work to implement this.  A lot more will be needed.

[Bug c++/53011] ice in verify_loop_structure: bad sizes

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #1 from Markus Trippelsdorf  
2012-04-16 19:35:42 UTC ---
Somewhat reduced:

 % cat test.ii
extern "C" class WvFastString;
typedef WvFastString& WvStringParm;
struct WvFastString {
  ~WvFastString();
  operator char* () {}
};
class WvString : WvFastString {};
class WvAddr {};
class WvIPAddr : WvAddr {};
struct WvIPNet : WvIPAddr {
  bool is_default() {}
};
template struct WvTraits_Helper {
  static void release(T *obj) {
delete obj;
  }
};
template struct WvTraits {
  static void release(From *obj) {
WvTraits_Helper::release(obj);
  }
};
struct WvLink {
  void   *data;
  WvLink *next;
  boolautofree;
  WvLink(bool, int) : autofree() {}
  bool get_autofree() {}

  void unlink() {
delete this;
  }
};
struct WvListBase {
  WvLink head, *tail;
  WvListBase() : head(0, 0) {}
};
template struct WvList : WvListBase {
  ~WvList() {
zap();
  }

  void zap(bool destroy = 1) {
while (head.next) unlink_after(&head, destroy);
  }

  void unlink_after(WvLink *after, bool destroy) {
WvLink *next = 0;
T *obj   = (destroy && next->get_autofree()) ? 
   static_cast(next->data) : 0;

if (tail) tail = after;
next->unlink();
WvTraits::release(obj);
  }
};
typedef WvListWvStringListBase;
class WvStringList : WvStringListBase {};
class WvSubProc {
  WvStringList last_args, env;
};
void addroute(WvIPNet& dest, WvStringParm table) {
  if (dest.is_default() || (table != "default")) WvSubProc checkProc;
}

 % g++ -c -O1 test.ii
test.ii: In function ‘void addroute(WvIPNet&, WvStringParm)’:
test.ii:64:1: internal compiler error: Segmentation fault

[Bug c++/53011] ice in verify_loop_structure: bad sizes

[markus at trippelsdorf dot de]

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

--- Comment #2 from Markus Trippelsdorf  
2012-04-16 19:59:38 UTC ---
create_preheader (loop=0x77452440, flags=) at
/home/markus/gcc/gcc/cfgloopmanip.c:1391
1391  latch_edge_was_fallthru = (mfb_kj_edge->flags & EDGE_FALLTHRU) != 0;
(gdb) bt
#0  create_preheader (loop=0x77452440, flags=) at
/home/markus/gcc/gcc/cfgloopmanip.c:1391
#1  0x00607838 in create_preheaders (flags=1) at
/home/markus/gcc/gcc/cfgloopmanip.c:1443
#2  0x0074e417 in loop_optimizer_init (flags=flags@entry=7) at
/home/markus/gcc/gcc/loop-init.c:89
#3  0x0074e4ef in rtl_loop_init () at
/home/markus/gcc/gcc/loop-init.c:210
#4  0x0078dec8 in execute_one_pass (pass=pass@entry=0x1074880) at
/home/markus/gcc/gcc/passes.c:2176
#5  0x0078e225 in execute_pass_list (pass=0x1074880) at
/home/markus/gcc/gcc/passes.c:2231
#6  0x0078e237 in execute_pass_list (pass=0x10748e0) at
/home/markus/gcc/gcc/passes.c:2232
#7  0x0078e237 in execute_pass_list (pass=0x1074cc0) at
/home/markus/gcc/gcc/passes.c:2232
#8  0x00612c69 in tree_rest_of_compilation (node=)
at /home/markus/gcc/gcc/cgraphunit.c:1898
#9  0x006157d2 in cgraph_expand_function (node=0x77412720) at
/home/markus/gcc/gcc/cgraphunit.c:1968
#10 0x00616c28 in cgraph_expand_all_functions () at
/home/markus/gcc/gcc/cgraphunit.c:2033
#11 cgraph_optimize () at /home/markus/gcc/gcc/cgraphunit.c:2724
#12 0x0061749a in cgraph_finalize_compilation_unit () at
/home/markus/gcc/gcc/cgraphunit.c:2809
#13 0x004f1b2f in cp_write_global_declarations () at
/home/markus/gcc/gcc/cp/decl2.c:4072
#14 0x0081fbd8 in compile_file () at /home/markus/gcc/gcc/toplev.c:572
#15 do_compile () at /home/markus/gcc/gcc/toplev.c:1938
#16 toplev_main (argc=13, argv=0x7fffe438) at
/home/markus/gcc/gcc/toplev.c:2014
#17 0x77893675 in __libc_start_main (main=0x5c1b40 , argc=13,
ubp_av=0x7fffe438, init=, fini=, 
rtld_fini=, stack_end=0x7fffe428) at libc-start.c:225
#18 0x00492369 in _start () at ../sysdeps/x86_64/start.S:116

[Bug c++/53012] unrelated friend operators in same namespace interfere with operator resolution outside of namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-16
 Ever Confirmed|0   |1

[Bug c/53013] New: Inconsistent Behaviour with Left Shift Operator.

[john.stevens at f5 dot com]

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

 Bug #: 53013
   Summary: Inconsistent Behaviour with Left Shift Operator.
Classification: Unclassified
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: john.stev...@f5.com


In this example:

#include
#include
#include

#define ALL_KEY_BITS(~ (uint32_t) 0)

int
main(
int argc,
char**argv )
{
registeruint32_ti;

printf(
"Size: %d\n",
sizeof( 32LU ) );
printf(
"Mask (<< %lu): 0x%lx\n",
32LU,
ALL_KEY_BITS << 32LU );
i = 32LU;
printf(
"Mask (<< %lu): 0x%lx\n",
i,
ALL_KEY_BITS << i );
}

The result is:

Size: 4
Mask (<< 32): 0x0
Mask (<< 32): 0x

While the above code is undefined by the standard, it would be preferable to
have consistent behaviour between shifting by a constant, or by a variable.

A result of all zero would give the least surprising result; if you start with
an unsigned value with only the top bit set, and shift it left by one, the
result is zero.  Start with one, shift it left by one in a loop where the
iteration count is the number of bits in the data, you get zero.

[Bug c/53013] Inconsistent Behaviour with Left Shift Operator.

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #1 from Manuel López-Ibáñez  2012-04-16 
21:16:48 UTC ---
Sorry, you cannot expect consistency from undefined behaviour. It doesn't work
that way: http://c-faq.com/ansi/undef.html

And if you want to know why:
http://www.eskimo.com/~scs/readings/undef.950321.html

[Bug c++/52849] crash when using subscript operator in decltype argument

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2012-04-16 
21:27:18 UTC ---
Really, 4.4.x is very old, especially in terms of C++11 features. Current
mainline, 4.7.0 and 4.6.x have no problems with the testcase.

[Bug c++/52849] crash when using subscript operator in decltype argument

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #4 from Paolo Carlini  2012-04-16 
21:27:43 UTC ---
.

[Bug fortran/52916] [4.8 Regression] 481.wrf in SPEC CPU 2006 failed to build

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  2012-04-16 
21:38:53 UTC ---
Author: burnus
Date: Mon Apr 16 21:38:49 2012
New Revision: 186506

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186506
Log:
2012-04-16  Tobias Burnus  

PR fortran/52916
* gfortran.dg/public_private_module_3.f90: Use dg-additional-sources
to include public_private_module_4.f90.
* gfortran.dg/public_private_module_4.f90: Skip this test on all
targets


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/public_private_module_3.f90
trunk/gcc/testsuite/gfortran.dg/public_private_module_4.f90

[Bug c/53013] Inconsistent Behaviour with Left Shift Operator.

[john.stevens at f5 dot com]

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

--- Comment #2 from john.stevens at f5 dot com 2012-04-16 21:47:11 UTC ---
I would respectfully point out that "consistent", and "undefined by the
standard", are two different things.

I can expect consistent behavior that is not defined by the standard, but I
agree that I may not expect that that behavior will be defined by the standard,
nor that it will remain the same from one version to the next, only that the
result generated by the same operation will give the same,
undefined-by-the-standard, but consistent result.

IOW, "undefined" means the standard deliberately refuses to make a statement
about a real thing, it does not mean that the thing is not real.  The
difference here is akin to the difference between Philosophy and Natural
Philosophy (Natural Philosophy being a proper subset of Philosophy that
deliberately refrains from discussing real things that are outside the realm of
Natural Philosophy).

Thanks,
John S.

-Original Message-
From: manu at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Monday, April 16, 2012 2:17 PM
To: John Stevens
Subject: [Bug c/53013] Inconsistent Behaviour with Left Shift Operator.

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #1 from Manuel López-Ibáñez  2012-04-16
21:16:48 UTC --- Sorry, you cannot expect consistency from undefined behaviour.
It doesn't work that way: http://c-faq.com/ansi/undef.html

And if you want to know why:
http://www.eskimo.com/~scs/readings/undef.950321.html

--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: --- You reported the bug.

[Bug fortran/52864] [4.6/4.7/4.8 Regression] Assignment to pointer component for INTENT(IN) dummy argument

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2012-04-16 
21:47:39 UTC ---
Author: burnus
Date: Mon Apr 16 21:47:35 2012
New Revision: 186507

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186507
Log:
2012-04-12  Tobias Burnus  

PR fortran/52864
* expr.c (gfc_check_vardef_context): Fix assignment check for
pointer components.

2012-04-16  Tobias Burnus  

PR fortran/52864
* gfortran.dg/pointer_intent_6.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/pointer_intent_6.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/49565] character(kind=4) is emitted as DW_ATE_unsigned, not DW_ATE_unsigned_char

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2012-04-16 
22:04:20 UTC ---
See also http://www.dwarfstd.org/ShowIssue.php?issue=120213.1