[Bug fortran/80751] New: NULL pointer dereferencing in gfc_trans_call on calling elemental procedure (trunk 247930)

[zeccav at gmail dot com]

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

Bug ID: 80751
   Summary: NULL pointer dereferencing in gfc_trans_call on
calling elemental procedure (trunk 247930)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

This issue is exposed by adding a gcc_assert at trans-stmt.c:455


! NULL pointer dereferencing in gfc_trans_call on calling elemental procedure
(trunk 247930)
!trans-stmt.c:455 gcc_assert(code->expr1);   /*!vz my addition
gfortran.dg/bounds_check_fail_2.f90*/
!trans-stmt.c:456 gfc_conv_loop_setup (, >expr1->where);
  interface
   elemental subroutine sub(i)
intent(in) :: i
   end subroutine
  end interface
  call sub((/1,2/))
  end
!.f:9:0:

!   call sub((/1,2/))

!internal compiler error: in gfc_trans_call, at fortran/trans-stmt.c:455
!0xc6ee72 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
!   ../../gcc/fortran/trans-stmt.c:455
!0x99834e trans_code
!   ../../gcc/fortran/trans.c:1885
!0x99900f gfc_trans_code(gfc_code*)
!   ../../gcc/fortran/trans.c:2128
!0xa9d0cf gfc_generate_function_code(gfc_namespace*)
!   ../../gcc/fortran/trans-decl.c:6332
!0x999080 gfc_generate_code(gfc_namespace*)
!   ../../gcc/fortran/trans.c:2145
!0x81564d translate_all_program_units
!   ../../gcc/fortran/parse.c:6074
!0x82be66 gfc_parse_file()
!   ../../gcc/fortran/parse.c:6274
!0x970e19 gfc_be_parse_file
!   ../../gcc/fortran/f95-lang.c:204
!Please submit a full bug report,
!with preprocessed source if appropriate.
!Please include the complete backtrace with any bug report.
!See  for instructions.

[Bug middle-end/67486] ira-color.c sanitizer detects signed integer overflow

[zeccav at gmail dot com]

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

--- Comment #4 from Vittorio Zecca  ---
Still in 8.0.0 trunk 247930

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[zeccav at gmail dot com]

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

--- Comment #5 from Vittorio Zecca  ---
ICE still in 7.1.0 and trunk 8.0.0

Even if the code is invalid the compiler should not just crash.

[Bug fortran/50410] [5/6/7/8 Regression] ICE in record_reference

[zeccav at gmail dot com]

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

--- Comment #27 from Vittorio Zecca  ---
Still in 7.1.0 and trunk 8.0.0

