[Bug c/88568] [7 Regression] 'dllimport' no longer implies 'extern' in C

[steve at sk2 dot org]

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

Stephen Kitt  changed:

   What|Removed |Added

 CC||steve at sk2 dot org

--- Comment #14 from Stephen Kitt  ---
Created attachment 45890
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45890&action=edit
Pre-processed source producing ICE

This appears to cause an ICE when cross-compiling Qt. To reproduce, download
adn extract
https://download.qt.io/archive/qt/5.12/5.12.1/submodules/qtbase-everywhere-src-5.12.1.tar.xz
then configure as follows:

./configure -release -optimized-tools -platform linux-g++ -opensource
-confirm-license -xplatform win32-g++ -qt-libpng -qt-libjpeg -qt-freetype
-device-option CROSS_COMPILE=i686-w64-mingw32- -no-compile-examples -nomake
examples -nomake tests -opengl dynamic -no-eglfs

Running make will eventually fail (it doesn’t take very long) with a GCC ICE:

i686-w64-mingw32-g++ -c -include .pch/release/qt_pch.h -pipe
-fno-keep-inline-dllexport -msse2 -mstackrealign -mfpmath=sse -O2 -std=c++1z
-fno-exceptions -Wall -W -Wextra -Wvla -Wdate-time -Wshift-overflow=2
-Wduplicated-cond -Wno-stringop-overflow -DUNICODE -D_UNICODE -DWIN32
-DMINGW_HAS_SECURE_API=1 -DWINVER=0x0601 -D_WIN32_WINNT=0x0601
-DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DQT_USE_SYSTEM_PROXIES
-DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_NETWORK_LIB
-DQT_BUILDING_QT -D_CRT_SECURE_NO_WARNINGS -D_USE_MATH_DEFINES
-DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x040800 -DQT_NO_EXCEPTIONS -DQT_NO_DEBUG
-DQT_CORE_LIB -I. -Ikernel -I../../include -I../../include/QtNetwork
-I../../include/QtNetwork/5.12.1 -I../../include/QtNetwork/5.12.1/QtNetwork
-Itmp -I../../include/QtCore/5.12.1 -I../../include/QtCore/5.12.1/QtCore
-I../../include/QtCore -I.moc/release -I../../mkspecs/win32-g++  -o
.obj/release/http2streams.o access/http2/http2streams.cpp
In file included from ../../include/QtCore/qfloat16.h:1,
 from
../../include/QtCore/../../src/corelib/global/qendian.h:44,
 from ../../include/QtCore/qendian.h:1,
 from access/http2/http2frames_p.h:57,
 from access/http2/http2streams_p.h:54,
 from access/http2/http2streams.cpp:40:
../../include/QtCore/../../src/corelib/global/qfloat16.h:79:54: internal
compiler error: in make_rtl_for_nonlocal_decl, at cp/decl.c:
6590
 Q_CORE_EXPORT static const quint32 mantissatable[];
  ^
0x7f9fde1a52e0 __libc_start_main
../csu/libc-start.c:291
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile.Release:14167: recipe for target '.obj/release/http2streams.o' failed
make[3]: *** [.obj/release/http2streams.o] Error 1

(This is just one of the occurrences, running a parallel build will hit a few —
but they’re all in the same place.)

I’m attaching the pre-processed source. The offending line ends up as

__attribute__((dllimport)) static const quint32 mantissatable[];

[Bug rtl-optimization/89588] [8/9 Regression] ICE in unroll_loop_constant_iterations, at loop-unroll.c:498

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-05
 CC||ebotcazou at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Known to work||7.4.0
   Target Milestone|--- |8.4
 Ever confirmed|0   |1
  Known to fail||8.3.0, 9.0

--- Comment #1 from Martin Liška  ---
Well, started with r255973 which is a revision when we added support for the
pragma. Thus it should not be older.

[Bug middle-end/52285] [7/8/9 Regression] libgcrypt _gcry_burn_stack slowdown

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

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

--- Comment #23 from Steven Bosscher  ---
Won't be working on this any time soon...

[Bug target/40730] redundant memory load

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

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

--- Comment #13 from Steven Bosscher  ---
Not working on this...

[Bug c++/55402] Compiling large initializer lists never finishes

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Last reconfirmed|2012-11-20 00:00:00 |2019-3-5
   Assignee|steven at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #16 from Steven Bosscher  ---
Reconfirmed with trunk 20190303.
But I won't be working on this any time soon => unassigning...

