[Bug middle-end/57586] ICE when expanding volatile asm using unaligned pointer

[amodra at gmail dot com]

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

Alan Modra amodra at gmail dot com changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
 CC||amodra at gmail dot com
  Component|target  |middle-end
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com
   Severity|major   |normal

[Bug fortran/57596] Wrong code for allocatable deferred-length strings

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org ---
Author: burnus
Date: Fri Jun 14 07:41:42 2013
New Revision: 200084

URL: http://gcc.gnu.org/viewcvs?rev=200084root=gccview=rev
Log:
2013-06-14  Tobias Burnus  bur...@net-b.de

PR fortran/57596
* trans-decl.c (gfc_trans_deferred_vars): Honor OPTIONAL
for nullify and deferred-strings' length variable.

2013-06-14  Tobias Burnus  bur...@net-b.de

PR fortran/57596
* gfortran.dg/deferred_type_param_9.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/deferred_type_param_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/57596] Wrong code for allocatable deferred-length strings

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org ---
FIXED on the trunk (4.9).

Thanks for the report!

[Bug fortran/45170] [F2003] allocatable character lengths

[burnus at gcc dot gnu.org]

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

Bug 45170 depends on bug 57596, which changed state.

Bug 57596 Summary: Wrong code for allocatable deferred-length strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57596

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug target/57608] [4.8/4.9 Regression] wrong code for expression at -O3 on x86_64-linux-gnu with -m32

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-14
 CC||jakub at gcc dot gnu.org
Summary|wrong code for expression   |[4.8/4.9 Regression] wrong
   |at -O3 on x86_64-linux-gnu  |code for expression at -O3
   |with -m32   |on x86_64-linux-gnu with
   ||-m32
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
Started with r193553.

[Bug target/57608] [4.8/4.9 Regression] wrong code for expression at -O3 on x86_64-linux-gnu with -m32

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.8.2

[Bug target/57608] [4.8/4.9 Regression] wrong code for expression at -O3 on x86_64-linux-gnu with -m32

[hubicka at gcc dot gnu.org]

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

Jan Hubicka hubicka at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||hubicka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org

--- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org ---
mine :(

[Bug tree-optimization/57608] [4.8/4.9 Regression] wrong code for expression at -O3 on x86_64-linux-gnu with -m32

[rguenth at gcc dot gnu.org]

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||i?86-*-*
 CC||rguenth at gcc dot gnu.org
  Component|target  |tree-optimization

--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
I'm sure PRE is only the enabler, not the culprit here, is it?

[Bug c++/57599] result of dynamic_castcv T is just T

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

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

--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com ---
Fixed for 4.9.0.

[Bug c++/57593] Friendship not extended into friend member-declaration

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
If a defect report has been submitted, then we should add its number to the
Subject of this bug and suspend it immediately. Do you have the number?

[Bug c++/57599] result of dynamic_castcv T is just T

[abel at gcc dot gnu.org]

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

--- Comment #7 from Andrey Belevantsev abel at gcc dot gnu.org ---
(In reply to Paolo Carlini from comment #6)
 Fixed for 4.9.0.

Do you plan to backport this to 4.7 and 4.8?

[Bug bootstrap/57604] LRA related bootstrap comparison failure on s390x --with-arch=zEC12

[krebbel at gcc dot gnu.org]

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

--- Comment #1 from Andreas Krebbel krebbel at gcc dot gnu.org ---
This is caused by a miscompilation of cp/lex.c:

#define DEF_OPERATOR(NAME, CODE, MANGLING, ARITY, ASSN_P)\
  sprintf (buffer, ISALPHA (NAME[0]) ? operator %s : operator%s, NAME); \
  identifier = get_identifier (buffer);\
...

The problem is that during LRA an add insn is being generated which is placed
between the ISALPHA check and the conditional load for the format string. 
The ADD which is generated clobbers the condition code why DSE later removes
the ISALPHA check completely.

When generating the ADD LRA probably needs to check whether it will break
dataflow. On S/390 we can do such address calculations without clobbering CC by
using the load address instruction. Unfortunately la cannot be used for generic
add patterns when generating 32 bit code since it only deals with the lower 31
bits.

Breakpoint 1, make_insn_raw (pattern=0x3fff6195580) at
/home/andreas/clean/gcc-head/gcc/emit-rtl.c:3651
3651  insn = rtx_alloc (INSN);
(gdb) p debug_rtx(pattern)
(parallel [
(set (reg:DI 3022)
(plus:DI (reg/f:DI 34 %fp)
(const_int 176 [0xb0])))
(clobber (reg:CC 33 %cc))
])
$1 = void
(gdb) bt
#0  make_insn_raw (pattern=0x3fff6195580) at
/home/andreas/clean/gcc-head/gcc/emit-rtl.c:3651
#1  0x805b4578 in emit_insn (x=0x3fff6195580) at
/home/andreas/clean/gcc-head/gcc/emit-rtl.c:4736
#2  0x807d5e74 in lra_emit_add (x=0x3fff7a079c0, y=0x3fff78754c0,
z=0x3fff632a630) at /home/andreas/clean/gcc-head/gcc/lra.c:266
#3  0x807d656e in lra_emit_move (x=0x3fff7a079c0, y=0x3fff6199600) at
/home/andreas/clean/gcc-head/gcc/lra.c:415
#4  0x807eb7fa in curr_insn_transform() ()
#5  0x807ed45c in lra_constraints(bool) ()
#6  0x807dc616 in lra (f=0x816a46f0) at
/home/andreas/clean/gcc-head/gcc/lra.c:2278
#7  0x807845a6 in do_reload () at
/home/andreas/clean/gcc-head/gcc/ira.c:4641
#8  0x8078485e in rest_of_handle_reload () at
/home/andreas/clean/gcc-head/gcc/ira.c:4753
#9  0x8085a4b2 in execute_one_pass (pass=0x81359060 pass_reload) at
/home/andreas/clean/gcc-head/gcc/passes.c:2337
#10 0x8085a76a in execute_pass_list (pass=0x81359060 pass_reload) at
/home/andreas/clean/gcc-head/gcc/passes.c:2389
#11 0x8085a7b8 in execute_pass_list (pass=0x813597d0
pass_rest_of_compilation) at /home/andreas/clean/gcc-head/gcc/passes.c:2390
#12 0x804ece5e in expand_function (node=0x3fff62f1130) at
/home/andreas/clean/gcc-head/gcc/cgraphunit.c:1582
#13 0x804ed418 in expand_all_functions () at
/home/andreas/clean/gcc-head/gcc/cgraphunit.c:1686
#14 0x804ee00c in compile () at
/home/andreas/clean/gcc-head/gcc/cgraphunit.c:2020
#15 0x804ee1f0 in finalize_compilation_unit () at
/home/andreas/clean/gcc-head/gcc/cgraphunit.c:2097
#16 0x802667fc in cp_write_global_declarations () at
/home/andreas/clean/gcc-head/gcc/cp/decl2.c:4356
#17 0x80966c06 in compile_file () at
/home/andreas/clean/gcc-head/gcc/toplev.c:558
#18 0x809697e8 in do_compile () at
/home/andreas/clean/gcc-head/gcc/toplev.c:1872
#19 0x809699c4 in toplev_main (argc=32, argv=0x3fff138) at
/home/andreas/clean/gcc-head/gcc/toplev.c:1948
#20 0x004f6a8ec30c in __libc_start_main () from /lib64/libc.so.6
#21 0x801335aa in _start ()
(gdb)

