[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[egallager at gcc dot gnu.org]

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

--- Comment #20 from Eric Gallager  ---
(In reply to m...@gcc.gnu.org from comment #19)
> I'm fine with Backporting for affected branches.

So... that's still 6 and 7 at this point?

[Bug libstdc++/87258] vector useless offset

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-08
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Marc Glisse from comment #0)
> Maybe begin could return _Bit_iterator(_M_start._M_p, 0) instead of _M_start
> to give more information to the compiler?

Even if we can't change anything else, this seems worthwhile.

[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
For the above case, there are during the recursion 77608 synth_mult calls,
which might be ok, so indeed better hashing would help, but 10311 is too large
and is not a prime number.  Plus this hash table is resolving all collisions by
evicting older cash entries.
That is perhaps fine for the toplevel synth_mult calls, but for the recursive
ones I guess we want to make sure we cache all the values needed to compute the
same toplevel call and perhaps only record the toplevel call's entry if it
would need to evict older entries.
So maybe use the current hash table + another temporary hash_map live just
during the outermost synth_mult call (and activate this behavior only if say
seeing a recursion count of 16)?

[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()

[slyfox at inbox dot ru]

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

--- Comment #5 from Sergei Trofimovich  ---
(In reply to dave.anglin from comment #3)
> On 2018-09-08 3:11 PM, slyfox at inbox dot ru wrote:
> > -#define NUM_ALG_HASH_ENTRIES 1031
> > +#define NUM_ALG_HASH_ENTRIES 10311
> Does this help the compile time for xxhash?

A bit: it shrinks compile time from 80s to 13s (other targets do it in
sub-second times).

Ran the build against gcc master as:

${HOME}/dev/git/gcc-hppa2.0/gcc/xgcc -B${HOME}/dev/git/gcc-hppa2.0/gcc/ -O2
-pipe -fdiagnostics-show-option -frecord-gcc-switches -Wall -Wextra -Wcast-qual
-Wcast-align -Wshadow -Wstrict-aliasing=1 -Wswitch-enum
-Wdeclaration-after-statement -Wstrict-prototypes -Wundef   -c -o xxhash.o
xxhash.c -ftime-report

  Before the patch:
Time variable   usr   sys 
wall   GGC
 expand :  82.20 ( 93%)   0.01 (  7%)  82.94 (
93%)4372 kB ( 11%)
 TOTAL  :  88.11  0.14 89.06   
  40621 kB

  After the patch:
Time variable   usr   sys 
wall   GGC
 expand :   8.95 ( 68%)   0.00 (  0%)   8.93 (
67%)4372 kB ( 11%)
 TOTAL  :  13.15  0.08 13.24   
  40623 kB

perf record/report still shows most of time is dominated by synth_mult():
64.59%  cc1  cc1   [.] synth_mult
 3.00%  cc1  cc1   [.] sd_lists_size

[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Can be reproduced on x86_64-linux on the same testcase, just put a breakpoint
on
synth_mult and
(gdb) set var t = -8796714831421723037
(gdb) set cost_limit->cost = 128
(gdb) set cost_limit->latency = 128
there is quite a recursion.  Or even on
unsigned long long foo (unsigned long long x) { return x *
-8796714831421723037LL; }
with -O2 and the same manually bumped cost/latency on the outermost synth_mult.
If I instrument synth_mult, in this case there are 4897996 calls to synth_mult,
different counts at various levels of synth_mult recursion (first number is
number of synth_mult callers of synth_mult, the second number how many such
synth_mult calls have been made):
0 2
1 5
2 16
3 36
4 98
5 231
6 528
7 1112
8 2127
9 4007
10 7492
11 13147
12 22400
13 36880
14 59282
15 93213
16 141522
17 201388
18 271570
19 359030
20 440279
21 505613
22 571884
23 587240
24 518362
25 409409
26 299289
27 195388
28 102828
29 40657
30 10932
31 1897
32 132

In any case, with very small cost of addition and shifts and extremely high
cost and latency of multiplication, we seem to spend way too much trying to
find an optimal synthetic multiplication sequence.

[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build

[iains at gcc dot gnu.org]

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

--- Comment #3 from Iain Sandoe  ---
Just a few notes:

1. I'm not objecting to some kind of automation to switch off the 32b multiline
where the *target* system is >= 10.14/Darwin18 (someone needs to write it,
that's all).

2. Actually, you get the same failure on GNU-Linux if you try to configure
defaults on (for example) an x86_64 system without 32bit libs installed (one
has to add --disable-multilib there, or install 32b libs), so automation is not
the default on Linux.

3. I don't see why GCC should be subject to the vendor's support policy.  As
far as I am concerned, with the right SDK / sysroot available, there's no
reason why a compiler *hosted* on x86-64-Darwin18 shouldn't be able to build
code for i686-darwin10 *target*.

[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-08
 CC||danglin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||howarth.at.gcc at gmail dot com

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

[Bug target/87257] i386 multilib build should be disabled for x86_64-apple-darwin18

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Iain Sandoe  ---


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

[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()

[dave.anglin at bell dot net]

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

--- Comment #3 from dave.anglin at bell dot net ---
On 2018-09-08 3:11 PM, slyfox at inbox dot ru wrote:
> -#define NUM_ALG_HASH_ENTRIES 1031
> +#define NUM_ALG_HASH_ENTRIES 10311
Does this help the compile time for xxhash?

[Bug libstdc++/87258] New: vector useless offset

[glisse at gcc dot gnu.org]

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

Bug ID: 87258
   Summary: vector useless offset
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ABI, missed-optimization
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

Hello,

I guess nobody will care much since this is vector, but I don't
understand why _M_start is a _Bit_iterator. This means that it includes a
useless _M_offset that is always 0 (that's easy to check since operator[]
ignores it). It wastes some space. And since begin() returns _M_start, it also
makes it hard for the compiler to know that the beginning offset is always 0,
and we often generate a lot of dead code to handle the non-zero case.

Removing the offset would break the ABI, so I guess that's not going to fly.
(_M_finish is also not very space efficient with pointer+length where just the
size would work, but maybe it is faster?) As a comparison, sizeof(vector)
is 40 with libstdc++ and 24 with libc++ on x86_64 linux.

Maybe begin could return _Bit_iterator(_M_start._M_p, 0) instead of _M_start to
give more information to the compiler?

[Bug target/87257] i386 multilib build should be disabled for x86_64-apple-darwin18

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-09-08
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Duplicate of pr87030?

[Bug target/87257] New: i386 multilib build should be disabled for x86_64-apple-darwin18

[howarth.at.gcc at gmail dot com]

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

Bug ID: 87257
   Summary: i386 multilib build should be disabled for
x86_64-apple-darwin18
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: howarth.at.gcc at gmail dot com
  Target Milestone: ---

The Xcode 10 release on x86_64-apple-darwin18 obsoletes i386 code generation as
its default behavior. This was achieved by having the 10.14 SDK's buried
/usr/lib/libSystem.tbd only expose the x86_64 symbols contained in the fat root
level /usr/lib/libSystem.dylib.   

$ clang -m32 hello.c
ld: warning: The i386 architecture is deprecated for macOS (remove from the
Xcode build setting: ARCHS)
ld: warning: ignoring file
/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd,
missing required architecture i386 in file
/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd
Undefined symbols for architecture i386:
  "_printf", referenced from:
  _main in hello-04a500.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This can be fudged by installing the fall back header package for / so that the
/usr/lib/libSystem.dylib is used, but that package is slated for removal in a
later OS release and its use highly discouraged. So FSF gcc's configure should
be modified to default to disable-multilib for darwin18 and later.

[Bug ipa/87254] Inlining clones in trivial wrappers

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to Alexander Monakov from comment #1)
> I think the "stack growth" aspect of this issue is the same as PR 87094?

It is quite possible that this is a DUP indeed, I'll let someone else decide.
Here, if IPA cleaned up after cloning (most of f's clone is behind if(0!=0)),
it might not even need the improved stack growth heuristic. But we also want
inlining when f's clone remains large, so changing that heuristic seems like
the right option.

Thanks for filing PR 87094 :-)

[Bug ipa/87254] Inlining clones in trivial wrappers

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
I think the "stack growth" aspect of this issue is the same as PR 87094?

[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()

[slyfox at inbox dot ru]

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

--- Comment #2 from Sergei Trofimovich  ---
synth_mult() is called 57M times on this tiny sample.

I noticed there is a NUM_ALG_HASH_ENTRIES bucket size for already computed
algorithms for multiplication. The below tweak seems to workaround pathological
case:

--- a/gcc/expmed.h
+++ b/gcc/expmed.h
@@ -128,7 +128,7 @@ struct alg_hash_entry {

 /* The number of cache/hash entries.  */
 #if HOST_BITS_PER_WIDE_INT == 64
-#define NUM_ALG_HASH_ENTRIES 1031
+#define NUM_ALG_HASH_ENTRIES 10311
 #else
 #define NUM_ALG_HASH_ENTRIES 307
 #endif

$ ./xgcc -B. -O2 -fomit-frame-pointer -c -o bug.o bug.c -ftime-report

Time variable   usr   sys  wall
  GGC
 phase setup:   0.00 (  0%)   0.00 (  0%)   0.01 (  2%)
960 kB ( 62%)
 phase parsing  :   0.00 (  0%)   0.00 (  0%)   0.02 (  4%)
109 kB (  7%)
 phase opt and generate :   0.39 (100%)   0.00 (  0%)   0.46 ( 94%)
464 kB ( 30%)
 preprocessing  :   0.00 (  0%)   0.00 (  0%)   0.02 (  4%)
  9 kB (  1%)
 dominator optimization :   0.00 (  0%)   0.00 (  0%)   0.02 (  4%)
  1 kB (  0%)
 expand :   0.37 ( 95%)   0.00 (  0%)   0.42 ( 86%)
 50 kB (  3%)
 combiner   :   0.01 (  3%)   0.00 (  0%)   0.01 (  2%)
 97 kB (  6%)
 initialize rtl :   0.01 (  3%)   0.00 (  0%)   0.00 (  0%)
 13 kB (  1%)
 verify RTL sharing :   0.00 (  0%)   0.00 (  0%)   0.01 (  2%)
  0 kB (  0%)
 TOTAL  :   0.39  0.00  0.49   
   1543 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.

[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

 Target||hppa-*
 CC||dave.anglin at bell dot net,
   ||law at redhat dot com

--- Comment #1 from Sergei Trofimovich  ---
Reproducible on today's vanilla gcc-master as well:

./xgcc -B. -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: hppa2.0-unknown-linux-gnu
Configured with: ../gcc/configure --target=hppa2.0-unknown-linux-gnu
--prefix=/home/slyfox/dev/git/gcc-hppa2.0/../gcc-hppa2.0-installed
--with-sysroot=/usr/hppa2.0-unknown-linux-gnu --disable-bootstrap
--enable-languages=c --disable-nls CFLAGS='-O2 -g' CXXFLAGS='-O2 -g'
Thread model: posix
gcc version 9.0.0 20180908 (experimental) (GCC)

$ ./xgcc -B. -O2 -fomit-frame-pointer -c -o bug.o bug.c -ftime-report

Time variable   usr   sys  wall
  GGC
 phase opt and generate :  10.90 (100%)   0.00 (  0%)  10.91 (100%)
464 kB ( 30%)
 df live regs   :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
  0 kB (  0%)
 tree PRE   :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
 23 kB (  2%)
 expand :  10.89 (100%)   0.00 (  0%)  10.89 (100%)
 50 kB (  3%)
 integrated RA  :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
 98 kB (  6%)
 TOTAL  :  10.90  0.00 10.91   
   1543 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.

$ perf record -- ./xgcc -B. -O2 -fomit-frame-pointer -c -o bug.o bug.c
-ftime-report
$ perf report | cat

96.49%  cc1  cc1   [.] synth_mult
 2.36%  cc1  cc1   [.] optimize_function_for_size_p
 0.34%  cc1  cc1   [.] optimize_insn_for_size_p
 0.32%  cc1  cc1   [.] optimize_insn_for_speed_p
 0.02%  cc1  [kernel.vmlinux]  [k] native_irq_return_iret

[Bug middle-end/87256] New: hppa spends huge amount of time in synth_mult()

[slyfox at inbox dot ru]

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

Bug ID: 87256
   Summary: hppa spends huge amount of time in synth_mult()
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
  Target Milestone: ---

Created attachment 44672
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44672=edit
bug.c

Performance hog initially noticed on http://www.xxhash.com project
(xxhash-0.6.5). When being compiled on hppa it takes hours for gcc. When being
compiled on x86_64 it takes seconds.

Minimal example:

// $ time /usr/bin/hppa2.0-unknown-linux-gnu-gcc -O2 -fomit-frame-pointer -c -o
bug.o bug.C
// real0m9,051s
// user0m9,040s
// sys 0m0,009s
void a (long);
void b (long long c, int s)
{
  switch (s)
{
case 4:
  c = 0;
case 6:
  c = c * 13;
case 8:
  c = c + 19;
case 28:
  c = c * 0x85ebca77c2b2ae63LLU;
  c = c * 9650029242287828579LL;
  c = c * 9650029242287828579LL;
  c = c * 9650029242287828579LL; /* this line adds 2 seconds: 7->9 */
  c = c * 9650029242287828579LL; /* this line adds 2 seconds: 9->11 */
  a (c);
}
}

[Bug fortran/87255] New: Different semantics of OpenMP combined construct and nested constructs

[ben at rockshrub dot de]

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

Bug ID: 87255
   Summary: Different semantics of OpenMP combined construct and
nested constructs
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ben at rockshrub dot de
  Target Milestone: ---

This was reported on the OpenMP Forum as a difference between gfortran and the
Intel Fortran compiler here
http://forum.openmp.org/forum/viewtopic.php?f=3=2055

However, I think gfortran incorrectly compiles the OpenMP combined "parallel
do" construct, evaluating the loop bounds outside of the parallel context. An
OpenMP "do" construct directly nested inside an OpenMP "parallel" construct
seems to evaluate the loop bounds inside the parallel context as one would
expect. The OpenMP API 4.5 states in section 2.11 that the two (combined
construct and nested constructs) should have identical semantics.

GCC version, configure/build options, system type:
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/8.2.0/libexec/gcc/x86_64-apple-darwin17.7.0/8.2.0/lto-wrapper
Target: x86_64-apple-darwin17.7.0
Configured with: ../configure --build=x86_64-apple-darwin17.7.0
--prefix=/usr/local/Cellar/gcc/8.2.0
--libdir=/usr/local/Cellar/gcc/8.2.0/lib/gcc/8
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-8
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-checking=release --with-pkgversion='Homebrew GCC
8.2.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-nls
Thread model: posix
gcc version 8.2.0 (Homebrew GCC 8.2.0) 

Command line that triggers the bug:
$ gfortran -Wall -Wextra -fopenmp num_threads_as_loop_bounds.f90
(no compiler output/error messages)

Contents of num_threads_as_loop_bounds.f90:
program test
  use omp_lib
  implicit none

  integer :: i

  print *, "Combined construct:"
  !$omp parallel do
  do i = 1, omp_get_num_threads()
print *, i
  end do
  !$omp end parallel do

  print *, "Nested constructs:"
  !$omp parallel
  !$omp do
  do i = 1, omp_get_num_threads()
print *, i
  end do
  !$omp end do
  !$omp end parallel
end program

Expected program output:
 Combined construct:
   1
   3
   4
   2
 Nested constructs:
   2
   3
   4
   1

Actual program output:
 Combined construct:
   1
 Nested constructs:
   2
   3
   4
   1

[Bug c++/87150] [8 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[8/9 Regression] move ctor  |[8 Regression] move ctor
   |wrongly chosen in return|wrongly chosen in return
   |stmt (derived vs. base) |stmt (derived vs. base)

--- Comment #14 from Marek Polacek  ---
Fixed.  (I don't think this should be backported to 8.)

[Bug c++/87150] [8/9 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
Author: mpolacek
Date: Sat Sep  8 17:36:08 2018
New Revision: 264172

URL: https://gcc.gnu.org/viewcvs?rev=264172=gcc=rev
Log:
PR c++/87150 - wrong ctor with maybe-rvalue semantics.
* call.c (struct conversion): Update commentary.
(standard_conversion): Set rvaluedness_matches_p if
LOOKUP_PREFER_RVALUE
for ck_base.

* g++.dg/cpp0x/move-return2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/move-return2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/86678] constexpr evaluation incorrectly diagnoses unevaluated call to non-constexpr function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #6 from Jason Merrill  ---
Fixed for GCC 9.

[Bug c++/86678] constexpr evaluation incorrectly diagnoses unevaluated call to non-constexpr function

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Sat Sep  8 16:00:02 2018
New Revision: 264171

URL: https://gcc.gnu.org/viewcvs?rev=264171=gcc=rev
Log:
PR c++/86678 - constexpr function with non-constant after return.

In this testcase, the call to f() can never be a constant
expression, but that's not a problem because it isn't always
reached by calls to g.  We were wrongly rejecting this because
potential_constant_expression_1 lacked the jump tracking that
cxx_eval_constant_expression has.  So this patch adds a simpler
version of that tracking.

* constexpr.c (potential_constant_expression_1): Add jump_target.
(breaks): Check for BREAK_STMT.
(continues): Check for CONTINUE_STMT.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-return4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug c++/53215] Warn if orphaned memory is created by ignoring return value of new

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
The result of the builtin operator new isn't unused in a new expression.
operator new() is called by the compiler to allocate memory, then it constructs
objects in that memory. So the actual allocation result isn't unused. The
pointer returned by the new expression is unused, but that's not always a bug.
This code is fine and doesn't leak:

struct X {
  X();
};

X* global;

X::X() { global = this; }

int main() {
  new X;
  delete global;
}

We could probably teach the compiler to warn about unused results of anything
with attribute__((malloc)), which would cover raw calls to the operator new()
function (but nobody calls that by mistake and forgets to use the result, so I
doubt it will catch any bugs).

More useful might be to warn about any new expression where no non-trivial
initialization happens. That would not warn about the example above (because X
has a non-trivial default constructor) but would warn about the example in
comment 0, and cases for classes with trivial default constructors.

I'm still not convinced this is a real problem that needs to be solved, but if
adding a warning isn't too hard maybe it's worth doing.

[Bug c++/87150] [8/9 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|SUSPENDED   |ASSIGNED

--- Comment #12 from Marek Polacek  ---
(In reply to Jason Merrill from comment #11)
> (In reply to Stephan Bergmann from comment #9)
> > (In reply to Marek Polacek from comment #8)
> > > It appears that the sentiment is that this testcase should actually be
> > > valid
> > 
> > Do you have a reference for that?  The reason for this not to be valid,
> > presented at the bottom of
> >  "Re:
> > [cfe-dev] return lvalue move instead of copy?" looks rather convincing to 
> > me.
> 
> (Namely, slicing by move leaving the object in a partially-moved state that
> might not maintain invariants.)
> 
> That's a good point.  I guess the rule we're looking for will still require
> that the returned object being treated as an xvalue be bound to some rvalue
> reference to the whole object, rather than a base subobject.
> 
> So Marek, please go ahead and apply your patch after all.  

Will do.

> And similarly,
> maybe refine your 87109 patch to only reject the conversion function if it
> comes from a base class.

I'll send a patch to the ML, I don't feel like committing that without a
review.

[Bug fortran/87103] [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-08
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Patch at https://gcc.gnu.org/ml/fortran/2018-09/msg00044.html.

[Bug libfortran/87000] LBOUND and UBOUND give unexpected result for arrays without 1-based indices if in subprogram

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #4 from Dominique d'Humieres  ---
Related discussion at
https://groups.google.com/forum/#!topic/comp.lang.fortran/YoQPFwla7L0.

For the test in comment 2, gfortran gives

 lbound =   -5
 ubound =   10
 lbound =1
 ubound =   16

since gcc6. I think it is the expected result. Closing as INVALID.

[Bug middle-end/63510] Wrong line number in Wstrict-overflow message

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #14 from Iain Buclaw  ---
Not reproducible on gcc (GCC) 9.0.0 20180903 (experimental)

[Bug rtl-optimization/85458] FAIL: gcc.dg/pr83480.c (internal compiler error)

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from John David Anglin  ---
Fixed on trunk.

[Bug c++/86678] constexpr evaluation incorrectly diagnoses unevaluated call to non-constexpr function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug rtl-optimization/85458] FAIL: gcc.dg/pr83480.c (internal compiler error)

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin  ---
Author: danglin
Date: Sat Sep  8 13:20:23 2018
New Revision: 264168

URL: https://gcc.gnu.org/viewcvs?rev=264168=gcc=rev
Log:
PR rtl-optimization/85458
* sel-sched.c (sel_target_adjust_priority): Allow backend adjust
priority hook to reduce the priority of EXPR.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/sel-sched.c

[Bug ipa/87254] New: Inlining clones in trivial wrappers

[glisse at gcc dot gnu.org]

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

Bug ID: 87254
   Summary: Inlining clones in trivial wrappers
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

int h();
static int f(int j,double*a){
  if(j)
  {
double t[1024];
for(int i=0;i<1024;++i){t[i]=i;}
return t[(int)*a];
  }
  else
return h();
}
int g(double*a){return f(0,a);}

Compiled with -O3.

The code in f is random crap, the key elements to reproduce are:
- f is not inlined in einline,
- f is cloned in IPA-CP,
- the clone of f is not inlined in g.

(so a simpler reproducer may be possible with -fdisable-tree-einline --param
ipa-cp-eval-threshold=10)

The first 2 steps are normal, but the last one seems wrong to me. There is
nothing to lose by inlining f's clone into the trivial wrapper that is its only
caller. The inline dump complains that "--param large-stack-frame-growth limit
reached", but changing this param has no effect, I have to change
"large-stack-frame" instead to convince it to inline.


Just in case, before that I was investigating

static int f(int j,double*a){
  if(j)
  {
double t[1024];
for(int i=0;i<1024;++i){t[i]=i;}
return t[(int)*a];
  }
  else
  {
float t[1024];
for(int i=0;i<1024;++i){t[i]=i;}
return t[(int)*a];
  }
}
int g(double*a){return f(0,a);}
int h(double*a){return f(1,a);}

with -O3 -fdisable-tree-einline --param ipa-cp-eval-threshold=10 .

In the past, I have seen such trivial left-over wrappers with -flto on GMP (
https://gmplib.org/list-archives/gmp-devel/2018-April/004874.html ), and I was
reminded of it by https://stackoverflow.com/q/51152215/1918193 .

[Bug fortran/85395] [F03] private clause contained in derived type acquires spurious scope

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
I have verified that the patch in comment 5 shows no failures in the testsuite.

[Bug target/87253] New: Python test_ctypes fails when built with gcc 8.2

[kugan at gcc dot gnu.org]

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

Bug ID: 87253
   Summary: Python test_ctypes fails when built with gcc 8.2
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kugan at gcc dot gnu.org
  Target Milestone: ---

Python-2.7.15

Steps to reproduce error
In Python src directory:
./configure
make
./python Lib/test/regrtest.py -v test_ctypes

==
FAIL: test_struct_by_value (ctypes.test.test_win32.Structures)
--
Traceback (most recent call last):
  File
"/home/kugan.vivekanandarajah/Python-2.7.15/Lib/ctypes/test/test_win32.py",
line 113, in test_struct_by_value
self.assertEqual(ret.left, left.value)
AssertionError: -200 != 10



gdb ./python
b ReturnRect
r Lib/test/regrtest.py -v test_ctypesQuit

(gdb) p cp
$9 = {x = 15, y = 25}
(gdb) p fp
$10 = {x = 548534164448, y = 9890688}

cp and fp are the same as can  be seen from below:

vi /home/kugan.vivekanandarajah/Python-2.7.15/Lib/ctypes/test/test_win32.py
+112

pt = POINT(15, 25)
...
ReturnRect = dll.ReturnRect
ReturnRect.argtypes = [c_int, RECT, POINTER(RECT), POINT, RECT,
  POINTER(RECT), POINT, RECT]


ret = ReturnRect(i, rect, pointer(rect), pt, rect,
 byref(rect), pt, rect)


gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/kugan.vivekanandarajah/install/usr/local/bin/../libexec/gcc/aarch64-unknown-linux-gnu/8.2.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../gcc/configure --disable-bootstrap
Thread model: posix
gcc version 8.2.1 20180907 (GCC)

[Bug c++/87150] [8/9 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill  ---
(In reply to Stephan Bergmann from comment #9)
> (In reply to Marek Polacek from comment #8)
> > It appears that the sentiment is that this testcase should actually be
> > valid
> 
> Do you have a reference for that?  The reason for this not to be valid,
> presented at the bottom of
>  "Re:
> [cfe-dev] return lvalue move instead of copy?" looks rather convincing to me.

(Namely, slicing by move leaving the object in a partially-moved state that
might not maintain invariants.)

That's a good point.  I guess the rule we're looking for will still require
that the returned object being treated as an xvalue be bound to some rvalue
reference to the whole object, rather than a base subobject.

So Marek, please go ahead and apply your patch after all.  And similarly, maybe
refine your 87109 patch to only reject the conversion function if it comes from
a base class.

[Bug fortran/85395] [F03] private clause contained in derived type acquires spurious scope

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
The following patch also fixes the problem:


diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 03298833c98..83fc6c29b5a 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -6754,7 +6754,7 @@ match_ppc_decl (void)
   gfc_clear_attr (_attr);
   current_attr.procedure = 1;
   current_attr.proc_pointer = 1;
-  current_attr.access = tb->access;
+  current_attr.access = gfc_current_block()->component_access;
   current_attr.flavor = FL_PROCEDURE;

   /* Match the colons (required).  */


I think this approach is better than the one in comment 4.

There are two kinds of default access: One for components, one for type-bound
procedures. For procedure-pointer components, gfortran currently applies the
TBP default access. I think this is wrong (since PPCs are declared in the
component part, not in the TBP part of a type declaration). The above patch
fixes it.

[Bug fortran/85395] [F03] private clause contained in derived type acquires spurious scope

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from janus at gcc dot gnu.org ---
The problem can be fixed with this patch:


diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
index 13cc6f5fccd..5f0d181d728 100644
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -3267,6 +3267,7 @@ parse_derived (void)
   push_state (, COMP_DERIVED, gfc_new_block);

   gfc_new_block->component_access = ACCESS_PUBLIC;
+  gfc_typebound_default_access = ACCESS_PUBLIC;
   seen_private = 0;
   seen_sequence = 0;
   seen_component = 0;


I'm not sure if this is the best way to fix it, though.

[Bug lto/87187] FAIL: gfortran.dg/short_circuiting_3.f90 -g -flto (internal compiler error) on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
This PR is not fixed by the patch in pr86549 comment0.

[Bug debug/86549] [8/9 Regression] -flto -g0 vs. -g issues

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
The patch in comment 0 fixes

FAIL: g++.dg/asan/pr62017.C   -O2 -flto  (internal compiler error)
FAIL: g++.dg/asan/pr62017.C   -O2 -flto  (test for excess errors)
FAIL: g++.dg/asan/pr62017.C   -O2 -flto -flto-partition=none  (internal
compiler error)
FAIL: g++.dg/asan/pr62017.C   -O2 -flto -flto-partition=none  (test for excess
errors)
FAIL: g++.dg/asan/pr78651.C   -O2 -flto  (internal compiler error)
FAIL: g++.dg/asan/pr78651.C   -O2 -flto  (test for excess errors)
FAIL: g++.dg/asan/pr78651.C   -O2 -flto -flto-partition=none  (internal
compiler error)
FAIL: g++.dg/asan/pr78651.C   -O2 -flto -flto-partition=none  (test for excess
errors)
FAIL: g++.dg/asan/pr81021.C   -O2 -flto  (internal compiler error)
FAIL: g++.dg/asan/pr81021.C   -O2 -flto  (test for excess errors)
FAIL: g++.dg/asan/pr81021.C   -O2 -flto -flto-partition=none  (internal
compiler error)
FAIL: g++.dg/asan/pr81021.C   -O2 -flto -flto-partition=none  (test for excess
errors)

but not pr87187.

[Bug fortran/86830] [8/9 Regression] Contiguous array pointer function result not recognized as contiguous

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> This draft patch fixes the problem:

... and regtests cleanly.

[Bug fortran/77325] ICE in gimplify_var_or_parm_decl, at gimplify.c:1933

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Blocks||68241

--- Comment #3 from Dominique d'Humieres  ---
Duplicate of/ related to pr84109 and pr87239.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
[Bug 68241] [meta-bug] [F03] Deferred-length character

[Bug fortran/84109] ICE in adjustl on allocatable array of strings

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
Duplicate of/ related to pr77325 and pr87239.

[Bug fortran/87239] ICE in deferred-length string

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Blocks||68241

--- Comment #4 from Dominique d'Humieres  ---
Duplicate of/ related to pr77325 and pr84109.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
[Bug 68241] [meta-bug] [F03] Deferred-length character

[Bug fortran/86830] [8/9 Regression] Contiguous array pointer function result not recognized as contiguous

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from janus at gcc dot gnu.org ---
It seems the regressions was introduced by r254914, see PR 83012.

[Bug fortran/86830] [8/9 Regression] Contiguous array pointer function result not recognized as contiguous

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org
   Target Milestone|--- |8.3

--- Comment #2 from janus at gcc dot gnu.org ---
This draft patch fixes the problem:


diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index c5bf822cd24..43a37018575 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -5390,7 +5390,7 @@ gfc_is_simply_contiguous (gfc_expr *expr, bool strict,
bool permit_element)
  gfc_ref *r, *rc;

  s = expr->symtree->n.sym;
- if (s->ts.type != BT_CLASS)
+ if (s->ts.type != BT_CLASS && s->ts.type != BT_DERIVED)
return false;

  rc = NULL;