[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

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

--- Comment #58 from Steven Bosscher  ---
Not working on this => unassigned...

[Bug c++/89589] New: [8.3 regression] "asm volatile (" leads to "expected '(' before

[eb at emlix dot com]

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

Bug ID: 89589
   Summary: [8.3 regression] "asm volatile (" leads to "expected
'(' before
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eb at emlix dot com
  Target Milestone: ---

tee >> JITStubs.cpp << EOF
#define SYMBOL_STRING(name) #name

asm volatile (
".text\n"
".globl " SYMBOL_STRING(ctiTrampoline) "\n"
SYMBOL_STRING(ctiTrampoline) ":" "\n"
"pushq %rbp" "\n"
"popq %rbp" "\n"
"ret" "\n"
);
EOF

x86_64-unknown-linux-gnu-g++ -c -pipe -O2 -o JITStubs.o JITStubs.cpp

+JITStubs.cpp:3:5: error: expected '(' before 'volatile'
+ asm volatile (
+ ^~~~
+ (
+JITStubs.cpp:4:1: error: expected unqualified-id before string constant
+ ".text\n"
+ ^
+JITStubs.cpp:3:15: error: expected ')' before string constant
+ asm volatile (
+  ~^
+   )
+ ".text\n"
+ ~

[Bug tree-optimization/89505] [7/8 Regression] LibreOffice miscompilation starting with r260383

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Mar  5 08:26:32 2019
New Revision: 269383

URL: https://gcc.gnu.org/viewcvs?rev=269383&root=gcc&view=rev
Log:
2019-03-05  Richard Biener  

Backport from mainline
2019-02-26  Richard Biener  

PR tree-optimization/89505
* tree-ssa-structalias.c (compute_dependence_clique): Make sure
to handle restrict pointed-to vars with multiple subvars
correctly.

* gcc.dg/torture/pr89505.c: New testcase.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89505.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tree-ssa-structalias.c

[Bug fortran/24546] [meta-bug] gfortran debugging problems

[steven at gcc dot gnu.org]

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

Bug 37826 Summary: gfortran emits incorrect debug information if compiled with 
-finit-local-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37826

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

[Bug fortran/37826] gfortran emits incorrect debug information if compiled with -finit-local-zero

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #7 from Steven Bosscher  ---
Enhancement for old debug info format, old compiler, etc. => wontfix.

[Bug rtl-optimization/38711] ira should not be using df-lr except at -O1.

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

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

--- Comment #11 from Steven Bosscher  ---
Not working on this => unassigned...

[Bug c++/89589] [8.3 regression] "asm volatile (" leads to "expected '(' before 'volatile'"

[eb at emlix dot com]

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

Rolf Eike Beer  changed:

   What|Removed |Added

URL||https://bugreports.qt.io/br
   ||owse/QTBUG-74196
Summary|[8.3 regression] "asm   |[8.3 regression] "asm
   |volatile (" leads to|volatile (" leads to
   |"expected '(' before|"expected '(' before
   ||'volatile'"

--- Comment #1 from Rolf Eike Beer  ---
Sorry for the previous mess, I accidentially submitted in the middle of
editing.

So, this is a regression between 8.2.0 and 8.3.0. It happens when building
QtScript 5.12.1. This is the reproducer for x86_64 but I have seen it also for
ARM and i686 (i.e. all platforms supported by the JIT code AFAICT).

[Bug c++/89589] [8.3 regression] "asm volatile (" leads to "expected '(' before 'volatile'"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup.

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

[Bug rtl-optimization/48389] [4.6 Regression] ICE: in make_edges, at cfgbuild.c:319 with -mtune=pentiumpro

[steven at gcc dot gnu.org]

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

Bug 48486 Summary: cfgexpand leaves BARRIERs at the end of basic blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48486

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WORKSFORME

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||eb at emlix dot com

--- Comment #6 from Andrew Pinski  ---
*** Bug 89589 has been marked as a duplicate of this bug. ***

[Bug middle-end/48486] cfgexpand leaves BARRIERs at the end of basic blocks

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Steven Bosscher  ---
Can't reproduce with trunk.

[Bug tree-optimization/89570] [9 Regression] ICE in prepare_cmp_insn, at optabs.c:4001

[rsandifo at gcc dot gnu.org]

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
I think there are two things here:

(1) checking earlier for whether an ifn is supported.

I think we should get genmatch to do that itself rather than
manually do it for each expansion.

(2) not splitting out the condition in a (vec_)cond_expr if it
isn't supported as a stand-alone operation

It looks like (2) is the real fix and (1) is a compile-time
improvement that happens to make (2) latent in this case.

How is it possible for a condition to be supported only in
a VEC_COND_EXPR?  Isn't a stand-alone condition equivalent
to a VEC_COND_EXPR between {-1, ...} and {0, ...}?

[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics

[steven at gcc dot gnu.org]

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

Bug 27906 Summary: reload allocates register of live register variable to 
earlyclobber output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27906

   What|Removed |Added

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

[Bug middle-end/27906] reload allocates register of live register variable to earlyclobber output

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

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

--- Comment #3 from Steven Bosscher  ---
Reportedly fixed (comment #2).

[Bug tree-optimization/89566] [9 Regression] ICE on compilable C++ code: in gimple_call_arg, at gimple.h:3166

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar  5 08:43:16 2019
New Revision: 269384

URL: https://gcc.gnu.org/viewcvs?rev=269384&root=gcc&view=rev
Log:
PR tree-optimization/89566
* gimple-ssa-sprintf.c (sprintf_dom_walker::handle_gimple_call):
Set info.fncode to BUILT_IN_NONE if gimple_call_builtin_p failed.
Punt if get_user_idx_format succeeds, but idx_format argument is
not provided or doesn't have pointer type, or if idx_args is above
number of provided arguments.

* c-c++-common/pr89566.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr89566.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/89570] [9 Regression] ICE in prepare_cmp_insn, at optabs.c:4001

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar  5 08:44:21 2019
New Revision: 269385

URL: https://gcc.gnu.org/viewcvs?rev=269385&root=gcc&view=rev
Log:
PR tree-optimization/89570
* match.pd (vec_cond into cond_op simplification): Guard with
vectorized_internal_fn_supported_p test and #if GIMPLE.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr89570.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/89570] [9 Regression] ICE in prepare_cmp_insn, at optabs.c:4001

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to rsand...@gcc.gnu.org from comment #6)
> I think there are two things here:
> 
> (1) checking earlier for whether an ifn is supported.
> 
> I think we should get genmatch to do that itself rather than
> manually do it for each expansion.
> 
> (2) not splitting out the condition in a (vec_)cond_expr if it
> isn't supported as a stand-alone operation
> 
> It looks like (2) is the real fix and (1) is a compile-time
> improvement that happens to make (2) latent in this case.
> 
> How is it possible for a condition to be supported only in
> a VEC_COND_EXPR?  Isn't a stand-alone condition equivalent
> to a VEC_COND_EXPR between {-1, ...} and {0, ...}?

Oops, I've committed already before reading your comments.
Yes, the committed patch does (1).  Not really sure it needs to be done in
other patterns that don't introduce IFN_COND_*, those other take IFN_COND_* and
transform that to some other IFN_COND_*.

For VEC_COND_EXPR, yes, it is pretty usual on many of the targets that you can
only do:
  _1 = VEC_COND_EXPR <_2 == _3, {-1, -1, ...}, {0, 0, ...}>;
(that is vcond/vcondu/vcondeq optab), and not:
  _4 = _2 == _3;
(that is vec_cmp/vec_cmpu/vec_cmpeq optab).
Quick grep for '"vcond' config/*/*.md shows that the former is likely in
aarch64, arm, gcn, i386, ia64, mips, rs6000, s390, sparc, spu
and the latter only in
aarch64, gcn, i386, s390
(haven't checked exact modes).

[Bug tree-optimization/28144] floating point constant -> byte/char/short conversion is wrong for java

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|REOPENED|WAITING
   Last reconfirmed|2016-03-08 00:00:00 |2019-3-5
 CC|aph at redhat dot com, |rguenth at gcc dot 
gnu.org
   |olegendo at gcc dot gnu.org,   |
   |per at bothner dot com,|
   |tromey at redhat dot com   |

--- Comment #8 from Steven Bosscher  ---
This bug affected Java, which is not part of GCC anymore since GCC 7.
(And apparently this was so insignificant that it didn't even make it
to the news page!). But fold_convert_const_int_from_real() still has
the behavior that is alledgedly incorrect.

Leaving it to release manager to decide what to do with the patches
and with this bug report in general.

[Bug rtl-optimization/89588] [8/9 Regression] ICE in unroll_loop_constant_iterations, at loop-unroll.c:498

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-05
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Richard Biener  ---
Since it's now rejected with 8.3 there's no point in accepting it again (IMHO).

But the diagnostic could be improved.

[Bug ipa/89584] [9 Regression] CPU2000 degradations with r268448 (172.mgrid -22%, 252.eon -8%)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
Summary|CPU2000 degradations with   |[9 Regression] CPU2000
   |r268448 (172.mgrid -22%,|degradations with r268448
   |252.eon -8%)|(172.mgrid -22%, 252.eon
   ||-8%)

[Bug target/89582] Suboptimal code generated for floating point struct in -O3 compare to -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-05
 CC||rguenth at gcc dot gnu.org
 Blocks||53947
 Depends on||84101
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
There's a duplicate for this (or slightly different testcases with the same
underlying issue).  The vectorizer knows nothing about the target ABI
and assumes the arguments reside in memory while they are actually passed in
two %xmm registers each.  Same for the return value.  PR84101 is one of
the related PRs.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84101
[Bug 84101] [7/8/9 Regression] -O3 and -ftree-vectorize trying too hard for
function returning trivial pair-of-uint64_t-structure

[Bug c/28306] const / pure call with ignored argument emitted.

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

   Last reconfirmed|2006-07-07 17:30:13 |2019-3-5
   Host|i686-pc-linux-gnu   |

--- Comment #4 from Steven Bosscher  ---
GCC trunk today on x86-64 produces:

gen_x86_64_shrd(int):
xorl%eax, %eax
ret
ok(int):
movl$1, %eax
ret
ix86_split_ashr(int):
testl   %edi, %edi
movl$ok(int), %eax
movl$gen_x86_64_shrd(int), %edx
cmove   %rdx, %rax
xorl%edi, %edi
jmp *%rax


FWIW clang trunk also does not optimize this, yielding:
ix86_split_ashr(int):   # @ix86_split_ashr(int)
testl   %edi, %edi
movl$gen_x86_64_shrd(int), %eax
movl$ok(int), %ecx
cmoveq  %rax, %rcx
xorl%edi, %edi
jmpq*%rcx   # TAILCALL
ok(int):# @ok(int)
movl$1, %eax
retq
gen_x86_64_shrd(int):  # @gen_x86_64_shrd(int)
xorl%eax, %eax
retq


ICC 19.0.1 _does_ optimize, resulting in:
ix86_split_ashr(int):
ret #24.1
_INTERNALf242c0c5::gen_x86_64_shrd(int):
xorl  %eax, %eax#6.10
ret #6.10
_INTERNALf242c0c5::ok(int):
movl  $1, %eax  #12.10
ret #12.10

[Bug bootstrap/89560] [9 regression] ICE In function 'rtx_def* gen_vec_extract_lo_v64qi(rtx, rtx)'

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar  5 09:03:50 2019
New Revision: 269386

URL: https://gcc.gnu.org/viewcvs?rev=269386&root=gcc&view=rev
Log:
PR bootstrap/89560
* fold-const.c (fold_checksum_tree): Don't use fixed size buffer,
instead alloca it only when needed with the needed size.

* g++.dg/other/pr89560.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/pr89560.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/89570] [9 Regression] ICE in prepare_cmp_insn, at optabs.c:4001

[rsandifo at gcc dot gnu.org]

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

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
(In reply to Jakub Jelinek from comment #8)
> For VEC_COND_EXPR, yes, it is pretty usual on many of the targets that you
> can only do:
>   _1 = VEC_COND_EXPR <_2 == _3, {-1, -1, ...}, {0, 0, ...}>;
> (that is vcond/vcondu/vcondeq optab), and not:
>   _4 = _2 == _3;
> (that is vec_cmp/vec_cmpu/vec_cmpeq optab).
> Quick grep for '"vcond' config/*/*.md shows that the former is likely in
> aarch64, arm, gcn, i386, ia64, mips, rs6000, s390, sparc, spu
> and the latter only in
> aarch64, gcn, i386, s390
> (haven't checked exact modes).
Could we get tree-vect-generic.c to "lower" stand-alone comparisons
into VEC_COND_EXPRs if they're not supported otherwise?  I guess this
is all bound up with that discussion about having 4-op comparisons vs.
always having separate comparisons though.

[Bug tree-optimization/28144] floating point constant -> byte/char/short conversion is wrong for java

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
Iff there's anything to fix it is not in fold_convert_const_int_from_real which
does exactly what is documented.  Instead a frontend has to emit
(short)(int)floatvar if float-to-integer conversion has to happen via an
intermediate promoted type.

[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics

[rguenth at gcc dot gnu.org]

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

Bug 28144 Summary: floating point constant -> byte/char/short conversion is 
wrong for java
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28144

   What|Removed |Added

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

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[harald at gigawatt dot nl]

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

--- Comment #8 from Harald van Dijk  ---
(In reply to Richard Biener from comment #7)
> Since it's now rejected with 8.3 there's no point in accepting it again
> (IMHO).

The point in accepting it again would be that people can skip 8.3 because of
this and upgrade from 8.2 to a future 8.4 without worrying too much about
existing code being broken. The alternative is that people who have to deal
with the possibility of old code are forced treat 8.2 as the last release in
the 8 series, and to treat 8.3 and newer as if they were a new major version.

[Bug tree-optimization/27394] double -> char conversion varies with optimization level

[rguenth at gcc dot gnu.org]

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

Bug 28144 Summary: floating point constant -> byte/char/short conversion is 
wrong for java
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28144

   What|Removed |Added

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

[Bug tree-optimization/89570] [9 Regression] ICE in prepare_cmp_insn, at optabs.c:4001

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
That wouldn't help at all, the propagation in this PR is in forwprop4, after
vector lowering.

[Bug tree-optimization/89570] [9 Regression] ICE in prepare_cmp_insn, at optabs.c:4001

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Tue, 5 Mar 2019, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89570
> 
> --- Comment #10 from Jakub Jelinek  ---
> That wouldn't help at all, the propagation in this PR is in forwprop4, after
> vector lowering.

The only way would be to make expanders have fallback code.  But the
reason for only allowing target supported vector GIMPLE is to avoid
pessimizing code generation - in the case of compares/conds the
chance is we end up with duplicated work.

[Bug rtl-optimization/29860] comment / code incosistency in cfgcleanup.c:flow_find_cross_jump

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-05
 Ever confirmed|0   |1

[Bug tree-optimization/89570] [9 Regression] ICE in prepare_cmp_insn, at optabs.c:4001

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to rsand...@gcc.gnu.org from comment #6)
> (2) not splitting out the condition in a (vec_)cond_expr if it
> isn't supported as a stand-alone operation

(2) can be just documented as a requirement, unless we have targets that would
need further changes.  So, if IFN_COND_* is supported for certain modes, then
vec_cmp{,u} needs to be supported for that mode too.  I bet masked operations
are done using those bitmasks that are set by vec_cmp{,u}, dunno how exactly
for aarch64, but if x86 is adjusted to use those, it would be the mask
registers and
all the arithmetic etc. vector instructions masked.

[Bug tree-optimization/29944] should do more loops transformations to enable more biv widening

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-05
 Ever confirmed|0   |1

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
I actually agree it would be better to accept it for the rest of 8.x lifetime. 
Yes, it doesn't make any sense in the code and people will eventually fix it
for 9.x.

[Bug libobjc/89586] warning: cast between incompatible function types when building libobjc

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Let me see what I can do this weekend.

[Bug libobjc/89586] warning: cast between incompatible function types when building libobjc

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #2 from Andrew Pinski  ---
Note the warning is correct, the undefined behavior is not invoked here though.

[Bug tree-optimization/89566] [9 Regression] ICE on compilable C++ code: in gimple_call_arg, at gimple.h:3166

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

(In reply to Martin Sebor from comment #3)
As for a better way, you haven't proposed anything.  The thing is that an
indirect call can be folded into direct at hundreds of places through the
optimizations, so calling a function that does the checking before you start
trusting the arguments is what we have now, the bug is if it is not called or
(like in this case) not used with care.

[Bug middle-end/89590] New: [7/8/9 Regression] ICE in maybe_emit_free_warning

[jakub at gcc dot gnu.org]

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

Bug ID: 89590
   Summary: [7/8/9 Regression] ICE in maybe_emit_free_warning
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, msebor at gcc dot gnu.org,
su at cs dot ucdavis.edu, webrown.cpp at gmail dot com
Depends on: 89566
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #89566 +++

Filed for:
$ cat t.c && gcc -O2 -S -Wall t.c
void f (void)
{
  ((void (*)()) __builtin_free) ();
}
during RTL pass: expand
t.c: In function ‘f’:
t.c:3:4: internal compiler error: tree check: accessed operand 4 of call_expr
with 3 operands in maybe_emit_free_warning, at builtins.c:10608
3 |   ((void (*)()) __builtin_free) ();
  |   ~^~~
0x15b045d tree_operand_check_failed(int, tree_node const*, char const*, int,
char const*)
/src/gcc/svn/gcc/tree.c:10059
0x827e8c tree_operand_check(tree_node*, int, char const*, int, char const*)
/src/gcc/svn/gcc/tree.h:3676
0x9d4bdb maybe_emit_free_warning
/src/gcc/svn/gcc/builtins.c:10608
0x9cc317 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/src/gcc/svn/gcc/builtins.c:8305
from that PR.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89566
[Bug 89566] [9 Regression] ICE on compilable C++ code: in gimple_call_arg, at
gimple.h:3166

[Bug middle-end/89590] [7/8/9 Regression] ICE in maybe_emit_free_warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-05
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |7.5
 Ever confirmed|0   |1

[Bug middle-end/89590] [7/8/9 Regression] ICE in maybe_emit_free_warning

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug bootstrap/89560] [9 regression] ICE In function 'rtx_def* gen_vec_extract_lo_v64qi(rtx, rtx)'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Fixed.

[Bug libstdc++/89591] New: How can thread.joinable() reliably work if the pthread_t id is not initialized?

[bique.alexandre at gmail dot com]

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

Bug ID: 89591
   Summary: How can thread.joinable() reliably work if the
pthread_t id is not initialized?
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bique.alexandre at gmail dot com
  Target Milestone: ---

Hi,

I've been reading the  header and I've found that the thread id of
std::thread is not initialized, I hope that I'm wrong and I missed something.

So I wonder how std::thread.joinable() can work?

On top of that, pthread_t has no "invalid thread id" or "uninitialized thread
id" value. So I wonder how the whole logic can work.

To me if your only attribute is pthread_t, you can't know figure anything about
the thread, and even if the thread exists, there is no guarantee that the
current std::thread object created it: if you create a object: std::thread t;
then t.id will be uninitialized, so could very well point to an existing thread
right?

Regards,
Alex




From the header:

thread() noexcept = default;

and also:

typedef __gthread_t native_handle_type;

/// thread::id
class id
{
  native_handle_type_M_thread;

public:
  id() noexcept : _M_thread() { }

  explicit
  id(native_handle_type __id) : _M_thread(__id) { }

private:
  friend class thread;
  friend class hash;

  friend bool
  operator==(thread::id __x, thread::id __y) noexcept;

  friend bool
  operator<(thread::id __x, thread::id __y) noexcept;

  template
friend basic_ostream<_CharT, _Traits>&
operator<<(basic_ostream<_CharT, _Traits>& __out, thread::id __id);
};

  private:
id  _M_id;



and then later:

typedef pthread_t __gthread_t;

[Bug preprocessor/66505] -Wno-error=pedantic does not reverse -Werror -Wpedantic

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
(In reply to Martin Liška from comment #3)
> I believe I'll fix it once patch for PR89051 will be merged.

Apparently it's more comlicated.

[Bug c/89051] -Wno-error= does not work for warning groups

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Liška  ---
I spent quite some time with that and it's much complicated. Basic problem I
face is that there are 2 situations:

1) -Wno-error=pedantic - in that situation -Wpedantic should not be set
(because it's not enabled before)
2) -Werror -Wno-error=implicit - here -Wimplicit should be set + all
sub-options

So it definitely needs to go through handle_generate_option:

#0  set_option (opts=0x271a920 , opts_set=0x0, opt_index=179,
value=1, arg=0x0, kind=4, loc=0, dc=0x271e080 ) at
/home/marxin/Programming/gcc/gcc/opts-common.c:1373
#1  0x01af202b in handle_option (opts=0x271a920 ,
opts_set=0x271b8a0 , decoded=0x7fffd220,
lang_mask=3120, kind=4, loc=0, handlers=0x7fffd8b0, generated_p=true,
dc=0x271e080 )
at /home/marxin/Programming/gcc/gcc/opts-common.c:1098
#2  0x01af2165 in handle_generated_option (opts=0x271a920
, opts_set=0x271b8a0 , opt_index=179,
arg=0x0, value=1, lang_mask=3120, kind=4, loc=0, handlers=0x7fffd8b0,
generated_p=true, 
dc=0x271e080 ) at
/home/marxin/Programming/gcc/gcc/opts-common.c:1130
#3  0x01af4d06 in C_handle_option_auto (opts=0x271a920
, opts_set=0x271b8a0 , scode=163, arg=0x0,
value=1, lang_mask=3120, kind=4, loc=0, handlers=0x7fffd8b0, dc=0x271e080
) at options.c:16717
#4  0x008ab013 in c_common_handle_option (scode=163, arg=0x0, value=1,
kind=4, loc=0, handlers=0x7fffd8b0) at
/home/marxin/Programming/gcc/gcc/c-family/c-opts.c:710
#5  0x00cb282a in lang_handle_option (opts=0x271a920 ,
opts_set=0x271b8a0 , decoded=0x7fffd4b0, lang_mask=16,
kind=4, loc=0, handlers=0x7fffd8b0, dc=0x271e080
)
at /home/marxin/Programming/gcc/gcc/opts-global.c:180

which implements EnabledBy dependencies. I'm retreating for now :/

[Bug target/89592] New: FAIL: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_x_alt.o-cp_compat_y_tst.o execute against GCC4.8

[amker at gcc dot gnu.org]

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

Bug ID: 89592
   Summary: FAIL: tmpdir-g++.dg-struct-layout-1/t025
cp_compat_x_alt.o-cp_compat_y_tst.o execute against
GCC4.8
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

Created attachment 45892
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45892&action=edit
t025_y.E

With X86_64 host GCC4.8 configured as below:
../configure --prefix=/usr --enable-bootstrap --enable-shared
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --disable-libgcj --with-isl=... --with-cloog=...
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64
--build=x86_64-redhat-linux

Configuring/building GCC6.5 as below:
../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,go,lto --prefix=/usr
--enable-shared --enable-threads=posix --enable-checking=release
--enable-multilib --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --disable-libgcj --without-isl --disable-libmpx
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 

We have below test case failure:
FAIL: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_x_alt.o-cp_compat_y_tst.o
execute

Attachment is reduced callee site code, compiling with following command line:

$ g++  -w  -mno-mmx -Wno-abi   -S   -o 48.S -xc++ t025_y.E -g

with GCC4.8, we have:
movl$0, -4(%rbp)
movl$0, -8(%rbp)
.loc 1 26 0
movl-64(%rbp), %edx
movls2227(%rip), %eax
cmpl%eax, %edx
je  .L2

while with GCC6.5/GCC9, we have:
movl$0, -4(%rbp)
movl$0, -8(%rbp)
.loc 1 26 0
movl16(%rbp), %edx
movls2227(%rip), %eax
cmpl%eax, %edx

Given it checks compatibility between this GCC against old(4.8) one, there must
be change in layout the structure from 4.8 to 6.5.  Or I am missing something?

[Bug target/89587] gcc's rs6000 configuration unconditionally sets MULTIARCH_DIRNAME, even when multiarch is disabled

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #2 from Paolo Carlini  ---
A few notes - I'm not sure I will actually be able to work on this, maybe
somebody like Marek wants to beat me to it.

If in build_over_call we unconditionally return error_mark_node when mark_used
returns false we avoid the ICE. Then, however, we have duplicate diagnostics,
because we already emitted the second error while trying to parse a class
member access, but when cp_parser_postfix_expression returns error_mark_node in
cp_parser_decltype_expr we don't set id_expression_or_member_access_p and try a
full expression too.

[Bug libfortran/89593] New: warning "passing argument 3 of ‘_gfortran_caf_{get,send}_by_ref’ from incompatible pointer type" when building libgfortran

[ubizjak at gmail dot com]

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

Bug ID: 89593
   Summary: warning "passing argument 3 of
‘_gfortran_caf_{get,send}_by_ref’ from incompatible
pointer type" when building libgfortran
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

The following warning is generated when building libgfortran:

../../../git/gcc/libgfortran/caf/single.c: In function
‘_gfortran_caf_sendget_by_ref’:
../../../git/gcc/libgfortran/caf/single.c:2813:57: warning: passing argument 3
of ‘_gfortran_caf_get_by_ref’ from incompatible pointer type
[-Wincompatible-pointer-types]
 2813 |   _gfortran_caf_get_by_ref (src_token, src_image_index, &temp,
src_refs,
  | ^
  | |
  | struct
 *
../../../git/gcc/libgfortran/caf/single.c:1544:24: note: expected
‘gfc_descriptor_t *’ {aka ‘struct  *’} but argument is of type
‘struct  *’
 1544 |  gfc_descriptor_t *dst, caf_reference_t *refs,
  |  ~~^~~
../../../git/gcc/libgfortran/caf/single.c:2820:58: warning: passing argument 3
of ‘_gfortran_caf_send_by_ref’ from incompatible pointer type
[-Wincompatible-pointer-types]
 2820 |   _gfortran_caf_send_by_ref (dst_token, dst_image_index, &temp,
dst_refs,
  |  ^
  |  |
  |  struct
 *
../../../git/gcc/libgfortran/caf/single.c:2434:25: note: expected
‘gfc_descriptor_t *’ {aka ‘struct  *’} but argument is of type
‘struct  *’
 2434 |   gfc_descriptor_t *src, caf_reference_t *refs,
  |   ~~^~~


Happens in _gfortran_caf_sendget_by_ref, where we have:

--cut here--
void
_gfortran_caf_sendget_by_ref (caf_token_t dst_token, int dst_image_index,
  caf_reference_t *dst_refs, caf_token_t src_token,
  int src_image_index,
  caf_reference_t *src_refs, int dst_kind,
  int src_kind, bool may_require_tmp, int
*dst_stat,
  int *src_stat, int dst_type, int src_type)
{
  GFC_FULL_ARRAY_DESCRIPTOR (GFC_MAX_DIMENSIONS, void) temp;
  GFC_DESCRIPTOR_DATA (&temp) = NULL;
  GFC_DESCRIPTOR_RANK (&temp) = -1;
  GFC_DESCRIPTOR_TYPE (&temp) = dst_type;

  _gfortran_caf_get_by_ref (src_token, src_image_index, &temp, src_refs,
dst_kind, src_kind, may_require_tmp, true,
src_stat, src_type);

  if (src_stat && *src_stat != 0)
return;

  _gfortran_caf_send_by_ref (dst_token, dst_image_index, &temp, dst_refs,
 dst_kind, dst_kind, may_require_tmp, true,
 dst_stat, dst_type);
  if (GFC_DESCRIPTOR_DATA (&temp))
free (GFC_DESCRIPTOR_DATA (&temp));
}
--cut here--

GFC_FULL_ARRAY_DESCRIPTOR is defined in libgfortran.h as:

#define GFC_FULL_ARRAY_DESCRIPTOR(r, type) \
struct {\
  type *base_addr;\
  size_t offset;\
  dtype_type dtype;\
  index_type span;\
  descriptor_dimension dim[r];\
}

  GFC_FULL_ARRAY_DESCRIPTOR (GFC_MAX_DIMENSIONS, void) temp;

while _gfortran_caf_get_by_ref and _gfortran_caf_send_by_ref expect
gfc_descriptor_t, defined as:

#define GFC_ARRAY_DESCRIPTOR(type) \
struct {\
  type *base_addr;\
  size_t offset;\
  dtype_type dtype;\
  index_type span;\
  descriptor_dimension dim[];\
}

typedef GFC_ARRAY_DESCRIPTOR (void) gfc_array_void;

typedef gfc_array_void gfc_descriptor_t;


These two structures differ in the last element:

descriptor_dimension dim[GFC_MAX_DIMENSIONS];

vs.

descriptor_dimension dim[];

[Bug c++/68975] Request: Provide alternate keyword for decltype in C++03

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|WONTFIX |WORKSFORME

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> I see that clang supports __decltype (but not __decltype__, strangely)

And GCC does too.

[Bug c++/68975] Request: Provide alternate keyword for decltype in C++03

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Since at least GCC 4.3, so probably when decltype itself was first supported.

[Bug tree-optimization/89594] New: [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*))

[asolokha at gmx dot com]

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

Bug ID: 89594
   Summary: [9 Regression] ICE: Segmentation fault (in
gsi_for_stmt(gimple*))
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-9.0.0-alpha20190303 snapshot (r269357) ICEs when compiling the following
testcase w/ -O1 -ftree-loop-if-convert -ftree-loop-vectorize -fno-tree-ch:

int h3;

void
in (void)
{
  long int zr;
  int ee = 0;

  for (zr = 0; zr < 1; zr = h3)
{
  ee = !!h3 ? zr : 0;

  h3 = 0;
  while (h3 < 0)
h3 = 0;
}

  h3 = 0;
  while (h3 < 1)
h3 = !!ee ? (!!h3 + 1) : 0;
}

% gcc-9.0.0-alpha20190303 -O1 -ftree-loop-if-convert -ftree-loop-vectorize
-fno-tree-ch -c fu9roqfs.c
during GIMPLE pass: ifcvt
fu9roqfs.c: In function 'in':
fu9roqfs.c:4:1: internal compiler error: Segmentation fault
4 | in (void)
  | ^~
0xd6fc4f crash_signal
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/toplev.c:326
0xab3157 gsi_for_stmt(gimple*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/gimple-iterator.c:609
0xdb03c4 fold_loop_internal_call(gimple*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/tree-cfg.c:7418
0xde7f5e execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/tree-if-conv.c:3184
0xde7f5e execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/tree-if-conv.c:3137

==19053== Invalid read of size 4
==19053==at 0xAB3157: gsi_for_stmt(gimple*) (gimple-iterator.c:609)
==19053==by 0xDB03C4: fold_loop_internal_call(gimple*, tree_node*)
(tree-cfg.c:7418)
==19053==by 0xDE7F5E: execute (tree-if-conv.c:3184)
==19053==by 0xDE7F5E: (anonymous
namespace)::pass_if_conversion::execute(function*) (tree-if-conv.c:3137)
==19053==by 0xC8CF89: execute_one_pass(opt_pass*) (passes.c:2487)
==19053==by 0xC8D6EF: execute_pass_list_1(opt_pass*) (passes.c:2573)
==19053==by 0xC8D701: execute_pass_list_1(opt_pass*) (passes.c:2574)
==19053==by 0xC8D701: execute_pass_list_1(opt_pass*) (passes.c:2574)
==19053==by 0xC8D728: execute_pass_list(function*, opt_pass*)
(passes.c:2584)
==19053==by 0x94B28F: cgraph_node::expand() (cgraphunit.c:2198)
==19053==by 0x94C22A: expand_all_functions (cgraphunit.c:2336)
==19053==by 0x94C22A: symbol_table::compile() [clone .part.0]
(cgraphunit.c:2687)
==19053==by 0x94E8CC: compile (cgraphunit.c:2599)
==19053==by 0x94E8CC: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2865)
==19053==by 0xD6FF3E: compile_file() (toplev.c:481)
==19053==  Address 0x50 is not stack'd, malloc'd or (recently) free'd

[Bug target/89592] FAIL: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_x_alt.o-cp_compat_y_tst.o execute against GCC4.8

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Started with r233126.  Before that change, check2227 has not been NRV
optimized, but now it is.  That doesn't explain an ABI difference though.

[Bug tree-optimization/89595] New: [8/9 Regression] DOM miscompiles code

[rguenth at gcc dot gnu.org]

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

Bug ID: 89595
   Summary: [8/9 Regression] DOM miscompiles code
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

The testcase below is miscompiled at -O1+ because DOM doesn't visit stmts
in a folded sequence other than the last for value-ranges so we end up
with

Visiting statement:
i_1 = val_2(D) > 0 ? i_6 : 0;
Meeting
  int [val_2(D), val_2(D)]  EQUIVALENCES: { val_2(D) } (1 elements)
and
  int [0, 0]
to
  VARYING
Optimizing statement i_1 = val_2(D) > 0 ? i_6 : 0;
  Replaced 'i_6' with variable 'val_2(D)'
gimple_simplified to _9 = MAX_EXPR ;
i_1 = _9;
  Folded to: i_1 = _9;
LKUP STMT i_1 = _9
 ASGN i_1 = _9
...
Visiting PHI node: i_3 = PHI <0(2), _9(3)>
Argument #0 (2 -> 4 executable)
0: int [0, 0]
Argument #1 (3 -> 4 executable)
_9: UNDEFINED
Meeting
  int [0, 0]
and
  UNDEFINED
to
  int [0, 0]
LKUP STMT i_3 = PHI <0, _9>
2>>> STMT i_3 = PHI <0, _9>
 STMT i_3 = PHI <0, _9>
Optimizing statement bb_5:
Optimizing statement return i_3;
  Replaced 'i_3' with constant '0'


int __attribute__((noipa))
__GIMPLE(startwith("dom1")) bar(int cond, int val)
{
  int i;

  if (0 != 0)
goto bb_6;
  else
goto bb_2;

bb_2:
  if (cond_5(D) != 0)
goto bb_4;
  else
goto bb_5;

bb_4:
  i_6 = val_2(D);
  i_1 = val_2(D) > 0 ? i_6 : 0;

bb_5:
  i_3 = __PHI (bb_4: i_1, bb_2: 0);
  return i_3;

bb_6:
  i_4 = 1;
  i_9 = 2;
  goto bb_2;
}

int main()
{
  if (bar (1, 1) != 1)
__builtin_abort ();
  return 0;
}

[Bug tree-optimization/89595] [8/9 Regression] DOM miscompiles code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-05
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.4
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I have a patch.

Note to trigger the issue there has to be a free SSA name in the queue to
not run into

value_range *
vr_values::get_value_range (const_tree var)
{
...
  /* If we query the range for a new SSA name return an unmodifiable VARYING.
 We should get here at most from the substitute-and-fold stage which
 will never try to change values.  */
  if (ver >= num_vr_values)
return CONST_CAST (value_range *, &vr_const_varying);

[Bug tree-optimization/89595] [8/9 Regression] DOM miscompiles code

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
For some reason the testcase doesn't fail on the branch.  DOM dump:

Visiting PHI node: i_3 = PHI <0(2), _9(3)>
Argument #0 (2 -> 4 executable)
0: [0, 0]
Argument #1 (3 -> 4 executable)
_9: UNDEFINED
Meeting
  [0, 0]
and
  UNDEFINED
to
  [0, 0]
LKUP STMT i_3 = PHI <0, _9>
2>>> STMT i_3 = PHI <0, _9>
 STMT i_3 = PHI <0, _9>
Optimizing statement bb_5:
Optimizing statement return i_3;

so the singleton isn't extracted for some reason.  The issue is still latent
of course.

[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  ---
I must also add: if we had decided to fix c++/89488 the way I originally
proposed https://gcc.gnu.org/ml/gcc-patches/2019-02/txtzrb81mYdom.txt we would
not have to fix this one too ;)

[Bug rtl-optimization/89588] [8/9 Regression] ICE in unroll_loop_constant_iterations, at loop-unroll.c:498

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
There is:
401   /* However we cannot unroll completely at the RTL level a loop
with
402  constant number of iterations; it should have been peeled
instead.  */
403   if ((unsigned) loop->unroll - 1 > desc->niter - 2)
404 {
405   if (dump_file)
406 fprintf (dump_file, ";; Loop should have been peeled\n");
407 }

As desc->niter is uint64_t 1, desc->niter - 2 is 0xULL.
Shouldn't we punt also for desc->niter == 1 , so desc->niter == 1 || (unsigned)
... ?

[Bug tree-optimization/89594] [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*))

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug rtl-optimization/89588] [8/9 Regression] ICE in unroll_loop_constant_iterations, at loop-unroll.c:498

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Or desc->niter <= 1, dunno what exactly means if niter == 0, is that zero
iterations or unknown number of iterations?

[Bug target/89592] FAIL: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_x_alt.o-cp_compat_y_tst.o execute against GCC4.8

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ABI, wrong-code
 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-05
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed by bisection.

[Bug middle-end/89590] [7/8/9 Regression] ICE in maybe_emit_free_warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/89595] [8/9 Regression] DOM miscompiles code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The testcase FAILs since r263342.

[Bug target/89592] FAIL: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_x_alt.o-cp_compat_y_tst.o execute against GCC4.8

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Confirmed it is this revision even on the runtime testcase from
struct-layout-1.exp testing.  The question is what if anything the psABI says
here, what do other compilers do etc.  Passing flexible array members as values
isn't the best documented thing in the ABIs...

[Bug tree-optimization/89594] [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*))

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Started with r268689.  I'll have a look.

[Bug c++/89538] [7.3.0] GCC miscompiling LLVM because of wrong vectorization

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Taewook Oh from comment #5)
> The name of the function is "void llvm::SmallVectorTemplateBase  >::grow(size_t) [with T =
> std::pair, const
> llvm::DICompositeType*>; bool  = false]".
> 
> I tried with GCC 7.4.0, and seems that GCC 7.4.0 doesn't attempt to
> vectorize the problematic code. 
> 
> Thank you for taking a look!