[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign

[zeccav at gmail dot com]

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

--- Comment #9 from Vittorio Zecca  ---
Still in 7.1.0 and in trunk 8.0.0!
Will it ever be fixed?

[Bug c++/80750] [concepts] noexcept specifier operands are allowed but ignored in compound requirements

[tom at honermann dot net]

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

--- Comment #1 from Tom Honermann  ---
*** Bug 80748 has been marked as a duplicate of this bug. ***

[Bug c++/80750] [concepts] noexcept specifier operands are allowed but ignored in compound requirements

[tom at honermann dot net]

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

--- Comment #2 from Tom Honermann  ---
*** Bug 80749 has been marked as a duplicate of this bug. ***

[Bug c++/80748] [concepts] noexcept specifier operands are allowed but ignored in compound requirements

[tom at honermann dot net]

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

Tom Honermann  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Tom Honermann  ---
Closing as a duplicate of bug 80750 (web server connectivity issues resulted in
multiple submissions).

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

[Bug c++/80750] New: [concepts] noexcept specifier operands are allowed but ignored in compound requirements

[tom at honermann dot net]

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

Bug ID: 80750
   Summary: [concepts] noexcept specifier operands are allowed but
ignored in compound requirements
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

It appears that an operand provided to the noexcept specifier in compound
requirements is ignored; the presence of any exception specification appears to
be interpreted as introducing an exception constraint:

$ cat t.cpp
template
concept bool C = requires { { T::smf() } noexcept(false); };
struct S1 {
  static void smf();
};
struct S2 {
  static void smf() noexcept;
};
static_assert(C);
static_assert(C);

$ g++ --version
g++ (GCC) 8.0.0 20170513 (experimental)
...

$ g++ -c -fconcepts t.cpp
t.cpp:9:1: error: static assertion failed
 static_assert(C);
 ^

In the above example, the expectation is that the compound requirement having a
'noexcept(false)' specifier will confer no exception constraint requirement and
that both S1 and S2 should satisfy constraint checks.  However, S1 is rejected.

The test case above is ill-formed according to the Concepts TS (N4641) given
that compound requirements are specified to only accept an optional 'noexcept'
specifier (without operands):

§ 5.1.4.3 Compound requirements [expr.prim.req.compound]
  compound-requirement:
  { expression } noexcept[opt] trailing-return-type[opt] ;

gcc allows an operand to be specified, but appears not to evaluate it.  If the
intent of the TS is to disallow operands to the noexcept specifier in compound
requirements, then gcc should reject them.  Otherwise, if the intent of the TS
is to allow operands, then gcc should evaluate them and conditionally apply
exception constraints (and an issue opened with the Concepts TS).

[Bug c++/80749] New: [concepts] noexcept specifier operands are allowed but ignored in compound requirements

[tom at honermann dot net]

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

Bug ID: 80749
   Summary: [concepts] noexcept specifier operands are allowed but
ignored in compound requirements
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

It appears that an operand provided to the noexcept specifier in compound
requirements is ignored; the presence of any exception specification appears to
be interpreted as introducing an exception constraint:

$ cat t.cpp
template
concept bool C = requires { { T::smf() } noexcept(false); };
struct S1 {
  static void smf();
};
struct S2 {
  static void smf() noexcept;
};
static_assert(C);
static_assert(C);

$ g++ --version
g++ (GCC) 8.0.0 20170513 (experimental)
...

$ g++ -c -fconcepts t.cpp
t.cpp:9:1: error: static assertion failed
 static_assert(C);
 ^

In the above example, the expectation is that the compound requirement having a
'noexcept(false)' specifier will confer no exception constraint requirement and
that both S1 and S2 should satisfy constraint checks.  However, S1 is rejected.

The test case above is ill-formed according to the Concepts TS (N4641) given
that compound requirements are specified to only accept an optional 'noexcept'
specifier (without operands):

§ 5.1.4.3 Compound requirements [expr.prim.req.compound]
  compound-requirement:
  { expression } noexcept[opt] trailing-return-type[opt] ;

gcc allows an operand to be specified, but appears not to evaluate it.  If the
intent of the TS is to disallow operands to the noexcept specifier in compound
requirements, then gcc should reject them.  Otherwise, if the intent of the TS
is to allow operands, then gcc should evaluate them and conditionally apply
exception constraints (and an issue opened with the Concepts TS).

[Bug c++/80748] New: [concepts] noexcept specifier operands are allowed but ignored in compound requirements

[tom at honermann dot net]

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

Bug ID: 80748
   Summary: [concepts] noexcept specifier operands are allowed but
ignored in compound requirements
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
  Target Milestone: ---

It appears that an operand provided to the noexcept specifier in compound
requirements is ignored; the presence of any exception specification appears to
be interpreted as introducing an exception constraint:

$ cat t.cpp
template
concept bool C = requires { { T::smf() } noexcept(false); };
struct S1 {
  static void smf();
};
struct S2 {
  static void smf() noexcept;
};
static_assert(C);
static_assert(C);

$ g++ --version
g++ (GCC) 8.0.0 20170513 (experimental)
...

$ g++ -c -fconcepts t.cpp
t.cpp:9:1: error: static assertion failed
 static_assert(C);
 ^

In the above example, the expectation is that the compound requirement having a
'noexcept(false)' specifier will confer no exception constraint requirement and
that both S1 and S2 should satisfy constraint checks.  However, S1 is rejected.

The test case above is ill-formed according to the Concepts TS (N4641) given
that compound requirements are specified to only accept an optional 'noexcept'
specifier (without operands):

§ 5.1.4.3 Compound requirements [expr.prim.req.compound]
  compound-requirement:
  { expression } noexcept[opt] trailing-return-type[opt] ;

gcc allows an operand to be specified, but appears not to evaluate it.  If the
intent of the TS is to disallow operands to the noexcept specifier in compound
requirements, then gcc should reject them.  Otherwise, if the intent of the TS
is to allow operands, then gcc should evaluate them and conditionally apply
exception constraints (and an issue opened with the Concepts TS).

[Bug c/80747] New: gcc.dg/tree-ssa/tailrecursion-4.c fails with ICE when compiled with options "-fprofile-use -freorder-blocks-and-partition"

[zwzhangwen.zhang at huawei dot com]

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

Bug ID: 80747
   Summary: gcc.dg/tree-ssa/tailrecursion-4.c fails with ICE when
compiled with options "-fprofile-use
-freorder-blocks-and-partition"
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zwzhangwen.zhang at huawei dot com
  Target Milestone: ---

Created attachment 41355
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41355=edit
my patch for fix this ICE.

When I test bb-reorder pass with deja testcase, this ICE has been found.
Compile line is as follow:
./install/bin/mips-sde-elf-gcc -fprofile-use -freorder-blocks-and-partition
-O1 -foptimize-sibling-calls -S tailrecursion-4.c
The ICE information is:
tailrecursion-4.c: In function 't':
tailrecursion-4.c:16:1: internal compiler error: in df_compact_blocks, at
df-core.c:1743
 }
 ^
0x859fce df_compact_blocks()
   
/home/wangtao/SDK_CPU_HCC_TEST/hi1822/SDK_CPU_HCC/build/script/1822/hi1822_build_dir/src/gcc-6.3.0/gcc/df-core.c:1743
0x11f3abe compact_blocks()
   
/home/wangtao/SDK_CPU_HCC_TEST/hi1822/SDK_CPU_HCC/build/script/1822/hi1822_build_dir/src/gcc-6.3.0/gcc/cfg.c:159
0x813fea relink_block_chain(bool)
   
