[Bug c/63567] Linux kernel build error due to non-static initializers

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63567

--- Comment #7 from Marek Polacek  ---
Well, can you give me preprocessed source code then?
Because the short testcase in Comment 1 is accepted now.

[Bug c++/63585] no warning

[maxim.prohorenko at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63585

--- Comment #1 from Максим Прохоренко  ---
int f (double x)
{
  if (x > 0 || x < 0)
return 1;
  // ok - warn
}

struct value
{
  double x;

  int operator== (const value &a)
  {
if (a.x < x || a.x > x)
  return 0;
// no warn ??
  }
};

int main (int argc, char **argv)
{
  value a, b;

  int bb = 1.;

  if (bb == f (1.) || bb == 2.5)
return 1;

  if (bb == 2.)
return 2;

  bb = bb;

  return 0;
  return a == b;
}

[Bug c++/63585] New: no warning

[maxim.prohorenko at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63585

Bug ID: 63585
   Summary: no warning
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maxim.prohorenko at gmail dot com

[Bug c++/63585] no warning

[maxim.prohorenko at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63585

--- Comment #2 from Максим Прохоренко  ---
clang return all warnings

[Bug libstdc++/63500] [4.9/5 Regression] bug in debug version of std::make_move_iterator?

[fdumont at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63500

--- Comment #9 from François Dumont  ---
Author: fdumont
Date: Sat Oct 18 09:33:28 2014
New Revision: 216423

URL: https://gcc.gnu.org/viewcvs?rev=216423&root=gcc&view=rev
Log:
2014-10-18  François Dumont  
Jonathan Wakely  

PR libstdc++/63500
* include/debug/functions.h (__foreign_iterator_aux2): Do not check for
foreign iterators if input iterators returns rvalue reference.
* testsuite/23_containers/vector/63500.cc: New.

Added:
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/23_containers/vector/63500.cc
Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/include/debug/functions.h

[Bug libstdc++/63500] [4.9/5 Regression] bug in debug version of std::make_move_iterator?

[fdumont at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63500

François Dumont  changed:

   What|Removed |Added

Version|5.0 |4.9.0
   Target Milestone|5.0 |4.9.2

--- Comment #10 from François Dumont  ---
Also fixed in 4.9 branch.

[Bug c/48116] -Wreturn-type does not work as advertised

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48116

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
Hi Marek,

Do you have even an unfinished patch? I will add this to the list of EasyHacks.

[Bug c++/55698] gcc does not report warning if operator not used : control reaches end of non-void function [-Wreturn-type]

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55698

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #1 from Manuel López-Ibáñez  ---
If the operator is not used, we do not warn. And it is not used because you
have

return 0;
return a==b;

and this is what we should warn about.

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

[Bug c++/46476] Missing Warning about unreachable code after return

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||maxim.prohorenko at gmail dot 
com

--- Comment #4 from Manuel López-Ibáñez  ---
*** Bug 55698 has been marked as a duplicate of this bug. ***

[Bug c++/63585] no warning

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63585

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #3 from Manuel López-Ibáñez  ---
Dup

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

[Bug c++/55698] gcc does not report warning if operator not used : control reaches end of non-void function [-Wreturn-type]

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55698

--- Comment #2 from Manuel López-Ibáñez  ---
*** Bug 63585 has been marked as a duplicate of this bug. ***

[Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513

--- Comment #40 from Oleg Endo  ---
Author: olegendo
Date: Sat Oct 18 10:51:08 2014
New Revision: 216424

URL: https://gcc.gnu.org/viewcvs?rev=216424&root=gcc&view=rev
Log:
gcc/
PR target/53513
* config/sh/sh-modes.def (PSI): Remove.
* config/sh/sh-protos.h (get_fpscr_rtx): Remove.
* config/sh/sh.c (fpscr_rtx, get_fpscr_rtx): Remove.
(sh_reorg): Remove commented out FPSCR code.
(fpscr_set_from_mem): Use SImode instead of PSImode.  Emit lds_fpscr
insn instead of move insn.
(sh_hard_regno_mode_ok): Return SImode for FPSCR.
(sh_legitimate_address_p, sh_legitimize_reload_address): Remove PSImode
handling.
(sh_emit_mode_set): Emit lds_fpscr and sts_fpscr insns.
(sh1_builtin_p): Uncomment.
(SH_BLTIN_UV 25, SH_BLTIN_VU 26): New macros.
(bdesc): Add __builtin_sh_get_fpscr and __builtin_sh_set_fpscr.
* config/sh/sh/predicates.md (fpscr_operand): Simplify.
(fpscr_movsrc_operand, fpscr_movdst_operand): New predicates.
(general_movsrc_operand, general_movdst_operand): Disallow
fpscr_operand.
* config/sh/sh.md (FPSCR_FR): New constant.
(push_fpscr): Emit sts_fpscr insn.
(pop_fpscr): Emit lds_fpscr_insn.
(movsi_ie): Disallow FPSCR operands.
(fpu_switch, unnamed related split, extend_psi_si,
truncate_si_psi): Remove insns.
(lds_fpscr, sts_fpscr): New insns.
(toggle_sz, toggle_pr): Use SImode for FPSCR_REG instead of PSImode.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/predicates.md
trunk/gcc/config/sh/sh-modes.def
trunk/gcc/config/sh/sh-protos.h
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.md

[Bug c/48116] -Wreturn-type does not work as advertised

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48116

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
(In reply to Manuel López-Ibáñez from comment #4)
> Do you have even an unfinished patch? I will add this to the list of
> EasyHacks.

I have nothing so far, I couldn't get to this one yet.  I'm going to unassign
myself for now, maybe I'll get to this one some day.

Feel free to put it on EasyHacks.

[Bug c++/55698] gcc does not report warning if operator not used : control reaches end of non-void function [-Wreturn-type]

[maxim.prohorenko at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55698

--- Comment #3 from Максим Прохоренко  ---
Thanks guys.

[Bug tree-optimization/63586] New: x+x+x+x -> 4*x in gimple

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63586

Bug ID: 63586
   Summary: x+x+x+x -> 4*x in gimple
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org

unsigned f(unsigned x){
  unsigned y = x + x;
  y = y + x;
  y = y + x;
  y = y + x;
  y = y + x;
  y = y + x;
  y = y + x;
  return y;
}

The .optimized dump still shows:

  y_2 = x_1(D) + x_1(D);
  y_3 = y_2 + x_1(D);
  y_4 = y_3 + x_1(D);
  y_5 = y_4 + x_1(D);
  y_6 = y_5 + x_1(D);
  y_7 = y_6 + x_1(D);
  y_8 = y_7 + x_1(D);
  return y_8;

RTL later optimizes it to x<<3 (leal), but I am surprised we aren't doing
anything in gimple. I would expect us to canonicalize to 8*x.

[Bug c++/63584] [4.8/4.9 Regression] ICE in strip_typedefs, at cp/tree.c:1326

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63584

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-18
 CC||trippels at gcc dot gnu.org
  Known to work||5.0
   Target Milestone|--- |4.8.5
Summary|ICE in strip_typedefs, at   |[4.8/4.9 Regression] ICE in
   |cp/tree.c:1326  |strip_typedefs, at
   ||cp/tree.c:1326
 Ever confirmed|0   |1
  Known to fail||4.8.3, 4.9.1

--- Comment #2 from Markus Trippelsdorf  ---
 ~ % cat preprocessed_repro.ii
namespace std
{
template  struct A
{
  static constexpr _Tp value = __v;
};
typedef A false_type;
template  void declval ();
struct __add_lvalue_reference_helper
{
  typedef int type;
};
int make_tuple ();
template  struct __lazy_conditional;
template  struct __lazy_conditional
{
  using type = typename F::type;
};
template  struct B
{
  using execution_category = typename Executor::execution_category;
  using shape_type = struct tuple_of_references_t;
  template 
  struct C : __lazy_conditional
  {
  };
  template  using shared_param_type = typename C::type;
};
template 
auto __make_tuple_if_not_nested (T) -> decltype (make_tuple ());
template  class D
{
  using outer_executor_type = Executor1;
  using inner_executor_type = Executor2;
  using outer_traits = B;
  using inner_traits = B;
  using inner_execution_category = typename inner_traits::execution_category;
  using outer_index_type = typename outer_traits::shape_type;
  using inner_shape_type = typename inner_traits::shape_type;

public:
  using shape_type
  = decltype (__make_tuple_if_not_nested (
  declval));
  template  struct inner_lambda_gcc49_workaround
  {
  };
  template 
  void
  bulk_async (Function, shape_type, Tuple shared_arg_tuple)
  {
auto outer_shared_arg (shared_arg_tuple);
using outer_shared_ref_type =
typename outer_traits::template shared_param_type;
[]
{
  inner_lambda_gcc49_workaround{};
};
  }
};
class F
{
public:
  using execution_category = int;
};
}
main ()
{
  std::D ex2;
  ex2.bulk_async ([]
  {
  },
  std::make_tuple (), std::make_tuple);
}


 ~ % g++ -c -O0 -std=c++11 preprocessed_repro.ii
preprocessed_repro.ii: In instantiation of 'std::D::bulk_async(Function, std::D::shape_type,
Tuple):: [with Function = main()::; Tuple = int (*)();
Executor1 = std::F; Executor2 = std::F]':
preprocessed_repro.ii:57:6:   required from 'struct std::D::bulk_async(Function, std::D::shape_type,
Tuple) [with Function = main()::; Tuple = int (*)(); Executor1 =
std::F; Executor2 = std::F; std::D::shape_type = int;
std::D::inner_execution_category = int; std::D::inner_shape_type = std::tuple_of_references_t]::'
preprocessed_repro.ii:57:5:   required from 'void std::D::bulk_async(Function, std::D::shape_type,
Tuple) [with Function = main()::; Tuple = int (*)(); Executor1 =
std::F; Executor2 = std::F; std::D::shape_type = int;
std::D::inner_execution_category = int; std::D::inner_shape_type = std::tuple_of_references_t]'
preprocessed_repro.ii:75:54:   required from here
preprocessed_repro.ii:59:7: internal compiler error: in strip_typedefs, at
cp/tree.c:1326
   inner_lambda_gcc49_workaround{};
   ^
0x6118b7 strip_typedefs(tree_node*)
../../gcc-4.9.1-src/gcc/cp/tree.c:1326
0x558e4c canonicalize_type_argument
../../gcc-4.9.1-src/gcc/cp/pt.c:6349
0x5672e0 coerce_template_parms
../../gcc-4.9.1-src/gcc/cp/pt.c:7002
0x56ba4a lookup_template_class_1
../../gcc-4.9.1-src/gcc/cp/pt.c:7551
0x56ba4a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc-4.9.1-src/gcc/cp/pt.c:7886
0x56dbe7 tsubst_aggr_type
../../gcc-4.9.1-src/gcc/cp/pt.c:10196
0x568493 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-4.9.1-src/gcc/cp/pt.c:11604
0x5612f6 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-4.9.1-src/gcc/cp/pt.c:15075
0x5656ff tsubst_expr
../../gcc-4.9.1-src/gcc/cp/pt.c:14016
0x5647af tsubst_expr
../../gcc-4.9.1-src/gcc/cp/pt.c:13432
0x5656cd tsubst_expr
../../gcc-4.9.1-src/gcc/cp/pt.c:13623
0x5656cd tsubst_expr
../../gcc-4.9.1-src/gcc/cp/pt.c:13623
0x564402 instantiate_decl(tree_node*, int, bool)
../../gcc-4.9.1-src/gcc/cp/pt.c:19922
0x579d11 instantiate_class_template_1
../../gcc-4.9.1-src/gcc/cp/pt.c:9367
0x579d11 instantiate_class_template(tree_node*)
../../gcc-4.9.1-src/gcc/cp/pt.c:9435
0x5cfffd complete_type(tree_node*)
../../gcc-4.9.1-src/gcc/cp/typeck.c:134
0x5

[Bug ipa/63587] New: [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587

Bug ID: 63587
   Summary: [5 Regression] ICE : tree check: expected var_decl,
have result_decl in add_local_variables, at
tree-inline.c:4112
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: marxin at gcc dot gnu.org

trippels@gcc1-power7 status % g++ -c -w -std=c++11 -O2 form_attr.ii
form_attr.ii: In static member function ‘static int
boost::function_obj_invoker0::invoke(boost::function_buffer&)
[with FunctionObj =
boost::test_case_template_invoker]’:
form_attr.ii:216:66: internal compiler error: tree check: expected var_decl,
have result_decl in add_local_variables, at tree-inline.c:4112
   make_output_actor, attribute_actor >::make (left,
right);
  ^
0x10c686af tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9185
0x10a1161f tree_check
../../gcc/gcc/tree.h:2733
0x10a1161f add_local_variables
../../gcc/gcc/tree-inline.c:4112
0x10a1c39f expand_call_inline
../../gcc/gcc/tree-inline.c:4389
0x10a1c39f gimple_expand_calls_inline
../../gcc/gcc/tree-inline.c:4518
0x10a1c39f optimize_inline_calls(tree_node*)
../../gcc/gcc/tree-inline.c:4659
0x10fc7acf inline_transform(cgraph_node*)
../../gcc/gcc/ipa-inline-transform.c:460
0x1089755f execute_one_ipa_transform_pass
../../gcc/gcc/passes.c:1990
0x1089755f execute_all_ipa_transforms()
../../gcc/gcc/passes.c:2031
0x1052cc67 cgraph_node::expand()
../../gcc/gcc/cgraphunit.c:1735
0x1052e957 expand_all_functions
../../gcc/gcc/cgraphunit.c:1878
0x1052e957 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2213
0x105309d3 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2290
0x10260d33 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4666
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
trippels@gcc1-power7 status % g++ -fno-ipa-icf -c -w -std=c++11 -O2
form_attr.ii
trippels@gcc1-power7 status %

[Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587

--- Comment #1 from Markus Trippelsdorf  ---
Created attachment 33754
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33754&action=edit
reduced testcase

[Bug c++/63588] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf

[doko at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63588

Bug ID: 63588
   Summary: [5 Regression] ICE (segfault) on arm-linux-gnueabihf
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

seen building libjava on arm-linux-gnueabihf on the trunk (PR63574 for the
bootstrap issue).

$ cat foo.cc 
template < class T > T elements;
   elements <> 
$ /home/doko/gcc/gcc-snapshot-20141017/build/gcc/xg++
-B/home/doko/gcc/gcc-snapshot-20141017/build/gcc/ -c -O2 foo.cc
foo.cc:1:24: warning: variable templates only available with -std=c++14 or
-std=gnu++14
 template < class T > T elements;
^
foo.cc:2:18: internal compiler error: Segmentation fault
elements <> 
  ^
Please submit a full bug report,
with preprocessed source if appropriate.


unsure if this is correctly reduced, because the original file in PR63574
succeeds to build with -O1.

[Bug libfortran/63589] New: find_addr2line does not consider last PATH component

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63589

Bug ID: 63589
   Summary: find_addr2line does not consider last PATH component
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb at gcc dot gnu.org

As reported on the ml, " if the PATH is not finished by ':' the last directory
present in the path is NOT processed.". Thus, in case addr2line is installed in
the last directory on the PATH, symbolic backtraces are not available.

[Bug fortran/63553] [OOP] Wrong code when assigning a CLASS to a TYPE

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63553

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Sat Oct 18 14:35:51 2014
New Revision: 216427

URL: https://gcc.gnu.org/viewcvs?rev=216427&root=gcc&view=rev
Log:
2014-10-18  Paul Thomas  

PR fortran/63553
* resolve.c (resolve_ordinary_assign): Add data component to
rvalue expression for class to type assignment.

2014-10-18  Paul Thomas  

PR fortran/63553
* gfortran.dg/class_to_type_3.f03 : New test

Added:
trunk/gcc/testsuite/gfortran.dg/class_to_type_3.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/63589] find_addr2line does not consider last PATH component

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63589

Janne Blomqvist  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2014-10/msg01813.ht
   ||ml

--- Comment #1 from Janne Blomqvist  ---
Patch at https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01813.html

[Bug c++/63582] [5 Regression]: g++.dg/init/enum1.C ... (test for errors, line 12)

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63582

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-18
 CC||danglin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from John David Anglin  ---
Also fails on hppa64-hp-hpux11.11.

[Bug target/63590] New: wrong code with -mstringop-strategy=vector_loop

[zsojka at seznam dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63590

Bug ID: 63590
   Summary: wrong code with -mstringop-strategy=vector_loop
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

Created attachment 33755
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33755&action=edit
reduced testcase

Output:
$ gcc -O -mstringop-strategy=vector_loop testcase.c
$ valgrind -q ./a.out 
==6236== Jump to the invalid address stated on the next line
==6236==at 0x0: ???
==6236==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==6236== 
==6236== 
==6236== Process terminating with default action of signal 11 (SIGSEGV)
==6236==  Bad permissions for mapped region at address 0x0
==6236==at 0x0: ???
Segmentation fault

The return address is being overwritten while initialising l[].

Tested revisions:
r216420 - fail
4_9 r213788 - fail
4_8 - unrecognized argument in option '-mstringop-strategy=vector_loop'

[Bug c/63567] Linux kernel build error due to non-static initializers

[sasha.levin at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63567

--- Comment #8 from Sasha Levin  ---
Created attachment 33756
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33756&action=edit
Preprocessed kernel/smpboot.c

[Bug c/63567] Linux kernel build error due to non-static initializers

[sasha.levin at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63567

--- Comment #9 from Sasha Levin  ---
I've attached the preprocessed kernel/smpboot.c. The problem seems to be in
line 24563:

static struct mutex smpboot_threads_lock = { .count = { (1) } , .wait_lock =
(spinlock_t ) { { .rlock = { .raw_lock = { { 0 } }, .magic = 0xdead4ead,
.owner_cpu = -1, .owner = ((void *)-1L), .dep_map = { .name =
"smpboot_threads_lock.wait_lock" } } } } , .wait_list = {
&(smpboot_threads_lock.wait_list), &(smpboot_threads_lock.wait_list) } , .magic
= &smpboot_threads_lock , .dep_map = { .name = "smpboot_threads_lock" } };

[Bug c/63567] Linux kernel build error due to non-static initializers

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63567

--- Comment #10 from Marek Polacek  ---
Thanks.  This fixes it (I need to write a proper testcase and test it).

2014-10-18  Marek Polacek  

PR c/63567
* c-typeck.c (output_init_element): Allow initializing objects with
static storage duration with compound literals even in C99 and add
pedwarn for it.

diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index 0dd3366..ee874da 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -8251,11 +8251,14 @@ output_init_element (location_t loc, tree value, tree
origtype,
 value = array_to_pointer_conversion (input_location, value);

   if (TREE_CODE (value) == COMPOUND_LITERAL_EXPR
-  && require_constant_value && !flag_isoc99 && pending)
+  && require_constant_value && pending)
 {
   /* As an extension, allow initializing objects with static storage
  duration with compound literals (which are then treated just as
  the brace enclosed list they contain).  */
+  if (flag_isoc99)
+pedwarn_init (loc, OPT_Wpedantic, "initializer element is not "
+  "constant");
   tree decl = COMPOUND_LITERAL_EXPR_DECL (value);
   value = DECL_INITIAL (decl);
 }

[Bug c/63591] New: No syntax error yielded for semicolons inside a function proto, instead code with memory corruption can be created

[k.s.matheussen at notam02 dot no]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63591

Bug ID: 63591
   Summary: No syntax error yielded for semicolons inside a
function proto, instead code with memory corruption
can be created
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: k.s.matheussen at notam02 dot no

This code should, as far as I know, not be legal C code:

extern int afunction(
 int anint,
 struct Happ *happ; // <- Extra semicolon
 );

int afunction(
  int velocityvelocity,
  struct Happ *happ
  )
{
  return 208;
}


Gcc does not complain about this code, even with -Wall and -Werror.

I'm also seeing memory corruption in a larger program I'm working on,
because of this extra misplaced semicolon, but I haven't been able
to create a smaller example doing this. Please let me know if you need
the larger example causing memory corruption.

I consider this bug (I assume it is a bug) quite serious.
If adding this extra semicolon by mistake (like I did), things appear
to work as normal, whille possibly getting serious bugs which are
hard to trace.

[Bug c/63591] No syntax error yielded for semicolons inside a function proto, instead code with memory corruption can be created

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63591

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html

[Bug c/63591] No syntax error yielded for semicolons inside a function proto, instead code with memory corruption can be created

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63591

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---


(In reply to Kjetil Matheussen from comment #0)
> This code should, as far as I know, not be legal C code:
> 
> extern int afunction(
>  int anint,
>  struct Happ *happ; // <- Extra semicolon
>  );
> 
> int afunction(
>   int velocityvelocity,
>   struct Happ *happ
>   )
> {
>   return 208;
> }
> 
> 
> Gcc does not complain about this code, even with -Wall and -Werror.

GCC 5.0 complains by default.

manuel@gcc10:~$ ~/test1/216257/build/gcc/cc1 test.c  
test.c:9:15: warning: ‘struct Happ’ declared inside parameter list
   )
   ^
test.c:9:15: warning: its scope is only this definition or declaration, which
is probably not what you want

(The location is a bit off, yes).

[Bug c/63591] No syntax error yielded for semicolons inside a function proto, instead code with memory corruption can be created

[k.s.matheussen at notam02 dot no]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63591

--- Comment #3 from Kjetil Matheussen  ---
I didn't know about this gnu extension. But regardless, shouldn't gcc complain
when the proto doesn't match the function itself?

Also, although I don't understand how this extension works from the
documentation, I have a feeling that there should have been a warning or error
when compiling code calling "afunction" as well?

int main(){
  return afunction(5, NULL);
}

(this compiles just fine)

[Bug c/63591] No syntax error yielded for semicolons inside a function proto, instead code with memory corruption can be created

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63591

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2014-10-18
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #4 from Manuel López-Ibáñez  ---
Ah, I get it know. Your testcase was not complete. Please follow
https://gcc.gnu.org/bugs/ when reporting bugs. You will avoid a lot of
confusion.

A complete minimal testcase:

struct Happ;
extern int afunction(
 int anint,
 struct Happ *happ; // <- Extra semicolon
 );

I think we should warn for this case, or even not accept it at all. The above
is clearly not the use intended for VLAs because:

1) happ cannot be the length of the array
2) there are no arguments to the function, so a foward declaration is useless.


If you *really* think this is a serious bug, why not help us to fix it?
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

[Bug c/63591] be more strict when accepting parameter forward declarations

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63591

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
Summary|No syntax error yielded for |be more strict when
   |semicolons inside a |accepting parameter forward
   |function proto, instead |declarations
   |code with memory corruption |
   |can be created  |

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Kjetil Matheussen from comment #3)
> I didn't know about this gnu extension. But regardless, shouldn't gcc
> complain when the proto doesn't match the function itself?

Unfortunately, there is [*] too much old code that would break if we did so.
But you can use -Wstrict-prototypes.

[*] or there was, perhaps we should revisit adding -Wstrict-prototypes to
-Wall. But to do that we need someone that will propose such a patch, fix any
failing testcases in the testsuite and convince the maintainers.

> Also, although I don't understand how this extension works from the
> documentation, I have a feeling that there should have been a warning or
> error when compiling code calling "afunction" as well?
> 
> int main(){
>   return afunction(5, NULL);
> }
> 
> (this compiles just fine)

This is because int foo(); is not a prototype (you can call it with foo(5,5)).
You need -Wstrict-prototypes.

[Bug c/63591] No syntax error yielded for semicolons inside a function proto, instead code with memory corruption can be created

[k.s.matheussen at notam02 dot no]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63591

--- Comment #5 from Kjetil Matheussen  ---
Sorry, complete example below. The problem with the code is:

1. Proto doesn't match function. There is an extra semicolon in the proto, but
not in the function itself.
2. Calling "afunction" may cause memory corruption, although it is not clear to
me how or why, and I can't reproduce it in a minimal example. I can provide a
larger program that demonstrate this memory corruption though.



struct Happ{
  int a;
  int b[203];
};

extern int afunction(
 int anint,
 struct Happ *happ; // <- Problem 1. Extra semicolon.
 );

int afunction(
  int velocityvelocity,
  struct Happ *hepp
  )
{
  return 208;
}

int main(){
  struct Happ happ;
  return afunction(50,&happ); // <- Problem 2.
}

[Bug libstdc++/57925] discrete_distribution can be improved to O(1) per sampling

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57925

Paolo Carlini  changed:

   What|Removed |Added

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

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #69 from Kazumoto Kojima  ---
The patch in c#57 disables memory equiv substitution for the memory
with base+index and base+display addressing.

static bool
sh_cannot_substitute_equiv_p (rtx subst)
{
  if (TARGET_SHMEDIA)
return false;

  if (GET_CODE (subst) == SUBREG)
subst = SUBREG_REG (subst);
  if (MEM_P (subst) && GET_CODE (XEXP (subst, 0)) == PLUS)
return true;

  return false;
}

A bit surprisingly, disabling all memory equiv substitution wins
CSiBE tests.  With

static bool
sh_cannot_substitute_equiv_p (rtx subst)
{
  if (TARGET_SHMEDIA)
return false;

  return true;
}

the code size regression for CSiBE from non LRA is reduced to 0.59%.
Looking at the improved cases, the extra save/restore insns to/from
stack disappear.  I guess that SH has not enough numbers of the hard
registers to make the equiv substitution win in the size and the speed
on average working sets.  It looks the pseudos produced to hold
the equiv values can't get hard registers for bad cases and end up
memory save/restore insns which make the code worse.

[Bug c/63567] Linux kernel build error due to non-static initializers

[sasha.levin at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63567

--- Comment #11 from Sasha Levin  ---
That does the trick. Thanks!

A different issue with the patch I've previously bisected came up, I'll open a
different bug report for that.

[Bug c/63592] New: Linux kernel build failure due to duplicate exported symbols

[sasha.levin at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63592

Bug ID: 63592
   Summary: Linux kernel build failure due to duplicate exported
symbols
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sasha.levin at oracle dot com
CC: mpolacek at gcc dot gnu.org

Hi,

I'm seeing the following build failure with the Linux Kernel:

/home/sasha/linux-next/lib/mpi/mpi-inline.h:82: multiple definition of
`mpihelp_sub_1'
lib/mpi/generic_mpih-lshift.o:/home/sasha/linux-next/lib/mpi/mpi-inline.h:82:
first defined here
lib/mpi/mpih-div.o: In function `mpihelp_sub':
/home/sasha/linux-next/lib/mpi/mpi-inline.h:110: multiple definition of
`mpihelp_sub'
lib/mpi/generic_mpih-lshift.o:/home/sasha/linux-next/lib/mpi/mpi-inline.h:110:
first defined here
lib/mpi/mpih-mul.o: In function `mpihelp_add_1':
/home/sasha/linux-next/lib/mpi/mpi-inline.h:39: multiple definition of
`mpihelp_add_1'
lib/mpi/generic_mpih-lshift.o:/home/sasha/linux-next/lib/mpi/mpi-inline.h:39:
first defined here
lib/mpi/mpih-mul.o: In function `mpihelp_add':
/home/sasha/linux-next/lib/mpi/mpi-inline.h:67: multiple definition of
`mpihelp_add'
lib/mpi/generic_mpih-lshift.o:/home/sasha/linux-next/lib/mpi/mpi-inline.h:67:
first defined here
lib/mpi/mpih-mul.o: In function `mpihelp_sub_1':
/home/sasha/linux-next/lib/mpi/mpi-inline.h:82: multiple definition of
`mpihelp_sub_1'
lib/mpi/generic_mpih-lshift.o:/home/sasha/linux-next/lib/mpi/mpi-inline.h:82:
first defined here
lib/mpi/mpih-mul.o: In function `mpihelp_sub':
/home/sasha/linux-next/lib/mpi/mpi-inline.h:110: multiple definition of
`mpihelp_sub'
lib/mpi/generic_mpih-lshift.o:/home/sasha/linux-next/lib/mpi/mpi-inline.h:110:
first defined here
lib/mpi/mpi-pow.o: In function `mpihelp_add':
/home/sasha/linux-next/lib/mpi/mpi-inline.h:67: multiple definition of
`mpihelp_add'
lib/mpi/generic_mpih-lshift.o:/home/sasha/linux-next/lib/mpi/mpi-inline.h:67:
first defined here
lib/mpi/mpi-pow.o: In function `mpihelp_sub_1':
/home/sasha/linux-next/lib/mpi/mpi-inline.h:82: multiple definition of
`mpihelp_sub_1'
lib/mpi/generic_mpih-lshift.o:/home/sasha/linux-next/lib/mpi/mpi-inline.h:82:
first defined here
lib/mpi/mpi-pow.o: In function `mpihelp_sub':
/home/sasha/linux-next/lib/mpi/mpi-inline.h:110: multiple definition of
`mpihelp_sub'
lib/mpi/generic_mpih-lshift.o:/home/sasha/linux-next/lib/mpi/mpi-inline.h:110:
first defined here
lib/mpi/mpi-pow.o: In function `mpihelp_add_1':
/home/sasha/linux-next/lib/mpi/mpi-inline.h:39: multiple definition of
`mpihelp_add_1'
lib/mpi/generic_mpih-lshift.o:/home/sasha/linux-next/lib/mpi/mpi-inline.h:39:
first defined here
lib/mpi/mpiutil.o: In function `mpihelp_add':
/home/sasha/linux-next/lib/mpi/mpi-inline.h:67: multiple definition of
`mpihelp_add'
lib/mpi/generic_mpih-lshift.o:/home/sasha/linux-next/lib/mpi/mpi-inline.h:67:
first defined here
lib/mpi/mpiutil.o: In function `mpihelp_sub_1':
/home/sasha/linux-next/lib/mpi/mpi-inline.h:82: multiple definition of
`mpihelp_sub_1'
lib/mpi/generic_mpih-lshift.o:/home/sasha/linux-next/lib/mpi/mpi-inline.h:82:
first defined here
lib/mpi/mpiutil.o: In function `mpihelp_sub':
/home/sasha/linux-next/lib/mpi/mpi-inline.h:110: multiple definition of
`mpihelp_sub'
lib/mpi/generic_mpih-lshift.o:/home/sasha/linux-next/lib/mpi/mpi-inline.h:110:
first defined here
lib/mpi/mpiutil.o: In function `mpihelp_add_1':
/home/sasha/linux-next/lib/mpi/mpi-inline.h:39: multiple definition of
`mpihelp_add_1'
lib/mpi/generic_mpih-lshift.o:/home/sasha/linux-next/lib/mpi/mpi-inline.h:39:
first defined here
make[1]: *** [lib/mpi/mpi.o] Error 1
make: *** [lib/mpi/] Error 2


This was bisected down to GCC commit:

commit b2601928b5bf34a817b5a9a2a371c476018e634d  
Author: mpolacek   
Date:   Wed Oct 15 10:08:00 2014 +  

* doc/invoke.texi: Update to reflect that GNU11 is the default  
mode for C.  
* c-common.h (c_language_kind): Update comment.  
c-family/  
* c-opts.c (c_common_init_options): Make -std=gnu11 the default for C.  


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@216247
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c/63591] be more strict when accepting parameter forward declarations

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63591

--- Comment #7 from Andreas Schwab  ---
A function declaration with forward declared parameters it is a prototype, sort
of.  Not defining the forward declared parameter as a real parameter should
probably be flagged as an error.