Hm, I've just build 7.3.0 release (git revision
87fb575328cc5d954b91672681aacfc383134b12) and I used your command line.
However, I can't see the function being vectorized:

DwarfDebug.cpp.158t.vect:
...
;; Function void llvm::SmallVectorTemplateBase >::grow(size_t)
[with T = std::pair, const
llvm::DICompositeType*>; bool  = false]
(_ZN4llvm23SmallVectorTemplateBaseISt4pairISt10unique_ptrINS_13DwarfTypeUnitESt14default_deleteIS3_EEPKNS_15DICompositeTypeEELb0EE4growEm,
funcdef_no=25366, decl_uid=680829, cgraph_uid=19027, symbol_order=19082)


Analyzing loop at
/data/users/twoh/server-llvm/llvm/include/llvm/ADT/SmallVector.h:184
/data/users/twoh/server-llvm/llvm/include/llvm/ADT/SmallVector.h:184:14: note:
= analyze_loop_nest =
/data/users/twoh/server-llvm/llvm/include/llvm/ADT/SmallVector.h:184:14: note:
=== vect_analyze_loop_form ===
/data/users/twoh/server-llvm/llvm/include/llvm/ADT/SmallVector.h:184:14: note:
not vectorized: control flow in loop.
/data/users/twoh/server-llvm/llvm/include/llvm/ADT/SmallVector.h:184:14: note:
bad loop form.

