[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #12 from Martin Liška  ---
> >static const unsigned HOST_WIDE_INT max_ratio_for_speed = 8;
> 
> I guess most of these should have been --params ...

Yes. I have been thinking about that for quite some time. I'll do it.

[Bug lto/90369] error: could not unlink output file

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Replicating on x86_64-linux native yields (assuming empty.ld is an empty file):

g++ -o f.elf -T empty.ld -Wl,--gc-sections -O2 -save-temps obj.a
/usr/bin/ld: f.elf: not enough room for program headers, try linking with -N
/usr/bin/ld: final link failed: bad value
/usr/bin/ld: error: could not unlink output file
collect2: error: ld returned 1 exit status

not sure if it really makes sense to link using an empty linker script?  Btw,
the removal error is probably from our debug copying magic:

31920 unlink("/tmp/ccXvUkmS")   = 0
31920 unlink("f.elf.ltrans0.ltrans.o")  = 0
31920 unlink("obj.a.debug.temp.o")  = 0
31920 unlink("obj.a.debug.temp.o")  = -1 ENOENT (No such file or directory)
31920 write(2, "/usr/bin/ld", 11)   = 11
31920 write(2, ": error: could not unlink output"..., 38) = 38

which eventually ends up re-using the same temporary file multiple times
for each archieve member.  Going to fix that.

[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
(In reply to Fredrik Hederstierna from comment #9)
> I did the test suggested, the results was as follows
> 
> A. gcc-8.2.0
> B. gcc-9.1.0
> C. gcc-9.1.0 -fno-jump-tables
> D. gcc-9.1.0 patched "max_ratio_for_size = 2"
> 
> Overall CSiBE was
> 
> A: 2 413 510 bytes
> B: 2 417 915 bytes (+4405 bytes, +0.18%)
> C: 2 423 413 bytes (+9903 bytes, +0.41%)
> D: 2 417 739 bytes (+4229 bytes, +0.18%)
> 
> Example file CSiBE "vsprintf.c" was
> 
> A: 2369 bytes
> B: 2589 bytes (+220 bytes, +9.3%)
> C: 2445 bytes ( +76 bytes, +3.2%)
> D: 2489 bytes (+120 bytes, +5.1%)
> 
> So it didn't really solve it, but made it better possibly,
> though there are othre code size regression aswell for gcc-9.1.0 which might
> also affect results..

Thank you very much for the numbers! Apparently, changing 3->2 does not help
as much as I hoped. Anyway, I'll prepare params for it.

[Bug c++/90372] [x64][missed optimization] pushes unused r12 onto stack on unique_ptr use

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
>The similar two() function does not do this

But it is different and not always semantically the same (due to a GNU
extension).

In the one case, the labada is called during a "finally" statement.

In the finally statement, rax becomes the exception (struct _Unwind_Exception
*) that is being thrown currently at the landing pad, this needs to be saved
around the call to fclose, so it is stored in r12 (maybe it could be pushed to
the stack instead but that raises more issues than it solves) and then it needs
to be in the function arugment for _Unwind_Resume.

In the two case, we do a catch and then we throw the current handled exception.
If you noticed the exception that is being currently throw is in eax but saved
off via __cxa_begin_catch into TLS global and then inside __cxa_rethrow, it
will grab that saved off value and then call _Unwind_Resume_or_Rethrow (~the
same call to _Unwind_Resume).  Oh there is an extra step "finally" step to call
__cxa_end_catch too after resuming of the unwinding.

So the one case is actually better for the normal case and the exception case.

[Bug tree-optimization/90373] Better alias analysis based on libc functions with arguments which cannot alias

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think this is a dup of bug 82885 or at least very much related to it.

[Bug tree-optimization/90373] New: Better alias analysis based on libc functions with arguments which cannot alias

[david.bolvansky at gmail dot com]

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

Bug ID: 90373
   Summary: Better alias analysis based on libc functions with
arguments which cannot alias
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.bolvansky at gmail dot com
  Target Milestone: ---

bool foo(int *a, int *b, unsigned n) {
memcpy(a, b, n);
return a == b;
}

GCC trunk X86-64 -O3
foo(int*, int*, unsigned int):
pushrbx
mov edx, edx
mov rbx, rsi
callmemcpy
cmp rax, rbx
pop rbx
seteal
ret

if a and b aliases, it would be UB to call memcpy since "The memory areas must
not overlap.". Currently GCC emits "a == b", but possibly, info that a cannot
alias b in range n could be propagated more.


Same for strcpy
"The strings may not overlap, and the destination string dest must be large
enough to receive the copy."

[Bug tree-optimization/90373] Better alias analysis based on libc functions with arguments which cannot alias

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug fortran/90374] New: Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[thenlich+gccbug at gmail dot com]

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

Bug ID: 90374
   Summary: Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d
and ew.d e0 edit descriptors for output
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thenlich+gccbug at gmail dot com
  Target Milestone: ---

The new features of Fortran 2018 (ISO/IEC JTC1/SC22/WG5 N2145):

"5.5 d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors

It was anomalous that the field width w was allowed to be given as zero for
some output g editing, but not for d, e, es, en, and all g output editing. This
has been corrected. If the value is zero, the processor selects the smallest
positive actual field width that does not result in a field filled with
asterisks. A zero value for the field width is not permitted for input.

The g0.d edit descriptor can be used to specify the output of integer, logical,
and character data. It follows the rules for the i0, l1, and a edit
descriptors, respectively.

The value 0 may be given to an exponent digits parameter in an ew.d ee edit
descriptor. The effect of this is that the processor uses the minimum number of
digits required to represent the exponent value. This avoids leading zeros,
which are unsightly and can cause errors if the value is read in another
language."

This would be useful to have.

[Bug rtl-optimization/57193] [7 Regression] suboptimal register allocation for SSE registers

[xry111 at mengyan1223 dot wang]

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at mengyan1223 dot wang

--- Comment #18 from Xi Ruoyao  ---
It's back in GCC 9.1.0 and trunk:

https://gcc.godbolt.org/z/KrrZW7

[Bug tree-optimization/90332] New test case gcc.dg/vect/slp-reduc-sad-2.c in r270847 fails

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #3 from ktkachov at gcc dot gnu.org ---
btw, I vaguely remember trying out Richard's patch back in stage 3 on aarch64
and it didn't end up triggering there because we had not implemented the
vec_initv16qiv8qi optab on aarch64, that is a vector construction of a v16qi
vector from a v8qi initialiser.

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[tomas.kalibera at gmail dot com]

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

--- Comment #20 from Tomas Kalibera  ---
(In reply to rguent...@suse.de from comment #19)

> I don't see how -fno-optimize-sibling-calls helps in a systematic way.
> It might obfuscate a specific example enough to make it work, but...?

There is only empirical data, but more than one case. I've debugged only one
case, but all the other R packages that were newly failing with that gfortran
change also started working again with -fno-optimize-sibling-calls (~15 CRAN
packages). That -fno-optimize-sibling-calls helps has also been confirmed by
Kurt Hornik from the CRAN team.

[Bug rtl-optimization/57193] [7 Regression] suboptimal register allocation for SSE registers

[xry111 at mengyan1223 dot wang]

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

--- Comment #19 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #18)
> It's back in GCC 9.1.0 and trunk:
> 
> https://gcc.godbolt.org/z/KrrZW7

Wrong link.  Should be:

https://gcc.godbolt.org/z/bxAeCR

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
Trunk:

 tree PRE   :  23.45 ( 58%)   0.18 ( 60%)  23.93 ( 58%)
  17811 kB ( 29%)
 `- tree tail merge :   0.03 (  0%)   0.00 (  0%)   0.02 (  0%)
197 kB (  0%)
 `- alias stmt walking  :  11.19 ( 27%)   0.04 ( 13%)  10.95 ( 27%)
  0 kB (  0%)
 `- tree PTA:   0.04 (  0%)   0.00 (  0%)   0.04 (  0%)
 16 kB (  0%)

gcc 8 with the patch:

 tree PRE   :  26.65 ( 46%)   0.19 ( 46%)  30.98 ( 49%)
  17935 kB ( 28%)
 `- alias stmt walking  :  12.43 ( 22%)   0.08 ( 20%)  14.08 ( 22%)
  0 kB (  0%)
 `- tree tail merge :   0.02 (  0%)   0.00 (  0%)   0.02 (  0%)
197 kB (  0%)
 `- tree CFG cleanup:   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
  0 kB (  0%)
 `- tree PTA:   0.03 (  0%)   0.00 (  0%)   0.03 (  0%)
 16 kB (  0%)

so this is in-line with the previous testcase and nowhere near minutes?

When I start with Name/V[0, 4] and double to Name/V[0,8] I go from
438 to 864 calls to get_continuation_for_phi and from 654 to 1260
calls to maybe_skip_until, similarly dominated_by_p calls double
so there doesn't seem to be any quadraticness here either.

It's true the walk limiting doesn't kick in for the work done by
get_continuation_for_phi but only at the first lookup after that
finished, wasting cycles.  I'll see if changing that improves
things here, but the work limit per query is quite high here.

[Bug d/88238] libphobos compile problems on Solaris 10

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

  Attachment #45109|0   |1
is obsolete||

--- Comment #3 from Rainer Orth  ---
Created attachment 46309
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46309&action=edit
Clean patch

This patch allowed me to build and test libphobos on Solaris 10/x86 and Solaris
10/SPARC.
However, 64-bit testing on Solaris 10/x86 only works with gld since ld doesn't
support -z relax=transtls.  What's worse, due to some packagaing accident or
some
such,
Solaris 10/SPARC has dl_iterate_phdr in the 32-bit libdl.so.1, but the 64-bit
libdl.so.1 is older and lacks the function.

Apart from that, test results are not too bad, so I wanted the patch recorded
for posteriority ;-)

[Bug tree-optimization/88709] Improve store-merging

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #6 from Christophe Lyon  ---
I've noticed that the new test store_merging_29.c fails on
arm-none-eabi --with-cpu cortex-a9
FAIL: gcc.dg/store_merging_29.c scan-tree-dump store-merging "New sequence of 3
stores to replace old one of 6 stores"

[Bug fortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-07
 Ever confirmed|0   |1

[Bug middle-end/89037] checking ice emitting 128-bit bit-field initializer

[rsandifo at gcc dot gnu.org]

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Tue May  7 08:49:05 2019
New Revision: 270936

URL: https://gcc.gnu.org/viewcvs?rev=270936&root=gcc&view=rev
Log:
Fix output_constructor_bitfield handling of wide bitfields (PR89037)

The testcase was failing because we were trying to access
TREE_INT_CST_ELT (x, 1) of a 128-bit integer that was small enough
to need only a single element.

2019-05-07  Richard Sandiford  

gcc/
Backport from mainline:
2019-01-25  Richard Sandiford  

PR middle-end/89037
* varasm.c (output_constructor_bitfield): Use wi::extract_uhwi
instead of accessing TREE_INT_CST_ELT directly.

gcc/testsuite/
Backport from mainline:
2019-01-25  Richard Sandiford  

PR middle-end/89037
* gcc.dg/pr89037.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr89037.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/varasm.c

[Bug middle-end/89037] checking ice emitting 128-bit bit-field initializer

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
Fixed.

[Bug lto/90369] error: could not unlink output file

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Tue May  7 08:52:33 2019
New Revision: 270937

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

PR lto/90369
* lto-wrapper.c (debug_objcopy): Use the original filename
including archive offset for the filename used for -save-temps.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-wrapper.c

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
Created attachment 46310
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46310&action=edit
untested patch

So on it's own that doesn't help, after changing this --param
sccvn-max-alias-queries-per-access makes a difference though (it doesn't
before).  It's default
is somewhat high at 1000, IIRC I chose a default limit that didn't trigger
during GCC bootstrap back in time.

The refactoring would also enable to assign an overall budget rather than
a per access one.

Can you try the patch on the original testcase?  (it doesn't apply 100% to
the GCC 8 branch but I guess you'll manage to do that manually in case
needed)

On your attached testcase it doesn't make a (big) difference unless you
lower --param sccvn-maxa-alias-queries-per-access.

I will poke a bit more.

[Bug other/90375] New: Environment variables not listed in ENVIRONMENT section of man page

[redi at gcc dot gnu.org]

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

Bug ID: 90375
   Summary: Environment variables not listed in ENVIRONMENT
section of man page
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: minor
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

The following env vars are documented as affecting GCC's behaviour, but are not
listed in the ENVIRONMENT section of the gcc(1) man page:

GCC_COLORS (for -fdiagnostics-color)
COLUMNS (for -fno-diagnostics-show-caret)
MAKE (for -flto=n)
ASAN_OPTIONS
TSAN_OPTIONS
LSAN_OPTIONS
VTV_LOGS_DIR (for -fvtv-debug)
PATH (for finding subprograms when -Bprefix and the standard locations don't
have them)

-M mentions "or use an environment variable like DEPENDENCIES_OUTPUT" which
isn't very clear if that actually gets used by GCC or is just an example. I
suggest saying "or use one of the environment variables DEPENDENCIES_OUTPUT or
SUNPRO_DEPENDENCIES" instead.

There's also "The runtime library  behavior can be influenced using various
CHKP_RT_* environment variables.  See

for more details."

[Bug lto/90369] error: could not unlink output file

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.0

--- Comment #3 from Richard Biener  ---
Fixed on trunk sofar.

[Bug gcov-profile/90364] 521.wrf_r is 9.5 % slower with PGO on Zen CPUs at -Ofast and native march/mtune

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 46311
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46311&action=edit
powf.simdclone dumps

So I focused first on powf simdclones and the number shrinks from 189 to 4..

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to Thomas Koenig from comment #7)
> Author: tkoenig
> Date: Thu Nov 16 20:24:00 2017
> New Revision: 254845
> 
> URL: https://gcc.gnu.org/viewcvs?rev=254845&root=gcc&view=rev
> Log:
> 2017-11-16  Thomas Koenig  
> 
>   PR bootstrap/82856
>   * doc/install.texi: Document incompatibility of Perl >=5.6.26
>   with the required version of automake 1.11.6.
> 
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/doc/install.texi

Thomas, this patch refers to a non-existent 5.6.26 version (did you mean
5.26.0?)

But is this even still relevant now that we've updated the automake version?
Can we revert it to just say 5.6.1 or later?

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
(In reply to Michael Matz from comment #7)
> No, this is not a problem in the stack slot sharing algorithm, but rather in
> the input.  As presented to expand, and only showing the important parts,
> and reordering some BBs to make the flow more obvious:
> 
> ;;   basic block 2, loop depth 0
> ;;pred:   ENTRY
>   _30 = (unsigned long) ∈
>   ivtmp.27_29 = _30 + 1;
>   goto ; [100.00%]
> 
> So, 'in' becomes "live" here, it's address in _30 and _29.  Fallthrough to
> bb5,
> which also uses in, but otherwise is uninteresting, except that it can reach
> only BBs 6 and 7:
> 
> ;;   basic block 5, loop depth 1
>   ...
>   _2 = check_zero (&in, _31);
>   if (_2 != 0)
> goto ; [99.96%]
>   else
> goto ; [0.04%]
> 
> bb6 is a no-return block, hence uninteresting.  bb7 _is_ interesting in that
> it clobbers in:
> 
> ;;   basic block 7, loop depth 1
> ;;pred:   5
>   in ={v} {CLOBBER};
>   if (i_11 != 5)
> goto ; [83.33%]
>   else
> goto ; [16.67%]
> 
> Note that the semantics of the clobber is not only that the former contents
> are destroyed, but rather that the very storage associated with the clobbered
> entity is gone.  So, from now on, any pointers into 'in', and memory accesses
> into 'in' are invalid.  Nevertheless the flow from bb7 goes to bb 8 and 9,
> the latter being the return block, so:
> 
> ;;   basic block 8, loop depth 1
> ;;pred:   7
>   if (i_11 > 0)
> goto ; [100.00%]
>   else
> goto ; [0.00%]
> 
> and here we finally have a path into bb3, which is the other interesting one:
> 
> ;;   basic block 3, loop depth 2
>   # ivtmp.20_6 = PHI <_30(8), ivtmp.20_18(3)>
> 
>  BOOM!  Here _30 is used, and ...
> 
>   _4 = (void *) ivtmp.20_6;
>   MEM[base: _4, offset: 0B] = 0;
> 
> ... even written into ...  That's invalid.  _30 is associated with an
> object that is clobbered and gone ...
> 
>   set_one (&buf);
>   buf ={v} {CLOBBER};
>   ivtmp.20_18 = ivtmp.20_6 + 1;
> 
> ... and as the MEM[] write can't have possibly been into 'in' (as that is
> invalid, as 'in' didn't exist at the MEM access), it's okay and sensible to
> allocate 'in' and 'buf' into the same memory.
> 
> It seems to be a common misconception of what the clobber is really about.
> I designed it to mean what I wrote above, the storage associated with the
> clobbered entities is gone after the clobber (not merely it's former
> contents!). 
> 
> But ivopts or dom extends the lifetime of 'in' (by moving an address-taken
> earlier) and hence the lifetime of its storage, but without doing anything
> about the clobber (and hence not _really_ extending the lifetime).  That
> doesn't work.
> It's basically a mirrored transformation of the usual take-address-of-local
> and access it out of it's declared scope, just that here the _start_ of the
> supposed lifetime is moved out of the declared scope, not the end.

While I spotted this "issue" as well I respectfully disagree about
the semantics.  Not because they are not sound but because of
the implementation challenge resolving around address-takens being
values with no data dependence on the clobbers.

I thought the liveness algorithm would be able to handle this situation.
If not we need to prune clobbers that became "invalid" somehow.
Not sure how - the address value never "dies", so we'd need to compute
liveness of the things the address escapes to - SSA names are easy,
calls - well, we have to give up.  This possiby defeats the whole idea
of doing stack sharing analysis (I remember kernel/fortran testcases
passing the stack slots by reference to a function).

Now if we would want to try forcing the original semantics we need a
verifier verifying the IL state against bogus transforms - but then we
would have a way to prune the invalid ones.

[Bug middle-end/82885] memcpy does not propagate aliasing knowledge

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||david.bolvansky at gmail dot 
com

--- Comment #3 from Richard Biener  ---
*** Bug 90373 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/90373] Better alias analysis based on libc functions with arguments which cannot alias

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
It is.  Note we have no good way of recording these flow-sensitive information
right now.

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

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||build
 CC||danglin at gcc dot gnu.org

--- Comment #8 from Jonathan Wakely  ---
A user on IRC reported similar errors for GCC 9.1.0:

g++ -mlp64 -std=gnu++98   -DUSE_LIBUNWIND_EXCEPTIONS  -g -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -static-libstdc++
-static-libgcc  -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o
c/c-decl.o c/c-typeck.o
c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-fold.o
c/gimple-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o
c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o
c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o
c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o
c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o
c-family/c-spellcheck.o ia64-c.o default-c.o \
   cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  
-L/wrk/ia64-9.1.0//lib -L/wrk/ia64-9.1.0//lib -L/wrk/ia64-9.1.0//lib -lmpc
-lmpfr -lgmp   -L./../zlib -lz -lunwind
ld: The value 0xfda61f70 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x2a2 in section index 622 of file
libbackend.a[wide-int-range.o]
426 errors.
collect2: error: ld returned 1 exit status


Dave, are you aware of anybody testing ia64-hpux?
Should it be deprecated if nobody is maintaining it?

[Bug lto/90369] error: could not unlink output file

[hoganmeier at gmail dot com]

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

--- Comment #4 from krux  ---
The code was automatically reduced, hence the empty linker script.
Looks promising, seems like you found the cause.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Joseph John from comment #5)
> I am still struggling to compiler any version giver than GCC 4.9.0 on ia64
> platform still but as far as this issue is concerned I was able to get pass
> the LD abort when I used the below options for configure:
> 
> CC="gcc -mlp64" CXX="g++ -mlp64"
> 
> With this option I was able to pass the linker abort just after the
> libbackend.a creation but I run into a segmentation error which I believe is
> the documented issue at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919

That bug now seems to have some fixes/workarounds to allow building 4.9.4

[Bug c/90376] New: spurious -Warray-bounds on memset() of several struct's subobjects

[ryabinin.a.a at gmail dot com]

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

Bug ID: 90376
   Summary: spurious -Warray-bounds on memset() of several
struct's subobjects
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryabinin.a.a at gmail dot com
  Target Milestone: ---

This is new on gcc 9.

# cat array_bounds.c

struct trace_iterator {
char a;
int seq;
long b;
};

void f(void)
{
static struct trace_iterator iter;
__builtin_memset(&iter.seq, 0,
sizeof(struct trace_iterator) -
__builtin_offsetof(struct trace_iterator, seq));

}

# gcc -O2 -c -Warray-bounds array_test.c
array_test.c: In function ‘f’:
array_test.c:12:2: warning: ‘__builtin_memset’ offset [9, 16] from the object
at ‘iter’ is out of the bounds of referenced subobject ‘seq’ with type ‘int’ at
offset 4 [-Warray-bounds]
   12 |  __builtin_memset(&iter.seq, 0,
  |  ^~
   13 |   sizeof(struct trace_iterator) -
  |   ~~~
   14 |   __builtin_offsetof(struct trace_iterator, seq));
  |   ~~~

[Bug c/90376] spurious -Warray-bounds on memset() of several struct's subobjects

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-07
 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
For me the warning looks fine, started with r269867.
Martin will clarify the warning..

[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible

[ostash at ostash dot kiev.ua]

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

--- Comment #4 from Viktor Ostashevskyi  ---
Bisected to:

commit c6e37a9f5734bfe731b042993f77cb41b5a566c5
Author: redi 
Date:   Sun Jan 6 22:34:29 2019 +

PR libstdc++/86756 add std::filesystem::path to libstdc++.so

Move the C++17 std::filesystem::path definitions from the libstdc++fs.a
archive to the main libstdc++ library. The path classes do not depend on
any OS functions, so can be defined unconditionally on all targets
(rather than depending on --enable-libstdcxx-filesystem-ts). The tests
should pass on all targets too.  
 ...
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@267615
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 46312
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46312&action=edit
gcc10-pr90348.patch

Untested patch that implements what was written in #c5.  I agree that without
further changes to the IL, determining if one can hoist addresses of local
variables or not is going to be hard, would require computing the variable life
info in each pass that would do something similar.  On the other side,
admittedly such hoisting results in worse code generation because if the
address is hoisted earlier than where it used to be live before, then there
will be more stack conflicts.

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
Author: rguenth
Date: Tue May  7 11:17:00 2019
New Revision: 270940

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

PR tree-optimization/90316
* tree-ssa-alias.h (get_continuation_for_phi): Take walking
limit by reference.
(walk_non_aliased_vuses): Take walking limit argument.
* tree-ssa-alias.c (maybe_skip_until): Take limit and abort
walking if it is reached instead of just counting.
(get_continuation_for_phi): Likewise.
(walk_non_aliased_vuses): Likewise, instead of leaving counter
limiting to the callback.
* tree-ssa-sccvn.c (vn_reference_lookup_2): Adjust.
(vn_reference_lookup_3): Likewise.
(vn_reference_lookup_pieces): Likewise.
(vn_reference_lookup): Likewise.
* tree-ssa-pre.c (translate_vuse_through_block): Limit walking.
* tree-ssa-scopedtables.c (vuse_eq): Adjust.
(avail_exprs_stack::lookup_avail_expr): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-alias.h
trunk/gcc/tree-ssa-pre.c
trunk/gcc/tree-ssa-sccvn.c
trunk/gcc/tree-ssa-scopedtables.c

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #10 from dave.anglin at bell dot net ---
On 2019-05-07 5:29 a.m., redi at gcc dot gnu.org wrote:
> Dave, are you aware of anybody testing ia64-hpux?
> Should it be deprecated if nobody is maintaining it?
I don't have or access to a ia64 box.

I don't know the status of Jim Wilson who is listed as ia64 maintainer.

Albert Chin  is the only person that I know who might
be actively using it.

My access to the hppa box that I use for hppa-hpux support requires support
from NRC Canada but
all colleagues there have retired.  It was down for a few weeks until yesterday
when I got a network person
to reboot it.

So, maybe it's time to deprecate hpux.  I'm still working on hppa-linux.

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #30 from Martin Liška  ---
A possible solution can be usage of '-flinker-output=nolto-rel -r' for huge
files.

[Bug c++/87847] spec_hasher::hash does not match with spec_hasher::equal

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
May I please ping this? I would like to finish the hast table sanitization
patch in this stage1.

[Bug rtl-optimization/87845] cselib_hasher::hash function does not match with cselib_hasher::equal operator

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
May I please ping this? I would like to finish the hast table sanitization
patch in this stage1.

[Bug tree-optimization/90377] New: [10 Regression] New -Wstringop-overflow with -O3 since r270852

[marxin at gcc dot gnu.org]

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

Bug ID: 90377
   Summary: [10 Regression] New -Wstringop-overflow with -O3 since
r270852
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Isolated from webkit2gtk3 package:

$ cat webkit.ii
# 1 "" 3
typedef int a;
namespace b {
template  void d(c);
}
enum e { f };
void *operator new(a, e, void *g) { return g; }
template  class h;
template  struct j {
  static void k(i *l, i *m, i *aa) {
while (l != m) {
  new (f, aa) i;
  ++aa;
  ++l;
}
  }
};
template  struct n {
  static void k(i *l, i *m, i *aa) { j::k(l, m, aa); }
};
class C {
public:
  ac();
  unsigned o;
  unsigned ad;
};
template  class p : C {
public:
  d(p af, a, a) {
af.ac();
i *q = af.r(), *a = q;
n::k(0, s, a);
b::d(o);
  }
  C::ad;
  a s;
  i *r() { return reinterpret_cast(ah); }
  int ah[];
};
class t;
template  class h : p {
  typedef p ae;

public:
  h();
  h &operator=(h &&);
  d(h &af) { ae::d(af, ad, ad); }
};
template 
h &h::operator=(h &&af) {
  d(af);
}
class t {
public:
  t() : x(){} * x;
};
class D {
  void aj();
  h ak;
};
void D::aj() { ak = {}; }

$ g++ webkit.ii -O3 -Werror -Wall -std=c++14 -c  -Wstringop-overflow
-fpermissive
In member function ‘void D::aj()’:
cc1plus: error: ‘void* __builtin_memset(void*, int, long unsigned int)’ writing
8 or more bytes into a region of size 0 overflows the destination
[-Werror=stringop-overflow=]
cc1plus: all warnings being treated as errors

[Bug tree-optimization/90377] [10 Regression] New -Wstringop-overflow with -O3 since r270852

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2019-5-7
 CC||glisse at gcc dot gnu.org
  Known to work||9.1.0
Version|9.0 |10.0
   Target Milestone|--- |10.0
  Known to fail||10.0

[Bug gcov-profile/90364] 521.wrf_r is 9.5 % slower with PGO on Zen CPUs at -Ofast and native march/mtune

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
So the problem is that without a profile tree-vectorizer does a vectorization
in 1162 functions, while with PGO only 49 functions are vectorized.
Can you please Richi take a look? I can provide vectorizer dump files.

[Bug gcov-profile/90364] 521.wrf_r is 9.5 % slower with PGO on Zen CPUs at -Ofast and native march/mtune

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 46312 [details]
> gcc10-pr90348.patch
> 
> Untested patch that implements what was written in #c5.  I agree that
> without further changes to the IL, determining if one can hoist addresses of
> local variables or not is going to be hard, would require computing the
> variable life info in each pass that would do something similar.  On the
> other side, admittedly such hoisting results in worse code generation
> because if the address is hoisted earlier than where it used to be live
> before, then there will be more stack conflicts.

Ick.  You need to handle pt->anything and pt->escaped (walk the escaped
solution) as well.  And !SSA_NAME_PTR_INFO (op) is of course the same
as pt->anything.

I see it quickly degrading given the last PTA compute is far far away...

[Bug middle-end/90345] too pessimistic check whether pointer may alias a local variable

[vanyacpp at gmail dot com]

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

--- Comment #4 from Ivan Sorokin  ---
Making points-to analysis aware of SESE regions will definitely help here and
is a nice thing to have.

There is one more option. In my reduced test case the body of 'push_back' is
unavailable, but when it is it can be analysed and an attribute can be added
that 'push_back' only uses the received reference internally and does not
escape it.

>From my experiments this is what clang does: even when the body of 'push_back'
is not inlined it generates different code for 'operator*=' depending on
whether push_back escapes the received reference or not:

void push_back(uint32_t const&) __attribute__((noinline));

void big_integer::push_back(uint32_t const& a)
{
__asm__("" : : : "memory");
//__asm__("" : : "g"(&a) : "memory");
}

I guess with LTO enabled this type of analysis is quite powerful, as many
'const&' and 'this' parameters in C++ don't really escape.

[Bug rtl-optimization/88879] [9/10 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
ping?

[Bug gcov-profile/90364] 521.wrf_r is 9.5 % slower with PGO on Zen CPUs at -Ofast and native march/mtune

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Martin Liška from comment #3)
> So the problem is that without a profile tree-vectorizer does a
> vectorization in 1162 functions, while with PGO only 49 functions are
> vectorized.
> Can you please Richi take a look? I can provide vectorizer dump files.

optimize_loop_nest_for_speed_p returning false?

Does the train profile match the ref profile or is there a clear mismatch
so we guess a ref hot loop as cold?

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
Author: rguenth
Date: Tue May  7 13:03:19 2019
New Revision: 270944

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

PR tree-optimization/90316
* tree-ssa-pre.c (translate_vuse_through_block): When
same_valid is NULL do not bother to search for a virtual
PHI continuation.
(phi_translate_1): When operands changed we cannot keep
the same value-number so do not bother to ask whether
that's possible from translate_vuse_through_block.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > Created attachment 46312 [details]
> > gcc10-pr90348.patch
> > 
> > Untested patch that implements what was written in #c5.  I agree that
> > without further changes to the IL, determining if one can hoist addresses of
> > local variables or not is going to be hard, would require computing the
> > variable life info in each pass that would do something similar.  On the
> > other side, admittedly such hoisting results in worse code generation
> > because if the address is hoisted earlier than where it used to be live
> > before, then there will be more stack conflicts.
> 
> Ick.  You need to handle pt->anything and pt->escaped (walk the escaped
> solution) as well.  And !SSA_NAME_PTR_INFO (op) is of course the same
> as pt->anything.

Do I?
I thought I don't.  The thing is, I believe the partitioning only cares about
where (originally in the source) the automatic variables are referenced.
Now, if I have say:
__attribute__((noipa)) type *foo (type *x) { return x; }
or similar, in order for a variable to be live before the clobber, it needs to
escape in the area where the variable is live, we don't care what we do with
whatever it returned, unless we actually hoist such escaping calls before that
region.  If we can say for:
  for (...)
{
  unsigned char v[10];
  unsigned char *p = foo (v);
  *p = 1;
  unsigned char w[10];
  bar (w);
}
hoist the p = foo (v); call before the loop, then indeed we are in big trouble.
But if we can't, the attached patch was just meant as a shorthand for trying to
do a dataflow propagation of the can a pointer SSA_NAME point to variable xyz,
if we don't consider escaping (to other functions and to global state).
What I'm trying to "undo" is just the hoisting of the address loads, not
hoisting of those address loads plus function calls in which it escapes or
where that address is saved to memory.

If I have to consider pt->anything and pt->escaped, then it will be as useless
for the variable conflicts as is removing the important clearing of the bitmap
bit on clobber stmt, we won't share stack slots pretty much at all.

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

[matz at gcc dot gnu.org]

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

--- Comment #12 from Michael Matz  ---
(In reply to Jakub Jelinek from comment #11)
> before that region.  If we can say for:
>   for (...)
> {
>   unsigned char v[10];
>   unsigned char *p = foo (v);
>   *p = 1;
>   unsigned char w[10];
>   bar (w);
> }
> hoist the p = foo (v); call before the loop, then indeed we are in big
> trouble.

This is effectively what the testcase is doing (just that 'foo' is no call, but
a normal address expression), so yes, we can do that, and yes we are in big
trouble :-/

> If I have to consider pt->anything and pt->escaped, then it will be as
> useless for the variable conflicts as is removing the important clearing of
> the bitmap bit on clobber stmt, we won't share stack slots pretty much at
> all.

Yeah; if we don't want to patch the specific situation for this testcase
(which might be okayish, we haven't seen this problem very often over the
last years), but want to really fix it we might have to take more involved
means like doing stack slot sharing before gimplification and rewriting
the IL to reflect this.  Or give up on sharing (which isn't a good idea).
Gnah.

[Bug tree-optimization/90332] New test case gcc.dg/vect/slp-reduc-sad-2.c in r270847 fails

[seurer at gcc dot gnu.org]

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

--- Comment #4 from seurer at gcc dot gnu.org ---
This still fails (just on power 9) even with the above change.  On all the
other powerpc64 targets it comes up as unsupported.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #11 from The Written Word  
---
(In reply to dave.anglin from comment #10)
> On 2019-05-07 5:29 a.m., redi at gcc dot gnu.org wrote:
> > Dave, are you aware of anybody testing ia64-hpux?
> > Should it be deprecated if nobody is maintaining it?
> I don't have or access to a ia64 box.
> 
> I don't know the status of Jim Wilson who is listed as ia64 maintainer.
> 
> Albert Chin  is the only person that I know who
> might be actively using it.
> 
> My access to the hppa box that I use for hppa-hpux support requires support
> from NRC Canada but
> all colleagues there have retired.  It was down for a few weeks until
> yesterday when I got a network person
> to reboot it.
> 
> So, maybe it's time to deprecate hpux.  I'm still working on hppa-linux.

We are still using it but haven't been able to build anything post 4.9.4. We
tried to find someone to pay to bring this port up-to-date but had no success.
Open to other suggestions but deprecating it might be the only way forward.

[Bug rtl-optimization/87845] cselib_hasher::hash function does not match with cselib_hasher::equal operator

[rsandifo at gcc dot gnu.org]

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
(In reply to Martin Liška from comment #0)
> Can please anybody familiar with cselib help me here?

Don't think that's me (not really familiar with it), but I agree
the code looks dubious.  cselib_hash_rtx is going to return a
different hash for each location, so I can't see how using
a fixed v->hash from one location for ::hash and a linear
search over the locations for ::equal is going to work.

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to Richard Biener from comment #10)
> > (In reply to Jakub Jelinek from comment #9)
> > > Created attachment 46312 [details]
> > > gcc10-pr90348.patch
> > > 
> > > Untested patch that implements what was written in #c5.  I agree that
> > > without further changes to the IL, determining if one can hoist addresses 
> > > of
> > > local variables or not is going to be hard, would require computing the
> > > variable life info in each pass that would do something similar.  On the
> > > other side, admittedly such hoisting results in worse code generation
> > > because if the address is hoisted earlier than where it used to be live
> > > before, then there will be more stack conflicts.
> > 
> > Ick.  You need to handle pt->anything and pt->escaped (walk the escaped
> > solution) as well.  And !SSA_NAME_PTR_INFO (op) is of course the same
> > as pt->anything.
> 
> Do I?
> I thought I don't.  The thing is, I believe the partitioning only cares
> about where (originally in the source) the automatic variables are
> referenced.
> Now, if I have say:
> __attribute__((noipa)) type *foo (type *x) { return x; }
> or similar, in order for a variable to be live before the clobber, it needs
> to escape in the area where the variable is live, we don't care what we do
> with whatever it returned, unless we actually hoist such escaping calls
> before that region.  If we can say for:
>   for (...)
> {
>   unsigned char v[10];
>   unsigned char *p = foo (v);
>   *p = 1;
>   unsigned char w[10];
>   bar (w);
> }
> hoist the p = foo (v); call before the loop, then indeed we are in big
> trouble.
> But if we can't, the attached patch was just meant as a shorthand for trying
> to do a dataflow propagation of the can a pointer SSA_NAME point to variable
> xyz, if we don't consider escaping (to other functions and to global state).
> What I'm trying to "undo" is just the hoisting of the address loads, not
> hoisting of those address loads plus function calls in which it escapes or
> where that address is saved to memory.
> 
> If I have to consider pt->anything and pt->escaped, then it will be as
> useless for the variable conflicts as is removing the important clearing of
> the bitmap bit on clobber stmt, we won't share stack slots pretty much at
> all.

The point about !SSA_NAME_PTR_INFO is that passes might clear it, replace
such SSA name with a new one, forgetting to copy it, etc.  The point
about anything is that points-to analysis might just have given up
(consider the provenance thing where we might end up with anything for
going through some uintptr arithmetic), the point about escaped is that
this is just a placeholder for a set of variables and points-to tends
to shrink sets by removing bits also in escaped.  Also
global = ptr; ptr2 = global; will have escaped in the sets but not
necessarily the bit of the original decl.

So my comments are just about correctly interpreting points-to data.

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
(In reply to Michael Matz from comment #12)
> (In reply to Jakub Jelinek from comment #11)
> > before that region.  If we can say for:
> >   for (...)
> > {
> >   unsigned char v[10];
> >   unsigned char *p = foo (v);
> >   *p = 1;
> >   unsigned char w[10];
> >   bar (w);
> > }
> > hoist the p = foo (v); call before the loop, then indeed we are in big
> > trouble.
> 
> This is effectively what the testcase is doing (just that 'foo' is no call,
> but a normal address expression), so yes, we can do that, and yes we are in
> big
> trouble :-/

Well, that p = foo (v); or store of memory is something that will have (unless
const call, indeed) a vuse or even a vdef and the alias oracle should usually
consider it to be conflicting with the clobber stmt, so I'd hope it isn't
hoisted in that case, while for the pure address arithmetics there is nothing
that can easily stop the hoisting.

Now, if there isn't really an easy way out of this and given how rarely this
has been reported (I think we have this PR and PR61203, don't remember anything
else), the options can be do nothing, or do something simple that isn't that
expensive, will fix this testcase and while not perfect solution will still
allow variable sharing in the general case almost as often as before, or change
the IL representation so that such hoisting or sinking of addresses is not
possible.

[Bug tree-optimization/90332] New test case gcc.dg/vect/slp-reduc-sad-2.c in r270847 fails

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
I don't see a vec_initv16qiv8qi on power either, so that might be it - there's
no
effective target for building a vector from halves (and I wonder how
code-generation fares here).

So an option is to simply xfail for all but x86_64-*-* and i?86-*-* ...

Or try more fancy code-generation options (build from two large integer modes,
but I don't see vec_initv2didi either).

[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
Educating people about -fstack-reuse is also a possibility, thus leave the
issue to workarounds like that, experimenting with full rewrites that are
obviously not back-portable.

[Bug rtl-optimization/90378] New: [9 regression] -Os -flto miscompiles 454.calculix after r266385 on Arm

[mkuvyrkov at gcc dot gnu.org]

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

Bug ID: 90378
   Summary: [9 regression] -Os -flto miscompiles 454.calculix
after r266385 on Arm
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mkuvyrkov at gcc dot gnu.org
  Target Milestone: ---

I'm investigating a miscompilation of 454.calculix, which occurs only with LTO
on ARMv7.  Miscompilation results in SIGSEGV and seems to occur only on ARMv7
hardware (cortex-a15), same binary runs fine on ARMv8 hardware.

Miscompilation occurs at and after
===
commit 8fc3599dcab36e0b905fa442c0fc0a905280eea2 (HEAD)
Author: vmakarov 
Date:   Thu Nov 22 17:25:57 2018 +

2018-11-22  Vladimir Makarov  

PR rtl-optimization/87718
* ira-costs.c: Remove trailing white-spaces.
(record_operand_costs): Add a special treatment for moves
involving a hard register.

2018-11-22  Vladimir Makarov  

PR rtl-optimization/87718
* gcc.target/i386/pr82361-1.c: Check only the first operand of
moves.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@266385
138bc75d-0d04-0410-961f-82ee72b054a4
===
but I do not have hard evidence that this patch is the root cause.  It may be
triggering a latent bug or even exposing undefined behavior in the benchmark.

I'm struggling to reduce the 300-object LTO compilation down to something
manageable.  Advice and ideas on where to look are appreciated.

[Bug middle-end/90263] Calls to mempcpy should use memcpy

[wilco at gcc dot gnu.org]

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

--- Comment #20 from Wilco  ---
(In reply to Martin Liška from comment #19)
> Created attachment 46265 [details]
> Patch candidate v2
> 
> Update patch that should be fine. Tests on x86_64 work except:
> FAIL: gcc.c-torture/execute/builtins/mempcpy.c execution,  -O1 
> 
> Where the test expects that mempcpy without LHS should be transformed into
> memcpy.

Thanks, this version works as expected on AArch64. In principle we could keep
mempcpy for tailcalls with -Os, but I'm not sure it's worth the trouble.

[Bug testsuite/90379] New: Gcc 9.1 fails "make check" on linux due to missing MacOS-specific header file

[make_distclean at yahoo dot com]

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

Bug ID: 90379
   Summary: Gcc 9.1 fails "make check" on linux due to missing
MacOS-specific header file
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: make_distclean at yahoo dot com
  Target Milestone: ---

Hi

I'm hitting a missing header when making the target 'check' in  fixincludes:
'ucred.h' in $TESTBASE (which is pointing to gcc-9.1.0/fixincludes/tests/base).

I can successfully compile (with gcc 8.3) gcc release 9.1 on
x86_64-unknown-linux-gnu. Then, the output of 'make check' in
my_build_dir/fixincludes looks like this:

--- snip ---
autogen -T ../../fixincludes/check.tpl ../../fixincludes/inclhack.def
/bin/sh ./check.sh ../../fixincludes/tests/base
Fixed:  testing.h
Fixed:  testing.h
Fixed:  alloca.h
Fixed:  ansi/math.h
Fixed:  ansi/stdlib.h
Fixed:  arch/i960/archI960.h
Fixed:  architecture/ppc/math.h
Fixed:  assert.h
Fixed:  AvailabilityInternal.h
Fixed:  AvailabilityMacros.h
Fixed:  bits/fenv.h
Fixed:  bits/huge_val.h
Fixed:  bits/string2.h
Fixed:  bsd/libc.h
Fixed:  c_asm.h
Fixed:  com_err.h
Fixed:  complex.h
Fixed:  ctrl-quotes-def-1.h
Fixed:  ctype.h
Fixed:  curses.h
Fixed:  errno.h
Fixed:  fcntl.h
Fixed:  features.h
Fixed:  fixinc-test-limits.h
Fixed:  hsfs/hsfs_spec.h
Fixed:  i386/setjmp.h
Fixed:  ia64/sys/getppdp.h
Fixed:  inttypes.h
Fixed:  ioLib.h
Fixed:  io-quotes-def-1.h
Fixed:  iso/math_c99.h
Fixed:  iso/math_iso.h
Fixed:  iso/stdio_iso.h
Fixed:  iso/stdlib_c99.h
Fixed:  iso/stdlib_iso.h
Fixed:  linux/vt.h
Fixed:  locale.h
Fixed:  mach-o/dyld.h
Fixed:  mach-o/swap.h
Fixed:  malloc.h
Fixed:  math.h
Fixed:  netdnet/dnetdb.h
Fixed:  net/if_arp.h
Fixed:  net/if.h
Fixed:  netinet/in.h
Fixed:  netinet/ip.h
Fixed:  obstack.h
Fixed:  os/trace.h
Fixed:  pixrect/memvar.h
Fixed:  pthread.h
Fixed:  regex.h
Fixed:  regexp.h
Fixed:  reg_types.h
Fixed:  rpc/auth.h
Fixed:  rpc/rpc.h
Fixed:  rpcsvc/rstat.h
Fixed:  rpcsvc/rusers.h
Fixed:  rpc/xdr.h
Fixed:  rtldef/decc$types.h
Fixed:  rtldef/if.h
Fixed:  rtldef/resolv.h
Fixed:  rtldef/setjmp.h
Fixed:  rtldef/signal.h
Fixed:  rtldef/stdio.h
Fixed:  rtldef/string.h
Fixed:  rtldef/wait.h
Fixed:  setjmp.h
Fixed:  signal.h
Fixed:  sparc/asm_linkage.h
Fixed:  spawn.h
Fixed:  stdarg.h
Fixed:  stdint-aix.h
Fixed:  stdint-darwin.h
Fixed:  stdint.h
Fixed:  stdint-hpux11.h
Fixed:  stdint-newlib.h
Fixed:  stdio.h
Fixed:  stdio_tag.h
Fixed:  stdlib.h
Fixed:  string.h
Fixed:  strings.h
Fixed:  sundev/vuid_event.h
Fixed:  sunwindow/win_lock.h
Fixed:  sym.h
Fixed:  sys/cdefs.h
Fixed:  sys/feature_tests.h
Fixed:  sys/file.h
Fixed:  sys/int_const.h
Fixed:  sys/int_limits.h
Fixed:  sys/_inttypes.h
Fixed:  sys/machine.h
Fixed:  sys/mman.h
Fixed:  sys/pthread.h
Fixed:  sys/signal.h
Fixed:  sys/socket.h
Fixed:  sys/spinlock.h
Fixed:  sys/stat.h
Fixed:  sys/sysmacros.h
Fixed:  sys/time.h
Fixed:  sys/types.h
Fixed:  sys/ucontext.h
Fixed:  sys/ucred.h
Fixed:  sys/wait.h
Fixed:  testing.h
Fixed:  tgmath.h
Fixed:  time.h
Fixed:  tinfo.h
Fixed:  types/vxTypesBase.h
Fixed:  unistd.h
Fixed:  X11/ShellP.h
Fixed:  X11/Xmu.h
Fixed:  Xm/BaseClassI.h
Fixed:  Xm/Traversal.h
Newly fixed header:  sys/ucred.h

There were fixinclude test FAILURES
make: *** [Makefile;177: check] Error 1
--- snip ---

I'm not really sure how gcc-9.1.0/fixincludes/inclhack.def works, but 'mach' at
line 1631 shouldn't match my host triplet x86_64-unknown-linux-gnu.  But then
again, none of the fixes for "*-*-darwin*" in inclhack.def should match yet
they're all applied...

As I don't understand why/how we need to fix includes from other OS'es, my
quick&dirty hack was to just copy
my_build_dir/fixincludes/tests/res/sys/ucred.h to $TESTBASE, which tricked
check.sh.

This failure is also mentioned in Bug 90330 but that bug was raised
specifically for build failing on darwin.

The ucred.h part seems to have been added to inclhack.def as part of git commit
62f180560c835a2f8402978c422448a35d9fe2b1, to fix bug 89864.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #12 from dave.anglin at bell dot net ---
On 2019-05-07 9:32 a.m., bugzilla-gcc at thewrittenword dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #11 from The Written Word  com> ---
> (In reply to dave.anglin from comment #10)
>> On 2019-05-07 5:29 a.m., redi at gcc dot gnu.org wrote:
>>> Dave, are you aware of anybody testing ia64-hpux?
>>> Should it be deprecated if nobody is maintaining it?
>> I don't have or access to a ia64 box.
>>
>> I don't know the status of Jim Wilson who is listed as ia64 maintainer.
>>
>> Albert Chin  is the only person that I know who
>> might be actively using it.
>>
>> My access to the hppa box that I use for hppa-hpux support requires support
>> from NRC Canada but
>> all colleagues there have retired.  It was down for a few weeks until
>> yesterday when I got a network person
>> to reboot it.
>>
>> So, maybe it's time to deprecate hpux.  I'm still working on hppa-linux.
> We are still using it but haven't been able to build anything post 4.9.4. We
> tried to find someone to pay to bring this port up-to-date but had no success.
> Open to other suggestions but deprecating it might be the only way forward.
As I said before, I can't accept US contracts because of HST tax implications. 
I can only accept
Canadian source income.

It might help to compile stage1 with -O2 or -Os.  This might reduce offset and
get a newer version
of gcc to build.  gcc-8.3.0 seems to have built okay on Debian.  gcc-9 so far
has failed to build on ia64.

[Bug c/78666] conflicting attribute alloc_size accepted

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/81933] [7 Regression] Invalid "constexpr call flows off the end of the function" error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #10 from Marek Polacek  ---
Fixed.

[Bug gcov-profile/90380] New: gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project

[vsande at cimne dot upc.edu]

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

Bug ID: 90380
   Summary: gcov issue: gets stuck (infinite loop?) while
analyzing coverage on Fortran project
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsande at cimne dot upc.edu
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Dear GCC/Gcov team,

we are developing Fempar, a Fortran200X project with some mixed C code, that
takes advantage of CPP preprocessor.

We have recently updated our CI environment from GCC 5.4.1 to 8.3.0. Coverage
with GCC 8.3.0 fails because it gets stuck in a infinite loop while analyzing
some files in our software project

We did not determine the exact version of GCC in which this issue appears. The
latest version that was working correctly for us was 6.2.0. This issue can be
reproduced, at least, with GCC 8.X.X and 9.X.X.

We have reproduced the issue environment by means of Docker containers. In
particular, to reproduce the issue please run the following commands:

```
$ # Launch the docker container
$ docker run --rm -ti fempar/fempar:gnu-8.3.0_gcov-issue gcov
$ # Run the following command inside the docker container
$ gcov -l -o
"/data/fempar/Sources/Lib/CMakeFiles/FEMPAR.dir/Geometry/Triangulation"
"/data/fempar/Sources/Lib/CMakeFiles/FEMPAR.dir/Geometry/Triangulation/p4est_triangulation.f90.gcda"
```

After running these commands, gcov output is shown in the following lines:

```
File
'/tmp/fempar-experimental/Sources/Lib/Geometry/Triangulation/sbm_p4est_base_triangulation.i90'
Lines executed:81.37% of 1653
Creating 'p4est_triangulation.f90.gcda##sbm_p4est_base_triangulation.i90.gcov'
```

At this point gcov gets stuck and, it seems, that never ends.

The code has been compiled with the following flags:

-fdefault-real-8 -ffree-line-length-0 -cpp -Wimplicit-interface -g -fbacktrace
-fbounds-check -fprofile-arcs -ftest-coverage -Wimplicit-interface

Is this a known bug?
Is there any possible workaround?

Let me know if you need any other further information.

Thanks in advance,
Víctor.

[Bug gcov-profile/90380] gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project

[vsande at cimne dot upc.edu]

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

--- Comment #1 from Victor  ---
Sorry,

the command to launch the docker container has an extra `gcov` at the end.

To correctly launch the container, please use this command:

$ docker run --rm -ti fempar/fempar:gnu-8.3.0_gcov-issue

Best,
Víctor

[Bug c++/89612] [7/8 Regression] internal compiler error: in push_access_scope, at cp/pt.c:237

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
Fixed.

[Bug gcov-profile/90380] gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Thanks for the report, I'll take a look..

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #14 from The Written Word  
---
(In reply to dave.anglin from comment #10)
> I don't know the status of Jim Wilson who is listed as ia64 maintainer.

We reached out to Jim Wilson in 2016 and got a reply back. He no longer has
access to any ia64 machines.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #13 from The Written Word  
---
(In reply to dave.anglin from comment #12)
> It might help to compile stage1 with -O2 or -Os.  This might reduce offset
> and get a newer version
> of gcc to build.  gcc-8.3.0 seems to have built okay on Debian.  gcc-9 so
> far has failed to build on ia64.

Ok, I'll try. I'll try to reach out to the Debian/ia maintainers again.

[Bug c++/61990] Incorrect caret location for type mismatches in function calls

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
We now print:

61990.C: In function ‘void test(foo*)’:
61990.C:9:18: error: cannot convert ‘foo*’ to ‘bar*’
9 |   some_fn (f, f, f, f, f);
  |  ^
  |  |
  |  foo*
61990.C:5:36: note:   initializing argument 3 of ‘void some_fn(foo*, foo*,
bar*, foo*, foo*)’
5 | extern void some_fn (foo *, foo *, bar *, foo *, foo *);
  |^


so fixed.

[Bug gcov-profile/90380] gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Confirmed, I see following back-trace:

#0  0x0044f9d4 in handle_cycle (count=, edges=...) at
/usr/src/debug/gcc8-8.3.1+r269200-1.1.x86_64/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include/bits/stl_vector.h:948
#1  circuit (v=, path=..., start=0x6e0f10, blocked=...,
block_lists=..., linfo=..., count=@0x7fffd868: 0) at ../../gcc/gcov.c:695
#2  0x0044fa54 in circuit (v=, path=..., start=0x6e0f10,
blocked=..., block_lists=..., linfo=..., count=@0x7fffd868: 0) at
../../gcc/gcov.c:697
#3  0x0044fa54 in circuit (v=, path=..., start=0x6e0f10,
blocked=..., block_lists=..., linfo=..., count=@0x7fffd868: 0) at
../../gcc/gcov.c:697
#4  0x0044fa54 in circuit (v=, path=..., start=0x6e0f10,
blocked=..., block_lists=..., linfo=..., count=@0x7fffd868: 0) at
../../gcc/gcov.c:697
#5  0x0044fa54 in circuit (v=, path=..., start=0x6e0f10,
blocked=..., block_lists=..., linfo=..., count=@0x7fffd868: 0) at
../../gcc/gcov.c:697
...
#443 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#444 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#445 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#446 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#447 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#448 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#449 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#450 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#451 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#452 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#453 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#454 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#455 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#456 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#457 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#458 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#459 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#460 0x0044fa54 in circuit (v=, path=...,
start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffd868:
0) at ../../gcc/gcov.c:697
#461 0x0044fb32 in get_cycles_count (linfo=...,
handle_negative_cycles=handle_negative_cycles@entry=true) at
../../gcc/gcov.c:742
#462 0x00450c5f in accumulate_line_info (add_coverage=false,
src=, line=0x4c0670) at ../../gcc/gcov.c:2601
#463 accumulate_line_counts (src=0x67fdd0) at ../../gcc/gcov.c:2631
#464 generate_results (file_name=0x78df10 "p4est_triangulation.f90.gcda") at
../../gcc/gcov.c:1328
#465 0x00438ac2 in main (argc=, argv=) at
../../gcc/gcov.c:796

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 90376 Summary: spurious -Warray-bounds on memset() of several struct's 
subobjects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90376

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

[Bug middle-end/90376] spurious -Warray-bounds on memset() of several struct's subobjects

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|NEW |RESOLVED
  Component|c   |middle-end
 Blocks||56456
 Resolution|--- |INVALID

--- Comment #2 from Martin Sebor  ---
The warning in this case points out that the memset call accesses memory
outside the bounds of the subobject pointed to by the first argument.  Making
it explicit that the access is intended to span multiple members by passing to
memset a pointer derived from the address of the enclosing object avoids the
warning:

  void g (void)
  {
static struct trace_iterator iter;
__builtin_memset ((char*)&iter
  + __builtin_offsetof (struct trace_iterator, seq),
  0,
  sizeof (struct trace_iterator)
  - __builtin_offsetof(struct trace_iterator, seq));
  }


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[thanm at google dot com]

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

--- Comment #18 from Than McIntosh  ---

I tested the most recent commit (270944). That cuts the compile time on the
larger example in half, but still at around 1200 seconds. I took another
profile (will attach an SVG image from 'pprof web').

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[thanm at google dot com]

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

--- Comment #19 from Than McIntosh  ---
Created attachment 46313
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46313&action=edit
SVG graph from profiling run

[Bug c++/90372] [x64][missed optimization] pushes unused r12 onto stack on unique_ptr use

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
(In reply to marc from comment #0)

Please always include all details relevant to the report here for future
reference (in case the external references should become inaccessible).  The
test case:

#include 
#include 
#include 

using file_ptr = std::unique_ptr;

const std::string_view s = "Hello, World";

extern void may_throw() noexcept(false);

void two() {
if (auto f = fopen(nullptr, nullptr)) {
fwrite(s.data(), s.size(), 1, f);
try {
may_throw();
} catch (...) {
fclose(f);
throw;
}
fclose(f);
}
}

void one() {
if (auto f = file_ptr{fopen(nullptr, nullptr)}) {
fwrite(s.data(), s.size(), 1, f.get());
may_throw();
}
}

[Bug c++/87145] [7/8 Regression] Implicit conversion to scoped enum fails: "error: taking address of temporary/rvalue"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #11 from Marek Polacek  ---
GCC 8 doesn't have CONSTRUCTOR_IS_DEPENDENT so I guess I won't backport it.

[Bug libstdc++/48101] obscure error message with std::set

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Author: redi
Date: Tue May  7 15:46:05 2019
New Revision: 270960

URL: https://gcc.gnu.org/viewcvs?rev=270960&root=gcc&view=rev
Log:
PR libstdc++/85965 delay static assertions until types are complete

The static assertions added for PR libstdc++/48101 were at class scope
and so were evaluated too eagerly, when it might not be possible to
determine whether the function objects are invocable with the key types.
The problematic cases are where the key type is not known to be
convertible to the argument type(s) of the function object until later,
after a type has been completed. Specifically, if the key type is a
pointer to a derived class and the function object's argument type is a
pointer to a base class, then the derived-to-base conversion is only
valid once the derived type is complete.

By moving the static assertions to the destructor they will only be
evaluated when the destructor is instantiated, at which point whether
the key type can be passed to the function object should be knowable.
The ideal place to do the checks would be only when the function objects
are actually invoked, but that would mean adding the checks in numerous
places, so the destructor is used instead.

The tests need to be adjusted because the "required from here" line is
now the location of the destructor, not the point of instantiation in
the test file. For the map and multimap tests which check two
specializations, the dg-error matching the assertion text matches both
cases. Also check the diagnostic output for the template arguments, to
ensure both specializations trigger the assertion.

Backport from mainline
2019-03-26  Jonathan Wakely  

PR libstdc++/85965
* include/bits/hashtable.h (_Hashtable): Move static assertions to
destructor so they are not evaluated until the _Key type is complete.
* include/bits/stl_tree.h (_Rb_tree): Likewise.
* testsuite/23_containers/set/85965.cc: New test.
* testsuite/23_containers/unordered_set/85965.cc: New test.
* testsuite/23_containers/map/48101_neg.cc: Replace "here" errors
with regexp matching the corresponding _Rb_tree specialization.
* testsuite/23_containers/multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/multiset/48101_neg.cc: Remove "here" error.
* testsuite/23_containers/set/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_map/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multiset/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_set/48101_neg.cc: Likewise.

Added:
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/set/85965.cc
  - copied, changed from r270959,
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_set/85965.cc
  - copied, changed from r270959,
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/hashtable.h
branches/gcc-8-branch/libstdc++-v3/include/bits/stl_tree.h
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/multimap/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/multiset/48101_neg.cc
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/set/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_map/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_multimap/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_multiset/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_set/48101_neg.cc

[Bug libstdc++/85965] [8 Regression] G++ gives cryptic error instead of incomplete type

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Tue May  7 15:46:05 2019
New Revision: 270960

URL: https://gcc.gnu.org/viewcvs?rev=270960&root=gcc&view=rev
Log:
PR libstdc++/85965 delay static assertions until types are complete

The static assertions added for PR libstdc++/48101 were at class scope
and so were evaluated too eagerly, when it might not be possible to
determine whether the function objects are invocable with the key types.
The problematic cases are where the key type is not known to be
convertible to the argument type(s) of the function object until later,
after a type has been completed. Specifically, if the key type is a
pointer to a derived class and the function object's argument type is a
pointer to a base class, then the derived-to-base conversion is only
valid once the derived type is complete.

By moving the static assertions to the destructor they will only be
evaluated when the destructor is instantiated, at which point whether
the key type can be passed to the function object should be knowable.
The ideal place to do the checks would be only when the function objects
are actually invoked, but that would mean adding the checks in numerous
places, so the destructor is used instead.

The tests need to be adjusted because the "required from here" line is
now the location of the destructor, not the point of instantiation in
the test file. For the map and multimap tests which check two
specializations, the dg-error matching the assertion text matches both
cases. Also check the diagnostic output for the template arguments, to
ensure both specializations trigger the assertion.

Backport from mainline
2019-03-26  Jonathan Wakely  

PR libstdc++/85965
* include/bits/hashtable.h (_Hashtable): Move static assertions to
destructor so they are not evaluated until the _Key type is complete.
* include/bits/stl_tree.h (_Rb_tree): Likewise.
* testsuite/23_containers/set/85965.cc: New test.
* testsuite/23_containers/unordered_set/85965.cc: New test.
* testsuite/23_containers/map/48101_neg.cc: Replace "here" errors
with regexp matching the corresponding _Rb_tree specialization.
* testsuite/23_containers/multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/multiset/48101_neg.cc: Remove "here" error.
* testsuite/23_containers/set/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_map/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multiset/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_set/48101_neg.cc: Likewise.

Added:
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/set/85965.cc
  - copied, changed from r270959,
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_set/85965.cc
  - copied, changed from r270959,
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/hashtable.h
branches/gcc-8-branch/libstdc++-v3/include/bits/stl_tree.h
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/multimap/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/multiset/48101_neg.cc
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/set/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_map/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_multimap/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_multiset/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_set/48101_neg.cc

[Bug libstdc++/89629] std::hash segfault for long strings

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Tue May  7 15:45:59 2019
New Revision: 270959

URL: https://gcc.gnu.org/viewcvs?rev=270959&root=gcc&view=rev
Log:
PR libstdc++/89629 fix _Hash_bytes for lengths > INT_MAX

Backport from mainline
2019-03-11  Jonathan Wakely  

PR libstdc++/89629
* libsupc++/hash_bytes.cc [__SIZEOF_SIZE_T__ == 8] (_Hash_bytes):
Use correct type for len_aligned.
* testsuite/20_util/hash/89629.cc: New test.

Added:
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/hash/89629.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/libsupc++/hash_bytes.cc

[Bug libstdc++/90105] std::forward_list::sort() is not "stable"

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Tue May  7 15:46:32 2019
New Revision: 270965

URL: https://gcc.gnu.org/viewcvs?rev=270965&root=gcc&view=rev
Log:
PR libstdc++/90105 make forward_list::sort stable

While testing the fix I also discovered that operator== assumes the
elements are comparable with operator!= which is not required.

Backport from mainline
2019-04-17  Jonathan Wakely  

PR libstdc++/90105
* include/bits/forward_list.tcc (operator==): Do not use operator!= to
compare elements.
(forward_list::sort(Comp)): When elements are equal take the one
earlier in the list, so that sort is stable.
* testsuite/23_containers/forward_list/operations/90105.cc: New test.
* testsuite/23_containers/forward_list/comparable.cc: Test with
types that meet the minimum EqualityComparable and LessThanComparable
requirements. Remove irrelevant comment.

Added:
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/forward_list/operations/90105.cc
  - copied, changed from r270964,
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/forward_list/comparable.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/forward_list.tcc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/forward_list/comparable.cc

[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Tue May  7 15:46:44 2019
New Revision: 270968

URL: https://gcc.gnu.org/viewcvs?rev=270968&root=gcc&view=rev
Log:
PR libstdc++/89102 fix common_type<> and common_type specializations

This is a partial implementation of the revised std::common_type rules
from P0435R1.

Backport from mainline
2019-02-06  Jonathan Wakely  

PR libstdc++/89102 (partial)
* include/std/type_traits (common_type<>): Define.
(common_type): Derive from common_type.
* testsuite/20_util/common_type/requirements/explicit_instantiation.cc:
Test zero-length template argument list.
* testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc:
Test additional single argument cases.
* testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc:
Adjust expected error.

Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/std/type_traits
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/common_type/requirements/explicit_instantiation.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc

[Bug libstdc++/85965] [8 Regression] G++ gives cryptic error instead of incomplete type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Fixed for 8.4 too.

[Bug libstdc++/90165] std::variant constructs wrong alternative

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed for 8.4 too.

[Bug libstdc++/90165] std::variant constructs wrong alternative

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Tue May  7 15:46:36 2019
New Revision: 270966

URL: https://gcc.gnu.org/viewcvs?rev=270966&root=gcc&view=rev
Log:
PR libstdc++/90165 constrain variant(T&&) constructor

Backport from mainline
2019-04-23  Jonathan Wakely  

PR libstdc++/90165
* include/std/variant (variant::__is_in_place_tag)
(variant::__not_in_place_tag): New helpers for variant(T&&)
constructor constraint.
(variant::variant(T&&)): Use __not_in_place_tag in constraints.
* testsuite/20_util/variant/compile.cc: Check variant(T&&) constructor
isn't used for in_place_type or in_place_index arguments.

Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/std/variant
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/variant/compile.cc

[Bug libstdc++/88740] [7/8 Regression] libstdc++ tests no longer print assertion failure messages

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue May  7 15:46:40 2019
New Revision: 270967

URL: https://gcc.gnu.org/viewcvs?rev=270967&root=gcc&view=rev
Log:
PR libstdc++/88740 Print assertion messages to stderr

Backport from mainline
2019-01-22  Jonathan Wakely  

PR libstdc++/88740
* testsuite/util/testsuite_hooks.h [stderr] (VERIFY): Use fprintf to
write to stderr instead of using printf.

Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/testsuite/util/testsuite_hooks.h

[Bug libstdc++/90105] std::forward_list::sort() is not "stable"

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Also fixed for 8.4 now.

[Bug target/89424] __builtin_vec_ext_v1ti (v, i) results in ICE with variable i (RS6000)

[kelvin at gcc dot gnu.org]

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

--- Comment #2 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Tue May  7 16:22:21 2019
New Revision: 270969

URL: https://gcc.gnu.org/viewcvs?rev=270969&root=gcc&view=rev
Log:
gcc/ChangeLog:

2019-05-07  Kelvin Nilsen  

Backport from mainline.
2019-05-06  Kelvin Nilsen  

PR target/89424
* config/rs6000/rs6000.c (rs6000_expand_vector_extract): Add
handling of V1TImode.

gcc/testsuite/ChangeLog:

2019-05-07  Kelvin Nilsen  

Backport from mainline.
2019-05-06  Kelvin Nilsen  

PR target/89424
* gcc.target/powerpc/pr89424-0.c: New test.
* gcc.target/powerpc/vsx-builtin-13a.c: Define macro PR89424 to
enable testing of newly patched capability.
* gcc.target/powerpc/vsx-builtin-13b.c: Likewise.
* gcc.target/powerpc/vsx-builtin-20a.c: Likewise.
* gcc.target/powerpc/vsx-builtin-20b.c: Likewise.


Added:
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/pr89424-0.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/rs6000/rs6000.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20a.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20b.c

[Bug c++/88857] [7/8 Regression] ICE in build_value_init

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
Author: mpolacek
Date: Tue May  7 16:23:19 2019
New Revision: 270970

URL: https://gcc.gnu.org/viewcvs?rev=270970&root=gcc&view=rev
Log:
PR c++/88857 - ICE with value-initialization of argument in template.
* call.c (convert_like_real): Don't call build_value_init in template.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/initlist-value4.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/call.c

[Bug c++/89214] [7/8 Regression] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
Author: mpolacek
Date: Tue May  7 16:25:26 2019
New Revision: 270971

URL: https://gcc.gnu.org/viewcvs?rev=270971&root=gcc&view=rev
Log:
PR c++/89214 - ICE when initializing aggregates with bases.
* typeck2.c (digest_init_r): Warn about object slicing instead of
crashing.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/aggr-base8.C
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/aggr-base9.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/typeck2.c

[Bug c++/89511] [7/8 Regression] ICE in push_using_decl_1, at cp/name-lookup.c:3845

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
Author: mpolacek
Date: Tue May  7 16:26:38 2019
New Revision: 270972

URL: https://gcc.gnu.org/viewcvs?rev=270972&root=gcc&view=rev
Log:
PR c++/89511 - ICE with using-declaration and unscoped enumerator.
* parser.c (cp_parser_using_declaration): For an unscoped enum
only use its context if it's not a function declaration.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/using-enum-3.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/parser.c

[Bug c++/89705] [7/8 Regression] ICE in convert_like_real, at cp/call.c:7334

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Tue May  7 16:28:11 2019
New Revision: 270973

URL: https://gcc.gnu.org/viewcvs?rev=270973&root=gcc&view=rev
Log:
PR c++/89705 - ICE with reference binding with conversion function.
* call.c (reference_binding): If the result of the conversion function
is a prvalue of non-class type, use the cv-unqualified type.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/rv-conv2.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/call.c

[Bug c++/89876] [8 Regression] ICE in convert_like_real on decltype expression involving string conversion to char*

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Tue May  7 16:29:39 2019
New Revision: 270974

URL: https://gcc.gnu.org/viewcvs?rev=270974&root=gcc&view=rev
Log:
PR c++/89876 - ICE with deprecated conversion.
* call.c (convert_like_real): Only give warnings with tf_warning.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/warn/conv5.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/call.c

[Bug c++/89705] [7/8 Regression] ICE in convert_like_real, at cp/call.c:7334

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
Fixed for 8.4.

[Bug c++/89511] [7/8 Regression] ICE in push_using_decl_1, at cp/name-lookup.c:3845

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #14 from Marek Polacek  ---
Fixed for 8.4.

[Bug c++/89876] [8 Regression] ICE in convert_like_real on decltype expression involving string conversion to char*

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed.

[Bug c++/88857] [7/8 Regression] ICE in build_value_init

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #11 from Marek Polacek  ---
Fixed for 8.4.

[Bug c++/89214] [7/8 Regression] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #14 from Marek Polacek  ---
Fixed for 8.4.

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

[egallager at gcc dot gnu.org]

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

--- Comment #22 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #21)
> (In reply to Eric Gallager from comment #20)
> > (In reply to Dominique d'Humieres from comment #18)
> > > For the record with darwin15 I had to add
> > > 
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/
> > > NSEnumerator.h
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSObject.h
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSValue.h
> > > 
> > > from the 10.9 SDK to
> > > 
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSArray.h
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSString.h
> > > /usr/include/objc/NSObject.h
> > 
> > that seems dangerous
> 
> Not so dangerous as it seems.
> 
> Many (most, in fact) of the failures seen from GCC Objective-C are caused by
> missing support for new features that have been introduced into the vendor's
> headers.  Short list: Apple Blocks, Lightweight Generics, Nullability,
> Syntactic sugar on ID.

Blocks support at least is bug 78352; are there bugs open for the other 3? 

> I'm working on a set of replacement test-suite headers that allow us to
> test the things that _do_ work on GCC Objective-C, and expose any real
> regressions.
> 
> Tests on Darwin13 and earlier show that we are not in such bad shape as the
> header fails make it appear.
> 
> I hope to get these test fixes (there's a set of three PRs related to excess
> fails on Yosemite+) in place soon - and to back port them to the open
> branches.

[Bug tree-optimization/90377] [10 Regression] New -Wstringop-overflow with -O3 since r270852

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Marc Glisse from comment #1)
> What kind of obfuscator did this go through?

Most likely used creduce to reduce the failure.  NOTE sometimes creduce reduced
are reduced into invalid/undefined code.