[Bug tree-optimization/57358] segmentation fault with attribute(optimize(O0))

[jamborm at gcc dot gnu.org]

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

Martin Jambor jamborm at gcc dot gnu.org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2013-06/msg00666.htm
   ||l

--- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org ---
I have submitted a fix for the 4.8 branch here:

http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00663.html

and for the current trunk here:

http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00666.html

[Bug tree-optimization/57539] [4.9 Regression] ice in ipa_edge_duplication_hook

[jamborm at gcc dot gnu.org]

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

Martin Jambor jamborm at gcc dot gnu.org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2013-06/msg00661.htm
   ||l

--- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org ---
I have submitted the fix to the mailing list:

http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00661.html

[Bug c++/57599] result of dynamic_castcv T is just T

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com ---
No, because isn't a regression. If you care a lot about that, just ask on the
mailing list.

[Bug c++/48453] [C++0x] Invalid reference initialization via explicit conversion

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
It would be nice to have a DR # for this. In any case, if in practice the
compiler is already Ok, we can probably close it, right?

[Bug c++/48632] Internal compiler error when using OpenMP with template

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com ---
I suppose we can close this.

[Bug fortran/57508] [4.8/4.9 Regression] [OOP] Intrinsic assignment+defined-assignment for comps: PROCEDURE attribute of '_F.DA0' conflicts with VARIABLE attribute

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org ---
Author: burnus
Date: Fri Jun 14 11:24:27 2013
New Revision: 200089

URL: http://gcc.gnu.org/viewcvs?rev=200089root=gccview=rev
Log:
2013-06-14  Tobias Burnus  bur...@net-b.de

PR fortran/57508
* resolve.c (get_temp_from_expr): Don't copy function
result attributes to temporary.

2013-06-14  Tobias Burnus  bur...@net-b.de

PR fortran/57508
* gfortran.dg/defined_assignment_7.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/defined_assignment_7.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/57508] [4.8/4.9 Regression] [OOP] Intrinsic assignment+defined-assignment for comps: PROCEDURE attribute of '_F.DA0' conflicts with VARIABLE attribute

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org ---
FIXED - now also on the trunk; GCC 4.8 was fixed in comment 4.

At the end, the same patch was applied to the trunk as on the branch, cf.
http://gcc.gnu.org/ml/fortran/2013-06/msg00086.html

[Bug fortran/49074] [OOP] Defined assignment w/ CLASS arrays: Incomplete error message

[mikael at gcc dot gnu.org]

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

Mikael Morin mikael at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
Version|4.7.0   |4.9.0
 Resolution|--- |FIXED

--- Comment #13 from Mikael Morin mikael at gcc dot gnu.org ---
FIXED again.

[Bug bootstrap/57609] New: S/390 ESA mode bootstrap failure since r197266

[krebbel at gcc dot gnu.org]

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

Bug ID: 57609
   Summary: S/390 ESA mode bootstrap failure since r197266
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org

cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mlong-double-128 -mesa
-m31 -march=g5 -auxbase-strip _negdi2.o -g -g -g -O2 -O2 -O2 -Wextra -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -version -fbuilding-libgcc
-fno-stack-protector -fPIC -fvisibility=hidden -o libgcc2.s


Program received signal SIGSEGV, Segmentation fault.
0x70685820 in ?? ()
(gdb) bt
#0  0x70685820 in ?? ()
#1  0x006cc074 in fold_binary_loc(unsigned int, tree_code, tree_node*,
tree_node*, tree_node*) ()
#2  0x00714c20 in fold(tree_node*) ()
#3  0x00537e0c in c_fully_fold_internal(tree_node*, bool, bool*, bool*) ()
#4  0x00538998 in c_fully_fold(tree_node*, bool, bool*) ()
#5  0x004e81ba in build_function_call_vec(unsigned int, tree_node*,
vectree_node*, va_gc, vl_embed*, vectree_node*, va_gc, vl_embed*) ()
#6  0x004fd24e in c_parser_postfix_expression_after_primary(c_parser*, unsigned
int, c_expr) ()
#7  0x004f57e8 in c_parser_postfix_expression(c_parser*) ()
#8  0x004f6b4c in c_parser_unary_expression(c_parser*) ()
#9  0x004fb0ac in c_parser_cast_expression(c_parser*, c_expr*) ()
#10 0x004fb2a6 in c_parser_binary_expression(c_parser*, c_expr*, c_parser_prec)
()
#11 0x004fba44 in c_parser_conditional_expression(c_parser*, c_expr*) ()
#12 0x004fc00c in c_parser_expr_no_commas(c_parser*, c_expr*) ()
#13 0x004fc49c in c_parser_expression(c_parser*) ()
#14 0x004f588a in c_parser_postfix_expression(c_parser*) ()
#15 0x004f6b4c in c_parser_unary_expression(c_parser*) ()
#16 0x004fb0ac in c_parser_cast_expression(c_parser*, c_expr*) ()
#17 0x004fb2a6 in c_parser_binary_expression(c_parser*, c_expr*, c_parser_prec)
()
#18 0x004fba44 in c_parser_conditional_expression(c_parser*, c_expr*) ()
#19 0x004fc00c in c_parser_expr_no_commas(c_parser*, c_expr*) ()
#20 0x004fc49c in c_parser_expression(c_parser*) ()
#21 0x004fc924 in c_parser_expression_conv(c_parser*) ()
#22 0x00505784 in c_parser_statement_after_labels(c_parser*) ()
#23 0x00502528 in c_parser_compound_statement_nostart(c_parser*) ()
#24 0x00502ce0 in c_parser_compound_statement(c_parser*) ()
#25 0x00503936 in c_parser_declaration_or_fndef(c_parser*, bool, bool, bool,
bool, bool, tree_node**)
()
#26 0x005083fc in c_parser_external_declaration(c_parser*) ()
#27 0x00508d02 in c_parse_file() ()
#28 0x0054e950 in c_common_parse_file() ()
#29 0x008e2650 in compile_file() ()
#30 0x008e485a in toplev_main(int, char**) ()
#31 0x7dd008e6 in __libc_start_main (main=0x4aca88 main, argc=33,
ubp_av=0x7fffef44, 
init=optimized out, fini=0xd11ecc __libc_csu_fini, rtld_fini=0x7dfef84c
_dl_fini, 
stack_end=0x7fffeed8) at libc-start.c:226
#32 0x004acbd6 in _start ()

