[Bug c/89340] ICE in function_and_variable_visibility, at ipa-visibility.c:707

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-14
 CC||jsm28 at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, FE should reject that similarly to:

$ of ‘bar’ was here
 void bar () { }
  ^~~
marxin@marxinbox:~/Programming/testcases> cat pr89340.c
__attribute__((weak))
void bar () { }
bar();

$ gcc pr89340.c
pr89340.c:3:1: warning: data definition has no type or storage class
 bar();
 ^~~
pr89340.c:3:1: warning: type defaults to ‘int’ in declaration of ‘bar’
[-Wimplicit-int]
pr89340.c:3:1: error: conflicting types for ‘bar’
pr89340.c:2:6: note: previous definition of ‘bar’ was here
 void bar () { }
  ^~~

[Bug c/89341] ICE in get, at cgraph.h:1332

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-14
 CC||jsm28 at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
It's invalid code as definition can't be an alias at the same time.
Clang provides nice diagnostics here:

$ clang pr89341.c
pr89341.c:1:16: error: definition 'foo' cannot also be an alias
__attribute__((weakref("bar")))
   ^
1 error generated.

[Bug tree-optimization/89314] [7/8/9 Regression] ICE in wide_int_to_tree_1, at tree.c:1561

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb 14 09:25:01 2019
New Revision: 268868

URL: https://gcc.gnu.org/viewcvs?rev=268868&root=gcc&view=rev
Log:
PR tree-optimization/89314
* fold-const.c (fold_binary_loc): Cast strlen argument to
const char * before dereferencing it.  Formatting fixes.