/home/wangtao/SDK_CPU_HCC_TEST/hi1822/SDK_CPU_HCC/build/script/1822/hi1822_build_dir/src/gcc-6.3.0/gcc/cfgrtl.c:3654
0x11e85c9 reorder_basic_blocks
   
/home/wangtao/SDK_CPU_HCC_TEST/hi1822/SDK_CPU_HCC/build/script/1822/hi1822_build_dir/src/gcc-6.3.0/gcc/bb-reorder.c:2501
0x11e862c execute
   
/home/wangtao/SDK_CPU_HCC_TEST/hi1822/SDK_CPU_HCC/build/script/1822/hi1822_build_dir/src/gcc-6.3.0/gcc/bb-reorder.c:2591
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I debug it, and find that there is a bug when reorder bb according to cold/hot
partition in function reorder_basic_blocks_simple. In
find_rarely_executed_basic_blocks_and_crossing_edges will not set partition for
the first bb(cfun->cfg->x_entry_block_ptr), but reorderring bb in
reorder_basic_blocks_simple may be according to the partition of the first bb.
Therefore, after reorderring, some bbs have been lost, which triggered ICE.
According to the above, I set a default partition for reorderring bb when
partition is neither hot nor cold, which as the attachment shows. Please check
my solution and give some suggestion.
Thanks a lot.

[Bug c++/67147] [concepts] ICE on checking concept with default template arguments

[tom at honermann dot net]

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

--- Comment #2 from Tom Honermann  ---
The following bug looks likely to be related:
- Bug 80746 - [concepts] ICE evaluating constraints for concepts with dependent
template parameters

[Bug c++/80746] [concepts] ICE evaluating constraints for concepts with dependent template parameters

[tom at honermann dot net]

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

Tom Honermann  changed:

   What|Removed |Added

 Blocks||67491

--- Comment #1 from Tom Honermann  ---
This seems likely to be related to:
- Bug 67147 - [concepts] ICE on checking concept with default template
arguments


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/80746] New: [concepts] ICE evaluating constraints for concepts with dependent template parameters

[tom at honermann dot net]

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

Bug ID: 80746
   Summary: [concepts] ICE evaluating constraints for concepts
with dependent template parameters
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net
  Target Milestone: ---

gcc 6.2/7.0/trunk reports an ICE when checking constraints involving concepts
defined with dependent template parameters:

$ cat t.cpp
template
concept bool C = true;
template T> class ct {};
struct S {
  using type = int;
};
template class ct;

$ g++ --version
g++ (GCC) 8.0.0 20170513 (experimental)
...

$ g++ -c -fconcepts t.cpp
t.cpp:3:13: internal compiler error: in tsubst, at cp/pt.c:13471
 template T> class ct {};
 ^
0x5dc61a tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13471
0x5daf5e tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13895
0x5e6720 convert_template_argument
../../source/gcc/cp/pt.c:7623
0x5e7a10 coerce_template_parms
../../source/gcc/cp/pt.c:8098
0x6de12a resolve_variable_concept_check(tree_node*)
../../source/gcc/cp/constraint.cc:304
0x6de1d4 deduce_constrained_parameter(tree_node*, tree_node*&, tree_node*&)
../../source/gcc/cp/constraint.cc:329
0x61f41e cp_parser_maybe_constrained_type_specifier
../../source/gcc/cp/parser.c:17097
0x6333bd cp_parser_maybe_partial_concept_id
../../source/gcc/cp/parser.c:17154
0x6333bd cp_parser_template_id
../../source/gcc/cp/parser.c:15513
0x63362f cp_parser_class_name
../../source/gcc/cp/parser.c:21974
0x63dcc7 cp_parser_qualifying_entity
../../source/gcc/cp/parser.c:6287
0x63dcc7 cp_parser_nested_name_specifier_opt
../../source/gcc/cp/parser.c:5973
0x62a650 cp_parser_constructor_declarator_p
../../source/gcc/cp/parser.c:25986
0x62a650 cp_parser_decl_specifier_seq
../../source/gcc/cp/parser.c:13332
0x6448b5 cp_parser_parameter_declaration
../../source/gcc/cp/parser.c:21204
0x645856 cp_parser_template_parameter
../../source/gcc/cp/parser.c:15133
0x645856 cp_parser_template_parameter_list
../../source/gcc/cp/parser.c:14722
0x64670b cp_parser_explicit_template_declaration
../../source/gcc/cp/parser.c:26580
0x64670b cp_parser_template_declaration_after_export
../../source/gcc/cp/parser.c:26614
0x62b369 cp_parser_declaration
../../source/gcc/cp/parser.c:12462
...

[Bug c/80745] inconsistent warning: large integer implicitly truncated to unsigned type

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
The reason for the missing warning is that in the latter two cases the
initializer expression itself wraps around to zero, which isn't diagnosed or
detected, and the initialization then isn't diagnosed.

It seems that unsigned integer wrapping should be diagnosed independently of
signed integer overflow (e.g., under -Wtruncation or something like that), and
consistently for any kind of unsigned truncation or wrapping.

As a data point, Clang diagnoses the truncation with -Wconstant-conversion, but
it also fails to diagnose the same two cases as GCC.