[Bug c++/48453] [C++0x] [DR 1287] Invalid reference initialization via explicit conversion

[jason at gcc dot gnu.org]

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

Jason Merrill jason at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[C++0x] Invalid reference   |[C++0x] [DR 1287] Invalid
   |initialization via explicit |reference initialization
   |conversion  |via explicit conversion

--- Comment #5 from Jason Merrill jason at gcc dot gnu.org ---
Added DR 1287 reference.  I'm inclined to leave the bug suspended until that
issue is resolved.

[Bug c++/57593] Friendship not extended into friend member-declaration

[potswa at mac dot com]

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

--- Comment #2 from David Krauss potswa at mac dot com ---
The maintainer (Mike Miller at EDG) said simply that he will add it to the
list, but as far as I know a number isn't assigned until the new list is
drafted. The title is access granted by friendship to class-scope friend
declaration. (But I suppose he could take a liberty and remove the redundant
class-scope.)

Regardless of any possible defect, GCC is inconsistent. The change in access
applies to certain declarations, not others, but GCC is applying it to parts of
certain declarations (seemingly only the function body is excluded). To be
consistent with the current standard, the only choices are to allow all 3
examples or disallow all 3. The latter choice would be a nasty breaking change.

If it helps, here is the text of DR submission.


Friendship is not transitive, but it does grant access to member declarations
of the befriended class. ([class.friend]/2) And a friend is declared by a
member-declaration. Is a grammatical member-declaration with the friend
specifier still a member declaration?

class c {
class n {};
friend struct s;
};

struct s {
friend class c::n; // 1
friend c::n g(); // 2
friend void f() { c::n(); } // 3
};

If a friend member-declaration is not a member declaration, then it is
impossible to grant access to a private nested class (1) or a function composed
from a type specified using a private nested class (2). Both GCC and Clang
allow these examples.

If a friend member-declaration is a member declaration, then it implements one
degree of transitive friendship, if it is also a definition (3). Clang accepts
this example, but GCC rejects it.

Friends are enough like members that the access should apply. One common
application is operator . A manipulator proxy class may need access from its
insertion operator to its client's restricted members. Another application is
to define a function that would otherwise be a nonstatic member but receives a
container or smart pointer, not a direct reference to the object. These are the
most common cases for the inline friend definition syntax. They are found by
ADL so the namespace-scope declaration may be omitted.

Working around by befriending the pseudo-member friend may be troublesome as it
may violate separation of concerns, form undesired associated classes for ADL,
or require forming a declaration which may use inconvenient nested types or
reduplicated SFINAE.

Although access control isn't really a security mechanism, no exploit would
be opened by granting access because a friend can always delegate to a static
member anyway.

Proposed resolution:

Modify [class.friend]:

… can be accessed in the base-specifiers, member-declarations, and definitions
of members of the befriended class.

Is there any context within a class-specifier where access control is performed
besides its base-specifiers and member-declarations? It doesn't seem to apply
to name lookup in the template-name of a partial or explicit specialization,
but I can't find the spec. Perhaps it should be:

… can be accessed in the class-specifier and definitions of members of the
befriended class.

[Bug c++/57593] Friendship not extended into friend member-declaration

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com ---
Ok. Please, when you have a number, send it here. In any case, I suppose we'd
rather prefer to have a resolution in order to act, otherwise we are not sure
in which way we want to resolve any inconsistency.

[Bug c++/48453] [C++0x] [DR 1287] Invalid reference initialization via explicit conversion

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com ---
Ok, thanks.

[Bug c++/48453] [C++0x] [DR 1287] Invalid reference initialization via explicit conversion

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com ---
Oh, by the way, the status is ready.

[Bug c++/57610] New: Result of conversion

[o_kniemeyer at maxon dot net]

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

Bug ID: 57610
   Summary: Result of conversion
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: o_kniemeyer at maxon dot net

[Bug c++/57610] Result of conversion

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
.

[Bug c++/57610] Result of conversion

[o_kniemeyer at maxon dot net]

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