* gcc.dg/pr89314.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr89314.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/83698] bogus offset in -Wrestrict messages for strcat of unknown strings

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
(In reply to Markus Trippelsdorf from comment #0)

Hey, Markus is back!

[Bug middle-end/89303] [7 Regression] memory leak with shared_ptr and enable_shared_from_this

[redi at gcc dot gnu.org]

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

--- Comment #28 from Jonathan Wakely  ---
Author: redi
Date: Thu Feb 14 09:40:02 2019
New Revision: 268869

URL: https://gcc.gnu.org/viewcvs?rev=268869&root=gcc&view=rev
Log:
PR middle-end/89303 add testcase for std::enable_shared_from_this

* testsuite/20_util/enable_shared_from_this/89303.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/enable_shared_from_this/89303.cc
Modified:
trunk/libstdc++-v3/ChangeLog

[Bug fortran/89103] Allow blank format items in format strings

[mark.eggleston at codethink dot com]

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

MarkEggleston  changed:

   What|Removed |Added

  Attachment #45554|0   |1
is obsolete||

--- Comment #7 from MarkEggleston  ---
Created attachment 45711
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45711&action=edit
Patch to allow blank item in format

Add documentation changes.

[Bug fortran/89103] Allow blank format items in format strings

[mark.eggleston at codethink dot com]

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

MarkEggleston  changed:

   What|Removed |Added

  Attachment #45604|0   |1
is obsolete||

--- Comment #8 from MarkEggleston  ---
Created attachment 45712
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45712&action=edit
Change log for gcc/fortran for patch

Add changes to documentation.

[Bug fortran/89103] Allow blank format items in format strings

[mark.eggleston at codethink dot com]

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

MarkEggleston  changed:

   What|Removed |Added

  Attachment #45556|0   |1
is obsolete||

--- Comment #9 from MarkEggleston  ---
Created attachment 45713
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45713&action=edit
Change Log for gcc/testsuite for patch

Replace -fdec-blank-format-item with PR fortran/89103.

[Bug tree-optimization/89263] Simplify bool expression to OR

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
A job for phiopt.

[Bug middle-end/89270] [9 regression] AVR ICE: verify_gimple failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |9.0

--- Comment #1 from Richard Biener  ---
Not sure, but possibly not returning false here:

static bool
verify_gimple_assign_unary (gassign *stmt)
{
..
/* Allow conversions from pointer type to integral type only if
   there is no sign or zero extension involved.
   For targets were the precision of ptrofftype doesn't match that
   of pointers we need to allow arbitrary conversions to ptrofftype. 
*/
if ((POINTER_TYPE_P (lhs_type)
 && INTEGRAL_TYPE_P (rhs1_type))
|| (POINTER_TYPE_P (rhs1_type)
&& INTEGRAL_TYPE_P (lhs_type)
&& (TYPE_PRECISION (rhs1_type) >= TYPE_PRECISION (lhs_type)
|| ptrofftype_p (lhs_type
  return false;

elsewhere I suggested that instead of special-casing ptrofftype_p we need
this special case only if POINTERS_EXTEND_UNSIGNED is defined and for
Pmode and word_mode lhs_type mode.

Not sure how named address-spaces are handled here since
POINTERS_EXTEND_UNSIGNED
doesn't talk about them.

[Bug tree-optimization/89314] [7/8/9 Regression] ICE in wide_int_to_tree_1, at tree.c:1561

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb 14 10:04:35 2019
New Revision: 268870

URL: https://gcc.gnu.org/viewcvs?rev=268870&root=gcc&view=rev
Log:
PR tree-optimization/89314
* fold-const.c (fold_binary_loc): Cast strlen argument to
const char * before dereferencing it.  Formatting fixes.

* gcc.dg/pr89314.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr89314.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/fold-const.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/89314] [7 Regression] ICE in wide_int_to_tree_1, at tree.c:1561

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||8.2.1, 9.0
Summary|[7/8/9 Regression] ICE in   |[7 Regression] ICE in
   |wide_int_to_tree_1, at  |wide_int_to_tree_1, at
   |tree.c:1561 |tree.c:1561
  Known to fail|9.0 |

--- Comment #5 from Jakub Jelinek  ---
Fixed for 8.3+ so far.

[Bug fortran/89348] New: Fortran Command Options documentation fixes

[mark.eggleston at codethink dot com]

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

Bug ID: 89348
   Summary: Fortran Command Options documentation fixes
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mark.eggleston at codethink dot com
  Target Milestone: ---

Created attachment 45714
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45714&action=edit
Fortran options documentation fixes

Enabling of -fdec-include is missing from list of options enabled by -fdec.
When rendered as a PDF some lines are too long in the list of options
controlling Fortran dialect and in the list of options to request or suppress
errors and warnings.

A patch is attached.

[Bug fortran/89348] Fortran Command Options documentation fixes

[mark.eggleston at codethink dot com]

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

--- Comment #1 from MarkEggleston  ---
Created attachment 45715
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45715&action=edit
Change log for gcc/fortran for patch

Date has been omitted from change log. Can be added when committed.

[Bug ada/89349] New: raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master

[marxin at gcc dot gnu.org]

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

Bug ID: 89349
   Summary: raised STORAGE_ERROR : stack overflow or erroneous
memory access when building GCC 8 branch with GCC
master
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Using latest GCC trunk as stage1 compiler and doing:

$ ../configure --enable-languages=c,c++,ada --disable-multilib
--prefix=/home/marxin/bin/gcc2 --disable-bootstrap --disable-libsanitizer

$ make
...

one can see:

make[7]: Entering directory '/home/marxin/Programming/gcc2/objdir/gcc/ada/rts'
/home/marxin/Programming/gcc2/objdir/./gcc/xgcc
-B/home/marxin/Programming/gcc2/objdir/./gcc/
-B/home/marxin/bin/gcc2/x86_64-pc-linux-gnu/bin/
-B/home/marxin/bin/gcc2/x86_64-pc-linux-gnu/lib/ -isystem
/home/marxin/bin/gcc2/x86_64-pc-linux-gnu/include -isystem
/home/marxin/bin/gcc2/x86_64-pc-linux-gnu/sys-include-c -g -O2  -fpic  -W
-Wall -gnatpg -nostdinc   a-assert.adb -o a-assert.o

raised STORAGE_ERROR : stack overflow or erroneous memory access

[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
I forgot to mention that the make is done on gcc-8 branch.

[Bug go/89277] [9 Regression] libgo memory hogs in libgo testsuite (at least on s390x-linux-gnu)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/89278] ICE in gimplify_modify_expr, at gimplify.c:5821

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
The issue is certainly latent, thus no regression.  Usual way-outs are to throw
rewrite_to_non_trapping_overflow onto the expr before gimplification.  I will
handle this if nobody beats me to it.

[Bug middle-end/89284] gcc -fsanitize=undefined inhibits -Wuninitialized

[jg at jguk dot org]

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

--- Comment #4 from Jonny Grant  ---
Fantastic! Thank you.

[Bug middle-end/89284] gcc -fsanitize=undefined inhibits -Wuninitialized

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed for GCC9+.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[jakub at gcc dot gnu.org]

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

Bug 89284 Summary: gcc -fsanitize=undefined inhibits -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89284

   What|Removed |Added

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

[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-14
 CC||msebor at gcc dot gnu.org
  Known to work||8.2.0
   Target Milestone|--- |9.0
 Ever confirmed|0   |1
  Known to fail||9.0

[Bug tree-optimization/89350] New: [9 Regression] Wrong -Wstringop-overflow= warning since r261518

[marxin at gcc dot gnu.org]

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

Bug ID: 89350
   Summary: [9 Regression] Wrong -Wstringop-overflow= warning
since r261518
   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 see following wrong warning:

$ cat snippet.c
char buf[128];
char *src = "HCSparta";

int main(int argc, char **argv)
{
char *dst = buf + sizeof(buf);

if (argc)
{
  dst -= argc;
  __builtin_memcpy(dst, src, argc + 0);
}
}

$ gcc snippet.c  -O2 -Wstringop-overflow=2  -fno-common -g
snippet.c: In function ‘main’:
snippet.c:11:7: warning: ‘__builtin_memcpy’ writing 1 or more bytes into a
region of size 0 overflows the destination [-Wstringop-overflow=]
   11 |   __builtin_memcpy(dst, src, argc + 0);
  |   ^~~~

$ gcc snippet.c  -O2 -Wstringop-overflow=2  -fno-common -g -fsanitize=address
&& ./a.out
[OK]

While doing s/0/1:

$ cat snippet.c
char buf[128];
char *src = "HCSparta";

int main(int argc, char **argv)
{
char *dst = buf + sizeof(buf);

if (argc)
{
  dst -= argc;
  __builtin_memcpy(dst, src, argc + 1);
}
}

$ gcc snippet.c  -O2 -Wstringop-overflow=2  -fno-common -g
[OK]

But:

$ gcc snippet.c  -O2 -Wstringop-overflow=2  -fno-common -g -fsanitize=address
&& ./a.out
=
==6195==ERROR: AddressSanitizer: global-buffer-overflow on address
0x00404220 at pc 0x7763a5d0 bp 0x7fffdb70 sp 0x7fffd320
WRITE of size 2 at 0x00404220 thread T0
#0 0x7763a5cf in __interceptor_memcpy
/home/marxin/Programming/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:790
#1 0x4010b4 in main /tmp/snippet.c:11
#2 0x773b4b7a in __libc_start_main ../csu/libc-start.c:308
#3 0x401119 in _start (/tmp/a.out+0x401119)

0x00404220 is located 0 bytes to the right of global variable 'buf' defined
in 'snippet.c:1:6' (0x4041a0) of size 128
SUMMARY: AddressSanitizer: global-buffer-overflow
/home/marxin/Programming/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:790
in __interceptor_memcpy
...

[Bug tree-optimization/89278] ICE in gimplify_modify_expr, at gimplify.c:5821

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 45716
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45716&action=edit
gcc9-pr89278.patch

Well, if you want to be beaten in that, here is a patch.  I've changed only the
spots I have testsuite coverage for though.

[Bug ipa/89009] [7/8/9 Regression] Miscompilation (missing function call) with -fvisibility=hidden -fpic -O2 -fno-inline

[marxin at gcc dot gnu.org]

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

--- Comment #16 from Martin Liška  ---
Author: marxin
Date: Thu Feb 14 11:24:45 2019
New Revision: 268871

URL: https://gcc.gnu.org/viewcvs?rev=268871&root=gcc&view=rev
Log:
Backport r268762

2019-02-14  Martin Liska  

Backport from mainline
2019-02-11  Martin Liska  

PR ipa/89009
* ipa-cp.c (build_toporder_info): Remove usage of a param.
* ipa-inline.c (inline_small_functions): Likewise.
* ipa-pure-const.c (propagate_pure_const): Likewise.
(propagate_nothrow): Likewise.
* ipa-reference.c (propagate): Likewise.
* ipa-utils.c (struct searchc_env): Remove unused field.
(searchc): Always search across AVAIL_INTERPOSABLE.
(ipa_reduced_postorder): Always allow AVAIL_INTERPOSABLE as
the only called IPA pure const can properly not propagate
across interposable boundary.
* ipa-utils.h (ipa_reduced_postorder): Remove param.
2019-02-14  Martin Liska  

Backport from mainline
2019-02-11  Martin Liska  

PR ipa/89009
* g++.dg/ipa/pr89009.C: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/ipa/pr89009.C
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/ipa-cp.c
branches/gcc-8-branch/gcc/ipa-inline.c
branches/gcc-8-branch/gcc/ipa-pure-const.c
branches/gcc-8-branch/gcc/ipa-reference.c
branches/gcc-8-branch/gcc/ipa-utils.c
branches/gcc-8-branch/gcc/ipa-utils.h
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug lto/88858] ICE in rtl_verify_fallthru, at cfgrtl.c:2930 in Firefox build with LTO and PGO

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Thu Feb 14 11:25:18 2019
New Revision: 268872

URL: https://gcc.gnu.org/viewcvs?rev=268872&root=gcc&view=rev
Log:
Backport r268835

2019-02-14  Martin Liska  

Backport from mainline
2019-02-13  Martin Liska  

PR lto/88858
* cfgrtl.c (remove_barriers_from_footer): New function.
(try_redirect_by_replacing_jump): Use it.
(cfg_layout_redirect_edge_and_branch): Likewise.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/cfgrtl.c

[Bug rtl-optimization/89242] [7/8/9 Regression] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 5, not 2)

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Thu Feb 14 11:30:58 2019
New Revision: 268873

URL: https://gcc.gnu.org/viewcvs?rev=268873&root=gcc&view=rev
Log:
Call free_dominance_info when transformed in DCE (PR rtl-optimization/89242).

2019-02-14  Martin Liska  

PR rtl-optimization/89242
* dce.c (delete_unmarked_insns): Call free_dominance_info we
process a transformation.
2019-02-14  Martin Liska  

PR rtl-optimization/89242
* g++.dg/pr89242.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr89242.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dce.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/89242] [7/8 Regression] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 5, not 2)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[7/8/9 Regression] ICE in   |[7/8 Regression] ICE in
   |verify_dominators, at   |verify_dominators, at
   |dominance.c:1184 (error:|dominance.c:1184 (error:
   |dominator of 7 should be 5, |dominator of 7 should be 5,
   |not 2)  |not 2)
  Known to fail|9.0 |

--- Comment #4 from Martin Liška  ---
Fixed on trunk so far.

[Bug tree-optimization/89280] [7/8/9 Regression] ICE: Segmentation fault (in is_gimple_reg_type)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
*** Bug 89283 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/89283] [8/9 Regression] ICE: Segmentation fault (in stmt_could_throw_1_p)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
I think this is just a dup, we want to cover both testcases in the other PR,
but the bug is the same, for the returns_twice calls/__builtin_setjmp_receiver,
we need to be able to consider them as unreachable if they aren't reachable
through non-EDGE_ABNORMAL edges from the abnormal dispatcher.

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

[Bug middle-end/89303] [7 Regression] memory leak with shared_ptr and enable_shared_from_this

[redi at gcc dot gnu.org]

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

--- Comment #29 from Jonathan Wakely  ---
Author: redi
Date: Thu Feb 14 11:53:57 2019
New Revision: 268874

URL: https://gcc.gnu.org/viewcvs?rev=268874&root=gcc&view=rev
Log:
PR middle-end/89303 add testcase for std::enable_shared_from_this

* testsuite/20_util/enable_shared_from_this/89303.cc: New test.

Added:
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/enable_shared_from_this/89303.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog

[Bug tree-optimization/89278] ICE in gimplify_modify_expr, at gimplify.c:5821

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Thu, 14 Feb 2019, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89278
> 
> --- Comment #4 from Jakub Jelinek  ---
> Created attachment 45716
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45716&action=edit
> gcc9-pr89278.patch
> 
> Well, if you want to be beaten in that, here is a patch.  I've changed only 
> the
> spots I have testsuite coverage for though.

Works for me.

[Bug c/89342] ICE in maybe_default_option, at opts.c:347

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-14
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug other/89342] ICE in maybe_default_option, at opts.c:347

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 45717
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45717&action=edit
gcc9-pr89342.patch