[Bug c/80745] New: inconsistent warning: large integer implicitly truncated to unsigned type

[msebor at gcc dot gnu.org]

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

Bug ID: 80745
   Summary: inconsistent warning: large integer implicitly
truncated to unsigned type
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In four declarations below, the initializer expression is truncated when
assigned to unsigned char.  Yet only the first two initializers are diagnosed
(the warning message could be more helpful but that's the subject of bug
80731).  The same problem affects other unsigned integers besides unsigned
char.

All four initializers should be diagnosed.

$ cat t.c && gcc -S -Wall -Wextra -Wpedantic -Woverflow t.c
#include 

unsigned char uc1 = UCHAR_MAX + 1U;
unsigned char uc2 = USHRT_MAX + 1U;
unsigned char uc3 = UINT_MAX + 1U;
unsigned char uc4 = ULONG_MAX + 1LU;

t.c:3:21: warning: large integer implicitly truncated to unsigned type
[-Woverflow]
 unsigned char uc1 = UCHAR_MAX + 1U;
 ^
t.c:4:21: warning: large integer implicitly truncated to unsigned type
[-Woverflow]
 unsigned char uc2 = USHRT_MAX + 1U;
 ^

[Bug pending/80744] New: Detect Divide By Zero and give a warning in C/C++

[jg at jguk dot org]

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

Bug ID: 80744
   Summary: Detect Divide By Zero and give a warning in  C/C++
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pending
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Could GCC be expanded for -Wdiv-by-zero to detect these?

$200 bounty

// (A), (B) and (C) should give "warning: unsafe, may divide by zero
// (D) is from a const, NB shouldn't give a warning
void test_func(const size_t value, const string & mystr)
{
const size_t i = 0;
const size_t j = 1;

printf("A %zu mystr\n", 5 / mystr.size());

printf("B %zu\n", 10/i);

printf("C %zu\n", i/value);

printf("D %zu\n", 10/j);
}

