[Bug middle-end/90676] [9 Regression] ambiguous GIMPLE after store merging

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
I guess we should simply switch to -gimple dumping format for dumping MEM:

void __GIMPLE (ssa,guessed_local(1073741824))
f2 ()
{
  __BB(2,guessed_local(1073741824)):
  __MEM  ((char *)&a) = _Literal (unsigned short) 1;
  return;

}


void __GIMPLE (ssa,guessed_local(1073741824))
f4 ()
{
  __BB(2,guessed_local(1073741824)):
  __MEM  ((char *)&a) = 1u;
  return;

}

which shows both the access type and its alignment.  Of course that likely
requires adjusting quite a number of testcases (which is why I added
those TDF_GIMPLE differences in the first place...).

[Bug c++/90687] New: [9 regression] ICE in ocp_convert, at cp/cvt.c:766

[kutdanila at yandex dot ru]

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

Bug ID: 90687
   Summary: [9 regression] ICE in ocp_convert, at cp/cvt.c:766
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kutdanila at yandex dot ru
  Target Milestone: ---

Found some internal compiler error while updating g++ to the 9th version that
was not an issue in 8.3.

#include 
#include 

std::string foo(int kind)
{
const std::unordered_map map;
return true ? map.find(kind)->second : throw 1;
}


If removing const from unordered_map, everything works fine.

Compiler options are `g++-9 -std=c++14 test.cpp`

[Bug middle-end/90676] default GIMPLE dumps lack information

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|[9 Regression] ambiguous|default GIMPLE dumps lack
   |GIMPLE after store merging  |information

--- Comment #5 from Richard Biener  ---
The bugreport is of course bougs - there's no ambiguity in GIMPLE just the
(default) GIMPLE dumps do not include everything needed to re-build the GIMPLE.
That's also hardly a regression.  You could argue in a similar way that
you want -vops and -alias to be the default.

That said, I'd be happy to see less if (flags & TDF_GIMPLE) in the dumper
and have the default be GIMPLE FE syntax for the individual GIMPLE stmts.
But I do not have the cycles to make this happen and adjust all of the
testsuite fallout.

[Bug middle-end/88784] Middle end is missing some optimizations about unsigned

[rguenther at suse dot de]

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