Analyzing loop at
/mnt/gvfs/third-party2/gcc/6e8e715624fd15256a7970073387793dfcf79b46/7.x/centos7-native/b2ef2b6/include/c++/7.3.0/bits/stl_uninitialized.h:82
/mnt/gvfs/third-party2/gcc/6e8e715624fd15256a7970073387793dfcf79b46/7.x/centos7-native/b2ef2b6/include/c++/7.3.0/bits/stl_uninitialized.h:82:23:
note: = analyze_loop_nest =
/mnt/gvfs/third-party2/gcc/6e8e715624fd15256a7970073387793dfcf79b46/7.x/centos7-native/b2ef2b6/include/c++/7.3.0/bits/stl_uninitialized.h:82:23:
note: === vect_analyze_loop_form ===
/mnt/gvfs/third-party2/gcc/6e8e715624fd15256a7970073387793dfcf79b46/7.x/centos7-native/b2ef2b6/include/c++/7.3.0/bits/stl_uninitialized.h:82:23:
note: not vectorized: control flow in loop.
/mnt/gvfs/third-party2/gcc/6e8e715624fd15256a7970073387793dfcf79b46/7.x/centos7-native/b2ef2b6/include/c++/7.3.0/bits/stl_uninitialized.h:82:23:
note: bad loop form.
/data/users/twoh/server-llvm/llvm/include/llvm/ADT/SmallVector.h:233:6: note:
vectorized 0 loops in function.
void llvm::SmallVectorTemplateBase >::grow(size_t) [with T =
std::pair, const llvm::DICompositeType*>;
bool  = false] (struct SmallVectorTemplateBase * const this, size_t
MinSize)
{
  void * Result;
  void * D.1212828;
  uint64_t A;
  struct pair * __cur;
  struct pair * __first$_M_current;
  struct pair * E;
  struct pair * NewElts;
  size_t NewCapacity;
  const long unsigned int D.1032599;
  long unsigned int _2;
  long unsigned int _4;
  unsigned int _5;
  void * _13;
  struct DwarfTypeUnit * _18;
  void * _21;
  unsigned int _27;
  struct pair * _28;
  struct DwarfTypeUnit * _31;
  const struct DICompositeType * _32;
  struct pair * _33;
  void * _35;
  unsigned int _36;
  long unsigned int _37;
  long unsigned int _38;
  struct pair * _39;
  long unsigned int _41;
  long unsigned int _42;
  long unsigned int _43;
  long unsigned int _45;
  long unsigned int _47;
  long unsigned int _49;
  long unsigned int _51;
  long unsigned int _53;
  long unsigned int _55;
  long unsigned int _56;
  struct DwarfUnit * _70;
  void * pretmp_124;
  void * prephitmp_125;

   [15.00%]:
  if (MinSize_59(D) > 4294967295)
goto ; [33.00%]
  else
goto ; [67.00%]

   [4.95%]:
  llvm::report_bad_alloc_error ("SmallVector capacity overflow during
allocation", 1);

   [15.00%]:
  # DEBUG D#3730 => &this_10(D)->D.680846.D.680786
  _27 = MEM[(unsigned int *)this_10(D) + 12B];
  # DEBUG D#78 => D#3730
  # DEBUG this => D#78
  _56 = (long unsigned int) _27;
  _2 = _56 + 2;
  # DEBUG A => _2
  _43 = _2 >> 1;
  A_44 = _2 | _43;
  # DEBUG A => A_44
  _45 = A_44 >> 2;
  A_46 = A_44 | _45;
  # DEBUG A => A_46
  _47 = A_46 >> 4;
  A_48 = A_46 | _47;
  # DEBUG A => A_48
  _49 = A_48 >> 8;
  A_50 = A_48 | _49;
  # DEBUG A => A_50
  _51 = A_50 >> 16;
  A_52 = A_50 | _51;
  # DEBUG A => A_52
  _53 = A_52 >> 32;
  A_54 = A_52 | _53;
  # DEBUG A => A_54
  _55 = A_54 + 1;
  # DEBUG A => NULL
  # DEBUG NewCapacity => _55
  # DEBUG __a => &NewCapacity
  # DEBUG __b => &MinSize
  _42 = MAX_EXPR <_55, MinSize_59(D)>;
  # DEBUG __a => NULL
  # DEBUG __b => NULL
  # DEBUG __a => NULL
  # DEBUG __b => &D.1032599
  _41 = MIN_EXPR <_42, 4294967295>;
  # DEBUG __a => NULL
  # DEBUG __b => NULL
  # DEBUG NewCapacity => _41
  _4 = _41 * 16;
  # DEBUG Sz => _4
  Result_69 = malloc (_4);
  # DEBUG Result => Result_69
  if (Result_69 == 0B)
goto ; [19.86%]
  else
goto ; [80.14%]

   [2.98%]:
  llvm::report_bad_alloc_error ("Allocation failed", 1);
...

so I can't see a vectorization in the function in 7.3.0 ei

[Bug tree-optimization/89594] [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*))

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Mine.  The CFG cleanup causes the .LOOP_VECTORIZED_CALL to vanish as well
because
if-conversion made us discover the dominating loops exit is never taken...

Before if-conversion we have

# _8 = PHI 
zr_15 = 0;
if (zr_15 <= 0)
  goto ; [87.64%]
else
  goto ; [12.36%]

the preceeding copyprop figures that out.  Before copyprop:

 [local count: 118111601]:
# _8 = PHI 
h3_lsm.11_4 = 0;
h3.2_19 = h3_lsm.11_4;
zr_15 = (long int) h3.2_19;
if (zr_15 <= 0)
  goto ; [87.64%]
else
  goto ; [12.36%]

and copyprop doesn't propagate through conversions but substitute-and-fold
will elide that.  And if-conversion then performs value-numbering on
the if-converted loop.

[Bug tree-optimization/89594] [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*))

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Not sure if maybe checking gimple_bb () on the call stmt would be enough.