Untested fix.

[Bug tree-optimization/89280] [7/8/9 Regression] ICE: Segmentation fault (in is_gimple_reg_type)

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
The issue is that r8 () is a source of abnormal edges which makes the abnormal
dispatcher reachable.  I think the testcase becomes clearer when one uses
setjmp instead of vfork since I'm not sure why we have full abnormal handling
for vfork at all.

It might work if we build the CFG first w/o any abnormal edges, then prune
unreachable blocks, and only after that do abnormal edge creation.

Also we could then build dominators on the CFG w/o abnormal edges and use
simple reachability analysis on that to determine if we need to add
outgoing abnormal edges to calls or not (like in this case the one out
of r8() is not needed).

OTOH with non-local goto the reachability analysis w/o abnormals would be
flawed...

[Bug ipa/89306] [8/9 regression] Hash based IPA summaries are too slow and consume up to 80% of IPA optimization time.

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 45718
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45718&action=edit
Tentative patch

[Bug c++/89285] [8/9 Regression] ICE after casting the this pointer in the constructor in C++17 mode

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug ipa/89306] [8/9 regression] Hash based IPA summaries are too slow and consume up to 80% of IPA optimization time.

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 45719
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45719&action=edit
libxul.so WPA (--enable-checking=release) before patch

[Bug tree-optimization/89280] [7/8/9 Regression] ICE: Segmentation fault (in is_gimple_reg_type)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
The problem is that it might be still reachable through both normal and
abnormal edges during cfg and might become unreachable only later (e.g.
inlining or whatever other opt), so we need something that will be able to cope
with it at any time.  Even if we improve decisions from which bbs to add edges
to the ABNORMAL_DISPATCHER, as we use one dispatcher for the whole function and
can mix non-local gotos etc. with returns_twice functions, I think we can't
avoid this problem, r8 e.g. could have a non-local goto to some other bb and so
would have EDGE_ABNORMAL edge to the dispatcher.

[Bug ipa/89306] [8/9 regression] Hash based IPA summaries are too slow and consume up to 80% of IPA optimization time.

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Created attachment 45720
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45720&action=edit
libxul.so WPA (--enable-checking=release) after patch

[Bug ipa/89306] [8/9 regression] Hash based IPA summaries are too slow and consume up to 80% of IPA optimization time.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #5 from Martin Liška  ---
So considering only fns with more that 0.05% I see before:

 0.83%  lto1-wpa lto1  [.]
hash_table, ipa_fn_summary*,
simple_hashmap_traits >,
ipa_fn_summary*> >::hash_entry, xcallocator>::find_with_hash
 0.37%  lto1-wpa lto1  [.]
hash_table, ipa_call_summary*,
simple_hashmap_traits >,
ipa_call_summary*> >::hash_entry, xcallocator>::find_slot_with_hash
 0.36%  lto1-wpa lto1  [.]
hash_table, ipa_call_summary*,
simple_hashmap_traits >,
ipa_call_summary*> >::hash_entry, xcallocator>::find_with_hash

After the patch:

 0.49%  lto1-wpa lto1  [.]
fast_call_summary::get_create

So there's an improvement, but it's quite small.
Can you Honza re-measure that for me please?

[Bug ipa/89306] [8/9 regression] Hash based IPA summaries are too slow and consume up to 80% of IPA optimization time.

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Having all *.o files in RAM, I see time change for WPA from 93.0 to 90.0s.
So relatively small improvement.

[Bug gcov-profile/89307] -fprofile-generate binary may be too slow in multithreaded environment due to cache-line conflicts on counters

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Jan Hubicka from comment #2)
> Created attachment 45703 [details]
> patch for tls counters (incomplete - no runtime bits)

Isn't the patch only a refactoring that is eliminating tls_model from
tree_decl_with_vis and moving that into cgraph_node?