--- Comment #21 from rguenther at suse dot de  ---
On Fri, 31 May 2019, ffengqi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784
> 
> --- Comment #20 from Qi Feng  ---
> I have tried to merge signed and unsigned together:
> 
> /* x >  y   &&   x != ( 0 or XXX_MIN )   -->   x > y */
> (for and (truth_and bit_and)
>  (simplify
>   (and:c (gt:c@3 @0 @1) (ne @0 INTEGER_CST@2))
>   (if (INTEGRAL_TYPE_P (TREE_TYPE(@0)) && INTEGRAL_TYPE_P (TREE_TYPE(@1)))
>(if ((TYPE_UNSIGNED (TREE_TYPE(@0)) && TYPE_UNSIGNED (TREE_TYPE(@1))
> && integer_zerop (@2))
> || (!TYPE_UNSIGNED (TREE_TYPE(@0)) && !TYPE_UNSIGNED (TREE_TYPE(@1))
> && wi::eq_p (wi::to_wide (@2),
>  wi::min_value (TYPE_PRECISION (TREE_TYPE (@2)),
> SIGNED
> @3
> 
> /* x >  y  ||  x != ( 0 or XXX_MIN )   -->  x != ( 0 or XXX_MIN ) */
> (for or (truth_or bit_ior)
>  (simplify
>   (or:c (gt:c @0 @1) (ne@3 @0 INTEGER_CST@2))
>   (if (INTEGRAL_TYPE_P (TREE_TYPE(@0)) && INTEGRAL_TYPE_P (TREE_TYPE(@1)))
>(if ((TYPE_UNSIGNED (TREE_TYPE(@0)) && TYPE_UNSIGNED (TREE_TYPE(@1))
> && integer_zerop (@2))
> || (!TYPE_UNSIGNED (TREE_TYPE(@0)) && !TYPE_UNSIGNED (TREE_TYPE(@1))
> && wi::eq_p (wi::to_wide (@2),
>  wi::min_value (TYPE_PRECISION (TREE_TYPE (@2)),
> SIGNED
> @3
> 
> /* x <  y  &&  x != ( UXXX_MAX or XXX_MAX )  -->  x < y */
> (for and (truth_and bit_and)
>  (simplify
>   (and:c (lt:c@3 @0 @1) (ne @0 INTEGER_CST@2))
>   (if (INTEGRAL_TYPE_P (TREE_TYPE(@0)) && INTEGRAL_TYPE_P (TREE_TYPE(@1)))
>(if ((TYPE_UNSIGNED (TREE_TYPE(@0)) && TYPE_UNSIGNED (TREE_TYPE(@1))
> && wi::eq_p (wi::to_wide (@2),
>  wi::max_value (TYPE_PRECISION (TREE_TYPE (@2)),
> UNSIGNED)))
> || (!TYPE_UNSIGNED (TREE_TYPE(@0)) && !TYPE_UNSIGNED (TREE_TYPE(@1))
> && wi::eq_p (wi::to_wide (@2),
>  wi::max_value (TYPE_PRECISION (TREE_TYPE (@2)),
> SIGNED
> @3
> 
> (That's not all of them, for that would be too long and I think it's not
> necessary.)
> 
> I also tried it on a x86 laptop, seems it does work. But I got a bootstrap
> issue. I don't know if it's caused by my patch or the version of gcc I used to
> compile.

You can always try to bootstrap the same revision without your patch.

> Another problem is that I can't craft some c/c++ code to test truth_and. Maybe
> it's used by other languages? Is it necessary to use truth_and along side
> bit_and?

The C family will end up with truth_andif.

> I have to make this work on a ppc64le machine, could you give me some hints of
> where to look into?

Upthread I mentioned LOGICAL_OP_NON_SHORT_CIRCUIT.  For the testsuite
we have --param logical-op-non-short-circuit=1 which you could put
into dg-options.  Upthread I said that the ifcombine workers should
probably be rewritten to support the patterns from match.pd.

An initial patch doesn't have to solve everything ;)

[Bug c++/84497] link errors with trivial external thread_local variables

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #9 from Iain Sandoe  ---
So, it turns out that the facility tested here requires alias support.
It seems that GCC currently has no support for initialising across TUs for
targets without alias support (and probably for any target using emulated TLS).
 However, that's a separate issue from this one.

Applied a require for the alias support as below, so re-closing. 

URL: https://gcc.gnu.org/viewcvs?rev=271801&root=gcc&view=rev
Log:
c++, testsuite - require alias support for a test.

The test for pr84497 uses a facility that requires alias support from
the target, and therefore fails on targets without.  Add a suitable 
dg-require statement.

2019-05-31  Iain Sandoe  

* g++.dg/cpp0x/pr84497.C: Require alias support.

[Bug c++/59994] [meta-bug] thread_local

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59994
Bug 59994 depends on bug 84497, which changed state.

Bug 84497 Summary: link errors with trivial external thread_local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84497

   What|Removed |Added

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

[Bug tree-optimization/90671] [10 Regression] ICE on valid code at -Os and above with -g enabled in gsi_split_seq_after, at gimple-iterator.c:345

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri May 31 07:53:48 2019
New Revision: 271802

URL: https://gcc.gnu.org/viewcvs?rev=271802&root=gcc&view=rev
Log:
PR tree-optimization/90671
* tree-ssa-threadupdate.c (ssa_create_duplicates): If
template_block used to be empty on the first call, don't use
gsi_split_seq_after and gsi_insert_seq_after, but remember whole
seq with bb_seq and set it with set_bb_seq.

* gcc.dg/torture/pr90671.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr90671.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadupdate.c

[Bug c++/90687] [9/10 Regression] ICE in ocp_convert, at cp/cvt.c:766

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||8.3.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2019-05-31
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|[9 regression] ICE in   |[9/10 Regression] ICE in
   |ocp_convert, at |ocp_convert, at
   |cp/cvt.c:766|cp/cvt.c:766
   Target Milestone|--- |9.2
  Known to fail||10.0, 9.1.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r260272.

[Bug tree-optimization/90688] New: [7/8/9/10 Regression] ICE in calc_dfs_tree, at dominance.c:458 since r235297

[marxin at gcc dot gnu.org]

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

Bug ID: 90688
   Summary: [7/8/9/10 Regression] ICE in calc_dfs_tree, at
dominance.c:458 since r235297
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

I know it's a weird option combination, but still:

$ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.old-deja/g++.law/ctors15.C
-fno-dse -Os -fnon-call-exceptions -funroll-loops -fno-inline
-fdelete-dead-exceptions
during RTL pass: fwprop2
/home/marxin/Programming/gcc/gcc/testsuite/g++.old-deja/g++.law/ctors15.C: In
function ‘int main()’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.old-deja/g++.law/ctors15.C:27:1:
internal compiler error: in calc_dfs_tree, at dominance.c:458
   27 | }
  | ^
0x6d0633 calc_dfs_tree
/home/marxin/Programming/gcc/gcc/dominance.c:458
0xbc81b5 calculate_dominance_info(cdi_direction)
/home/marxin/Programming/gcc/gcc/dominance.c:734
0x1798efd fwprop_init
/home/marxin/Programming/gcc/gcc/fwprop.c:1438
0x1799465 fwprop_addr
/home/marxin/Programming/gcc/gcc/fwprop.c:1557
0x1799465 execute
/home/marxin/Programming/gcc/gcc/fwprop.c:1603
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/90688] [7/8/9/10 Regression] ICE in calc_dfs_tree, at dominance.c:458 since r235297

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.5.0
Version|unknown |7.4.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2019-05-31
 CC||nathan at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |7.5
  Known to fail||10.0, 7.4.0, 8.3.0, 9.1.0

[Bug target/90689] ICE in extract_insn, at recog.c:2310 on ppc64le

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Target||powerpc64*-unknown-linux-gn
   ||u
   Last reconfirmed||2019-5-31
 CC||segher at gcc dot gnu.org
   Host||x86_64-pc-linux-gnu
Version|unknown |10.0
   Target Milestone|--- |10.0

[Bug target/90689] New: ICE in extract_insn, at recog.c:2310 on ppc64le

[marxin at gcc dot gnu.org]

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

Bug ID: 90689
   Summary: ICE in extract_insn, at recog.c:2310 on ppc64le
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

I see following ICE, I bet it's a recent regression:

$ pc64le-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/inline-24.c -mno-pltseq
-fno-inline -fno-plt -Os -c
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/inline-24.c: In function
‘main’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/inline-24.c:28:1: error:
unrecognizable insn:
   28 | }
  | ^
(insn 7 6 8 2 (set (mem/v/c:DI (plus:DI (reg/f:DI 1 1)
(const_int 24 [0x18])) [2  S8 A8])
(unspec:DI [
(reg:DI 2 2)
(symbol_ref:DI ("foo") [flags 0x41] )
(const_int 0 [0])
] UNSPEC_PLTSEQ))
"/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/inline-24.c":27:10 -1
 (nil))
during RTL pass: vregs
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/inline-24.c:28:1: internal
compiler error: in extract_insn, at recog.c:2310
0x55b2b5 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/rtl-error.c:108
0x55b2d1 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/rtl-error.c:116
0x55a73c extract_insn(rtx_insn*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/recog.c:2310
0x7b1e83 instantiate_virtual_regs_in_insn
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/function.c:1605
0x7b1e83 instantiate_virtual_regs
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/function.c:1975
0x7b1e83 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/function.c:2024

[Bug c/90690] New: Undocumented -Werror-implicit-function-declaration

[tim.ruehsen at gmx dot de]

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

Bug ID: 90690
   Summary: Undocumented -Werror-implicit-function-declaration
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tim.ruehsen at gmx dot de
  Target Milestone: ---

The command line option '-Werror-implicit-function-declaration' is listed by
`gcc -Q --help=warning[,C]` and also accepted by gcc 4.6 up to 9.1.

But `man gcc` doesn't mention this command line option. If this has been
obsoleted by `-Werror=implicit-function-declaration`, please do not list it
with '-Q --help=warning'. We use this to automatically enable *all* warnings
(something like clang's -Weverything).

Thank you !

[Bug debug/86964] [7/8 Regression] Too many debug symbols included, especially for extern globals

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
Author: rguenth
Date: Fri May 31 08:22:14 2019
New Revision: 271803

URL: https://gcc.gnu.org/viewcvs?rev=271803&root=gcc&view=rev
Log:
2019-05-31  Thomas De Schampheleire  

PR debug/86964
* common.opt (feliminate-unused-debug-symbols): Enable by default.
* doc/invoke.texi (Debugging Options): Document new default of
-feliminate-unused-debug-symbols and remove restriction to 'stabs'.

* g++.dg/debug/dwarf2/fesd-any.C: Use
-fno-eliminate-unused-debug-symbols.
* g++.dg/debug/dwarf2/fesd-baseonly.C: Likewise.
* g++.dg/debug/dwarf2/fesd-none.C: Likewise.
* g++.dg/debug/dwarf2/fesd-reduced.C: Likewise.
* g++.dg/debug/dwarf2/fesd-sys.C: Likewise.
* g++.dg/debug/dwarf2/inline-var-1.C: Likewise.
* g++.dg/debug/enum-2.C: Likewise.
* gcc.dg/debug/dwarf2/fesd-any.c: Likewise.
* gcc.dg/debug/dwarf2/fesd-baseonly.c: Likewise.
* gcc.dg/debug/dwarf2/fesd-none.c: Likewise.
* gcc.dg/debug/dwarf2/fesd-reduced.c: Likewise.
* gcc.dg/debug/dwarf2/fesd-sys.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/debug/dwarf2/fesd-any.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/fesd-baseonly.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/fesd-none.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/fesd-reduced.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/fesd-sys.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/inline-var-1.C
trunk/gcc/testsuite/g++.dg/debug/enum-2.C
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/fesd-any.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/fesd-baseonly.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/fesd-none.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/fesd-reduced.c
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/fesd-sys.c

[Bug driver/90684] New alignment options incorrectly report error

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-31
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Thanks for the report. I've tested that mainly on x86_64, that's why I haven't
seen it.
The patch is correct to me.

[Bug tree-optimization/90668] loop invariant moving a dependent store out of a loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||alias, wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-31
 CC||rguenth at gcc dot gnu.org
 Blocks||57359
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Yes, that's arguably a bug, there's a duplicate about this, PR57359, which
explains the complexity for retaining this optimizations (other compilers
happily do as well, at least for PR57359).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
[Bug 57359] store motion causes wrong code for union access at -O3

[Bug tree-optimization/90671] [10 Regression] ICE on valid code at -Os and above with -g enabled in gsi_split_seq_after, at gimple-iterator.c:345

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug debug/90674] [7/8/9/10 Regression] ICE in gen_subprogram_die

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/90677] [9/10 Regression] gcc-9.1.0 fails to build __gcc_diag__ souce: error: 'cgraph_node' is not defined as a type

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/90681] [10 Regression] ICE in vect_slp_analyze_node_operations_1, at tree-vect-slp.c:2513 since r271704

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||rguenth at gcc dot gnu.org

[Bug rtl-optimization/90688] [7/8/9/10 Regression] ICE in calc_dfs_tree, at dominance.c:458 since r235297

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Component|tree-optimization   |rtl-optimization

--- Comment #1 from Richard Biener  ---
I think I've seen a duplicate, fwprop not handling unreachable BBs (or whoever
introduced those not cleaning up the CFG properly).

[Bug target/90678] [10 Regression] ICE in aarch64_return_address_signing_enabled, at config/aarch64/aarch64.c:4865 since r271735

[samtebbs at gcc dot gnu.org]

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

--- Comment #4 from Sam Tebbs  ---
Thanks Martin, fixed by r271780. I can commit your reduced testcase if you
would like.

[Bug target/90678] [10 Regression] ICE in aarch64_return_address_signing_enabled, at config/aarch64/aarch64.c:4865 since r271735

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Sam Tebbs from comment #4)
> Thanks Martin, fixed by r271780. I can commit your reduced testcase if you
> would like.

It's probably not needed. Thank you for the fix.

[Bug c++/90691] New: [GCC9 regression] -Wsign-compare false-positive with constant

[lebedev.ri at gmail dot com]

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

Bug ID: 90691
   Summary: [GCC9 regression] -Wsign-compare false-positive with
constant
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lebedev.ri at gmail dot com
  Target Milestone: ---

Manually reduced:

#include 

struct S {
  int a;

  constexpr S();
  explicit constexpr S(int a_) : a(a_) {}
};

constexpr S b = S(12);

template 
bool c(unsigned int d) {
  return d >= e.a;
}

bool test(unsigned int d);
bool test(unsigned int d) {
return c(d);
}

GCC diagnoses:
: In instantiation of 'bool c(unsigned int) [with const S& e = b]':
:19:18:   required from here
:14:12: warning: comparison of integer expressions of different
signedness: 'unsigned int' and 'const int' [-Wsign-compare]
   14 |   return d >= e.a;
  |  ~~^~
Compiler returned: 0

clang doesn't.
https://godbolt.org/z/7xrWzz


But there can't ever be any issues here, the signed 'int a' is '12', which is
known-positive.
Indeed, if the constant is negative, clang warns:
https://godbolt.org/z/yQBXB8

[Bug libstdc++/90682] std::terminate() will happily call a null terminate handler

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Fri May 31 10:35:11 2019
New Revision: 271808

URL: https://gcc.gnu.org/viewcvs?rev=271808&root=gcc&view=rev
Log:
PR libstdc++/90682 allow set_terminate(0) and set_unexpected(0)

Make these functions restore the default handlers when passed a null
pointer. This is consistent with std::pmr::set_default_resource(0), and
also matches the current behaviour of libc++.

In order to avoid duplicating the preprocessor condition from
eh_term_handler.cc more that into a new eh_term_handler.h header and
define a macro that can be used in both eh_term_handler.cc and
eh_terminate.cc.

PR libstdc++/90682
* libsupc++/eh_term_handler.cc: Include eh_term_handler.h to get
definition of _GLIBCXX_DEFAULT_TERM_HANDLER.
* libsupc++/eh_term_handler.h: New header defining
_GLIBCXX_DEFAULT_TERM_HANDLER.
* libsupc++/eh_terminate.cc: Include eh_term_handler.h.
(set_terminate): Restore default handler when argument is null.
(set_unexpected): Likewise.
* testsuite/18_support/set_terminate.cc: New test.
* testsuite/18_support/set_unexpected.cc: New test.

Added:
trunk/libstdc++-v3/libsupc++/eh_term_handler.h
  - copied, changed from r271807,
trunk/libstdc++-v3/libsupc++/eh_term_handler.cc
trunk/libstdc++-v3/testsuite/18_support/set_terminate.cc
trunk/libstdc++-v3/testsuite/18_support/set_unexpected.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/libsupc++/eh_term_handler.cc
trunk/libstdc++-v3/libsupc++/eh_terminate.cc

[Bug libstdc++/71579] type_traits miss checks for type completeness in some traits

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Fri May 31 10:35:03 2019
New Revision: 271806

URL: https://gcc.gnu.org/viewcvs?rev=271806&root=gcc&view=rev
Log:
PR libstdc++/71579 assert that type traits are not misused with incomplete
types

This patch adds static asserts for type traits misuse with incomplete
classes and unions. This gives a nice readable error message instead
of an UB and odr-violations.

Some features of the patch:
* each type trait has it's own static_assert inside. This gives better
diagnostics than the approach with putting the assert into a helper
structure and using it in each trait.
* the result of completeness check is not memorized by the compiler.
This gives no false positive after the first failed check.
* some of the compiler builtins already implement the check. But not
all of them! So the asserts are in all the type_traits that may
benefit from the check. This also makes the behavior of libstdc++ more
consistent across different (non GCC) compilers.
* std::is_base_of does not have the assert as it works well in many
cases with incomplete types

2019-05-31  Antony Polukhin  

PR libstdc++/71579
* include/std/type_traits __type_identity, __is_complete_or_unbounded):
New helpers for checking preconditions in traits.
(is_trivial, is_trivially_copyable, is_standard_layout, is_pod)
(is_literal_type, is_empty, is_polymorphic, is_final, is_abstract)
(is_destructible, is_nothrow_destructible, is_constructible)
(is_default_constructible, is_copy_constructible)
(is_move_constructible, is_nothrow_default_constructible)
(is_nothrow_constructible, is_nothrow_copy_constructible)
(is_nothrow_move_constructible, is_copy_assignable, is_move_assignable)
(is_nothrow_assignable, is_nothrow_copy_assignable)
(is_nothrow_move_assignable, is_trivially_constructible)
(is_trivially_copy_constructible, is_trivially_move_constructible)
is_trivially_assignable, is_trivially_copy_assignable)
(is_trivially_move_assignable, is_trivially_destructible)
(alignment_of, is_swappable, is_nothrow_swappable, is_invocable)
(is_invocable_r, is_nothrow_invocable)
(has_unique_object_representations, is_aggregate): Add static_asserts
to make sure that type traits are not misused with incomplete types.
(__is_constructible_impl, __is_nothrow_default_constructible_impl)
(__is_nothrow_constructible_impl, __is_nothrow_assignable_impl): New
base characteristics without assertions that can be reused in other
traits.
* testsuite/20_util/is_complete_or_unbounded/memoization.cc: New test.
* testsuite/20_util/is_complete_or_unbounded/memoization_neg.cc: New
test.
* testsuite/20_util/is_complete_or_unbounded/value.cc: New test.
* testsuite/20_util/is_abstract/incomplete_neg.cc: New test.
* testsuite/20_util/is_aggregate/incomplete_neg.cc: New test.
* testsuite/20_util/is_class/value.cc: Check incomplete type.
* testsuite/20_util/is_function/value.cc: Likewise.
* testsuite/20_util/is_move_constructible/incomplete_neg.cc: New test.
* testsuite/20_util/is_nothrow_move_assignable/incomplete_neg.cc: New
test.
* testsuite/20_util/is_polymorphic/incomplete_neg.cc: New test.
* testsuite/20_util/is_reference/value.cc: Check incomplete types.
* testsuite/20_util/is_unbounded_array/value.cc: Likewise.
* testsuite/20_util/is_union/value.cc: Likewise.
* testsuite/20_util/is_void/value.cc: Likewise.
* testsuite/util/testsuite_tr1.h: Add incomplete union type.

Added:
trunk/libstdc++-v3/testsuite/20_util/is_abstract/incomplete_neg.cc
  - copied, changed from r271805,
trunk/libstdc++-v3/testsuite/20_util/is_reference/value.cc
trunk/libstdc++-v3/testsuite/20_util/is_aggregate/incomplete_neg.cc
  - copied, changed from r271805,
trunk/libstdc++-v3/testsuite/20_util/is_reference/value.cc
trunk/libstdc++-v3/testsuite/20_util/is_complete_or_unbounded/
   
trunk/libstdc++-v3/testsuite/20_util/is_complete_or_unbounded/memoization.cc
  - copied, changed from r271805,
trunk/libstdc++-v3/testsuite/20_util/is_reference/value.cc
   
trunk/libstdc++-v3/testsuite/20_util/is_complete_or_unbounded/memoization_neg.cc
  - copied, changed from r271805,
trunk/libstdc++-v3/testsuite/20_util/is_reference/value.cc
trunk/libstdc++-v3/testsuite/20_util/is_complete_or_unbounded/value.cc
   
trunk/libstdc++-v3/testsuite/20_util/is_move_constructible/incomplete_neg.cc
  - copied, changed from r271805,
trunk/libstdc++-v3/testsuite/20_util/is_reference/value.cc
   
trunk/libstdc++-v3/testsuite/20_util/is_nothrow_move_assignable/incomplete_neg.cc
  - copied, changed from r271805,
trunk/libstdc++-v3/testsuite/20_util/is_reference/value.cc
trunk/libstdc++-v3

[Bug libstdc++/90682] std::terminate() will happily call a null terminate handler

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #5 from Jonathan Wakely  ---
Fixed for GCC 10.

[Bug target/90678] [10 Regression] ICE in aarch64_return_address_signing_enabled, at config/aarch64/aarch64.c:4865 since r271735

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Earnshaw  ---
Fixed as per comment #4

[Bug libstdc++/71579] type_traits miss checks for type completeness in some traits

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-31
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #8 from Jonathan Wakely  ---
Is there more work to do to support the whole of https://wg21.link/lwg2797 ?

[Bug middle-end/90648] [8/9/10 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_MULT_EXPR, at generic-match.c:27222

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Created attachment 46437
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46437&action=edit
not fully fix

So even a 1:1 implementation of gimple_builtin_call_types_compatible_p doesn't
catch this since the FE registers a bogus prototype which we of course match.
Not sure why the issue doesn't appear on GIMPLE though.

It looks like we eventually get to some intermediate IL state from the
FEs c_fully_fold_internal?  At gimplification time the callees function
decl/type is that of the actual builtin, during the time we call
c_fully_fold_internal it is not.

In fact we adjust the function decls type in pop_scope:

  /* It is possible for a decl not to have a name.  We get
 here with b->id NULL in this case.  */
  if (b->id)
{
  gcc_assert (I_SYMBOL_BINDING (b->id) == b);
  I_SYMBOL_BINDING (b->id) = b->shadowed;
  if (b->shadowed && b->shadowed->u.type)
TREE_TYPE (b->shadowed->decl) = b->shadowed->u.type;

Aha.  It looks like since

extern _Float128 copysignf128 ();

isn't a prototype the actual call creates one in the local binding
(adding 'void' above makes the originally intended fix work).

In the end it's premature folding that makes the fix ineffective.

[Bug middle-end/90648] [8/9/10 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_MULT_EXPR, at generic-match.c:27222

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P2

--- Comment #12 from Richard Biener  ---
The following works around the broken transient state, but it's of course
not a full fix (but the best we can do here without to resorting to
the global built-in decls tables which we do not do in other related code).

I'll leave things to the frontend folks here, I'm not sure why the
non-prototype copysignf128 has to shadow the builtin signature?

Index: gcc/genmatch.c
===
--- gcc/genmatch.c  (revision 271803)
+++ gcc/genmatch.c  (working copy)
@@ -3099,10 +3099,12 @@ dt_node::gen_kids_1 (FILE *f, int indent
  gcc_assert (e->operation->kind == id_base::FN);

  fprintf_indent (f, indent, "case %s:\n", e->operation->id);
- fprintf_indent (f, indent, "  {\n");
- generic_fns[j]->gen (f, indent + 4, false);
- fprintf_indent (f, indent, "break;\n");
- fprintf_indent (f, indent, "  }\n");
+ fprintf_indent (f, indent, "  if (call_expr_nargs (%s) >= %d)\n"
+"{\n",
+kid_opname, e->ops.length ());
+ generic_fns[j]->gen (f, indent + 6, false);
+ fprintf_indent (f, indent, "}\n");
+ fprintf_indent (f, indent, "  break;\n");
}
   fprintf_indent (f, indent, "default:;\n");

[Bug c++/90691] [9/10 regression] -Wsign-compare false-positive with constant

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic, needs-bisection
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-31
   Target Milestone|--- |9.2
Summary|[GCC9 regression]   |[9/10 regression]
   |-Wsign-compare  |-Wsign-compare
   |false-positive with |false-positive with
   |constant|constant
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug c++/90691] [9/10 regression] -Wsign-compare false-positive with constant

[lebedev.ri at gmail dot com]

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

--- Comment #2 from Roman Lebedev  ---
(In reply to Richard Biener from comment #1)
> Confirmed.

Note that this isn't just about constants, but about the evaluation
of constant-range of the signed operand.
E.g. '(b ? 10 : 9)' is not a constant, but you know it will always be positive.

[Bug driver/90692] New: The "%{!shared:%:if-exists(default-manifest.o%s)}" spec option fails if gcc is installed in a path with spaces

[Olivier.Michel at cyberbotics dot com]

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

Bug ID: 90692
   Summary: The "%{!shared:%:if-exists(default-manifest.o%s)}"
spec option fails if gcc is installed in a path with
spaces
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Olivier.Michel at cyberbotics dot com
  Target Milestone: ---

Created attachment 46438
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46438&action=edit
Proposed patch

The "%{!shared:%:if-exists(default-manifest.o%s)}" spec option fails if gcc is
installed in a path with spaces.

It turns out the problem lies in gcc.c where the spec "%s" function will expand
"default-manifest.o" into "D:/msys
64/mingw64/x86_64-w64-mingw32/lib/default-manifest.o" or so which is correct,
but because of the if-exists function, it will be tested and further expanded
into "D:/msys" and "64/mingw64/x86_64-w64-mingw32/lib/default-manifest.o"
(split at the space) which is then passed to collect2 and fails.

See report here: https://github.com/msys2/MINGW-packages/issues/4744

[Bug c++/90691] [9/10 regression] -Wsign-compare false-positive with constant

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r270136.  I'd say we should stop considering -fcompare-debug=-W*
as bugs, after all, it is extremely unlikely we are going to fix those anyway,
warnings do affect code generation in pretty significant way, and just revert
that change.

[Bug libstdc++/68303] performance: unordered_map&co. up to 7x speedup

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Patch posted to https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00903.html
Reviewed at https://gcc.gnu.org/ml/gcc-patches/2019-05/msg02120.html

[Bug c++/90691] [9/10 regression] -Wsign-compare false-positive with constant

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #3)
> Started with r270136.  I'd say we should stop considering
> -fcompare-debug=-W* as bugs, after all, it is extremely unlikely we are
> going to fix those anyway, warnings do affect code generation in pretty
> significant way, and just revert that change.

Err, please no.  -W* should not affect code generation otherwise we can
simply declare -g may as well for even more obvious reasons.

[Bug c++/90691] [9/10 regression] -Wsign-compare false-positive with constant

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > Started with r270136.  I'd say we should stop considering
> > -fcompare-debug=-W* as bugs, after all, it is extremely unlikely we are
> > going to fix those anyway, warnings do affect code generation in pretty
> > significant way, and just revert that change.
> 
> Err, please no.  -W* should not affect code generation otherwise we can
> simply declare -g may as well for even more obvious reasons.

The choices are live with -fcompare-debug=-W* goal resulting in worse warnings
(like this PR), not considering -fcompare-debug=-W* a bug, slowing compile time
by doing all the maybe_const_value etc. calls regardless if we need them for
warnings or not, or perhaps some middle-ground like ask the constexpr
evaluation to compute something only without trying to instantiate anything
(nor copy_fn anything) when it is called from the warning guarded paths, just
punting in that case.

[Bug tree-optimization/90681] [10 Regression] ICE in vect_slp_analyze_node_operations_1, at tree-vect-slp.c:2513 since r271704

[alejandro.martinezvicente at arm dot com]

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

--- Comment #2 from Alejandro  ---
I'm looking at this, will keep you posted.

[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||kutdanila at yandex dot ru

--- Comment #3 from Marek Polacek  ---
*** Bug 90687 has been marked as a duplicate of this bug. ***

[Bug c++/90687] [9/10 Regression] ICE in ocp_convert, at cp/cvt.c:766

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Marek Polacek  ---
This is a dup.

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

[Bug tree-optimization/90681] [10 Regression] ICE in vect_slp_analyze_node_operations_1, at tree-vect-slp.c:2513 since r271704

[alejandro.martinezvicente at arm dot com]

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

--- Comment #3 from Alejandro  ---
(In reply to Alejandro from comment #2)
> I'm looking at this, will keep you posted.

I could also reproduce it targetting armv8.2-a+sve.

[Bug target/89659] [microblaze] unrecognizable insn at floating point conversion

[ra_gcc_bugzilla at hotmail dot com]

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

Rico Amslinger  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||8.2.0
 Resolution|--- |FIXED

--- Comment #1 from Rico Amslinger  ---
The issue does no longer occur in 8.2.0, as it was fixed by mbodapat. See 
https://forums.xilinx.com/t5/Embedded-Development-Tools/quot-unrecognizable-insn-quot-when-compiling-Parsec-Benchmarks/td-p/949479
for details.

[PATCH] fixincludes breaks mingw64 build

[Jonas Jelten]

Hi!

I'm trying to build the x86_64-w64-mingw64 crosscompiler on gentoo.
 It breaks because a fixincludes-fix is applied at a place where it should not 
be applied.

This broke the cross-gcc build for gcc-8.3.0 and 9.1.0 with error messages that 
made it tricky to figure out what was
really going on.


This code snippet of mingw's stdio.h:


#ifdef _WIN64
  _CRTIMP FILE *__cdecl __iob_func(void);
#define _iob  __iob_func()
#else
[.]
#if (!defined(NO_OLDNAMES) || defined(__GNUC__))
  __MINGW_EXTENSION typedef __int64 fpos_t;
#define _FPOSOFF(fp) ((long)(fp))


= is modified by fixincludes to be:


#ifdef _WIN64
  _CRTIMP FILE *__cdecl __iob_func(void);
#define _iob  __iob

#  if defined(__STDC__) || defined(__cplusplus)
 extern int snprintf(char *, size_t, const char *, ...);
 extern int vsnprintf(char *, size_t, const char *, __gnuc_va_list);
#  else /* not __STDC__) || __cplusplus */
 extern int snprintf();
 extern int vsnprintf();
#  endif /* __STDC__) || __cplusplus */
_func()
#else
[]
#if (!defined(NO_OLDNAMES) || defined(__GNUC__))
  __MINGW_EXTENSION typedef __int64 fpos_t;
#define _FPOSOFF(fp) ((long)(fp))


which leads to this compiler error:

In file included from /usr/x86_64-w64-mingw64/sys-include/_mingw.h:12,
 from /usr/x86_64-w64-mingw64/sys-include/crtdefs.h:10,
 from /usr/x86_64-w64-mingw64/sys-include/stddef.h:7,
 from 
/tmp/portage/cross-x86_64-w64-mingw64/gcc-8.3.0-r1/work/build/gcc/include/stddef.h:1,
 from 
/tmp/portage/cross-x86_64-w64-mingw64/gcc-8.3.0-r1/work/gcc-8.3.0/libgcc/../gcc/tsystem.h:44,
 from 
/tmp/portage/cross-x86_64-w64-mingw64/gcc-8.3.0-r1/work/gcc-8.3.0/libgcc/libgcc2.c:27:
/tmp/portage/cross-x86_64-w64-mingw64/gcc-8.3.0-r1/work/build/gcc/include-fixed/stdio.h:
 In function ‘_func’:
/tmp/portage/cross-x86_64-w64-mingw64/gcc-8.3.0-r1/work/build/gcc/include-fixed/stdio.h:136:3:
 error: expected
declaration specifiers before ‘__extension__’
   __MINGW_EXTENSION typedef __int64 fpos_t;
   ^

and many many more follow-up errors.



A simple fix seems to be to check for a line ending in the select-regex:

Author: Jonas Jelten 
Date:   Wed May 31 15:10:52 2019 +0200

fixincludes: check for lineending to not break mingw64-build

--- a/fixincludes/inclhack.def  2019-05-31 15:01:31.841235934 +0200
+++ b/fixincludes/inclhack.def  2019-05-31 15:09:31.068347492 +0200
@@ -2163,7 +2163,7 @@
 fix = {
 hackname = hpux10_stdio_declarations;
 files= stdio.h;
-select   = "^#[ \t]*define _iob[ \t]*__iob";
+select   = "^#[ \t]*define _iob[ \t]*__iob[ \t]*\n";
 bypass   = "^[ \t]*extern[ \t]*int[ \t]*vsnprintf[ \t]*\\(";
 c_fix = format;
 c_fix_arg = "%0\n\n"
--- a/fixincludes/fixincl.x 2019-05-31 15:13:20.430156243 +0200
+++ b/fixincludes/fixincl.x 2019-05-31 15:13:24.953156662 +0200
@@ -4272,7 +4272,7 @@
  *  content selection pattern - do fix if pattern found
  */
 tSCC zHpux10_Stdio_DeclarationsSelect0[] =
-   "^#[ \t]*define _iob[ \t]*__iob";
+   "^#[ \t]*define _iob[ \t]*__iob[ \t]*\n";

 /*
  *  content bypass pattern - skip fix if pattern found



Cheers

-- Jonas

[Bug c++/71482] Add -Wglobal-constructors warning option

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Marek Polacek from comment #2)
> Patch: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01860.html

Does Sean have a bugzilla account?

[Bug c++/71482] Add -Wglobal-constructors warning option

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
(In reply to Eric Gallager from comment #3)
> (In reply to Marek Polacek from comment #2)
> > Patch: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01860.html
> 
> Does Sean have a bugzilla account?

I don't see it.  Probably not yet.

[Bug middle-end/90693] New: Missing popcount simplifications

[wilco at gcc dot gnu.org]

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

Bug ID: 90693
   Summary: Missing popcount simplifications
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilco at gcc dot gnu.org
  Target Milestone: ---

While GCC optimizes __builtin_popcount (x) != 0 into x != 0, we can also
optimize __builtin_popcount (x) == 1 into x == (x & -x), and __builtin_popcount
(x) > 1 into (x & (x-1)) != 0.

[Bug libstdc++/71579] type_traits miss checks for type completeness in some traits

[antoshkka at gmail dot com]

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

--- Comment #9 from Antony Polukhin  ---
(In reply to Jonathan Wakely from comment #8)
> Is there more work to do to support the whole of https://wg21.link/lwg2797 ?

Looks like I've missed the is_nothrow_invocable_r, is_convertible,
is_nothrow_convertible, is_swappable_with, is_nothrow_swappable_with. I'll add
static asserts in a separate patch.

is_base_of is a hard one. But doable.

Non first template arguments of some traits could be hardened further. However
there are doubts about hardening those and especially the `R` parameter of the
is_*invocable_r traits:


#include 

struct X;
struct foo{
  X operator()(X&, X&);
};

// OK on GCC and Clang
constexpr bool r0 = std::is_invocable_r::value;


struct Y {
Y& operator=(X );
};

// OK on GCC, ill-formed on clang
constexpr bool r1 = std::is_assignable::value;

I'm not sure what to do. We may harden those and make the behavior match the
Comments/Preconditions columns in the [meta.*], or relax those preconditions in
the WD, or do nothing and leave it as is. Right now I'm in favor of the second
approach.

[Bug target/90689] [10 Regression] ICE in extract_insn, at recog.c:2310 on ppc64le

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
I cannot reproduce this (on a native compiler).  Do you use some non-default
defaults, maybe?  And, what SVN revision did you test?

[Bug middle-end/90694] New: incorrect representation of ADDR_EXPR involving a pointer to array

[msebor at gcc dot gnu.org]

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

Bug ID: 90694
   Summary: incorrect representation of ADDR_EXPR involving a
pointer to array
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As mentioned in bug 90662 comment #2, the format of an ADDR_EXPR involving
pointers to arrays printed in tree dumps is incorrect: it's missing the
required parentheses.  The test case below shows the problem.  In it the strlen
argument in #1 is equivalent to #2 but not to #3 or #4.  Similarly, the strlen
argument in #3 is equivalent to #4 but not to the other two.

But the IL representation of #1 that's in the dump is identical to the source
in #3: &*p[2], whose representation is actually p + 16.  This is incorrect and
makes tree dumps involving such expressions misleading.

typedef char A8[8];

int f0 (A8 *p)
{
  return __builtin_strlen (&(*p)[2]); // #1: this is equivalent...
}

int f1 (A8 *p)
{ 
  return __builtin_strlen ((*p) + 2); // #2: ...to this
}


int g0 (A8 *p)
{
  return __builtin_strlen (&*p[2]);   // #3: and this is equivalent...
}

int g1 (A8 *p)
{
  return __builtin_strlen ((*(p + 2)));   // #4: ...to this 
}

f0 (char[8] * p)
{
  int D.1969;

  _1 = &*p[2];;; #1: but this corresponds to #3
above
  _2 = __builtin_strlen (_1);
  D.1969 = (int) _2;
  return D.1969;
}


f1 (char[8] * p)
{
  int D.1971;

  _1 = p + 2;
  _2 = __builtin_strlen (_1);
  D.1971 = (int) _2;
  return D.1971;
}


g0 (char[8] * p)
{
  int D.1973;

  _1 = p + 16;
  _2 = __builtin_strlen (_1);
  D.1973 = (int) _2;
  return D.1973;
}


g1 (char[8] * p)
{
  int D.1975;

  _1 = p + 16;
  _2 = __builtin_strlen (_1);
  D.1975 = (int) _2;
  return D.1975;
}

[Bug middle-end/90694] incorrect representation of ADDR_EXPR involving a pointer to array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-31
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
The following patch adds the missing parentheses:

diff --git a/gcc/tree-pretty-print.c b/gcc/tree-pretty-print.c
index 6645a646617..c1effcddd65 100644
--- a/gcc/tree-pretty-print.c
+++ b/gcc/tree-pretty-print.c
@@ -1676,9 +1676,14 @@ dump_generic_node (pretty_printer *pp, tree node, int
spc, dump_flags_t flags,
  {
if (TREE_CODE (TREE_OPERAND (node, 0)) != ADDR_EXPR)
  {
+   /* Enclose pointers to arrays in parentheses.  */
+   tree op0 = TREE_OPERAND (node, 0);
+   if (POINTER_TYPE_P (TREE_TYPE (op0)))
+ pp_left_paren (pp);
pp_star (pp);
-   dump_generic_node (pp, TREE_OPERAND (node, 0),
-  spc, flags, false);
+   dump_generic_node (pp, op0, spc, flags, false);
+   if (POINTER_TYPE_P (TREE_TYPE (op0)))
+ pp_right_paren (pp);
  }
else
  dump_generic_node (pp,

[Bug c/90690] Undocumented -Werror-implicit-function-declaration

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
(In reply to Tim Ruehsen from comment #0)
> The command line option '-Werror-implicit-function-declaration' is listed by
> `gcc -Q --help=warning[,C]` and also accepted by gcc 4.6 up to 9.1.
> 
> But `man gcc` doesn't mention this command line option. If this has been
> obsoleted by `-Werror=implicit-function-declaration`,

yeah I'm pretty sure that's what happened

> please do not list it with '-Q --help=warning'. We use this to automatically
> enable *all* warnings (something like clang's -Weverything).
> 
> Thank you !

[Bug c/43673] Incorrect warning: use of 'D' length modifier with 'a' type character

[law at gcc dot gnu.org]

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

--- Comment #7 from Jeffrey A. Law  ---
Author: law
Date: Fri May 31 18:46:02 2019
New Revision: 271820

URL: https://gcc.gnu.org/viewcvs?rev=271820&root=gcc&view=rev
Log:
PR c/43673
* c-format.c (print_char_table, scanf_char_table): Replace BADLEN with
TEX_D32, TEX_D64 or TEX_D128.

PR c/43673
* gcc.dg/format-dfp-printf-1.c: New test.
* gcc.dg/format-dfp-scanf-1.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/c-format.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/format/dfp-printf-1.c
trunk/gcc/testsuite/gcc.dg/format/dfp-scanf-1.c

[Bug c/43673] Incorrect warning: use of 'D' length modifier with 'a' type character

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #8 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug libstdc++/71579] type_traits miss checks for type completeness in some traits

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Yes I noticed is_nothrow_invocable_r was missing but forgot to mention it.

[Bug target/90622] Suboptimal code generated for __builtin_avr_insert_bits

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-31
 Ever confirmed|0   |1
  Known to fail||8.0.1

--- Comment #1 from Georg-Johann Lay  ---
Confirmed with v8. The built-in folding special-cases if the inserted bit(s)
don't change their position and always expands to XOR-AND-XOR. Otherwise it
tries to find some better sequence and fails, and finally just prints that
BST-BLD.

[Bug middle-end/90694] incorrect representation of ADDR_EXPR involving a pointer to array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
   Severity|normal  |minor

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg02166.html

[Bug libstdc++/71579] type_traits miss checks for type completeness in some traits

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
This change broke a compiler test: g++.dg/cpp0x/noexcept15.C

I'll have to figure out how to update that test to keep testing what it was
meant to test, without triggering the library assertion.

[Bug other/90695] New: [10 regression] g++.dg/cpp0x/noexcept15.C fails starting with r271806

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 90695
   Summary: [10 regression] g++.dg/cpp0x/noexcept15.C fails
starting with r271806
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

r271806

 make -k check-gcc RUNTESTFLAGS=dg.exp=g++.dg/cpp0x/noexcept15.C


# of expected passes5
# of unexpected failures1
# of unsupported tests  1
FAIL: g++.dg/cpp0x/noexcept15.C  -std=c++14 (test for excess errors)


Executing on host:
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp0x/noexcept15.C   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 
-std=c++17  -pedantic-errors -Wno-long-long  -S -o noexcept15.s(timeout =
300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp0x/noexcept15.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0
-std=c++17 -pedantic-errors -Wno-long-long -S -o noexcept15.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp0x/noexcept15.C: In
instantiation of 'struct single':
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp0x/noexcept15.C:31:17:  
required from here
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp0x/noexcept15.C:9:8: error:
'single::elem' has incomplete type
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp0x/noexcept15.C:26:7: note:
forward declaration of 'class Blob'
compiler exited with status 1
PASS: g++.dg/cpp0x/noexcept15.C  -std=c++17  (test for errors, line 9)
PASS: g++.dg/cpp0x/noexcept15.C  -std=c++17  (test for warnings, line 26)
PASS: g++.dg/cpp0x/noexcept15.C  -std=c++17 (test for excess errors)

[Bug libstdc++/71579] type_traits miss checks for type completeness in some traits

[antoshkka at gmail dot com]

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

--- Comment #12 from Antony Polukhin  ---
(In reply to Jonathan Wakely from comment #11)
> This change broke a compiler test: g++.dg/cpp0x/noexcept15.C
> 
> I'll have to figure out how to update that test to keep testing what it was
> meant to test, without triggering the library assertion.

Something like the following should do the trick
- noexcept(std::is_nothrow_move_constructible::value)
+ noexcept(noexcept(std::declval() = std::declval()))

[Bug libstdc++/71579] type_traits miss checks for type completeness in some traits

[antoshkka at gmail dot com]

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

--- Comment #13 from Antony Polukhin  ---
I meant 
+ noexcept(noexcept(Tp(std::declval(

but now I'm not sure that it would test excactly the same thing.

[Bug testsuite/90696] New: fixinclude test failures--- sys/ucred.h

[democritus7 at att dot net]

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

Bug ID: 90696
   Summary: fixinclude test failures--- sys/ucred.h
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: democritus7 at att dot net
  Target Milestone: ---
 Build: gcc-9.1.0

Newly fixed header:  sys/ucred.h

There were fixinclude test FAILURES
Makefile:176: recipe for target 'check' failed
make[2]: *** [check] Error 1
make[2]: Leaving directory '/home/me/gcc/build/fixincludes'
Makefile:3795: recipe for target 'check-fixincludes' failed
make[1]: *** [check-fixincludes] Error 2
make[1]: Leaving directory '/home/me/gcc/build'
Makefile:2324: recipe for target 'do-check' failed
make: *** [do-check] Error 2

[Bug testsuite/90696] fixinclude test failures--- sys/ucred.h

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
IIRC this was fixed after the release was done.  It just the testcase that
needed to updated.

[Bug testsuite/90696] fixinclude test failures--- sys/ucred.h

[democritus7 at att dot net]

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

--- Comment #2 from dllbrt  ---
This failure occurred with two build configurations, a generic one and
../gcc-6.4.0/configure --prefix=/usr
--enable-languages=ada,c,c++,fortran,,go,java,objc,obj-c++ --enable-lto
--enable-__cxa_atexit --enable-build-with-cxx --with-long-double=128
--enable-decimal-float --enable-static-libjava --with-x --enable-gtk-cairo
--enable-checking=yes

The build and testing were done on i686 Mageia 6 Linux on an i5 system, target
same.

[Bug testsuite/90696] fixinclude test failures--- sys/ucred.h

[democritus7 at att dot net]

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

--- Comment #3 from dllbrt  ---
where would I get the corrected test suite?

[Bug middle-end/12849] testing divisibility by constant

[cassio.neri at gmail dot com]

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

--- Comment #7 from Cassio Neri  ---
Thanks for implementing the modular inverse algorithm in gcc. However, the
implementation has an issue. In some cases, for no obvious reason, the compiler
falls back to the old algorithm. For instance,

bool f1(unsigned n) { return n % 10 == 5; }

as expected, uses the modular inverse algorithm and translates to

f1(unsigned int):
  imull $-858993459, %edi, %edi
  subl $1, %edi
  rorl %edi
  cmpl $429496729, %edi
  setbe %al
  ret

whereas

bool f2(unsigned n) { return n % 10 == 6; }

doesn't use the modular inverse algorithm and is the same as in older versions
of gcc:

f2(unsigned int):
  movl %edi, %eax
  movl $3435973837, %edx
  imulq %rdx, %rax
  shrq $35, %rax
  leal (%rax,%rax,4), %eax
  addl %eax, %eax
  subl %eax, %edi
  cmpl $6, %edi
  sete %al
  ret

See on godbolt: https://godbolt.org/z/u-C54I

I would like make another observation. For some divisors (e.g. 7, 19, 21) the
modular inverse algorithm seems to be faster than the traditional one even when
the remainder r (in n % d == r) is not a compile time constant. In general this
happens in cases where the "magic number" M used by the traditional algorithm
to replace the division "n / d" with "n * M >> k" is such that M doesn't fit in
a register and extra operations are required to overcome this problem. In other
words, these are the divisors for which '"Add" indicator' in
https://www.hackersdelight.org/magic.htm shows 1.

I made some measurements and I hope to make my results available for your
consideration soon.

[Bug testsuite/90696] fixinclude test failures--- sys/ucred.h

[democritus7 at att dot net]

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

--- Comment #4 from dllbrt  ---
(In reply to dllbrt from comment #2)
> This failure occurred with two build configurations, a generic one and
> ../gcc-6.4.0/configure --prefix=/usr
> --enable-languages=ada,c,c++,fortran,,go,java,objc,obj-c++ --enable-lto
> --enable-__cxa_atexit --enable-build-with-cxx --with-long-double=128
> --enable-decimal-float --enable-static-libjava --with-x --enable-gtk-cairo
> --enable-checking=yes
> 
> The build and testing were done on i686 Mageia 6 Linux on an i5 system,
> target same.

Sorry, I copied the configuration line from the previous build to use with
9.1.0 edited to omit go and java

[Bug c/90677] [9/10 Regression] gcc-9.1.0 fails to build __gcc_diag__ souce: error: 'cgraph_node' is not defined as a type

[slyfox at inbox dot ru]

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

--- Comment #5 from Sergei Trofimovich  ---
No problem! Thank you for the very detailed explanation! Name stealing makes
sense.

I managed to craft a workaround for old gcc-4.6.4 source code locally [1] and
not blocked by proper fix.

[1] the workaround:
--- a/gcc/pretty-print.h
+++ b/gcc/pretty-print.h
@@ -305,7 +305,7 @@ extern void pp_base_append_text (pretty_printer *, const
char *, const char *);

 /* This header may be included before diagnostics-core.h, hence the duplicate
definitions to allow for GCC-specific formats.  */
-#if GCC_VERSION >= 3005
+#if (GCC_VERSION >= 3005) && (GCC_VERSION != 9001) /* 9.1.0 is buggy:
https://gcc.gnu.org/PR90677  */
 #define ATTRIBUTE_GCC_PPDIAG(m, n) __attribute__ ((__format__ (__gcc_diag__, m
,n))) ATTRIBUTE_NONNULL(m)
 #else
 #define ATTRIBUTE_GCC_PPDIAG(m, n) ATTRIBUTE_NONNULL(m)

[Bug c++/85254] boost::is_final does not work for template types

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

--- Comment #5 from Ville Voutilainen  ---
Mine. Patch available: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg02183.html

[Bug other/90695] [10 regression] g++.dg/cpp0x/noexcept15.C fails starting with r271806

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Target|powerpc64*-unknown-linux-gn |
   |u   |
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-31
   Host|powerpc64*-unknown-linux-gn |
   |u   |
Version|9.0 |10.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Build|powerpc64*-unknown-linux-gn |
   |u   |

--- Comment #1 from Jonathan Wakely  ---
The failure happens on all targets.

I need to figure out what it was originally testing, and then change the test
to be independent of the standard library headers.

C++ front end tests that depend on library headers are fragile, because the
library is a moving target.

[Bug target/89355] Unnecessary ENDBR

[hjl at gcc dot gnu.org]

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

--- Comment #6 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Fri May 31 23:59:16 2019
New Revision: 271828

URL: https://gcc.gnu.org/viewcvs?rev=271828&root=gcc&view=rev
Log:
i386: Don't insert ENDBR after NOTE_INSN_DELETED_LABEL

NOTE_INSN_DELETED_LABEL is used to mark what used to be a 'code_label',
but was not used for other purposes than taking its address which cannot
be used as target for indirect jumps.

Tested on Linux/x86-64 with -fcf-protection.

For x86-64 libc.so on glibc master branch (commit f43b8dd55588c3),

Before: 2961 endbr64
After:  2943 endbr64

gcc/

PR target/89355
* config/i386/i386-features.c (rest_of_insert_endbranch): Remove
NOTE_INSN_DELETED_LABEL check.

gcc/testsuite/

PR target/89355
* gcc.target/i386/cet-label-3.c: New test.
* gcc.target/i386/cet-label-4.c: Likewise.
* gcc.target/i386/cet-label-5.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/cet-label-3.c
trunk/gcc/testsuite/gcc.target/i386/cet-label-4.c
trunk/gcc/testsuite/gcc.target/i386/cet-label-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-features.c
trunk/gcc/testsuite/ChangeLog

[Bug c/90697] New: ia64: segmentation fault during GIMPLE pass: dom

[jason.duerstock at gmail dot com]

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

Bug ID: 90697
   Summary: ia64: segmentation fault during GIMPLE pass: dom
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.duerstock at gmail dot com
  Target Milestone: ---

Created attachment 46439
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46439&action=edit
gcc error report

While building ffmpeg-4.1.3:

during GIMPLE pass: dom
src/libavcodec/rle.c: In function ‘ff_rle_count_pixels’:
src/libavcodec/rle.c:27:5: internal compiler error: Segmentation fault
 int ff_rle_count_pixels(const uint8_t *start, int len, int bpp, int same)
 ^~~
cc1(13509): unaligned access to 0x215dc2d4, ip=0x41dce150
cc1(13509): unaligned access to 0x215dc2d4, ip=0x41dce180
cc1(13509): unaligned access to 0x215dc2d4, ip=0x41dce1b0
cc1(13509): unaligned access to 0x215ea6be, ip=0x41dcdf01
cc1(13509): unaligned access to 0x215ea6c6, ip=0x41dce150
0x2085b98f __libc_start_main
/build/glibc-SctTYI/glibc-2.28/csu/libc-start.c:308

[Bug target/90698] New: Darwin X86 backend lacks support for mcmodel={medium, large, kernel}

[iains at gcc dot gnu.org]

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

Bug ID: 90698
   Summary: Darwin X86 backend lacks support for mcmodel={medium,
large, kernel}
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

[Bug target/90698] Darwin X86 backend lacks support for mcmodel={medium, large, kernel}

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||x64_64-apple-darwin*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-01
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug target/90698] Darwin X86 backend lacks support for mcmodel={medium, large, kernel}

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||dominiq at lps dot ens.fr

--- Comment #1 from Iain Sandoe  ---
*** Bug 50077 has been marked as a duplicate of this bug. ***

[Bug target/50077] large model (-mcmodel=large) is broken on *86*-apple-darwin*

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from Iain Sandoe  ---
this is currently unimplemented for Darwin - posting an enhancement bug

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

[Bug target/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #22 from Iain Sandoe  ---
this is currently unimplemented for Darwin - posting an enhancement bug

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

[Bug target/90698] Darwin X86 backend lacks support for mcmodel={medium, large, kernel}

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||howarth.at.gcc.testresults@
   ||gmail.com

--- Comment #2 from Iain Sandoe  ---
*** Bug 63793 has been marked as a duplicate of this bug. ***

[Bug target/69061] Huge (~7GB of them) Static arrays are not fully usable on Darwin

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Iain Sandoe  ---
mcmodel=medium/large is currently unimplemented for Darwin - posting an
enhancement bug

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

[Bug target/90698] Darwin X86 backend lacks support for mcmodel={medium, large, kernel}

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||testuser021845 at gmail dot com

--- Comment #3 from Iain Sandoe  ---
*** Bug 69061 has been marked as a duplicate of this bug. ***

[Bug target/90698] Darwin X86 backend lacks support for mcmodel={medium, large, kernel}

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #4 from Iain Sandoe  ---
*** Bug 63893 has been marked as a duplicate of this bug. ***

[Bug target/63893] gcc.dg/pr61599-1.c fails on darwin, due to -mcmodel=medium

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||iains at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #5 from Iain Sandoe  ---
this is currently unimplemented for Darwin - posting an enhancement bug

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

[Bug target/90698] Darwin X86 backend lacks support for mcmodel={medium, large, kernel}

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
*** Bug 63794 has been marked as a duplicate of this bug. ***

[Bug target/63794] -mcmodel=large in gfortran on x86_64 emits references junk `@GOTOFF' after expression on darwin

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #6 from Iain Sandoe  ---
this is currently unimplemented for Darwin - posting an enhancement bug

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

[Bug bootstrap/57291] Failure in build stages 2 and 3 concerning pseudo-op: .balign

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||iains at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #2 from Iain Sandoe  ---
current open branches bootstrap successfully on i686-apple-darwin9 - for
example:

https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg02307.html

[Bug web/90699] New: typo: "taget" should be "target"

[hugh at mimosa dot com]

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

Bug ID: 90699
   Summary: typo: "taget" should be "target"
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hugh at mimosa dot com
  Target Milestone: ---

https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Common-Function-Attributes.html#index-copy-function-attribute

#define StrongAlias(TagetFunc, AliasDecl)   \
should be
#define StrongAlias(TargetFunc, AliasDecl)   \

[Bug c/90699] typo: "taget" should be "target"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-01
  Component|web |c
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/90697] ia64: segmentation fault during GIMPLE pass: dom

[jason.duerstock at gmail dot com]

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

--- Comment #1 from Jason Duerstock  ---
Changing -O3 to -O2 yields a successful build.

[Bug tree-optimization/90697] ia64: segmentation fault during GIMPLE pass: dom

[jason.duerstock at gmail dot com]

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

--- Comment #2 from Jason Duerstock  ---
Hopefully a more useful backtrace:

(gdb) bt
#0  0x4140a6b0 in set_value_range(value_range*, value_range_type,
tree_node*, tree_node*, bitmap_head*) ()
#1  0x41514260 in vr_values::update_value_range(tree_node const*,
value_range*) ()
#2  0x41a77320 in evrp_range_analyzer::record_ranges_from_stmt(gimple*,
bool) ()
#3  0x410c5650 in
dom_opt_dom_walker::before_dom_children(basic_block_def*) ()
#4  0x41a288f0 in dom_walker::walk(basic_block_def*) ()
#5  0x410c7590 in ?? ()
#6  0x40c15780 in execute_one_pass(opt_pass*) ()
#7  0x40c16d00 in ?? ()
#8  0x40c16d50 in ?? ()
#9  0x40c16e70 in execute_pass_list(function*, opt_pass*) ()
#10 0x404f0380 in cgraph_node::expand() ()
#11 0x404f3ce0 in ?? ()
#12 0x404f9500 in symbol_table::finalize_compilation_unit() ()
#13 0x40e2c270 in ?? ()
#14 0x4012a740 in toplev::main(int, char**) ()
#15 0x4012f750 in main ()