[Bug tree-optimization/89594] [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*))

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Like

Index: gcc/tree-if-conv.c
===
--- gcc/tree-if-conv.c  (revision 269385)
+++ gcc/tree-if-conv.c  (working copy)
@@ -3176,6 +3176,8 @@ pass_if_conversion::execute (function *f
   for (unsigned i = 0; i < preds.length (); ++i)
 {
   gimple *g = preds[i];
+  if (!gimple_bb (g))
+   continue;
   unsigned ifcvt_loop = tree_to_uhwi (gimple_call_arg (g, 0));
   if (!get_loop (fun, ifcvt_loop))
{

[Bug tree-optimization/89594] [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*))

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Yours then.

[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2009-03-01 11:39:34 |2019-3-5

--- Comment #59 from Richard Biener  ---
GCC 8.3, x86_64:

First testcase:

-O0: 1GB, 8.8s

-O1: 1.7GB, 242s
 alias stmt walking :  85.84 ( 35%)   0.82 ( 22%)  86.84 ( 35%)
   2189 kB (  0%)
 tree CFG cleanup   :  13.73 (  6%)   0.00 (  0%)  13.75 (  6%)
   2055 kB (  0%)
 tree loop invariant motion :  66.65 ( 27%)   0.09 (  2%)  66.85 ( 27%)
  30968 kB (  2%)
 combiner   :  16.87 (  7%)   0.02 (  1%)  16.90 (  7%)
  18054 kB (  1%)
 reload CSE regs:  11.46 (  5%)   0.01 (  0%)  11.47 (  5%)
  10633 kB (  1%)

-O2: 4.3GB, 1994s
 alias stmt walking : 126.85 (  6%)   1.14 ( 23%) 128.38 (  6%)
   2875 kB (  0%)
 tree loop invariant motion :  67.50 (  3%)   0.08 (  2%)  67.64 (  3%)
  62356 kB (  2%)
 PRE:1644.36 ( 82%)   0.07 (  1%)1644.49 ( 82%)
   2877 kB (  0%)

Second, smaller testcase:

-O1: 420MB, 16s
 alias stmt walking :   7.06 ( 43%)   0.08 ( 13%)   7.15 ( 42%)
621 kB (  0%)
 tree loop invariant motion :   0.90 (  5%)   0.01 (  2%)   0.92 (  5%)
   3497 kB (  2%)
 integrated RA  :   2.89 ( 18%)   0.05 (  8%)   2.91 ( 17%)
  14261 kB (  9%)

-O2: 780MB, 48s
 alias stmt walking :  10.23 ( 21%)   0.09 ( 14%)  10.31 ( 21%)
785 kB (  0%)
 tree loop invariant motion :   0.94 (  2%)   0.01 (  2%)   0.96 (  2%)
   7264 kB (  2%)
 PRE:  19.39 ( 40%)   0.00 (  0%)  19.40 ( 39%)
281 kB (  0%)
 integrated RA  :   5.38 ( 11%)   0.09 ( 14%)   5.46 ( 11%)
  14033 kB (  4%)
 reload CSE regs:   2.28 (  5%)   0.00 (  0%)   2.28 (  5%)
   2486 kB (  1%)


The other testcase:

-O1: 2.8GB, 761s
 alias stmt walking : 188.53 ( 25%)   1.55 ( 20%) 190.19 ( 25%)
   3400 kB (  0%)
 tree CFG cleanup   :  82.33 ( 11%)   0.02 (  0%)  82.35 ( 11%)
   4103 kB (  0%)
 tree DSE   :  18.31 (  2%)   0.00 (  0%)  18.32 (  2%)
  0 kB (  0%)
 tree loop invariant motion : 296.98 ( 39%)   0.18 (  2%) 297.22 ( 39%)
  62472 kB (  2%)
 forward prop   :  10.22 (  1%)   0.03 (  0%)  10.24 (  1%)
  57889 kB (  2%)
 CSE:  14.47 (  2%)   0.01 (  0%)  14.47 (  2%)
  54258 kB (  2%)
 combiner   :  75.19 ( 10%)   0.03 (  0%)  75.22 ( 10%)
  35852 kB (  1%)
 reload CSE regs:  24.39 (  3%)   0.01 (  0%)  24.40 (  3%)
  21083 kB (  1%)

-O2: 9.2GB, 7634s
 alias stmt walking : 273.85 (  4%)   2.30 ( 22%) 276.44 (  4%)
   4533 kB (  0%)
 tree loop invariant motion : 284.31 (  4%)   0.46 (  4%) 284.89 (  4%)
 125719 kB (  1%)
 PRE:6714.77 ( 88%)   0.44 (  4%)6716.39 ( 88%)
   5747 kB (  0%)

[Bug c/88568] [7 Regression] 'dllimport' no longer implies 'extern' in C

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Created attachment 45894
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45894&action=edit
gcc9-pr88568-2.patch

Untested fix for that.  Apparently the C++ FE relies that static data members
have TREE_STATIC set, even when they are DECL_EXTERNAL, so this patch
essentially reverts the previous patch for static data members.

Unfortunately, like before, I have no way to test this on mingw/cygwin etc.

[Bug target/89592] FAIL: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_x_alt.o-cp_compat_y_tst.o execute against GCC4.8

[amker at gcc dot gnu.org]

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

--- Comment #4 from bin cheng  ---
(In reply to Jakub Jelinek from comment #1)
> Started with r233126.  Before that change, check2227 has not been NRV
> optimized, but now it is.  That doesn't explain an ABI difference though.

Hmm?? I am getting below error when building gcc-6-branch at commit
6b94e1332a8322aff91b7ed88395b79080f5e30d

cfns.gperf: In function ‘const char* libc_name_p(const char*, unsigned int)’:
cfns.gperf:101:1: error: ‘const char* libc_name_p(const char*, unsigned int)’
redeclared inline with ‘gnu_inline’ attribute
cfns.gperf:26:14: note: ‘const char* libc_name_p(const char*, unsigned int)’
previously declared here
cfns.gperf: At global scope:
cfns.gperf:26:14: warning: inline function ‘const char* libc_name_p(const
char*, unsigned int)’ used but never defined

[Bug target/89592] FAIL: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_x_alt.o-cp_compat_y_tst.o execute against GCC4.8

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to bin cheng from comment #4)
> (In reply to Jakub Jelinek from comment #1)
> > Started with r233126.  Before that change, check2227 has not been NRV
> > optimized, but now it is.  That doesn't explain an ABI difference though.
> 
> Hmm?? I am getting below error when building gcc-6-branch at commit
> 6b94e1332a8322aff91b7ed88395b79080f5e30d
> 
> cfns.gperf: In function ‘const char* libc_name_p(const char*, unsigned int)’:
> cfns.gperf:101:1: error: ‘const char* libc_name_p(const char*, unsigned
> int)’ redeclared inline with ‘gnu_inline’ attribute
> cfns.gperf:26:14: note: ‘const char* libc_name_p(const char*, unsigned int)’
> previously declared here
> cfns.gperf: At global scope:
> cfns.gperf:26:14: warning: inline function ‘const char* libc_name_p(const
> char*, unsigned int)’ used but never defined

One needs to use CXX='g++ -std=gnu++98' to build older gcc revisions (those
that are already using C++, but don't have fixed cfns).

[Bug rtl-optimization/89487] [8 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7993

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar  5 13:38:59 2019
New Revision: 269388

URL: https://gcc.gnu.org/viewcvs?rev=269388&root=gcc&view=rev
Log:
PR tree-optimization/89487
* gcc.dg/tree-ssa/pr89487.c: Include ../pr87600.h.
(caml_interprete): Ifdef the whole body out if REG1 or REG2 macros
aren't defined.  Use REG1 instead of "%r15" and REG2 instead of
"%r14".

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr89487.c

[Bug c++/89480] internal compiler error: in unify, at cp/pt.c:22160 with the template argument force conversion

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Started to ICE with r137361 when all the C++11 features used in there got
implemented, before that it has been rejected.  clang++ accepts it, icpc
rejects it, so unsure if it is valid or not.

[Bug c++/89480] internal compiler error: in unify, at cp/pt.c:22160 with the template argument force conversion

[kutdanila at yandex dot ru]

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

--- Comment #3 from Danila Kutenin  ---
Also not sure if this should compile. But if change Foo{} to static_cast
all the compilers compile.

[Bug tree-optimization/85762] [8/9 Regression] range-v3 abstraction overhead not optimized away

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Do you really want to match type of any field whatsoever, or better look for
the type of a field at the particular position?

[Bug c++/87148] [7/8/9 Regression] backward compatibility issue to take char [] as incomplete type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2

[rguenth at gcc dot gnu.org]

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

--- Comment #60 from Richard Biener  ---
PRE is all find_base_term exploding ...

The LIM case is all store_motion () which is quadratic and the only
user of the quadratic in memory all_refs_stored_in_loop.  The latter
would be reasonably easy to fix by iterating.  The former is more
difficult to fix, we'd need to rewrite SM to work inner-to-outer
loops somehow.  But that's certainly doable.  Gating store-motion
on optimize > 1 is possible as well (it also has the bad side-effect
of increasing register pressure by introducing IVs).

[Bug tree-optimization/85762] [8/9 Regression] range-v3 abstraction overhead not optimized away

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
(In reply to Jakub Jelinek from comment #7)
> Do you really want to match type of any field whatsoever, or better look for
> the type of a field at the particular position?

I was thinking about exactly this question but eventually I'd like to
fix this with something like
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00176.html

[Bug c/89549] [7/8/9 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
(In reply to Martin Liška from comment #4)
> Created attachment 45877 [details]
> test-case

Thanks; I'm able to see the behavior with that.

[Bug tree-optimization/89247] [7/8 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2409

[rguenth at gcc dot gnu.org]

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

Bug 89594 Summary: [9 Regression] ICE: Segmentation fault (in 
gsi_for_stmt(gimple*))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89594

   What|Removed |Added

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

[Bug tree-optimization/89594] [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*))

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Mar  5 14:57:12 2019
New Revision: 269389

URL: https://gcc.gnu.org/viewcvs?rev=269389&root=gcc&view=rev
Log:
2019-03-05  Richard Biener  

PR tree-optimization/89594
* tree-if-conv.c (pass_if_conversion::execute): Handle
case where .LOOP_VECTORIZED_FUNCTION was removed.

* gcc.dg/pr89594.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr89594.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-if-conv.c

[Bug tree-optimization/89594] [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*))

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/89222] [7/8/9 regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os

[wilco at gcc dot gnu.org]

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

--- Comment #9 from Wilco  ---
Author: wilco
Date: Tue Mar  5 15:04:01 2019
New Revision: 269390

URL: https://gcc.gnu.org/viewcvs?rev=269390&root=gcc&view=rev
Log:
[ARM] Fix PR89222

The GCC optimizer can generate symbols with non-zero offset from simple
if-statements. Bit zero is used for the Arm/Thumb state bit, so relocations
with offsets fail if it changes bit zero and the relocation forces bit zero
to true.  The fix is to disable offsets on function pointer symbols.  

gcc/
PR target/89222
* config/arm/arm.md (movsi): Use targetm.cannot_force_const_mem
to decide when to split off a non-zero offset from a symbol.
* config/arm/arm.c (arm_cannot_force_const_mem): Disallow offsets
in function symbols.

testsuite/
PR target/89222
* gcc.target/arm/pr89222.c: Add new test.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr89222.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.md
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/89570] [9 Regression] ICE in prepare_cmp_insn, at optabs.c:4001

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar  5 15:05:07 2019
New Revision: 269391

URL: https://gcc.gnu.org/viewcvs?rev=269391&root=gcc&view=rev
Log:
PR tree-optimization/89570
* match.pd (vec_cond into cond_op simplification): Don't use
get_conditional_internal_fn, use as_internal_fn (cond_op).

Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd

[Bug tree-optimization/89570] [9 Regression] ICE in prepare_cmp_insn, at optabs.c:4001

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #14 from Jakub Jelinek  ---
Fixed.

[Bug target/89222] [7/8 regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
Summary|[7/8/9 regression] ARM  |[7/8 regression] ARM
   |thumb-2 misoptimisation of  |thumb-2 misoptimisation of
   |func ptr call with -O2 or   |func ptr call with -O2 or
   |-Os |-Os

[Bug debug/89498] [8/9 Regression] ICE in AT_loc_list, at dwarf2out.c:4871

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug rtl-optimization/20211] autoincrement generation is poor

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|steven at gcc dot gnu.org  |
 Resolution|--- |WONTFIX

--- Comment #41 from Steven Bosscher  ---
After 12 years of changes, the value of the patches in this bug 
report, and indeed the bug report itself, is difficult to gauge.

If this is still an issue, and that issue isn't covered by one
of the more specific auto-inc-dec issues, please open a new PR 
with a test case and with the expected code.

For now, wontfix.

[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics

[steven at gcc dot gnu.org]

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

Bug 20211 Summary: autoincrement generation is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

[Bug other/17652] [meta-bug] GCC 4.1 pending patches

[steven at gcc dot gnu.org]

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

Bug 20211 Summary: autoincrement generation is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

[Bug other/23111] [meta-bug] GCC 4.2 pending patches

[steven at gcc dot gnu.org]

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

Bug 20211 Summary: autoincrement generation is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

[Bug c++/89596] New: [8 regression] Multiple templated conversion operators result in compilation error

[jleahy+gcc at gmail dot com]

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

Bug ID: 89596
   Summary: [8 regression] Multiple templated conversion operators
result in compilation error
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jleahy+gcc at gmail dot com
  Target Milestone: ---

The follow code compiles fine on GCC <=7.4 (and also on Clang). However on 8.0
(and trunk) it fails.

template
struct Bar {
Bar() = default;
Bar(double x) {}
};

struct Foo {
template
operator T() {
return T();
}
template
operator Bar() {
return Bar();
}
};

void test() {
(void)static_cast>(Foo());
}

The following error is produced:

: In function 'void test()':
:20:38: error: call of overloaded 'Bar(Foo)' is ambiguous
 (void)static_cast>(Foo());
:5:5: note: candidate: 'Bar::Bar(double) [with T = int]'
 Bar(double x) {}
:3:8: note: candidate: 'constexpr Bar::Bar(const Bar&)'
 struct Bar {
:3:8: note: candidate: 'constexpr Bar::Bar(Bar&&)'

I believe from the standard GCC should consider all converting constructors (of
which there are none applicable) and user-defined conversion operators (of
which both are applicable) then apply normal overload resolution. During
overload resolution one of the two conversion operators will be discarded as
it's less specialized than the other.