[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc-
   |patches/2019-01/msg01666.ht |patches/2019-02/msg01019.ht
   |ml  |ml
   Last reconfirmed||2019-02-14
   Assignee|ibuclaw at gdcproject dot org  |ro at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #9 from Rainer Orth  ---
Mine, slightly revised patch posted.

[Bug c/89340] ICE in function_and_variable_visibility, at ipa-visibility.c:707

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
It should be actually rejected like:
__attribute__((weak)) static void foo () {}
void bar (void) { foo (); }
pr89340.c:1:35: error: weak declaration of ‘foo’ must be public
1 | __attribute__((weak)) static void foo () {}
  |   ^~~

[Bug c/89340] [7/8/9 Regression] ICE in function_and_variable_visibility, at ipa-visibility.c:707

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |7.5
Summary|ICE in  |[7/8/9 Regression] ICE in
   |function_and_variable_visib |function_and_variable_visib
   |ility, at   |ility, at
   |ipa-visibility.c:707|ipa-visibility.c:707

--- Comment #3 from Jakub Jelinek  ---
gcc 4.4 still accepted this, I think the ICE started with r154115.  As we do
reject static __attribute__((weak)) functions, I think we should reject this
too.

[Bug c/89340] [7/8/9 Regression] ICE in function_and_variable_visibility, at ipa-visibility.c:707

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 45721
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45721&action=edit
gcc9-pr89340.patch

Untested fix.

[Bug gcov-profile/89307] -fprofile-generate binary may be too slow in multithreaded environment due to cache-line conflicts on counters

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
I'm just looking at the google/gcc-4.9 branch:
https://android.googlesource.com/toolchain/gcc/+/master/gcc-4.9/

and they have a sampling approach:

/* Transform:

   ORIGINAL CODE

   Into:

   __gcov_sample_counter++;
   if (__gcov_sample_counter >= __gcov_sampling_period)
 {
   __gcov_sample_counter = 0;
   ORIGINAL CODE
 }

which effectively updates edge counters just for a limited time. I would expect
size increase:

Removing basic block 9
Removing basic block 10
main (int argc)
{
  unsigned int PROF_sample.2;
  unsigned int PROF_sample.1;
  long int PROF_edge_counter_6;
  long int PROF_edge_counter_7;
  long int PROF_edge_counter_8;
  long int PROF_edge_counter_9;

  :
  __gcov_indirect_call_profiler_v2 (1005944783, main);
  __gcov_indirect_call_callee = 0B;
  if (argc_2(D) != 0)
goto ;
  else
goto ;

  :
  a = 123;
  PROF_sample.2_13 = __gcov_sample_counter;
  PROF_sample.2_14 = PROF_sample.2_13 + 1;
  __gcov_sample_counter = PROF_sample.2_14;
  PROF_sample.2_15 = __gcov_sampling_period;
  if (PROF_sample.2_14 >= PROF_sample.2_15)
goto ;
  else
goto ;

  :
  goto ;

  :
  __gcov_sample_counter = 0;
  PROF_edge_counter_6 = __gcov0.main[0];
  PROF_edge_counter_7 = PROF_edge_counter_6 + 1;
  __gcov0.main[0] = PROF_edge_counter_7;
  goto ;

  :
  a = 0;
  PROF_sample.1_10 = __gcov_sample_counter;
  PROF_sample.1_11 = PROF_sample.1_10 + 1;
  __gcov_sample_counter = PROF_sample.1_11;
  PROF_sample.1_12 = __gcov_sampling_period;
  if (PROF_sample.1_11 >= PROF_sample.1_12)
goto ;
  else
goto ;

  :
  __gcov_sample_counter = 0;
  PROF_edge_counter_8 = __gcov0.main[1];
  PROF_edge_counter_9 = PROF_edge_counter_8 + 1;
  __gcov0.main[1] = PROF_edge_counter_9;

  :
  return 0;
}

[Bug gcov-profile/89307] -fprofile-generate binary may be too slow in multithreaded environment due to cache-line conflicts on counters

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
> 
> which effectively updates edge counters just for a limited time. I would
> expect

Ah now, it's really doing sampling. I guess it can lead to quite some profile
inconsistencies..

[Bug c/89341] [7/8/9 Regression] ICE in get, at cgraph.h:1332

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |7.5
Summary|ICE in get, at  |[7/8/9 Regression] ICE in
   |cgraph.h:1332   |get, at cgraph.h:1332

--- Comment #3 from Jakub Jelinek  ---
This used to be accepted before r154115 (so e.g. in GCC 4.2), then it started
to ICE:
pr89341.c:3:1: internal compiler error: in function_and_variable_visibility, at
ipa.c:662
then (likely) r169332 started rejecting this:
pr89341.c:2:13: warning: ‘weakref’ attribute ignored because function is
defined [-Wattributes]
pr89341.c:2:13: error: ‘foo’ aliased to undefined symbol ‘bar’
then r174952 started to ICE on this again.

[Bug middle-end/89351] New: internal compiler error: in exact_div, at poly-int.h:2139

[gsocshubham at gmail dot com]

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

Bug ID: 89351
   Summary: internal compiler error: in exact_div, at
poly-int.h:2139
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gsocshubham at gmail dot com
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
 Build: x86_64-linux-gnu

Created attachment 45722
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45722&action=edit
Preprocessed code of file named "sam.c" which caused internal compiler error

---COMMAND USED FOR COMPILATION---

~/gcc-9-trunk/build/gcc/xgcc -B ~/gcc-9-trunk/build/gcc/ sam.c -fgnu-tm -w
-Icsmith-crash-test/csmith/runtime/
during RTL pass: expand
sam.c: In function ‘func_33’:
sam.c:857:139: internal compiler error: in exact_div, at poly-int.h:2139
  857 | != l_130) , ((g_133[0][1] , l_134) != (p_36 != (void*)0))) > g_100.f3))
& ((void*)0 == l_135)) || 0xAC466B2A51B1567ELL) > g_56.f0);
  |  ~^~~

0x92f6f8 poly_int<1u, poly_result::is_poly>::type, poly_coeff_pair_traits::is_poly>::type>::result_kind>::type>
exact_div<1u, long, int>(poly_int_pod<1u, long> const&, int)
../../gcc/gcc/poly-int.h:2139
0x92f6f8 expand_expr_addr_expr_1
../../gcc/gcc/expr.c:8041
0x9220ed expand_expr_addr_expr
../../gcc/gcc/expr.c:8082
0x9220ed expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:11237
0x7dfb37 expand_normal
../../gcc/gcc/expr.h:285
0x7dfb37 precompute_register_parameters
../../gcc/gcc/calls.c:967
0x7dfb37 expand_call(tree_node*, rtx_def*, int)
../../gcc/gcc/calls.c:3998
0x7ccc0d expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/gcc/builtins.c:8337
0x921918 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:11005
0x92fb14 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/gcc/expr.c:5649
0x93194e expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.c:5432
0x7f4076 expand_call_stmt
../../gcc/gcc/cfgexpand.c:2722
0x7f4076 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3691
0x7f4076 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3850
0x7f6ef5 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5886
0x7fd1e6 execute
../../gcc/gcc/cfgexpand.c:6509
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

---REDUCED TEST CASE-

struct {
  signed : 5;
  unsigned b : 7
} c[][1];
a() {}
d() {
  __transaction_relaxed { a(c[0][1].b); }
}

--COMPILER BUILD OPTIONS-

Using built-in specs.
COLLECT_GCC=build/gcc/xgcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --enable-lto
--disable-bootstrap : (reconfigured) ../gcc/configure --enable-languages=c,c++
--enable-lto --disable-bootstrap
Thread model: posix
gcc version 9.0.1 20190214 (experimental) (GCC)

[Bug fortran/89352] New: Deferred length character array pointer error with gfortran

[clange001 at gmail dot com]

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

Bug ID: 89352
   Summary: Deferred length character array pointer error with
gfortran
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clange001 at gmail dot com
  Target Milestone: ---

I have two deferred length character arrays in gfortran.  I allocate one of
them, and then point the other one to it.  The pointer variable has the correct
array size, but not the correct character length.  The program terminates with
an error when trying to access the information in the pointer.

I see that there may be related bugs that have been fixed
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51976), but this one is present
now in version 8.

I'm testing this with:
GNU Fortran (MacPorts gcc8 8.2.0_2) 8.2.0

and also
GNU Fortran (MacPorts gcc8 8.2.0_3) 8.2.0


The code below works fine with Intel Fortran on Windows.

program test
  implicit none
  character(len=:), pointer, dimension(:) :: charvara
  character(len=:), pointer, dimension(:) :: charvara_ptr

  allocate(character(len=10) :: charvara(3))
  charvara(:) = '0123456789'
  print *, 'len(charvara) = ', len(charvara)
  print *, 'size(charvara) = ', size(charvara)
  print *, 'charvara = ', charvara

  charvara_ptr => charvara
  print *, 'associated = ', associated(charvara_ptr, charvara)
  print *, 'len(charvara_ptr) = ', len(charvara_ptr)
  print *, 'size(charvara_ptr) = ', size(charvara_ptr)
  print *, 'charvara_ptr = ', charvara_ptr

  print *, 'end'

end program test

I would expect the length, size, and contents of charvara_ptr to be the same as
charvara, but instead I get the following:

 len(charvara) =   10
 size(charvara) =3
 charvara = 012345678901234567890123456789
 associated =  T
 len(charvara_ptr) =   1708412736
 size(charvara_ptr) =3
test(71321,0x7fff9e47c380) malloc: *** mach_vm_map(size=140734901800960)
failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Operating system error: Cannot allocate memory
Memory allocation failure in xrealloc

Error termination. Backtrace:
#0  0x10bb11f8f
#1  0x10bb127fd
#2  0x10bb12987
#3  0x10bb119f9
#4  0x10bbc8950
#5  0x10bbbf147
#6  0x10bbc4b61
#7  0x10bbc7cd8
#8  0x10bbc877e
#9  0x10bb0ccab
#10  0x10bb0cd6e

[Bug lto/88677] [9 Regression] Divergence in -O2 and -O2 -flto early opts

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek  ---
Patch has been approved, are you going to commit it?

[Bug target/89353] New: Unnecessary ENDBR with -mmanual-endbr

[hjl.tools at gmail dot com]

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

Bug ID: 89353
   Summary: Unnecessary ENDBR with -mmanual-endbr
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-mic-2 gcc]$ cat x.c
#ifdef FOO
__attribute__ ((cf_check))
#endif
int test(int* val)
{
int status = 99;

if((val == 0))
{
status = 22;
goto end;
}

extern int x;
*val = x;

status = 0;
end:
return status;
}
[hjl@gnu-mic-2 gcc]$ ./xgcc -B./ -m32 -O2 -fcf-protection x.c -S -mmanual-endbr
[hjl@gnu-mic-2 gcc]$ cat x.s
.file   "x.c"
.text
.p2align 4
.globl  test
.type   test, @function
test:
.LFB0:
.cfi_startproc
movl4(%esp), %eax
testl   %eax, %eax
je  .L3
movlx, %edx
movl%edx, (%eax)
xorl%eax, %eax
ret
.p2align 4,,10
.p2align 3
.L3:
.L2:
endbr32 <<<<<<<< This should be there.
movl$22, %eax
ret
.cfi_endproc
.LFE0:
.size   test, .-test
.ident  "GCC: (GNU) 9.0.1 20190214 (experimental)"
.section.note.GNU-stack,"",@progbits
.section.note.gnu.property,"a"
.align 4
.long1f - 0f
.long4f - 1f
.long5
0:
.string  "GNU"
1:
.align 4
.long0xc002
.long3f - 2f
2:
.long0x3
3:
.align 4
4:
[hjl@gnu-mic-2 gcc]$

[Bug target/89353] Unnecessary ENDBR with -mmanual-endbr

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
(In reply to H.J. Lu from comment #0)
> [hjl@gnu-mic-2 gcc]$ cat x.c

> .L2:
>   endbr32  This should be there.
  This should NOT be there.
>   movl$22, %eax

[Bug middle-end/89351] internal compiler error: in exact_div, at poly-int.h:2139

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rth at gcc dot gnu.org,
   ||torvald at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Cleaned up testcase with -fgnu-tm:

struct S { int a : 5; unsigned b : 7; } c[1][1];

void
foo (int x)
{
}

void
bar (void)
{
  __transaction_relaxed {
foo (c[0][1].b);
  }
}

Seems the TM code can't deal with bitfields properly:
  _15 = __builtin__ITM_RU1 (&c[0][1].b);
taking address of a bitfield is invalid.  Dunno what exactly it should do,
perhaps tak address of the DECL_BIT_FIELD_REPRESENTATIVE and read the
DECL_BIT_FIELD_REPRESENTATIVE instead and then BIT_FIELD_REF or something
similar out of this?  And similarly deal somehow with the stores to bitfields
(that is actually a read modify write cycle that likely would need to be
exposed.

That said, -fgnu-tm is pretty much unmaintained for years, so maybe best would
be to remove that support (e.g. I believe it doesn't handle internal functions
at all, which appear commonly in the IL these days, doesn't handle various
builtins correctly, etc.).

[Bug rtl-optimization/89242] [7/8 Regression] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 5, not 2)

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Thu Feb 14 13:57:52 2019
New Revision: 268876

URL: https://gcc.gnu.org/viewcvs?rev=268876&root=gcc&view=rev
Log:
Backport r268873

2019-02-14  Martin Liska  

Backport from mainline
2019-02-14  Martin Liska  

PR rtl-optimization/89242
* dce.c (delete_unmarked_insns): Call free_dominance_info we
process a transformation.
2019-02-14  Martin Liska  

Backport from mainline
2019-02-14  Martin Liska  

PR rtl-optimization/89242
* g++.dg/pr89242.C: New test.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/dce.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/89354] New: Combine pass yields wrong code with -O2 and -msse2 for 32bit target

[d.sukhonin at gmail dot com]

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

Bug ID: 89354
   Summary: Combine pass yields wrong code with -O2 and -msse2 for
32bit target
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.sukhonin at gmail dot com
  Target Milestone: ---

Created attachment 45723
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45723&action=edit
Proposed patch for gcc 6.3 including a test

There is a problem with compiling this code (options -O2 -msse2 -m32):

$ gcc-6 -m32 -O2 -msse2 /src/gcc/gcc/testsuite/gcc.target/i386/sse2-extz_di.c
&& ./a.out
Aborted

#define BIT33 0x1ULL

#include 

static uint64_t const MASK33 = (1ULL << 33) - 1;
static uint64_t qword = 0;

static uint64_t
get_low33 (void)
{
  return qword & MASK33;
}

static void
__attribute__((noinline))
set_bit33 (void)
{
  qword = (qword & ~MASK33) | BIT33;
}

static void
main (int, char**)
{
  set_bit33 ();

  if (get_low33 () != BIT33))
abort ();
}

Investigation showed, that during combine pass for set_bit33 function wrong RTL
is yielded: the second operand of ior is truncated into dword, i.e. 0, and the
bit 33 is never switched on.

I have a fix attached. It does not allow narrowing while matching zero_extract
insn.
That is, before the fix the optimizer was dealing with this RTL inst (Note,
zero_extract:SI):
Trying 5, 6, 7 -> 8:
Failed to match this instruction:
(set (zero_extract:SI (mem/c:DI (plus:SI (reg:SI 87)
(const:SI (unspec:SI [
(symbol_ref:SI ("qword") [flags 0x2]  )
] UNSPEC_GOTOFF))) [3 qword+0 S8 A64])
(const_int 33 [0x21])
(const_int 0 [0]))
(const_int 0 [0]))


Now zero_extract has DI mode because the inner instruction mem has larger, DI,
mode size:

Trying 5, 6, 7 -> 8:
Failed to match this instruction:
(set (zero_extract:DI (mem/c:DI (symbol_ref:SI ("qword") [flags 0x2]  ) [3 qword+0 S8 A64])
(const_int 33 [0x21])
(const_int 0 [0]))
(const_int 4294967296 [0x1]))

References:

* get_best_reg_extraction_insn is called here
  https://github.com/gcc-mirror/gcc/blob/master/gcc/combine.c#L7819

* zero_extract is tried out
  https://github.com/gcc-mirror/gcc/blob/master/gcc/combine.c#L7983

$ gcc-6 -v
Using built-in specs.
COLLECT_GCC=gcc-6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)

It is reproduced on all versions >= 6.3.
I didn't test on older ones.

[Bug fortran/72715] ICE in gfc_trans_omp_do, at fortran/trans-openmp.c:3164

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code, openmp |openacc
 Status|NEW |ASSIGNED
   Last reconfirmed|2016-07-27 00:00:00 |2019-2-14
 CC||burnus at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org

--- Comment #5 from Thomas Schwinge  ---
Thanks for the report (Gerhard), and patch (Cesar); ICE addressed in trunk
r268875, like done for OpenMP in PR60127, trunk r210331.

[Bug gcov-profile/89307] -fprofile-generate binary may be too slow in multithreaded environment due to cache-line conflicts on counters

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka  ---
> Ah now, it's really doing sampling. I guess it can lead to quite some profile
> inconsistencies..
Yep, it is not coolest solution. I would not worry too much about
precision loss unless you get some weird interference between the
sampling counter and actual program behaviour.  Adding conditionals
everywhere is not very good and I am not sure how well CPU will predict
such branches.

Honza

[Bug target/89355] New: Unnecessary ENDBR

[hjl.tools at gmail dot com]

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

Bug ID: 89355
   Summary: Unnecessary ENDBR
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, xuepeng.guo at intel dot com
  Target Milestone: ---
Target: i386,x86-64

[hjl@gnu-cfl-2 gcc]$ cat x.i
int
test (int* val)
{
  int status = 99;

  if((val == 0))
{
  status = 22;
  goto end;
}

  extern int x;
  *val = x;

  status = 0;
end:
  return status;
}

[hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S -O2 -fcf-protection  x.i
[hjl@gnu-cfl-2 gcc]$ cat x.s
.file   "x.i"
.text
.p2align 4
.globl  test
.type   test, @function
test:
.LFB0:
.cfi_startproc
endbr64
testq   %rdi, %rdi
je  .L3
movlx(%rip), %eax
movl%eax, (%rdi)
xorl%eax, %eax
ret
.p2align 4,,10
.p2align 3
.L3:
.L2:
endbr64  <<< Why is ENDBR here?  There is no indirect branch.
movl$22, %eax
ret
.cfi_endproc
.LFE0:
.size   test, .-test
.ident  "GCC: (GNU) 9.0.1 20190214 (experimental)"
.section.note.GNU-stack,"",@progbits
.section.note.gnu.property,"a"
.align 8
.long1f - 0f
.long4f - 1f
.long5
0:
.string  "GNU"
1:
.align 8
.long0xc002
.long3f - 2f
2:
.long0x3
3:
.align 8
4:
[hjl@gnu-cfl-2 gcc]$

[Bug lto/88677] [9 Regression] Divergence in -O2 and -O2 -flto early opts

[hubicka at gcc dot gnu.org]

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

--- Comment #16 from Jan Hubicka  ---
Author: hubicka
Date: Thu Feb 14 14:49:03 2019
New Revision: 268880

URL: https://gcc.gnu.org/viewcvs?rev=268880&root=gcc&view=rev
Log:
PR lto/88677
Fix PR number.

Modified:
trunk/gcc/ChangeLog

[Bug lto/88677] [9 Regression] Divergence in -O2 and -O2 -flto early opts

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #17 from Jan Hubicka  ---
Fixed.

[Bug rtl-optimization/89354] [7/8/9 Regression] Combine pass yields wrong code with -O2 and -msse2 for 32bit target

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-14
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.5
Summary|Combine pass yields wrong   |[7/8/9 Regression] Combine
   |code with -O2 and -msse2|pass yields wrong code with
   |for 32bit target|-O2 and -msse2 for 32bit
   ||target
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r228231, will have a look.

Slightly simplified testcase:
static unsigned long long q = 0;

__attribute__((noipa)) static void
bar (void)
{
  q = (q & ~0x1ULL) | 0x1ULL;
}

int
main ()
{
  __asm volatile ("" : "+m" (q));
  bar ();
  if (q != 0x1ULL)
__builtin_abort ();
  return 0;
}

[Bug rtl-optimization/89354] [7/8/9 Regression] Combine pass yields wrong code with -O2 and -msse2 for 32bit target

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
-mno-stv also cures it.

[Bug c++/89356] New: [9 Regression] sorry, unimplemented: mangling implicit_conv_expr in nodejs8 package since r268321

[marxin at gcc dot gnu.org]

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

Bug ID: 89356
   Summary: [9 Regression] sorry, unimplemented: mangling
implicit_conv_expr in nodejs8 package since r268321
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Starting from the revision I see:

$ cat sorry.ii
typedef unsigned a;
template  struct h {};
template  auto c(b f) -> h;
typedef char byte;
enum d : byte;
d g(byte);
h e = c<6>(g);

$ g++ sorry.ii -c
sorry.ii: In instantiation of ‘h c(b) [with
int  = 6; b = d (*)(char)]’:
sorry.ii:3:30: sorry, unimplemented: mangling implicit_conv_expr
3 | template  auto c(b f) -> h;
  |

[Bug c++/89356] [9 Regression] sorry, unimplemented: mangling implicit_conv_expr in nodejs8 package since r268321

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||8.2.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2019-02-14
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug c/89341] [7/8/9 Regression] ICE in get, at cgraph.h:1332

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
The -Wattributes warning would be emitted here in cgraphunit.c:
process_function_and_variable_attributes:

777   if (lookup_attribute ("weakref", DECL_ATTRIBUTES (decl))
778   && (node->definition && !node->alias))
779 {
780   warning_at (DECL_SOURCE_LOCATION (node->decl),
OPT_Wattributes,
781   "% attribute ignored"
782   " because function is defined");
783   DECL_WEAK (decl) = 0;
784   DECL_ATTRIBUTES (decl) = remove_attribute ("weakref",
785  DECL_ATTRIBUTES
(decl));
786 }

but the alias stops the clause from firing:

(gdb) p node
$3 = 
(gdb) p node->definition
$4 = 1
(gdb) p node->alias
$5 = 1

The alias exclusion was added to the warning in r174952 (aka
c70f46b057cd12973d33c01c8fa0da5c14ba3944) by Honza:

@@ -880,7 +977,7 @@ process_function_and_variable_attributes (struct
cgraph_node *first,
 cgraph_mark_needed_node (node);
}
   if (lookup_attribute ("weakref", DECL_ATTRIBUTES (decl))
- && node->local.finalized)
+ && (node->local.finalized && !node->alias))
{
  warning_at (DECL_SOURCE_LOCATION (node->decl), OPT_Wattributes,
  "% attribute ignored"

[Bug c++/89356] [9 Regression] sorry, unimplemented: mangling implicit_conv_expr in nodejs8 package since r268321

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Amusingly, we already handle 
3440   /* Strip a conversion added by convert_nontype_argument.  */
3441   if (TREE_CODE (node) == IMPLICIT_CONV_EXPR)
3442 node = TREE_OPERAND (node, 0);

in write_template_arg.

[Bug c++/89356] [9 Regression] sorry, unimplemented: mangling implicit_conv_expr in nodejs8 package since r268321

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug rtl-optimization/89354] [7/8/9 Regression] Combine pass yields wrong code with -O2 and -msse2 for 32bit target

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug c/89341] [7/8/9 Regression] ICE in get, at cgraph.h:1332

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Both decls of "foo" are using the same FUNCTION_DECL.