--- Comment #2 from Ole Kniemeyer o_kniemeyer at maxon dot net ---
Created attachment 30301
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30301action=edit
cpp file (without any #includes) which shows the bug

[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result

[o_kniemeyer at maxon dot net]

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

Ole Kniemeyer o_kniemeyer at maxon dot net changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #3 from Ole Kniemeyer o_kniemeyer at maxon dot net ---
In the example X can be converted to B which is a derived class of A. When an A
reference is initialized with an X object, the result of the X::operator B()
should be used directly for the A reference, but GCC creates a temporary A
object and initializes this by copy-construction from the conversion result.

At least if the classes use virtual functions, this leads to wrong results.

[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result

[o_kniemeyer at maxon dot net]

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

--- Comment #4 from Ole Kniemeyer o_kniemeyer at maxon dot net ---
As I commented in the cpp example, the C++11 standard shows exactly this
example in sections 8.5.3. So this is definitely a bug according to C++11. I
think the GCC behaviour is correct according to older C++11 standards.

[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result

[o_kniemeyer at maxon dot net]

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

--- Comment #5 from Ole Kniemeyer o_kniemeyer at maxon dot net ---
Ops, sorry, of course I meant ... to older C++ standards.

[Bug fortran/56136] [OOP] ICE on lhs-reallocation of an object with overloaded (elemental) assignment operator

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 CC||mikael.morin at sfr dot fr

--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr ---
This PR seems to have been fixed between revisions 200062 and 200078
(r200069?).

[Bug fortran/57611] New: [Fortran-Dev Regression] Too much memory allocated (gfortran.dg/coarray_lib_alloc_2.f90)

[burnus at gcc dot gnu.org]

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

Bug ID: 57611
   Summary: [Fortran-Dev Regression] Too much memory allocated
(gfortran.dg/coarray_lib_alloc_2.f90)
   Product: gcc
   Version: fortran-dev
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
Blocks: 56818

The following should be:
  yy._data.base_addr = (void * restrict) __builtin_malloc (1);
however, it is
  yy._data.base_addr = (void * restrict) __builtin_malloc (128);

type t
end type t
class(t), allocatable :: yy(:)
allocate(yy(2))
end

Similarly for coarrays, cf. gfortran.dg/coarray_lib_alloc_2.f90:
 class(t), allocatable :: xx[:], yy(:)[:]
 allocate(yy(2)[*], stat=stat, errmsg=errmsg)
which gives
  xx._data.base_addr = _gfortran_caf_register (72, 1, xx._data.token, stat.0,
   errmsg, 200);
  yy._data.base_addr = _gfortran_caf_register (192, 1, yy._data.token,
stat.2,
   errmsg, 200);
The first arguments should be 1 instead of 72/192.


As the email at http://gcc.gnu.org/ml/fortran/2013-06/msg00071.html indicates,
there seems to be some pointer involved as the size varies between 32 and 64
bit systems.

[Bug c/57612] New: add builtin to assert that expression does not have side effects

[tromey at gcc dot gnu.org]

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

Bug ID: 57612
   Summary: add builtin to assert that expression does not have
side effects
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org

It would sometimes be useful to be able to assert
that an expression does not have side effects.
For example, this would be very nice to have for
macros which expand their arguments more than once:

#define multi_expand(x)  __builtin_assert_no_side_effects(x) + (x)

Specifically, this builtin would check its argument and
give an error if the argument had an assignment or a call
to a function which is neither const nor pure.
The builtin would evaluate to the value of its argument.

[Bug lto/57613] New: [LTO] error multiple definition symbol for local symbol

[dimhen at gmail dot com]

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

Bug ID: 57613
   Summary: [LTO] error multiple definition symbol for local
symbol
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com

$ cat foo.i 
void foo()
{
}

$ gcc -fpreprocessed -flto -c foo.i
$ ld -m elf_x86_64 -r -o hidden.o --whole-archive foo.o --no-whole-archive
$ objcopy -G bar hidden.o
$ cp hidden.o hidden2.o
$ gcc -flto hidden.o hidden2.o 
hidden2.o (symbol from plugin): In function `foo':
(.text+0x0): multiple definition of `foo'
hidden.o (symbol from plugin):(.text+0x0): first defined here
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status

$ nm hidden.o
 t foo
0001 C __gnu_lto_v1

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --with-multilib-list=m64
--enable-checking=yes,df,fold,rtl,tree --enable-languages=c,c++,lto
--enable-plugin --with-tune=native --with-arch=native
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.9.0 20130614 (experimental) [trunk revision 200088] (GCC) 

gcc-4.8.1 from Fedora 19 FAIL too
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.1-20130603/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.1-20130603/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.1 20130603 (Red Hat 4.8.1-1) (GCC)

[Bug c++/57614] New: Friend declaration and qualified class member access

[roger.ferrer at bsc dot es]

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

Bug ID: 57614
   Summary: Friend declaration and qualified class member access
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roger.ferrer at bsc dot es

In the snippet below, a weird interaction happens between two overloaded friend
declarations and a class member access using a qualified id-expression. 

// -- test.cc
class  A
{
protected:
int s;
public:
A();
};

class  B : public A
{
protected:
public:
B();

// By reversing the order of these two declarations
// you can change the location of the error
friend void foo(B , int);
friend void foo(B , B b);
};

void foo(B a, int)
{
// This is only fine if this function was the first friend declared
a.A::s = 3;
// Always fine
a.s = 3;
}

void foo(B a, B b)
{
// This is only fine if this function was the first friend declared
a.A::s = 3;
// Always fine
a.s = 3;
}
// -- end of test.cc

g++ is 4.7.3

$ g++ -c test.cc
test.cc: In function ‘void foo(B, B)’:
test.cc:4:7: error: ‘int A::s’ is protected
test.cc:32:7: error: within this context

If we reverse the order of the friend declarations we can change the error
location.

$ g++ -c test.cc
test.cc: In function ‘void foo(B, int)’:
test.cc:4:7: error: ‘int A::s’ is protected
test.cc:24:7: error: within this context

The error seems to happen with the second overloaded friend declaration.

This problem can be worked around if the id-expression of the class member
access is unqualified.

[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler daniel.kruegler at googlemail dot com changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #6 from Daniel Krügler daniel.kruegler at googlemail dot com ---
1) Your example code is a bit misleading, because irrespective of your concerns
the compiler is allowed to create one copy of B (and thus of A) when returning
the B value as result of the function call. You cannot rely on that the
compiler will not create at one copy and that is not related to this issue.

2) The core language was considering to change exactly this wording you
mention, see

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1287

The part related to the example was deferred and my understanding is that

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1650

is now focusing on class prvalues during reference-binding sub-part. My
suggestion is to suspend this bug until this core issue CWG 1650 has been
resolved.

[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result

[o_kniemeyer at maxon dot net]

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

--- Comment #7 from Ole Kniemeyer o_kniemeyer at maxon dot net ---
OK, thanks for your comments. I wasn't aware of the ongoing discussion about
this issue (I was referring to the the draft version N3376 of the C++11
standard).

A B-copy would be OK, but as I said copying B into A is not a good idea if
those classes have virtual functions. The N3376 wording would be much better
for such cases.

In my case A is an interface (with dummy implementations of the virtual
functions), B an implementation of A and X an unrelated class with conversion
operator to B. Now if a function has a const A parameter (so it works with the
interface), N3376 allows me to pass an X object to this function by implicitly
creating a temporary B object which makes X look like an A. With the variant
discussed in the links you posted this wouldn't work (copying B into A makes no
sense).

[Bug target/57615] New: power8 support does not deal with -mquad-memory -mno-vsx

[meissner at gcc dot gnu.org]

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

Bug ID: 57615
   Summary: power8 support does not deal with -mquad-memory
-mno-vsx
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org

Created attachment 30302
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30302action=edit
Function to show the problem.

If you compile the Advance Toolchain dl-lookup.c with the following options:

-m64 dl-lookup.c -c -std=gnu99 -fgnu89-inline  -O3 -Wall -Winline
-Wwrite-strings -fmerge-all-constants -frounding-math -g -mcpu=power8
-mlong-double-128 -finline-limit=2000 -Wstrict-prototypes -mlong-double-128 
-fpic -fexceptions -fasynchronous-unwind-tables -ffixed-32 -ffixed-33
-ffixed-34 -ffixed-35 -ffixed-36 -ffixed-37 -ffixed-38 -ffixed-39 -ffixed-40
-ffixed-41 -ffixed-42 -ffixed-43 -ffixed-44 -ffixed-45 -ffixed-46 -ffixed-47
-ffixed-48 -ffixed-49 -ffixed-50 -ffixed-51 -ffixed-52 -ffixed-53 -ffixed-54
-ffixed-55 -ffixed-56 -ffixed-57 -ffixed-58 -ffixed-59 -ffixed-60 -ffixed-61
-ffixed-62 -ffixed-63 -ffixed-v0 -ffixed-v1 -ffixed-v10 -ffixed-v11 -ffixed-v12
-ffixed-v13 -ffixed-v14 -ffixed-v15 -ffixed-v16 -ffixed-v17 -ffixed-v18
-ffixed-v19 -ffixed-v2 -ffixed-v20 -ffixed-v21 -ffixed-v22 -ffixed-v23
-ffixed-v24 -ffixed-v25 -ffixed-v26 -ffixed-v27 -ffixed-v28 -ffixed-v29
-ffixed-v3 -ffixed-v30 -ffixed-v31 -ffixed-v4 -ffixed-v5 -ffixed-v6 -ffixed-v7
-ffixed-v8 -ffixed-v9 -ffixed-vrsave -ffixed-vscr -mno-altivec -mno-vsx

It fails with the message:
dl-lookup.c: In function ‘_dl_lookup_symbol_x’:
dl-lookup.c:854:1: error: could not split insn
(insn:TI 1693 4115 1696 (set (reg:TI 10 10 [orig:838 val2 ] [838])
(mem/c:TI (reg/f:DI 18 18 [889]) [19 val2+0 S16 A128])) dl-lookup.c:976
454 {*movti_ppc64}
 (expr_list:REG_DEAD (reg/f:DI 18 18 [889])
(expr_list:REG_EQUIV (mem/c:TI (reg/f:DI 22 22 [874]) [19 val+0 S16
A128])
(nil
dl-lookup.c:854:1: internal compiler error: in final_scan_insn, at final.c:2887

This is due to the fact that I did not think about somebody having quad memory
enabled but not VSX instructions.  The non-VSX movti 64-bit insn always does a
# to split the insn, but the split function will not split it since it could
be handled by a lq instruction.

The fix is to use the function rs6000_output_move_128bit to properly generate
lq/stq if it is safe to do so.

[Bug target/57615] power8 support does not deal with -mquad-memory -mno-vsx

[meissner at gcc dot gnu.org]

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

Michael Meissner meissner at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-06-14
 CC||bergner at gcc dot gnu.org,
   ||dje.gcc at gmail dot com
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/57615] power8 support does not deal with -mquad-memory -mno-vsx

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner meissner at gcc dot gnu.org ---
Created attachment 30303
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30303action=edit
Proposed patch to fix problem

[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs

[Simon.Richter at hogyros dot de]

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

Simon Richter Simon.Richter at hogyros dot de changed:

   What|Removed |Added

 CC||Simon.Richter at hogyros dot de

--- Comment #2 from Simon Richter Simon.Richter at hogyros dot de ---
In 4.8, this causes build failures for me:

$ g++ -g -Wall -W -Werror -Wno-unused -I. -o stage1/tree_bison_lex.o -c
tree_bison_lex.cpp
tree_bison_lex.cpp:1744:13: error: unused parameter 'yyscanner'
[-Werror=unused-parameter]

As can be guessed from the name, this is a file that is generated from flex,
which is why I've added -Wno-unused for this file specifically.

4.7 did not warn.

[Bug fortran/46459] ICE (segfault): Invalid read in compare_actual_formal [error recovery]

[mikael at gcc dot gnu.org]

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

--- Comment #5 from Mikael Morin mikael at gcc dot gnu.org ---
The initial test doesn't lead to a segfault any more.

It is now rejected with:
comment_0.f90:7.8:

call sub(1)
1
Error: Explicit interface required for 'sub' at (1): volatile argument


However, the following variant is also rejected with the same error:

 call sub(1)
contains
  subroutine sub(j)
   integer, volatile :: j
  end subroutine sub
end

[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range

[tomga at wp dot pl]

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

Tomasz Gajewski tomga at wp dot pl changed:

   What|Removed |Added

 CC||tomga at wp dot pl

--- Comment #8 from Tomasz Gajewski tomga at wp dot pl ---
The testcase can be reduced to:

#include map

typedef std::mapint, int IntToIntMap;

int main()
{
  IntToIntMap amap;
  IntToIntMap  mapref = amap;
  amap[1] = 1;
  return 0;
}

and the problem is with map references. Executing on line with 'amap[1] = 1;'
commands to print 'amap' and 'mapref' I get:

(gdb) set python print-stack full
(gdb) p mapref
Traceback (most recent call last):
  File /home/tomga/devel/gdb-scripts/python/libstdcxx/v6/printers.py, line
438, in children
rep_type = find_type(self.val.type, '_Rep_type')
  File /home/tomga/devel/gdb-scripts/python/libstdcxx/v6/printers.py, line
52, in find_type
field = typ.fields()[0]
IndexError: list index out of range
$3 = std::map with 0 elements
(gdb) p amap
$4 = std::map with 0 elements

I get this with:

$ g++ --version
g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
...
$ gdb --version
GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
...

Pretty printers from svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python
(currently latest revision: 200105.

Currently I don't know how to debug this further.

[Bug fortran/57616] New: Support -fsanitize=undefined in Fortran

[burnus at gcc dot gnu.org]

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

Bug ID: 57616
   Summary: Support -fsanitize=undefined in Fortran
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

The newly being added patches for -fsanitize=undefined are partially done in
the the FE. Thus, we need to add some Fortran support for them.

Seemingly, the following should be handled:
* Integer divide by zero
* Invalid bit shifts


Fortran 2008 has for shift:

13.7.50 DSHIFTL (I, J, SHIFT)
13.7.51 DSHIFTR (I, J, SHIFT)
...
SHIFT   shall be of type integer. It shall be nonnegative and less than or
equal to BIT_SIZE (I) if I is of type integer; otherwise, it shall be less than
or equal to BIT_SIZE (J).

13.7.84 ISHFT (I, SHIFT)
...
SHIFT   shall be of type integer. The absolute value of SHIFT shall be less
than or equal to BIT_SIZE (I).

13.7.85 ISHFTC (I, SHIFT [, SIZE])
...
SIZE (optional) shall be of type integer. The value of SIZE shall be positive
and shall not exceed BIT SIZE (I).

13.7.150 SHIFTA (I, SHIFT)
13.7.151 SHIFTL (I, SHIFT)
13.7.151 SHIFTR (I, SHIFT)
...
SHIFT shall be of type integer. It shall be nonnegative and less than or equal
to BIT SIZE (I).

[Bug c/57490] ICE on c-c++-common/cilk-plus/AN/an-if.c

[ro at gcc dot gnu.org]

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

Rainer Orth ro at gcc dot gnu.org changed:

   What|Removed |Added

 Target|sparc*-sun-solaris2.*   |*-*-solaris2.*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-14
 CC||ro at gcc dot gnu.org
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #1 from Rainer Orth ro at gcc dot gnu.org ---
As of 2013-06-14 (r200089), I see the following ICE on both Solaris/SPARC and
Solaris/x86, can be reproduced with x86_64-unknown-linux-gnu x
i386-pc-solaris2.10 cross compiler:

% cc1 -fpreprocessed an-if.i -quiet -fcilkplus -o an-if.s
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c: In
function 'main':
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c:14:9:
internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2042
 int i = 0;
 ^
0x7884f7 gimplify_var_or_parm_decl
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:2042
0x790c18 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:7565
0x7a2980 gimplify_modify_expr
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:4851
0x790b6f gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:7160
0x797758 gimplify_stmt(tree_node**, gimple_statement_d**)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:5692
0x79a5d3 gimplify_and_add
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:327
0x79a5d3 gimplify_decl_expr
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:1468
0x790629 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:7327
0x797758 gimplify_stmt(tree_node**, gimple_statement_d**)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:5692
0x790e33 gimplify_statement_list
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:1521
0x790e33 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:7549
0x797758 gimplify_stmt(tree_node**, gimple_statement_d**)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:5692
0x79786a gimplify_body(tree_node*, bool)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:8193
0x797d82 gimplify_function_tree(tree_node*)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:8325
0x621c77 analyze_function
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:630
0x624399 analyze_functions
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:914
0x624b07 finalize_compilation_unit()
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2088
0x4e7092 c_write_global_declarations()
/vol/gcc/src/hg/trunk/local/gcc/c/c-decl.c:10118

Preprocessed testcase attached.

Balaji, could you please have a look.  At least on Solaris/x86, this is the
last
remaining cilkplus testsuite failure (Solaris/SPARC bootstrap still running).

  Rainer

[Bug c/57490] ICE on c-c++-common/cilk-plus/AN/an-if.c

[ro at gcc dot gnu.org]

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

--- Comment #2 from Rainer Orth ro at gcc dot gnu.org ---
Created attachment 30304
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30304action=edit
preprocessed testcase

[Bug target/57615] power8 support does not deal with -mquad-memory -mno-vsx

[meissner at gcc dot gnu.org]

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

Michael Meissner meissner at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Michael Meissner meissner at gcc dot gnu.org ---
Fixed in subversion id 200107.

[Bug c++/57617] New: OpenMP critical does not seem to synchronise correctly

[nmm1 at cam dot ac.uk]

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

Bug ID: 57617
   Summary: OpenMP critical does not seem to synchronise correctly
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nmm1 at cam dot ac.uk

Created attachment 30305
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30305action=edit
Gzipped tar file of sources, command to run the test and output

There are some ancient problems that match this (e.g. 45025), but I can't
find a new one.  I have written a portable, multi-interface memory
consistency checker for some common 'atomic' paradigms, and one of my tests
finds that gcc -fopenmp isn't behaving.  In the attached files, look for
'NOT expected' in output - I will report the store/load one separately.

Regrettably, there is no documentation yet and this is not stripped down,
but the code is structured so that the relevant function's assembler can
be inspected (with -O0 at least).  I ran commands to generate output.

If you find a bug in my code, I shan't be surprised :-(

[Bug c++/57618] New: OpenMP atomic read and write are not sequentially consistent

[nmm1 at cam dot ac.uk]

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

Bug ID: 57618
   Summary: OpenMP atomic read and write are not sequentially
consistent
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nmm1 at cam dot ac.uk

See bug 57617 for the data and more description.  But the same program
finds that OpenMP atomic read and write are not sequentially consistent.
That will assuredly cause wrong answers when yer everage programmer
attempts to use them.

But should they be?  If you can decode any specification on this matter
from what OpenMP are pleased to call a standard, you are more intelligent
than I am.

So is this a bug, a gotcha or a feature?

[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Simon Richter from comment #2)
 In 4.8, this causes build failures for me:
 
 $ g++ -g -Wall -W -Werror -Wno-unused -I. -o stage1/tree_bison_lex.o -c
 tree_bison_lex.cpp
 tree_bison_lex.cpp:1744:13: error: unused parameter 'yyscanner'
 [-Werror=unused-parameter]

Could you attach a self-contained preprocessed testcase?
See http://gcc.gnu.org/bugs/

[Bug libstdc++/57619] New: std::unordered_map and std::unordered_multimap::insert invoking std::pair move constructor

[gdjss2728 at gmail dot com]

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

Bug ID: 57619
   Summary: std::unordered_map and std::unordered_multimap::insert
invoking std::pair move constructor
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gdjss2728 at gmail dot com

The following code is invoking the std::pair move constructor:

int main ()
{
std::unordered_mapstd::string, std::string mymap;
std::unordered_multimapstd::string, std::string mymultimap;
std::pairstd::string, std::string mypair{std::string(key),
std::string(value)};
mymultimap.insert(mypair); // std::pair move constructor invoked here
mymap.insert(mypair); // strings already moved out!
}

This seems related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53657.

As far as I can tell, overload resolution is choosing `insert(_Pair __x)`
over `insert(const value_type __x)`. Since this is an lvalue, the latter
should be chosen. This happens for std::unordered_map::insert and
std::unordered_multimap::insert.

[Bug libstdc++/57619] std::unordered_map and std::unordered_multimap::insert invoking std::pair move constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-14
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Jesse Good from comment #0)
 The following code is invoking the std::pair move constructor:

Complete testcase:

#include unordered_map
#include string
#include cassert
int main ()
{
std::unordered_multimapstd::string, std::string mymultimap;
std::pairstd::string, std::string mypair{std::string(key),
std::string(value)};
mymultimap.insert(mypair); // std::pair move constructor invoked here
assert( mypair.first.length()  mypair.second.length() );
}

 As far as I can tell, overload resolution is choosing `insert(_Pair __x)`
 over `insert(const value_type __x)`. Since this is an lvalue, the latter
 should be chosen.

Calling that overload is correct, the problem is that it uses std::move() not
std::forward_Pair

[Bug c++/57620] New: Phantom terminator confuses raw string literal parsing.

[crowl at google dot com]

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

Bug ID: 57620
   Summary: Phantom terminator confuses raw string literal
parsing.
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crowl at google dot com

The first example of C++11 section 2.14.5 paragraph 5 confuses the scanner.

$ cat test.cc
const char *phantom_terminator = Ra(
)\
a
)a;
$ xg++ -std=c++11 -g -O2 -c test.cc
test.cc:4:3: warning: missing terminating  character [enabled by default]
 )a;
   ^
test.cc:4:1: error: missing terminating  character
 )a;
 ^
test.cc:4:1: error: expected ',' or ';' before ')' token

[Bug c++/57163] Link failure with thread_local

[meyerm at fs dot tum.de]

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

Marcel Meyer meyerm at fs dot tum.de changed:

   What|Removed |Added

 CC||meyerm at fs dot tum.de

--- Comment #2 from Marcel Meyer meyerm at fs dot tum.de ---
Confirmed for gcc 4.8.1.

[Bug c++/57163] Link failure with thread_local

[meyerm at fs dot tum.de]

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

--- Comment #3 from Marcel Meyer meyerm at fs dot tum.de ---
Please have a look at bug #55800 .

[Bug c++/55800] Link failure with thread_local in unnamed namespace

[meyerm at fs dot tum.de]

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

Marcel Meyer meyerm at fs dot tum.de changed:

   What|Removed |Added

 CC||meyerm at fs dot tum.de

--- Comment #1 from Marcel Meyer meyerm at fs dot tum.de ---
Confirmed for 4.8.1 (using -std=c++11). Seems to be the same as bug #57163.

[Bug c++/51413] Broken diagnostic with __builtin_offsetof

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com ---
Fixed for 4.9.0.

[Bug libstdc++/57619] std::unordered_map and std::unordered_multimap::insert invoking std::pair move constructor

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |4.8.2

--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com ---
Let's fix this.

[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs

[Simon.Richter at hogyros dot de]

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

--- Comment #4 from Simon Richter Simon.Richter at hogyros dot de ---
Testcase is simple:

$ cat tt.cpp

void bar(int baz) { }

$ g++-4.7 -c -W -Wall -Werror -Wno-unused tt.cpp 

$ g++-4.8 -c -W -Wall -Werror -Wno-unused tt.cpp 
tt.cpp:1:6: error: unused parameter ‘baz’ [-Werror=unused-parameter]
 void bar(int baz) { }
  ^
cc1plus: all warnings being treated as errors

[Bug rtl-optimization/57451] Incorrect debug ranges emitted for -freorder-blocks-and-partition -g

[ccoutant at gcc dot gnu.org]

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

--- Comment #4 from Cary Coutant ccoutant at gcc dot gnu.org ---
The problem is a lexical block in main() that appears to be getting split by
-freorder-blocks-and-partition, but when debug info is emitted during
rest_of_handle_final(), this particular lexical block still appears to be a
single block -- BLOCK_FRAGMENT_CHAIN is NULL, so the DWARF output code decides
that it can emit a DW_AT_low_pc/high_pc pair instead of a DW_AT_ranges. The
DW_AT_high_pc is now being output relative to DW_AT_low_pc, so we see an
assembly expression .LBE14 - .LBB14, which are labels attached to the block
start and block end, and should be in the same section.

Here's the block:

(gdb) p stmt
$1 = (tree) 0x75f4c4b0
(gdb) pt
warning: Expression is not an assignment (and might have no effect)
 block 0x75f4c4b0 asm_written used
vars var_decl 0x7608bc78 e
type reference_type 0x7609b930 type record_type 0x7608e9d8
MyException
sizes-gimplified unsigned DI
size integer_cst 0x75f24dc0 constant 64
unit size integer_cst 0x75f24de0 constant 8
align 64 symtab 0 alias set -1 canonical type 0x7609b930
readonly tree_1 tree_3 unsigned decl_5 DI file pr49115.C line 21 col 25
size integer_cst 0x75f24dc0 64 unit size integer_cst 0x75f24de0 8
align 64 context function_decl 0x76096f00 main
supercontext block 0x760c00f0 asm_written used
vars var_decl 0x7608bb48 data type record_type 0x7608ec78
Data
used tree_1 tree_3 decl_5 SI file pr49115.C line 18 col 8
size integer_cst 0x75f42140 constant 32
unit size integer_cst 0x75f42160 constant 4
align 128 context function_decl 0x76096f00 main
(reg/v:SI 64 [ data ])
supercontext block 0x75f4c550 asm_written used supercontext
function_decl 0x76096f00 main
subblocks block 0x75f4c500 asm_written used vars var_decl
0x7608bb48 data supercontext block 0x75f4c550 subblocks block
0x75f4c4b0 chain block 0x760c00f0

(gdb) p stmt-block
$2 = {base = {code = BLOCK, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0, 
volatile_flag = 0, readonly_flag = 0, asm_written_flag = 1, nowarning_flag
= 0, visited = 0, 
used_flag = 1, nothrow_flag = 0, static_flag = 0, public_flag = 0,
private_flag = 0, 
protected_flag = 0, deprecated_flag = 0, default_def_flag = 0, u = {bits =
{lang_flag_0 = 0, 
lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0,
lang_flag_5 = 0, 
lang_flag_6 = 0, saturating_flag = 0, unsigned_flag = 0, packed_flag =
0, user_align = 0, 
nameless_flag = 1, spare0 = 0, spare1 = 0, address_space = 0}, length =
2048, 
  version = 2048}}, chain = 0x0, abstract_flag = 0, block_num = 14, locus =
0, 
  vars = 0x7608bc78, nonlocalized_vars = 0x0, subblocks = 0x0, supercontext
= 0x760c00f0, 
  abstract_origin = 0x0, fragment_origin = 0x0, fragment_chain = 0x0}

Here's the fragment of assembly code between .LBB14 and .LBE14:

.LBB14:
# pr49115.C:21
.loc 1 21 0
call__cxa_begin_catch
.LVL7:
call__cxa_end_catch
.LVL8:
.p2align 4,,5
# SUCC: 3 [100.0%]  count:1
jmp .L15
.cfi_endproc
.section.text.unlikely
.cfi_startproc
.cfi_personality 0x3,__gxx_personality_v0
.cfi_lsda 0x3,.LLSDAC4
# BLOCK 6 freq:5000 seq:4
# PRED: 4 [50.0%]  (CROSSING,CAN_FALLTHRU)
.L14:
.cfi_def_cfa_offset 16
.p2align 4,,8
.LEHB1:
# SUCC:
call_Unwind_Resume
.LEHE1:
.LVL9:
.LBE14:
.LBE15:
.cfi_endproc

You can see that the block from .LBB14 to .LBE14 has been split across two
sections. In order for dwarf2out to generate the proper debug info,
BLOCK_FRAGMENT_CHAIN(stmt) needs to be non-NULL. I'm not sure why that's not
happening when the block is split.

[Bug libstdc++/57619] std::unordered_map and std::unordered_multimap::insert invoking std::pair move constructor

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||4.8.1

--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com ---
Fixed mainline and 4.8.2.

[Bug c++/57620] Phantom terminator confuses raw string literal parsing.

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
Maybe Jakub can have a look.

[Bug c++/52762] Firefox 11 segfault with gcc 4.7 (-O3 -march=corei7-avx)

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com ---
Feedback not forthcoming.

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

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.8.0, 4.9.0
 Resolution|--- |FIXED

--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com ---
Can't reproduce with the released 4.8.0, current 4_8-branch and mainline. If
somebody can, please provide further details and re-open, thanks.

[Bug c/57621] New: -Og

[naruse at airemix dot jp]

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

Bug ID: 57621
   Summary: -Og
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: naruse at airemix dot jp

Folloing program is to verify func's argument is not larger than 3 at compile
time.
And this program uses valid argument 0.
Threfore I want the code is compiled without error.

This idea works on -O, -O1, -O2, -O3, -Os.
But on -Og, it fails with attribute error.
Of course it is not what I want, but is this intended behavior?

% cat og.c
#include stdio.h

int ruby$safe_level$4(void) __attribute__((error($SAFE=4 is obsolete)));
#define func(a) (__builtin_constant_p(a)  (a)  3) ? ruby$safe_level$4() :
(a)
struct foo {
int n;
};
void show(struct foo *p) {
printf(%d\n, func(p-n));
}
void hoge(void) {
struct foo f;
f.n = 0;
show(f);
}
int main(void) {
hoge();
return 0;
}
% gcc49 -O og.c  ./a.out
0
% gcc49 -Og og.c  ./a.out
og.c: In function 'show':
og.c:9:11: error: call to 'ruby$safe_level$4' declared with attribute error:
$SAFE=4 is obsolete
 printf(%d\n, func(p-n));
   ^
%  gcc49 -v
Using built-in specs.
COLLECT_GCC=gcc49
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd9.1/4.9.0/lto-wrapper
Target: x86_64-portbld-freebsd9.1
Configured with: ./../gcc-4.9-20130526/configure --disable-nls
--libdir=/usr/local/lib/gcc49 --libexecdir=/usr/local/libexec/gcc49
--program-suffix=49 --with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc49/include/c++/
--with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local
--with-pkgversion='FreeBSD Ports Collection' --with-system-zlib
--disable-libgcj --enable-languages=c,c++,objc,fortran --prefix=/usr/local
--mandir=/usr/local/man --infodir=/usr/local/info/gcc49
--build=x86_64-portbld-freebsd9.1
Thread model: posix
gcc version 4.9.0 20130526 (experimental) (FreeBSD Ports Collection)
% uname -a
FreeBSD windy.airemix.net 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0: Mon Apr 29
18:27:25 UTC 2013
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64