[Bug target/80600] hidden symbol `__cpu_model' is referenced by DSO

[kristerw at gcc dot gnu.org]

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

--- Comment #11 from Krister Walfridsson  ---
Author: kristerw
Date: Sun May 14 22:49:03 2017
New Revision: 248037

URL: https://gcc.gnu.org/viewcvs?rev=248037=gcc=rev
Log:
PR target/80600 - hidden symbol '__cpu_model' is referenced by DSO

gcc/ChangeLog:

PR target/80600
* config/netbsd.h (NETBSD_LIBGCC_SPEC): Always add -lgcc.

libgcc/ChangeLog:

PR target/80600
* config.host (*-*-netbsd*): Add t-slibgcc-libgcc to tmake_file.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/netbsd.h
trunk/libgcc/ChangeLog
trunk/libgcc/config.host

[Bug middle-end/80743] ice in estimate_node_size_and_ti me, at ipa-inline-analysis.c:3385

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Reduced source code is

a, b, c;
e(unsigned long f) {
  if (!f)
return 0;
  if (f <= 3)
return;
  if (f <= 6)
return;
  if (f <= 32)
return;
  if (f <= 64)
return;
  if (f <= 128)
return;
  if (f <= 256)
return 8;
}
inline g(unsigned long f) {
  if (f > 1 << 12)
return;
  int d = e(f);
  h(d);
}
i(unsigned long f, int p2) {
  j(a, c, b, 0);
  if (p2)
g(f);
}
k() { i(k, 0); }

[Bug c/80743] New: ice in estimate_node_size_and_ti me, at ipa-inline-analysis.c:3385

[dcb314 at hotmail dot com]

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

Bug ID: 80743
   Summary: ice in estimate_node_size_and_ti me, at
ipa-inline-analysis.c:3385
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 41354
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41354=edit
gzipped C source code

While compiling a recent Linux kernel, I got trunk gcc to say this:

security/keys/dh.c:362:1: internal compiler error: in estimate_node_size_and_ti
me, at ipa-inline-analysis.c:3385
0x9c2c6c estimate_node_size_and_time
../../trunk/gcc/ipa-inline-analysis.c:3385
0x9c2c6c do_estimate_edge_time(cgraph_edge*)
../../trunk/gcc/ipa-inline-analysis.c:3935
0x9c2d8f do_estimate_edge_size(cgraph_edge*)
../../trunk/gcc/ipa-inline-analysis.c:3989
0x9c2fef estimate_edge_size
../../trunk/gcc/ipa-inline.h:304

gcc bug seems to be between revision 246605 and 247438

/home/dcb/gcc/results.246605/bin/gcc
/home/dcb/gcc/results.247438/bin/gcc
security/keys/dh.c:362:1: internal compiler error: in estimate_node_size_and_ti
me, at ipa-inline-analysis.c:3385

Flag -O2 required. I'll have a go at reducing the code.

[Bug testsuite/77684] many tree-prof testsuite failures in parallel make check

[andi at firstfloor dot org]

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

--- Comment #8 from andi at firstfloor dot org ---
> The log shows the same errors:
> spawn [open ...]
> Permission error mapping pages.
> Consider increasing /proc/sys/kernel/perf_event_mlock_kb,
> or try again with a smaller value of -m/--mmap_pages.
> (current value: 4294967295,0)

That's strange. it should be smaller with the -m flag.

Perhaps missed some case.

-Andi

> FAIL: gcc.dg/tree-prof/pr52150.c execution,-g

[Bug testsuite/77684] many tree-prof testsuite failures in parallel make check

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
It doesn't look like r247962 resolves the failures.  I continue to see them
with the top of trunk.

$ nice make -C /opt/notnfs/msebor/build/gcc-77671/gcc -j56
RUNTESTFLAGS='tree-prof.exp' check-c 2>&1 | grep FAIL
FAIL: gcc.dg/tree-prof/crossmodule-indircall-1.c execution,-g
FAIL: gcc.dg/tree-prof/val-prof-8.c execution,-g
FAIL: gcc.dg/tree-prof/pr52027.c execution,-g
FAIL: gcc.dg/tree-prof/val-prof-1.c execution,-g
FAIL: gcc.dg/tree-prof/ic-misattribution-1.c execution,-g
FAIL: gcc.dg/tree-prof/val-prof-2.c execution,-g
FAIL: gcc.dg/tree-prof/pr79587.c execution,-g
FAIL: gcc.dg/tree-prof/peel-1.c execution,-g

$ nice make -C /opt/notnfs/msebor/build/gcc-77671/gcc -j56
RUNTESTFLAGS='tree-prof.exp' check-c 2>&1 | grep FAIL
FAIL: gcc.dg/tree-prof/prof-robust-1.c execution,-g
FAIL: gcc.dg/tree-prof/pr49299-1.c execution,-g
FAIL: gcc.dg/tree-prof/val-prof-8.c execution,-g
FAIL: gcc.dg/tree-prof/val-prof-2.c execution,-g
FAIL: gcc.dg/tree-prof/pr52150.c execution,-g

The log shows the same errors:
spawn [open ...]
Permission error mapping pages.
Consider increasing /proc/sys/kernel/perf_event_mlock_kb,
or try again with a smaller value of -m/--mmap_pages.
(current value: 4294967295,0)
FAIL: gcc.dg/tree-prof/pr52150.c execution,-g

This is on the same 65-core x86_64 machine running Fedora 25, and with the same
512 setting in perf_event_mlock_kb.

[Bug middle-end/77671] missing -Wformat-overflow warning on sprintf overflow with "%s"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Sun May 14 17:50:28 2017
New Revision: 248035

URL: https://gcc.gnu.org/viewcvs?rev=248035=gcc=rev
Log:
PR middle-end/77671 - missing -Wformat-overflow warning on sprintf overflow
with %s

gcc/ChangeLog:

PR middle-end/77671
* gimple-fold.c (gimple_fold_builtin_sprintf): Make extern.
(gimple_fold_builtin_snprintf): Same.
* gimple-fold.h (gimple_fold_builtin_sprintf): Declare.
(gimple_fold_builtin_snprintf): Same.
* gimple-ssa-sprintf.c (get_format_string): Correct the detection
of character types.
(is_call_safe): New function.
(try_substitute_return_value): Call it.
(try_simplify_call): New function.
(pass_sprintf_length::handle_gimple_call): Call it.

gcc/testsuite/ChangeLog:

PR middle-end/77671
* gcc.dg/tree-ssa/builtin-sprintf-7.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-8.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-2.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Adjust.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-7.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/gimple-fold.h
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-3.c

--- Comment #7 from Martin Sebor  ---
Implemented in r248035.

[Bug middle-end/77671] missing -Wformat-overflow warning on sprintf overflow with "%s"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Sun May 14 17:50:28 2017
New Revision: 248035

URL: https://gcc.gnu.org/viewcvs?rev=248035=gcc=rev
Log:
PR middle-end/77671 - missing -Wformat-overflow warning on sprintf overflow
with %s

gcc/ChangeLog:

PR middle-end/77671
* gimple-fold.c (gimple_fold_builtin_sprintf): Make extern.
(gimple_fold_builtin_snprintf): Same.
* gimple-fold.h (gimple_fold_builtin_sprintf): Declare.
(gimple_fold_builtin_snprintf): Same.
* gimple-ssa-sprintf.c (get_format_string): Correct the detection
of character types.
(is_call_safe): New function.
(try_substitute_return_value): Call it.
(try_simplify_call): New function.
(pass_sprintf_length::handle_gimple_call): Call it.

gcc/testsuite/ChangeLog:

PR middle-end/77671
* gcc.dg/tree-ssa/builtin-sprintf-7.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-8.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-2.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Adjust.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-7.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/gimple-fold.h
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-3.c

--- Comment #7 from Martin Sebor  ---
Implemented in r248035.

[Bug c/80731] poor -Woverflow warnings, missing detail

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-14
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Testing a simple patch.

[Bug libfortran/80727] [7/8 Regression] Crash of runtime gfortran library during integer transformation

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #2 from Jerry DeLisle  ---
Mine, studying it.

[Bug target/80742] New: attribute target no- does not work

[andi-gcc at firstfloor dot org]

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

Bug ID: 80742
   Summary: attribute target no- does not work
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org
  Target Milestone: ---

Disabling ISAs with attribute target doesn't seem to work on x86_64

e.g. 

typedef float __m128 __attribute__ ((vector_size (16)));

__attribute__((target("no-sse2"))) __m128 func (__m128 x, __m128 y)
{
__m128 xmm0 = x, xmm1 = y, xmm2;
xmm0 = __builtin_ia32_xorps (xmm1, xmm1);
return xmm0;
}

does not error out.

[Bug fortran/80674] trunk/gcc/fortran/trans-stmt.c:2578]: (style) Redundant condition

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
(In reply to Jerry DeLisle from comment #2)
> Is it guaranteed for '!A || B'?  Is it guaranteed that B will 
> not be executed if !A is true?

Yes. See C FAQ.

http://c-faq.com/expr/shortcircuit.html

[Bug middle-end/80669] [8 Regression] Bad -Wstringop-overflow warnings for stpncpy

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Sun May 14 16:06:41 2017
New Revision: 248034

URL: https://gcc.gnu.org/viewcvs?rev=248034=gcc=rev
Log:
PR middle-end/80669 - Bad -Wstringop-overflow warnings for stpncpy

gcc/ChangeLog:

PR middle-end/80669
* builtins.c (expand_builtin_stpncpy): Simplify.

gcc/testsuite/ChangeLog:

PR middle-end/80669
* gcc.dg/builtin-stpncpy.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/builtin-stpncpy.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/80669] [8 Regression] Bad -Wstringop-overflow warnings for stpncpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed in r248034.

[Bug fortran/80666] character length parameter fails if declaration order incorrect

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #5 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #4)
> The change in behavior is likely due to revision r238904 (pr71730). 
> 
> Note that compiling the first test in comment 0 with -std=f95 before this
> revision gives
> 
> % /opt/gcc/gcc7p-238848p2/bin/gfortran pr80666.f90 -std=f95
> pr80666.f90:3:13:
> 
>character*(keylen), intent(in) :: key
>  1
> Error: GNU Extension: Symbol 'keylen' is used before it is typed at (1)
> pr80666.f90:1:29:
> 
>  subroutine test_arg_order(key,keylen)
>  1
> Error: Symbol 'key' at (1) has no IMPLICIT type
> 
> > Just try to write standard conforming code if possible.
>

I wonder if the code that gave this earlier Gnu Extension error is now dead
code. The patch catches the ICE. -std=f95 still gives the GNU Extension error
which obviously is no longer an extension. Maybe this needs some adjustment,
but not critical. At a minimum, cleanup diagnostic.

[Bug fortran/80741] New: incorrect behaviour of rewind with namelist

[james.s.spencer at gmail dot com]

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

Bug ID: 80741
   Summary: incorrect behaviour of rewind with namelist
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: james.s.spencer at gmail dot com
  Target Milestone: ---

Created attachment 41353
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41353=edit
test case

Rewind does not appear to work correctly if end of file has been reached and
the file contains a namelist.

With the attached file I get with gfortran 7.1.0:


 X= 10,
 Y= 10,
 /
 done  
 eof

 X=  0,
 Y=  0,
 /
 X=   

gfortran 6.3.0 I get the behaviour I expect (namelist set on both passes and
after reading the namelist, the next record is the line after the namelist):


 X= 10,
 Y= 10,
 /
 done  
 eof

 X= 10,
 Y= 10,
 /
 done

[Bug fortran/80674] trunk/gcc/fortran/trans-stmt.c:2578]: (style) Redundant condition

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #2 from Jerry DeLisle  ---
Right or wrong I think the concern was order of execution. Is it guaranteed for
'!A || B'?  Is it guaranteed that B will not be executed if !A is true?

[Bug target/80706] [7/8 Regression] peephole2 uses uninitialized stack variables on i686

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #17 from Uroš Bizjak  ---
Fixed.

[Bug ada/65696] ASAN reports global-buffer-overrun for local tagged types

[demoonlit at panathenaia dot halfmoon.jp]

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

--- Comment #2 from yuta tomino  ---
Here is a proposing fix.
I has tried this patch with gcc from 4.8 to 7, and it seems to work fine with
all versions.

diff --git a/gcc/ada/exp_atag.adb b/gcc/ada/exp_atag.adb
index 587432c..4313446 100644
--- a/gcc/ada/exp_atag.adb
+++ b/gcc/ada/exp_atag.adb
@@ -744,7 +744,8 @@ package body Exp_Atag is
function Build_Inherit_Predefined_Prims
  (Loc  : Source_Ptr;
   Old_Tag_Node : Node_Id;
-  New_Tag_Node : Node_Id) return Node_Id
+  New_Tag_Node : Node_Id;
+  Num_Predef_Prims : Int) return Node_Id
is
begin
   return
@@ -759,7 +760,7 @@ package body Exp_Atag is
 New_Tag_Node,
   Discrete_Range => Make_Range (Loc,
 Make_Integer_Literal (Loc, Uint_1),
-New_Occurrence_Of (RTE (RE_Max_Predef_Prims), Loc))),
+Make_Integer_Literal (Loc, Num_Predef_Prims))),

   Expression =>
 Make_Slice (Loc,
@@ -772,7 +773,7 @@ package body Exp_Atag is
   Discrete_Range =>
 Make_Range (Loc,
   Make_Integer_Literal (Loc, 1),
-  New_Occurrence_Of (RTE (RE_Max_Predef_Prims), Loc;
+  Make_Integer_Literal (Loc, Num_Predef_Prims;
end Build_Inherit_Predefined_Prims;

-
diff --git a/gcc/ada/exp_atag.ads b/gcc/ada/exp_atag.ads
index d53466f..eb4be55 100644
--- a/gcc/ada/exp_atag.ads
+++ b/gcc/ada/exp_atag.ads
@@ -111,7 +111,8 @@ package Exp_Atag is
function Build_Inherit_Predefined_Prims
  (Loc  : Source_Ptr;
   Old_Tag_Node : Node_Id;
-  New_Tag_Node : Node_Id) return Node_Id;
+  New_Tag_Node : Node_Id;
+  Num_Predef_Prims : Int) return Node_Id;
--  Build code that inherits the predefined primitives of the parent.
--
--  Generates: Predefined_DT (New_T).D (All_Predefined_Prims) :=
diff --git a/gcc/ada/exp_disp.adb b/gcc/ada/exp_disp.adb
index 2b63377..ef7440f 100644
--- a/gcc/ada/exp_disp.adb
+++ b/gcc/ada/exp_disp.adb
@@ -4524,6 +4524,7 @@ package body Exp_Disp is
   Iface_Table_Node   : Node_Id;
   Name_ITable: Name_Id;
   Nb_Predef_Prims: Nat := 0;
+  Cp_Predef_Prims: Nat := 0;
   Nb_Prim: Nat := 0;
   New_Node   : Node_Id;
   Num_Ifaces : Nat := 0;
@@ -5690,10 +5691,6 @@ package body Exp_Disp is
 Pos : Nat;

  begin
-if not Building_Static_DT (Typ) then
-   Nb_Predef_Prims := Max_Predef_Prims;
-
-else
Prim_Elmt := First_Elmt (Primitive_Operations (Typ));
while Present (Prim_Elmt) loop
   Prim := Node (Prim_Elmt);
@@ -5703,13 +5700,18 @@ package body Exp_Disp is
   then
  Pos := UI_To_Int (DT_Position (Prim));

- if Pos > Nb_Predef_Prims then
-Nb_Predef_Prims := Pos;
+ if Pos > Cp_Predef_Prims then
+Cp_Predef_Prims := Pos;
  end if;
   end if;

   Next_Elmt (Prim_Elmt);
end loop;
+
+if not Building_Static_DT (Typ) then
+   Nb_Predef_Prims := Max_Predef_Prims;
+else
+   Nb_Predef_Prims := Cp_Predef_Prims;
 end if;

 declare
@@ -6054,7 +6056,8 @@ package body Exp_Disp is
   (Node
 (Next_Elmt
   (First_Elmt
-(Access_Disp_Table (Typ, Loc)));
+(Access_Disp_Table (Typ, Loc),
+  Num_Predef_Prims => Cp_Predef_Prims));

   if Nb_Prims /= 0 then
  Append_To (Elab_Code,
@@ -6143,7 +6146,8 @@ package body Exp_Disp is
   Unchecked_Convert_To (RTE (RE_Tag),
 New_Occurrence_Of
   (Node (Next_Elmt (Sec_DT_Typ)),
-   Loc;
+   Loc)),
+Num_Predef_Prims => Cp_Predef_Prims));

 if Num_Prims /= 0 then
Append_To (Elab_Code,
@@ -6189,7 +6193,8 @@ package body Exp_Disp is
   Unchecked_Convert_To (RTE (RE_Tag),
 New_Occurrence_Of
   (Node (Next_Elmt (Sec_DT_Typ)),
-   Loc;
+   Loc)),
+Num_Predef_Prims => Cp_Predef_Prims));

 

[Bug tree-optimization/80740] New: Aliasing with the return value

[glisse at gcc dot gnu.org]

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

Bug ID: 80740
   Summary: Aliasing with the return value
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: alias, missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

struct A {
  int i;
  A():i(0){}
  A(A const):i(a.i){}
};

A f(A){
  A ret;
  ret.i=a.i;
  return ret;
}

We do not manage to remove the 0 initialization because of a possible aliasing
between ret and a

  ret_3(D)->i = 0;
  _1 = a_4(D)->i;
  ret_3(D)->i = _1;
  return ret_3(D);

Clang does remove it.
Aliasing would be something like

int g(){
  A x=f(x);
  return x.i;
}

which we optimize to return 0; and clang optimizes it to just return; without a
warning, although their static analysis tool says
/tmp/x.cc:9:8: warning: Assigned value is garbage or undefined
  ret.i=a.i;
   ^~~~

Clang has the opposite bug report, saying that they are wrong to optimize
because g is valid, but they seem to consider that the bug is in the standard
for not forbidding it more clearly...
https://bugs.llvm.org/show_bug.cgi?id=11470

[Bug c++/80739] New: Accessing value of X through a Y glvalue in a constant expression

[vince.rev at gmail dot com]

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

Bug ID: 80739
   Summary: Accessing value of X through a Y glvalue in a constant
expression
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vince.rev at gmail dot com
  Target Milestone: ---

Created attachment 41352
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41352=edit
Example of the bug

Consider the following valid code in C++14 (compiles without problem under
clang):
// ==
//
#include 
template  struct element {
constexpr element() noexcept: x0(0), x1(0), x2(0), x3(0) {}
T x0; int x1, x2, x3;
};
template  struct container {
constexpr container() noexcept: data() {data = element();}
element data;
};
template  constexpr bool test() {
return (container(), true);
}
int main() {
constexpr bool tmp0 = test(); // works
constexpr bool tmp1 = test(); // fails
return tmp0 && tmp1;
}
// ==
//

Compilation fails under g++-5 (g++-5 (Ubuntu 5.4.1-2ubuntu1~16.04) 5.4.1
20160904) with the following message:
## --
##
gcc_compiler_error.cpp: In function ‘int main()’:
gcc_compiler_error.cpp:16:44:   in constexpr expansion of ‘test()’
gcc_compiler_error.cpp:16:45:   in constexpr expansion of ‘container()’
gcc_compiler_error.cpp:16:45: internal compiler error: unexpected expression
‘*(container*)this’ of kind mem_ref
 constexpr bool tmp1 = test(); // fails
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
## --
##

Compilation fails under g++-6 (g++-6 (Ubuntu 6.2.0-3ubuntu11~16.04) 6.2.0
20160901) with the following message:
## --
##
gcc_compiler_error.cpp: In function ‘int main()’:
gcc_compiler_error.cpp:16:44:   in constexpr expansion of ‘test()’
gcc_compiler_error.cpp:16:45:   in constexpr expansion of ‘container()’
gcc_compiler_error.cpp:16:45: error: accessing value of ‘’ through a
‘char [20]’ glvalue in a constant expression
 constexpr bool tmp1 = test(); // fails
 ^
## --
##

Other versions may be affected (not tested).

[Bug target/80706] [7/8 Regression] peephole2 uses uninitialized stack variables on i686

[uros at gcc dot gnu.org]

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

--- Comment #16 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun May 14 12:49:55 2017
New Revision: 248032

URL: https://gcc.gnu.org/viewcvs?rev=248032=gcc=rev
Log:
Backport from mainline
2017-05-11  Uros Bizjak  

PR target/80706
* config/i386/sync.md (UNSPEC_LDX_ATOMIC): New unspec.
(UNSPEC_STX_ATOMIC): Ditto.
(loaddi_via_sse): New insn.
(storedi_via_sse): Ditto.
(atomic_loaddi_fpu): Emit loaddi_via_sse and storedi_via_sse.
Update corresponding peephole2 patterns.
(atomic_storedi_fpu): Ditto.

testsuite/ChangeLog:

Backport from mainline
2017-05-11  Uros Bizjak  
Jakub Jelinek  

PR target/80706
* gcc.target/i386/pr80706.c: New test.

2017-05-11  Uros Bizjak  

* gcc.target/i386/pr22152.c: Fix undefined testcase.
Remove unnecessary loop.  Run on 32-bit targets only.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr80706.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/sync.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr22152.c

[Bug tree-optimization/80738] New: dead first stmt in a=0;a=b;b=0 whatever the aliasing

[glisse at gcc dot gnu.org]

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

Bug ID: 80738
   Summary: dead first stmt in a=0;a=b;b=0 whatever the aliasing
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: alias, missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

In C++, with move/swap, we regularly see the following appear

void f(int,int){
  a=0;
  a=b;
  b=0;
}

If a and b do not alias, the first statement is clearly killed by the second.
If a and b are the same, the last statement kills all the rest. So in all
cases, the first statement is dead. (we could imagine that removing it means
that in some cases, we will copy uninitialized memory to itself, but that
doesn't seem so bad)

This is yet another case where the same optimization is valid whether 2
pointers alias or not, like PR 66261 or PR 80617, but the others were more
about propagation and this one is about dead code...

It seems hard to detect (involves 4 gimple statements, and plenty of
intermediate statements could interfere), the gain may not be worth it. If we
split the paths just right: if(!=){a=0;a=b;}else{a=0;a=b;}b=0; becomes
if(!=)a=b; b=0; and the if could be done unconditionally... Seems unlikely.

[Bug fortran/80442] Rejects DATA statement with array slice

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

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

--- Comment #3 from Nicolas Koenig  ---
Fixed on trunk.

[Bug c++/80736] Wrong overload picked with uniform initialization

[d.frey at gmx dot de]

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

Daniel Frey  changed:

   What|Removed |Added

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

--- Comment #2 from Daniel Frey  ---
I wasn't aware of DR 2137 and after reading it, I understand the reasoning.
Thanks.

[Bug c++/80736] Wrong overload picked with uniform initialization

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
This is correct behavior after DR 2137 backed out the relevant portions of DR
1467.