node->alias is set in varasm.c: assemble_alias here:

5991cgraph_node::get_create (decl)->alias = true;

when processing the second decl of "foo" here:

 void foo ();

since the FUNCTION_DECL for "foo" has an "alias" attribute, given to it by
handle_weakref_attribute when parsing the first decl of here:

__attribute__((weakref("bar")))
static void foo () { }

[Bug lto/89335] [9 Regression] ICE with LTO -Wsuggest-final-methods: ICE during IPA pass devirt in types_same_for_odr, at ipa-devirt.c:391

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Depends on||87089

--- Comment #2 from Jan Hubicka  ---
I think it is also caused by fact that the virtual destructor has no
DECL_VIRTUAL flag.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87089
[Bug 87089] [9 regression] tree check: expected class 'type', have
'declaration' (namespace_decl) in type_with_linkage_p, at ipa-utils.h

[Bug target/89357] New: alignas for automatic variables with alignment greater than 16 fails

[kretz at kde dot org]

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

Bug ID: 89357
   Summary: alignas for automatic variables with alignment greater
than 16 fails
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---
Target: aarch64-*-*, arm-*-*

Test case (cf. https://godbolt.org/z/ubJge4):

void g(int &);

auto f0() {
  __attribute__((aligned(128))) int x;
  g(x);
}

auto f1() {
  alignas(128) int x;
  g(x);
}

In f0, x is aligned on 128 Bytes, in f1 it is aligned on 16 Bytes. GCC emits
the warning "requested alignment 128 is larger than 16 [-Wattributes]". The
warning is not helpful as it only states an obvious fact (128 > 16). In any
case, it is unclear why the alignment is rejected in the first place.

http://eel.is/c++draft/dcl.align#2.2 says "[...] the implementation does not
support that alignment in the context of the declaration, the program is
ill-formed". Thus, compiling with alignment of 16 is non-conforming. If the
alignment is unsupported this needs to be a error.

My preferred solution would be to just align x in f1 to 128 Bytes. Why should
alignas and the aligned attribute behave differently?

On x86, power, mips, and msp430 (tested on Compiler Explorer) f0 and f1 are
equivalent.

[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-02-14
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
What happens without --disable-bootstrap?

[Bug rtl-optimization/89354] [7/8/9 Regression] Combine pass yields wrong code with -O2 and -msse2 for 32bit target

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 45724
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45724&action=edit
gcc9-pr89354.patch

Untested fix.  I think the bug is in make_extraction, which for VOIDmode,
(mem:DI ...), 0, NULL_RTX, 33, 1, 1, 0 arguments returns strangely (for 32-bit
target) (zero_extract:SI (mem:DI ...) (const_int 33) (const_int 0)).  That
looks bogus to me, because those 33 bits can't fit into SImode.

Then make_field_assignment does:
  assign = make_extraction (VOIDmode, dest, pos, NULL_RTX, len, 1, 1, 0);
  if (assign == 0)
return x;

  machine_mode new_mode = (GET_CODE (assign) == STRICT_LOW_PART
   ? GET_MODE (XEXP (assign, 0)) : GET_MODE (assign));

which sets new_mode to SImode too, and
  src = canon_reg_for_combine (simplify_shift_const (NULL_RTX, LSHIFTRT,
 src_mode, other, pos),
   dest);
  src = force_to_mode (src, new_mode,
   len >= HOST_BITS_PER_WIDE_INT
   ? HOST_WIDE_INT_M1U
   : (HOST_WIDE_INT_1U << len) - 1,
   0);
other is (const_int 0x1) and as pos is 0, the first call just returns
the same constant, but force_to_mode turns it into const0_rtx, which is where
we lose the |= 0x1ULL.

[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels

[seurer at gcc dot gnu.org]

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

--- Comment #3 from seurer at gcc dot gnu.org ---
Created attachment 45725
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45725&action=edit
Patch to disable ALSR for asan/tsan on powerpc64

[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels

[seurer at gcc dot gnu.org]

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

--- Comment #4 from seurer at gcc dot gnu.org ---
The above patch pulls in just enough of the changes from trunk to disable ASLR
for powerpc64 while leaving things alone for everyone else.

[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Ugh, does this mean if ASLR is enabled you get
"WARNING: Program is being run with address space layout "
"randomization (ASLR) enabled which prevents the thread and "
"memory sanitizers from working on powerpc64le.\n"
"ASLR will be disabled and the program re-executed.\n"
message from every -fsanitize=address/-fsanitize=thread linked program?
If so, that is extremely nasty.  Couldn't that be done only if you determine
the areas you need to mmap the shadow etc. memory can't be mapped?
Of course, that applies to trunk as well as possible backport.

[Bug ipa/89330] IPA inliner touches released cgraph_edges

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #4 from Martin Jambor  ---
The indirect inlining thingy was indeed written by me, that is true,
but that was before speculative inlining was creating and disposing of
edges at difficult to predict times.  What happens is that:

1. In the course of inlining an edge, we call ipa_propagate_indirect_call_infos
   to adjust jump functions and to add newly discovered direct edges to
   new_edges vector so that they can be added to the heap later.

2. The speculation code in try_make_edge_direct_virtual_call decides
   to create speculation, so a new speculative edge is created and
   added to the vector.

3. Immediately after calling ipa_propagate_indirect_call_infos,
   check_speculations is called, which finds the edge
   !speculation_useful_p and removes it.  But the edge already is in
   the vector.

Let me see if I can add the respective usefulness test to the code
deciding to speculate.

[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I thought that typically you can't build older gcc with newer gcc when using
ada, at least I remember seeing issues with gcc 7 built with gcc 8 too when ada
is enabled.

[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels

[seurer at gcc dot gnu.org]

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

--- Comment #6 from seurer at gcc dot gnu.org ---
I think it only comes out if you specify the verbose sanitizer option on the
compilation.  If I can remember how to specify that I will try it.

[Bug target/88850] [9 Regression] Hard register coming out of expand causing reload to fail.

[tnfchris at gcc dot gnu.org]

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

--- Comment #11 from Tamar Christina  ---
Author: tnfchris
Date: Thu Feb 14 17:17:20 2019
New Revision: 268884

URL: https://gcc.gnu.org/viewcvs?rev=268884&root=gcc&view=rev
Log:
Arm: Add HF modes to ANY iterators 

The iterator ANY64 are used in various general split patterns and is supposed
to contain all 64 bit modes.

For some reason the pattern has HI but not HF.  This adds HF so that general
64 bit splits are generated for these modes as well.  These are required
by various split patterns that expect them to be there.

gcc/ChangeLog:

PR target/88850
* config/arm/iterators.md (ANY64): Add V4HF.

gcc/testsuite/ChangeLog:

PR target/88850
* gcc.target/arm/pr88850-2.c: New test.
* lib/target-supports.exp
(check_effective_target_arm_neon_softfp_fp16_ok_nocache,
check_effective_target_arm_neon_softfp_fp16_ok,
add_options_for_arm_neon_softfp_fp16): New.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr88850-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/iterators.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp

[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Still, a reexec is costly and might break some programs.  If the ASLR makes
problems only sometimes, it might be better to try to map stuff it wants and if
that fails, before reporting failure try this CheckASLR.

[Bug ipa/89330] IPA inliner touches released cgraph_edges

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka  ---
> Let me see if I can add the respective usefulness test to the code
> deciding to speculate.

I see, it is mine, sorry for blaming you :)

One alternative would be also to put the indirect part of pseculative
edge to the vector and lookup the direct one if speculation survives.
But checking prior creation should work too.

Thanks for looking into this!

[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code

[rafael at espindo dot la]

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

Rafael Avila de Espindola  changed:

   What|Removed |Added

  Attachment #45710|0   |1
is obsolete||

--- Comment #7 from Rafael Avila de Espindola  ---
Created attachment 45726
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45726&action=edit
testcase that fails on trunk

[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels

[seurer at gcc dot gnu.org]

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

--- Comment #8 from seurer at gcc dot gnu.org ---
This is the way it came from upstream (llvm) and the solution for powerpc64 was
copied from what aarch64 did before.

What is really needed is a workable solution from whoever does sanitizer
development that works despite the huge ranges of addresses that ASLR now uses.

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[rafael at espindo dot la]

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

Bug 89337 Summary: Bogus "exceeds maximum object size" on unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337

   What|Removed |Added

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

[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code

[rafael at espindo dot la]

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

Rafael Avila de Espindola  changed:

   What|Removed |Added

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

--- Comment #8 from Rafael Avila de Espindola  ---
The previous testcase passes on trunk, but the original doesn't.

The original has a "if (boost::algorithm::ends_with(name, "%2A"))" instead of a
direct "if(name.size() > 3)".

The reduced testcase uses a find to avoid boost::algorithm and keep the
testcase size sane.

In the end it seems that gcc is doing an heroic effort to understand the code
and issue an warning if it can't prove that the bogus memset is not reached. I
don't think that is workable in practice (for sure not in theory): There is
always something that is obvious to the developer but not to gcc.

IMHO gcc should be issuing warnings only when it shows that a statement can be
reached, not when it fails to show the statement cannot be reached.

[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4

[ro at gcc dot gnu.org]

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

--- Comment #10 from Rainer Orth  ---
Author: ro
Date: Thu Feb 14 17:47:49 2019
New Revision: 268886

URL: https://gcc.gnu.org/viewcvs?rev=268886&root=gcc&view=rev
Log:
Provide __start_minfo/__stop_minfo for linkers that don't (PR d/87864)

libphobos:
PR d/87864
* configure.ac (DRTSTUFF_SPEC): New variable.
Substitute it.
* libdruntime/m4/druntime/os.m4 (DRUNTIME_OS_MINFO_BRACKETING):
New automake conditional.
* configure: Regenerate.
* libdruntime/gcc/drtstuff.c: New file.
* libdruntime/Makefile.am [!DRUNTIME_OS_MINFO_BRACKETING]
(DRTSTUFF, toolexeclib_DATA): New variables.
(gcc/drtbegin.lo, gcc/drtend.lo): New rules.
(libgdruntime_la_LDFLAGS): Use -Wc instead of -Xcompiler.
Add -dstartfiles -B../src -Bgcc.
(libgdruntime_la_DEPENDENCIES): New variable.
(unittest_static_LDFLAGS): Use -Wc instead of -Xcompiler.
(libgdruntime_t_la_LDFLAGS): Likewise.
(unittest_LDFLAGS): Likewise.
* src/Makefile.am (libgphobos_la_LDFLAGS): Use -Wc instead of
-Xcompiler.
Add -dstartfiles -B../libdruntime/gcc.
(unittest_static_LDFLAGS): Use -Wc instead of -Xcompiler.
(libgphobos_t_la_LDFLAGS): Likewise.
(unittest_LDFLAGS): Likewise.
* libdruntime/Makefile.in, src/Makefile.in: Regenerate.
* Makefile.in, testsuite/Makefile.in: Regenerate.
* libdruntime/rt/sections_elf_shared.d (Minfo_Bracketing): Don't
assert.
* libdruntime/gcc/config.d.in (Minfo_Bracketing): Remove.
* src/drtstuff.spec: New file.
* src/libgphobos.spec.in (DRTSTUFF_SPEC): Substitute.
(*lib): Only pass SPEC_PHOBOS_DEPS without -debuglib, -defaultlib,
-nophoboslib.
* testsuite/testsuite_flags.in <--gdcldflags> (GDCLDFLAGS): Add
-B${BUILD_DIR}/libdruntime/gcc.

gcc/d:
PR d/87864
* lang.opt (dstartfiles): New option.
* d-spec.cc (need_spec): New variable.
(lang_specific_driver) : Enable need_spec.
(lang_specific_pre_link): Also load libgphobos.spec if need_spec.

gcc/testsuite:
PR d/87864
* lib/gdc.exp (gdc_link_flags): Add path to drtbegin.o/drtend.o if
present.

Added:
trunk/libphobos/libdruntime/gcc/drtstuff.c
trunk/libphobos/src/drtstuff.spec
Modified:
trunk/gcc/d/ChangeLog
trunk/gcc/d/d-spec.cc
trunk/gcc/d/lang.opt
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/gdc.exp
trunk/libphobos/ChangeLog
trunk/libphobos/configure   (contents, props changed)
trunk/libphobos/configure.ac
trunk/libphobos/libdruntime/Makefile.am
trunk/libphobos/libdruntime/Makefile.in
trunk/libphobos/libdruntime/gcc/config.d.in
trunk/libphobos/libdruntime/rt/sections_elf_shared.d
trunk/libphobos/m4/druntime/os.m4
trunk/libphobos/src/Makefile.am
trunk/libphobos/src/Makefile.in
trunk/libphobos/src/libgphobos.spec.in
trunk/libphobos/testsuite/testsuite_flags.in   (contents, props changed)

[Bug c++/78147] The -Wshadow warning is too aggressive with constructor parameters

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=72789

--- Comment #4 from Eric Gallager  ---
(In reply to Martin Sebor from comment #1)
> Confirmed.  Paul, please post your patch to gcc-patches.  Personally, I
> think providing it under Clang's -Wunused-private-field for compatibility
> would be preferable to disabling the warning altogether.
> 

For reference, the bug to add -Wunused-private-field is bug 72789, btw.

[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #11 from Rainer Orth  ---
Fixed for GCC 9.1.

[Bug fortran/89352] Deferred length character array pointer error

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
The code works as expected with gfortran from trunk.  Whether
the patch that fixed the bud will be back ported remains to
be detemined.

[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #3)
> I thought that typically you can't build older gcc with newer gcc when using
> ada, at least I remember seeing issues with gcc 7 built with gcc 8 too when
> ada is enabled.

In openSUSE, we currently build gcc7 with gcc8 and it's fine:
https://build.opensuse.org/package/show/devel:gcc/gcc7

I saw failing gcc8 package being built with gcc9. Note that the gcc8 package is
using normal bootstrap.

[Bug ada/89349] raised STORAGE_ERROR : stack overflow or erroneous memory access when building GCC 8 branch with GCC master

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Eric Botcazou from comment #2)
> What happens without --disable-bootstrap?

My reproducer described in the first comment was:
1) build gcc trunk w/o bootstrap and install it
2) use the compiler and build gcc-8 branch w/o bootstrap
3) Ada FE is successfully built, but Ada runtime build fails (with gcc-8 Ada
FE)

[Bug rtl-optimization/89313] [9 Regression] ICE in process_alt_operands, at lra-constraints.c:2962

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner  ---
I'm testing a patch that gives a better error message and eliminates the ICE:

[bergner@dagger1 PR89313]$ cat pr89313.i 
long f;
long g (void)
{
  register long z asm ("rax");
  asm ("foo %0, %1, %2" : "=&r" (z) : "r" (f), "0" (f));
  return z;
}
[bergner@dagger1 PR89313]$
/home/bergner/gcc/build/gcc-fsf-mainline-pr89313-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr89313-debug/gcc -O2 -S pr89313.i 
pr89313.i: In function ‘g’:
pr89313.i:5:3: error: incompatible constraint usage for input operands when
paired with an early clobber operand
5 |   asm ("foo %0, %1, %2" : "=&r" (z) : "r" (f), "0" (f));
  |   ^~~
[bergner@dagger1 PR89313]$

[Bug rtl-optimization/85805] [7/8 Regression] Wrong code for 64 bit comparisons on avr-gcc

[segher at gcc dot gnu.org]

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

--- Comment #13 from Segher Boessenkool  ---
Author: segher
Date: Thu Feb 14 18:46:18 2019
New Revision: 26

URL: https://gcc.gnu.org/viewcvs?rev=26&root=gcc&view=rev
Log:
Backport from trunk
2018-07-26  Segher Boessenkool  

PR rtl-optimization/85805
* combine.c (reg_nonzero_bits_for_combine): Only use the last set
value for hard registers if that was written in the same mode.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/combine.c

[Bug target/88145] ICE: unrecognizable insn (mffs) targeting 32-bit BE FPU-less powerpc CPUs

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Segher Boessenkool  ---
This doesn't backport to 8.  Closing as fixed.

[Bug target/88892] [8 Regression] Double-to-float conversion uses wrong rounding mode when followed by memcpy

[segher at gcc dot gnu.org]

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

--- Comment #16 from Segher Boessenkool  ---
Author: segher
Date: Thu Feb 14 18:57:54 2019
New Revision: 268889

URL: https://gcc.gnu.org/viewcvs?rev=268889&root=gcc&view=rev
Log:
Backport from trunk
2019-01-18  Segher Boessenkool  

PR target/88892
* config/rs6000/rs6000.md (*movsi_from_df): Allow only register
operands.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/rs6000/rs6000.md

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

[segher at gcc dot gnu.org]

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

--- Comment #15 from Segher Boessenkool  ---
Author: segher
Date: Thu Feb 14 19:03:54 2019
New Revision: 268890

URL: https://gcc.gnu.org/viewcvs?rev=268890&root=gcc&view=rev
Log:
Backport from trunk
2018-08-31  Segher Boessenkool  

PR target/86684
PR target/87149
* config/rs6000/rs6000.md (lrounddi2): Gate on TARGET_FPRND.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/rs6000/rs6000.md